トーク

「ファミコンエミュレータを作る」と聞いて何を思い浮かべますか？
多くの方は何をどうしたら良いのか全く想像が付かないと思いますし、私もそうでした。

2016年2月にPHPで書かれたゲームボーイエミュレータ php-terminal-gameboy-emulator が話題になりました。このとき、PHPならばということでコードを読んでみました。エミュレータのコードを読んだのは初めての経験だったのですが、大きな衝撃を受けました。私は以前からこの頃のゲーム機に共通する仕様や、CPUやメモリについての知識は持っていたのですが、php-terminal-gameboy-emulator のコードにはそんな仕様がそのままPHPのコードとして表現されていたのです！

そしてその2年後、あるカンファレンスでファミコンエミュレータに関するトークを聞いた時に、2度目の衝撃が私を襲いました。そこで紹介されたコードは初めて見るにもかかわらず、断片を見るだけで内容が理解できたのです。

このトークでは2度目の衝撃を受けて私がPHPで書いたファミコンエミュレータ php-terminal-nes-emulator を題材に、エミュレータのコードの特長や設計、そしてその魅力をお伝えします。

CPUの動作（メモリアクセス, I/O, …）
エミュレータでの実装
ハードウェア仕様のソフトウェアとしての表現
エミュレータは決して難しいものではなく新しい言語の学習や設計の練習にちょうどよいテーマでもあります。このトークを聞けばきっと一度エミュレータを書いてみたくなるでしょう。

昨今やっとマイナンバーカードが普及してきており、マイナンバーカードを読み取って本人確認を行ったり、確定申告の電子申告を行ったりするサービスが増えてきました。
今後も(政府が頑張れば)マイナンバーカードは色んな情報を取得するのに使われていくでしょう。

今回では実際にマイナンバーカードの読み取りをプロダクトに組み込んだときの話を織り交ぜながら、マイナンバーカード読み取り機能の実装方法を紹介していきます。

[Target]
・今後マイナンバーカード読み取り機能を開発予定の方
・マイナンバーカードの読み取り方法について興味がある方
・マイナンバーカード読み取り機能をプロダクトに入れたときの苦労話を聞きたい方

[Goal]
・マイナンバーカード読み取り機能を実装する際に障壁無く実装出来るようになっている
・マイナンバーカード読み取りをプロダクトに導入するには何が必要なのか知っている状態

WWDC21の発表にあったように、iOS15でURLSessionのHTTP/3対応が実装されました。
あれからもうすぐ1年経ちますが、2022年6月7日現在HTTP/3対応はデベロッパオプションとして提供されている段階で、大半のiOSデバイスにおいて有効化されてはいません。
しかし、通信のパフォーマンスとセキュリティがより重要になってきていることを考えると、全てのデバイスでHTTP/3のサポートが有効になる日はそう遠くないかと思います。

このトークでは、「そもそもHTTP/3って何？QUICとどう違うの？」「どういう状況でメリットがあるの？」などの疑問にお答えしつつ、運用しているサービスの大半のWebAPIを事前にHTTP/3に対応させた事例から、HTTP/3対応の際に考慮すべき事項や、対応リリース後のモニタリングの想定など、来るべき日に備えた準備の知見をお話しします。

みなさん、AirPlay使いこなしていますか？
AirPlayはAppleのデバイスから映像や音楽をApple TVや対応スマートテレビ・スピーカーで再生できる機能です。発表当初から複雑な設定なしで直感的に使えるようにAppleらしい設計が行われ、ユーザーにその裏側で何が起きているのかを意識させることがほとんどないようにデザインされています。2018年にAirPlay 2が発表されて以降は対応デバイスも増え、またSiri連携や接続先デバイスの学習によりますます使いやすくなって来ました。
本トークではAirPlayで可能になる体験やアプリへの組み込み方法、他のキャスト技術との比較といった内容の他、その仕組みの裏でどんな通信が行われているのか？まで踏み込んでお話しできればと思います。

ソフトウェア開発において、チームのパフォーマンス改善は皆さんが継続的に取り組んでいる課題の１つだと思います。

チームのパフォーマンスを定量的に評価する代表的な指標として、GoogleのDORAという研究チームが確立したFour Keysがあり、これらの指標を使ってチームをそのパフォーマンスに応じてエリート、高、中、低に分類することができます。

iOSのチーム開発においても、デリバリーフローやオブザーバビリティを改善していくことでエリートチームを目指すことができます。

このトークでは、まずFour Keysとその定義を紹介し、計測方法について整理します。次に、iOSアプリ開発におけるボトルネックと、Four Keysに取り組む上での難しさについて解説します。また、私達のチームでの具体的な取り組みを紹介し、みなさんのプロジェクトでも明日からエリートチームを目指せるようにしたいと思います。

Swift向けのコードテンプレートを作成できるStencilを知っていますか？
実はSwiftGen, Kitura, Sourceryといった著名なOSSでも使用されている面白い言語です。

