トーク

AVPlayerでHTTP Live Streamingを再生する際、ネットワーク、暗号化、コーデックなど様々な事が原因でエラーが発生します。しかしこのエラーについては十分なドキュメントがありません。

実際に観察してみるとエラーが起こるタイミングが再生開始時か再生中かによっても内容が変わってきます。しかもエラー発生時にAVPlayerは内部でリトライなどの復帰のための高度な試みを行っているようにさえ見えます。

どんな場合に、どのような挙動になるのか？エラーは検知可能か？そのハンドリング方法は？
これまでAVPlayerを利用してきた中で知った知見を共有しつつ、皆さんとも是非「ここが大変だったよ」「こんなエラーがあったよ」といった内容でワイワイ出来たら嬉しいです。

Gitによるバージョン管理が当たり前となった現在、そのブランチの運用方法は多岐に渡ります。
しかし、代表的なブランチ戦略と言われるGit-flow、GitHub-flow、GitLab-flowはいずれもiOS開発でそのまま運用することは難しいです。
なぜなら、iOSアプリにはAppleによる審査というステップが含まれるためです。
どんなに凝ったフローでもリジェクトによって余計な手間がかかるリスクがあります。

筆者の所属しているプロダクトではそんな審査リジェクトのリスクを踏まえGit-flowを一部改変して運用しています。

本セッションではそんな自社の例を紹介しつつ、参加者の皆様とより良いブランチ戦略についてディスカッションができればと考えています。

iOSのSKStoreReviewControllerを使ったレビュー促進ポップアップには、表示タイミングや回数に制限があります。また、App Store Reviewガイドラインでは「レビューを求めるカスタムのメッセージ画面を表示することはできません」と記載されています。
しかし、それでもカスタムメッセージ画面を表示したいという要望がある方もいらっしゃるでしょう。

本記事では、Firebase In-App Messagingを活用し、カスタムメッセージ画面やポップアップ表示タイミングをリリースなしに変更することができる解決策を提案します。

新しいアプリを作るのってワクワクしますよね。
しかし、使ってもらいたいメインの機能だけを作ったらリリースできるわけではないのがつらいところ。

App Storeの概要やスクショを埋めるのはもちろん、
リリースしているバージョンに致命的な不具合が生じたときのための強制アップデート機能、
使っているライブラリのライセンス表示、
ログイン機能があればアカウント削除機能、
ユーザー生成コンテンツを表示している場合に報告・ブロック機能、
広告を表示する場合のATT、
GDPRや改正電気通信事業法のための対応など...
めちゃくちゃいっぱいありそうです。
軽く絶望しそうですが、新しくアプリを作っている方に絶望してもらいたいわけではなく...

やらなきゃいけないこと、やらなくても良いがメリデメあるものなどに分類して、
必要なものが抜けていないか確認したり、工数を考える助けになれば嬉しいです！

皆さんは SwiftUI を何世代目から使っていますか？
私は初代から利用しており、iOS13 でのみ対応したアプリを作成・ストアに配信したことが良い思い出です。当時は SwiftUI の将来について心配する声も多かったですが、iOS16 までに API は大きく進化し、非推奨になった要素も多くあります。また、UI設計の幅も大幅に広がり、SwiftUI を採用するプロダクトの数も増えています。
このポスターセッションでは、実際のソースコードを使った具体的な比較を行います。
初代から現在までの API の変化や非推奨要素の具体的な例、UI設計の幅の拡大によって可能となった新しい表現方法などを紹介します。さらに、SwiftUI の今後の進化予想についても議論し、参加者同士のコミュニケーションを促す場を提供します。世代関係なく、SwiftUI の歴史と未来を深く理解し、共有する機会となるでしょう

iOSにおける自動テストやそれを取り巻く環境は日々変化しています。
これらの自動テストに関するリリースは１つ１つが独立した話ではなく、それぞれ関係性を持っています。

そこで、ここ５年ぐらいのTestingのリリースや、iOSにおける自動テストに関する環境の変化について年単位でふりかえりながら次のような形でポスターにまとめます。
（１）どのようなAPIがどのタイミングで追加されたのか
（２）そのAPIはどのような活用のされ方をしていったのか
（３）実行環境や実行結果はどのように変化し、活用されるようになってきたのか
（４）これらのリリースに伴って自動テストを取り巻く環境はどのような変化が起きたのか
（５）今後考えられる展望

上述したポスターを元に、iOS自動テストの歴史をふりかえりながら、これらの背景情報をもとに今後どうなっていくのかを一緒に考察できればと思います。

iOSでグリッド状のレイアウトを実装するにはUICollectionViewを使います。コンテンツの配置が柔軟に行えるのが特徴です。

しかし、その柔軟性ゆえに、実装の難易度は高めです。また、iOS 13や14で新しい実装方法が追加されて便利になりましたが、それも簡単とは言えません。雰囲気で使うことはできても、ちゃんと理解しているかは自信が持てない人も多いのではないでしょうか。

そこで、このポスターセッションではUICollectionViewの基本的な考え方を整理してお伝えします。

• UICollectionViewの最小構成
• データソース（UICollectionViewDataSourceやDiffableDataSource）
• セル（CellRegistrationやContentConfiguration）
• レイアウト（Compositional Layout）

SwiftUIでは宣言的UIの特性から、複雑な画面ほどネストが深くなりがちです。
このような場合、コンポーネントをfunction等に分割してもネストの深さからは逃れにくいため、可読性が低下してしまいます。

そこで筆者がExtension Programmingと呼んでいるSwift独特のプログラミング手法をご紹介します。
computed propertiesやfunctions、inner classなどをextensionに分割することで、ネストを浅くできたり役割やアクセシビリティによってグルーピングすることができたりします。

