トーク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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