用意されたコマンドを用いることで、OSSでは簡単にコードを生成することができますが、自分でカスタマイズすることも可能です。
このセッションでは、どのようにしてStencilを使っているのか紐解いていきます。
また、Xcode templateやSnippetといった既存の言語テンプレートとの比較も交えて、どのように使っていくのかをご紹介していきます。

参考文献
Stencil: https://github.com/stencilproject/Stencil
StencilSwiftKit: https://github.com/SwiftGen/StencilSwiftKit

ネイティブではもう無理だと 諦めていたのにどうしたの？

あの頃 僕達はさ 何でもできる気がしてた
2軸で表を描いては たくさん点を打ったね

でも見てよ今の僕を クズになった僕を
Chart.jsをWebViewで見せても 何も感じ取れなくてさ

別にChartを求めてないけど 急に出されると思い出す
ラインチャート（折れ線グラフ）&バーチャート（棒グラフ）の そのグーラフのせいだよ

このトークでは、WWDC22で発表されたSwift Chartsフレームワークについて話します。
まだ発表直後でベータ版ですが、できる限り様々なチャートを触り、見た目や使い方などを紹介します。

Firebaseには、NoSQL DBのCloud Firestoreやバックエンドコードを実行可能なCloud Functionsといった機能を備えており、インフラのことをほぼ意識せずとも、サーバーレスなアプリを立ち上げられる他、クライアントに提供されているSDKを利用し、クライアント間でのデータ同期や、オフラインデータの永続性といったアプリの体験に寄り添った機能を享受できます。

一方、DBはスキーマレスであることや、クライアントから直接DBにアクセスするなど、馴染みがない仕組みも多く、仕様や特徴を踏まえた開発を行わないと、セキュリティやユーザー体験に悪影響を及ぼしたり、負債となる要因になり得ます。
本セッションでは、クライアントエンジニアのみのチームでサーバーレス開発を行う中で見えてきた、効果的にFirebaseを利用する方法を事例と合わせて紹介します。

CombineはiOS13から登場した時間変化による値の変化を処理するための宣言的なAPIを提供するフレームワークです。

今秋にはiOS16が登場し、iOS14以上をサポートできるアプリも多くなった昨今。
Combineは新しい技術ではなく、当たり前の技術となりました。

一方コミュニティを見回すと、当たり前のようにCombineを使いこなす層とまだまだCombineの勘所を得ることができない層との間に断絶があるように感じます。

SwiftUIとも密接な関係があり、せっかくのApple標準のフレームワークであるCombineを覚えないのはもったいない！
ということで、興味がある方みんながCombineに入門できるようなトークをしたいと思います。

本トークでは概念を頭で理解するというより、ちょっとずつステップを踏むことで「手を動かしていったら自然に理解が進んだ」を目指します。

近年、SRE（Site Reliability Engineering）の手法をアプリケーションにまで拡大しようといった動きが盛んです。

しかし、実際にモバイルアプリの可観測性≒オブザーバビリティを向上させるためには、ネイティブエンジニアの専門性が求められる場面が多く、あまり実際に効果のあった事例が共有されていないように感じます。

このトークでは

• アプリ内で計測される指標を用いてSLI / SLOを構成する
• アプリ内でのレスポンスのパースエラー検知
• 問い合わせ調査のオブザーバビリティ向上
• 外部SNSの認証サービスの障害検知
• App Store Connect API 、MeticKitの活用

といった実際にチームで効果のあったプラクティスを紹介したいと思います。

iPhoneが登場して以降、QRコードを読むという行為はありふれた行為となりました。

iOSにおいては

• 古くからカメラからのインプットを扱えるAVFoundationを用いて
• 新しくは画像解析フレームワークであるVisionを用いて
  QRコードを読むという機能は比較的簡単に実現できます。

しかし、QRコードを読み込むシーンというのはアプリによって様々です。

例えば

• １つのQRコードをしっかり読み込みたい
• リッチな表現でQRコードを読み込みたい
• 夜や倉庫の中といった暗い場所でもQRコードを読み込みたい
• 連続で複数のQRコードを読み込みたい
  などなど。

本セッションではシーンに応じてQRコードを気持ちよく読み取るためにした工夫をお話します。
頻繁に使う機能だからこそ体験の良いQRコード読み込みを実現していきましょう！

Appleが提供している中で最もバックグラウンドタスクが重要なプラットフォーム、それがwatchOSです。
操作は両腕を上げる必要があるので短時間で済ませたいですし、ワークアウトのような長時間のタスクはそもそも待っていられません。

そんなwatchOSのバックグラウンドタスクは2016年に開発者へ解禁されて早6年、日々進歩してきました。
watchOS 9でも新しい機能が追加されるようで、更なる進化が期待できます。

本セッションでは以下のテーマについてお話しすることで、今のwatchOSアプリでどこまで出来るのかを理解する手助けになればと思います。