Swift 2.xくらいの頃から存在した手法ではありますが、SwiftUIで開発する機会が増えてきた今その有用性を改めてお伝えできればと思っています。

SwiftUIが登場して以来、システムアーキテクチャの選択肢として注目される「The Composable Archtecture」(TCA)は、Reduxに近い構成となっている点が特徴の1つになります。

初めてTCAのサンプルコード等に触れた際に、過去にUIKitベースのプロジェクトで状態管理フレームワークにReduxを導入した時やSwiftUI＆Reduxを利用した簡易的なサンプル開発時に得た知識や体験が、処理概要を掴んでキャッチアップする際の大きな助けになりました。そして同時に「この様な部分にも配慮が施されているのか！」や「見比べてみるとこの様な特徴があった！」という気付きや学びを得ることもできました。

本セッションでは、ReduxとTCAにおける類似点や相違点に加えて、理解を進めるための前段で知っておきたい勘所等をコードやイメージ図解を交えてご紹介できればと考えております。

皆さんは、モバイルアプリ向けのSAST(Static Application Security Testing)ツールであるmobsfscanをご存知でしょうか？
このツールを使うことで、AndroidやiOS開発において安全でないコードパターンを見つけ、診断結果をSARIF(Static Analysis Results Interchange Format)ファイルとして出力できます。

本セッションでは具体的な設定方法を示しつつ、mobsfscanとGitHub Actionsを活用したDevSecOpsついて紹介します。

• mobsfscanの簡単な使い方
• GitHub Actionsとmobsfscanを使い安全でないコードパターンをSARIFファイルとして出力
• 出力したSARIFファイルをもとにGitHub上のSecurityタブにアラートとして表示

Redux Saga は単方向データフローの Redux を拡張し、非同期処理や副作用を直感的に管理できるようにしたアーキテクチャです。JavaScript で実装され、Web（React）や React Native でよく利用されています。

今回は、その Redux Saga を Swift で実装します。JavaScript と Swift の言語設計と性質の違いを考慮しつつ、Swift の言語特性を活かす形で、Redux Saga の主要な機能を実装したコードについて紹介します。そのコードを見ながら、Redux Saga の特性や利点を理解してもらい、iOS アプリ開発における Redux Saga の可能性を探求し、有用性と将来的な応用について議論したいです。

近年、ユーザデータ保護のためにデバイス上のユーザデータを暗号化した上で保存することが求められるようになりました。しかし、既存の大規模アプリにおいてデバイス上のユーザデータを暗号化するには制約があります。暗号化対応のためにデータにアクセスするアプリ内のコードを全て一気に書き換えることは現実的ではありません。また、暗号化の実装過程で生じるバグによってデバイス上に保存されたユーザのデータが失われることは許されません。
本トークでは、こうした制約下において安全にデバイス上のユーザデータの暗号化を行うために、copy on readやdouble writeポリシーを用いた戦略について、UserDefaultsを暗号化した事例をもとに説明します。
本トークによって、既存の大規模アプリにおいてUserDefaultsのようなデバイス上のユーザデータを安全に暗号化する方法を理解できるようになるでしょう。

iOSアプリを開発する中でユニットテストを書く時に、モックを使う機会は多いのではないでしょうか。
例えばモックを使うことで実際の通信を伴わないテストを書くことができ、テストが実行しやすくなります。
しかしモックすることで実際のプロダクションコードでの動作をテストしていない、保守性が下がるなどの問題もあります。
そのためモックの使い所を見極め、効果的に使う必要があります。

モックの扱いではTDDの文脈でロンドン学派、古典学派という2種類のアプローチがあります。
ロンドン学派はモックを積極的に使い、古典学派ではモックを可能な限り使いません。

この両者の議論を元に、プレゼンテーションロジックが多いなどiOSアプリ開発ならではの要素を考慮した上で、モックの効果的な使い方と使い分けについて品質保証、保守性等複数の観点から検証し、紹介します。
一緒により良いユニットテストのための議論をしましょう!

私は以下の構成で個人アプリを開発しています。

• UIの実装: SwiftUI
• アーキテクチャ: MVVM
• ソース管理: Swift Package

サードパーティ製のフルスタックフレームワークは使わず、SwiftUIを純粋に使ってきれいなコードになるよう心掛けています。
アーキテクチャはAndroidの公式ドキュメントを参考に設計し、可読性やコードを書くときの迷わなさを高めています。
Viewの分割も読みやすい粒度で適切に行っているつもりです。

ただ自分のコードが本当に読みやすいかは、実際に他の人に読んでもらわないとわかりません。
そこで 個人アプリのREADMEとソースコードをできる限り印刷して公開します 。

持てる限りの知見を共有するので、みなさんはぜひゴリゴリにコードレビューしてマサカリをぶん投げてください。
よりよいコードを作り上げ、一緒に成長しましょう。

「Swiftで競技プログラミングに参加できる」というのは、黎明期に比べれば多くの方が知る事実になっているかと思います。
一方で、Swiftを競技用言語として選ぶ参加者は、C++やPythonを始めとする有名な言語のそれと比べれば十分に少数派です。
実際C++やPythonから積極的に乗り換えを推奨できるものでもありません。
ただ、Swiftという「武器」には一部のコンテスタントの心を惹きつけてやまない力があるようです。

このセッションでは、私自身の取り組みから得た経験をもとに、競技用言語としてのSwiftが持つ魅力に迫ります。
具体的には

• そもそもSwiftって"速い"の？
• Swiftが持つ競技上の優位性と弱点
• 競技用言語としての現状と展望

といった話題について、初級者の視点から考察を行います。
普段のiOS開発では見逃しがちなSwiftの側面に、ぜひ触れてみてください！