• バックグラウンドでできること、できないこと
• 端末の世代やバッテリー残量などの環境によって受ける影響
• どのようにバックグラウンドタスクを設計すべきか
• watchOS 9から追加される新機能

SwiftUIは細かく指定しない限り簡潔にレイアウトを記述できることも多い一方で、
Auto Layoutでは簡単にできていたことが意外と難しかったり、そもそも実現が困難なケースもあります。

このトークでは、VStackやHStackで単にleadingやtopなどを指定するだけでは
実現が難しいレイアウトを攻略するために有効なAlignment Guideについて、次のステップで学ぶことができます。

1. Alignmentの概念および挙動についての基礎
2. alignmentGuide(_:computeValue:)の理解と利用方法
3. Custom Alignmentの実践的な使い方と制約

想定する対象者

• SwiftUIをなんとなく書けるようになってきた人
• alignmentGuideやCustom Alignmentを使ったことがないor使い方がよくわからない人

ディープリンクは、ブラウザや他のアプリからターゲットとなるアプリへのシームレスな遷移のために重要な技術ですが、まとまった情報が意外なほどありません。
iOS / Androidのアプリをディープリンクに対応させるときに悩んだことと、それにどう対処したかについてお話しします。

• ディープリンクを使ってどういったことができるか
• ディープリンクをiOS/Androidで実装するための技術の紹介（Custom URL scheme / Universal Links / App links）と、それらの違い
• 実際にアプリに活用する際にどういうリンク設計にすべきか？その際の考慮点

アプリのCIサービスとしてBitriseはそれなりに定着してきてますが、アップル自身もXcode Cloudをベータリリースしており、そして今年正式リリースされると予想されます本日のWWDCで正式リリースしました。

ちょうどBitriseが料金体系を改訂して従量課金しかなくなったからトライ＆エラーのコストが高くなるからメリットが非常に薄くなるし、何よりアップル本家が作っているという安心感（？）。

というわけで、これまでBitriseで回してたプロジェクトを、試しにXcode Cloudに移行してみたので、その過程をみなさんと共有したいです！

Storyboard辛い！Auto Layout難しい！でもSwiftUIのおかげでこれらとおさらばだ！！

そんな甘い思い、私にもありました…まさに若さゆえの過ち…

そう、SwiftUIがリリースして3年経った今でも、まだ我々はレイアウトのナイトメアから解放されていません…

この発表は、そのSwiftUIにまつわってよくある落とし穴やぶつかりやすい壁を紹介し、それらの理由と正しい回避策をお伝えしたいと思います！

チーム開発を経験されてるあなた、「静的チェック」は聞いたことあるでしょうか？そう、CIを回す時に、Lintを適用するとか、スペル確認を行うとか、そう言った機械的なチェックを行うことです。

そしてある程度の経験がある方でしたら、DangerというRuby制のツールを聞いたことある、あるいは今でも使っている方もいらっしゃるではないでしょうか。

実はそのDanger、本来はRubyでスクリプトを書かないといけないですが、Swiftでスクリプトを書くDanger-Swiftも存在しているんですよ！

この発表はSwift信者として、そのDanger-Swiftの良さを全力で伝えたいと思います！

みなさん、証明書管理やデプロイなど何使ってます？やはりFastlane？ですよねーFastlane便利ですもんね

でもFastlaneはRubyで書かないといけないからそこ大変ですよね、Rubyは型が保証されないから使うときドキドキするし、初心者がそもそもRubyの導入で躓きやすいので。

というわけでSwiftlaneを使ってみてはいかが？我々iOSエンジニアが使い慣れてるSwiftで書けるからとっても書きやすいですよ！はいこの発表はSwiftlaneの布教です！

Carthageでビルドしたframeworkを共有キャッシュとしてS3などで管理できるツールのRomeがついにXCFrameworkにも対応しました。
Swift Package Manager対応のライブラリも増えてきていますが、まだまだCarthageを利用されている方もいると思います。

今回はRomeに関する以下の内容について、具体的な設定ファイル、スクリプトコードを用いて説明します。

・共有キャッシュの導入することでビルド時間をどれだけ短縮できるか
・XCFrameworkを共有キャッシュとして、S3およびローカルドライブで管理する方法
・（現状のリリース版に残っている）Romeのバグに遭遇した際の対応方法

iOSアプリ開発の周辺技術としてRubyは非常に人気な言語です。パッケージ管理のCocoaPods、静的検査のDanger、そしてCI/CDスクリプトのfastlaneなどなど、Rubyは幅広く使われています。

しかし初心者にとってRubyも一つの鬼門なのです。たとえば誰でもPermission Denied問題に一度は会ったことあるでしょう。右も左も分からない初心者がネットで検索するとすぐ「sudoすれば上手くいくよ」と悪魔の囁きを目にします。怖いですね。

というわけでRubyを開発過程から排除できないか？誰でも簡単にできるより安全な環境構築の仕方ないか？この発表はその脱Rubyの仕方をお伝えします。