トーク

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

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

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

「swift-markdown」は、Apple自身が開発を進めているSwiftでMarkdownドキュメントのパース・編集を行うためのライブラリです。

swift-markdownは、Swift言語との親和性が高く、かつGithubで使用可能なMarkdown構文に準拠していることが特徴です。開発が開始されてまだ日が浅いものの、今後、iOSでMarkdownに関連したアプリを開発する上では有力な選択肢となることが期待されます。

本稿では、Markdown機能を組み込みたいとお考えの方へ向けて、他のMarkdown機能実装手法との比較を通じて、swift-markdownの特徴や利用シーンについてご紹介します。

また、簡単なMarkdown構文を題材に、SwiftUIを使用してMarkdown表示を行うことを目標に、サンプルコードを交えてアプリに組み込む方法についてもご紹介します。

DangerはCI/CD環境でコードレビューを機械的に実施してくれるツールで、Danger-Swiftはその名の通りDangerがSwiftで書かれたものです。
レビューの内容をDangerfile.swiftに記述していきますが、当然Swiftで書くことになります。

Swift Concurrencyが出た当初はtop-levelでのawaitがサポートされていませんでしたが、Swift 5.7から書けるようになりました。
つまり、Xcode 14になってからDangerfile.swiftでも正式にasync/awaitが扱えるようになったことになります。

本記事は昨年のパンフレット記事の続編として、Danger-Swift上でGitHub-APIを触るためにasync/awaitを導入する話を書きます。

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

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

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

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

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

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

ARKitは拡張現実の体験を作るためのFrameworkです．
ARKitは普段の業務で使う機会が少なく，学ぶことが退屈に感じるかもしれません．

しかし，ARKitは今後より身近で重要な存在になるかもしれません．
WWDC23においてVision Proと呼ばれる新しいデバイスが登場しました．
このデバイスはARデバイスの側面を持っており，そのデバイスが実行するアプリが実世界を認識しインタラクトできる事は非常に重要です．

そして，そのような体験を生み出すために必要となるのがARKitです．
もし，Vision Proで動作するアプリの開発を行う際にはARKitの知識や経験が活きてきます．

iOS上で動作するARアプリの開発について学びVision Proに備えましょう．
この原稿ではカメラを通して認識した世界に3Dオブジェクトを登場させ，インタラクトするアプリの作り方を説明します．

"開発"という言葉が放つ魔力
その力に魅せられた奴等がいる
人は彼等をデベロッパーと呼ぶ

iOS Developerたちの日常をマンガでコミカルに描きます。

OpenAPI Specification活用してますか？HTTP APIのインターフェース定義で仕様の認識合わせにうってつけ。エコシステムも充実しています。

WWDC23ではSwift特化のGenerator、Swift OpenAPI Generatorが発表されました。Swift Package pluginとして提供されたことでコードの生成から利用を、Xcodeを離れることなくスムーズに行えます。

似たコードを何度も書かずに済むという利点の一方、自動生成ならではのコツも存在します。例えばドキュメント生成のためだけなら気にしなくてよかったspecの書き方があります。また現時点の自動生成は未熟な点もありこのGenerator独自の実装方法を知る必要もあります。

本記事ではそんなSwift OpenAPI Generatorの導入手順や活用のコツを実際のコードを交えてご紹介します。

皆さんはシークレットキーをどのように管理していますか？
GitHub Sponsors を利用することで、一定の第三者にコードを公開する手法が登場するなど、ソースコードの公開スタイルは様々です。ただし、機密情報の管理方法には注意が必要です。契約を結んでいない技術者に機密情報が見える状態は、漏洩や不正アクセスなどのトラブルを引き起こす可能性を高めます。
本稿では、既存のチーム開発スタイルを維持しつつ、機密情報を Git のコミットに含めない開発手法を紹介します。Xcode Cloud への対応はもちろん、KMM（Kotlin Multiplatform Mobile）などの異なる開発スタイルでも有効な方法です。これは特に OSS活動 で力を発揮しますが、業務委託契約など、多様な働き方が進む中でトラブルを未然に防ぐためのノウハウとして活用できます。

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

Apple標準フレームワークでお馴染み「MapKit」ですが、
「ただ地図にピンを立てるだけ」ではなく様々な機能がいくつもあることを、みなさん知っていますか？

実はMapKitには毎年新機能が追加され、年々出来ることも増えて来ています！

• スポット名での検索＆サジェスト
• A地点からB地点への経路探索
• 緯度経度と住所の相互変換（ジオコーディング）
• ピンのカスタマイズやクラスタリング
• 地図上のスポットアイコン（POI）のフィルタリング
• マップ上への図形の描画
• Look Aroundの表示

など、MapKitを使い無料で実現できる様々なカスタマイズや機能を、
実際にプロダクトに導入した経験も踏まえてご紹介します！

アプリの機能開発時やUI実装時、あるいは基盤となり得る部分に手を入れたりする場合には、自前で準備をする選択肢の他にOSSを利用する選択肢も候補に含める場面も数多くあると思います。また、自前でいざ実装を考えていくとなると「結構大変そうに見えて2の足を踏んでしまう」という経験があるかもしれません。

本稿では、少し難しそうなイメージがある部分をDIYする際に、少しでもお役に立てそうなポイントやアプローチをご紹介できればと思います。

【現在考えているトピックス】

※内容は一部変更または調整する可能性があります。

• 奥行きがある立体的なCarousel表現
• メディアアプリ等でもある無限循環型タブを持ち一覧画面を切り替える表現
• 自前でPropertyWrapperで作成するDIコンテナ機構
• 画面上部を引っ張って閉じる処理と画面遷移トランジションの組み合わせ

等々...

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

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

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

iOSでグリッド状やリスト状のレイアウトを実装する際には、UICollectionViewが広く使われています。iOS 13以降ではレイアウトの実装クラスとしてCompositional Layoutが標準で用意され、複雑なレイアウトが組みやすくなりました。

しかし実際のところ、どのようなレイアウトが組めるのでしょうか。この記事では、具体的なレイアウトの実例を紹介していきます。

・レイアウトを構成するセクション、グループ、アイテムについての説明
・グループの使い方、グループのネスト
・セクションヘッダーの実装
・アイテムバッジの実装

じっくり読んで理解していただくために、レイアウトの図解や具体的なコードを掲載する予定です。

アプリ開発で日付を表示する場面は多くあります。DateFormatterはDate型のデータを任意のフォーマットでString型に変換することができます。
しかし、DateFormatterはインスタンス生成コストが高く、アプリのパフォーマンスを低下させてしまうことがあります。

この問題を防ぐには、DateFormatterをキャッシュして不要な生成コストを抑えるのが効果的です。

本記事では、DateFormatterのキャッシュによるパフォーマンス改善案についてコードを元に解説します。その上で、パフォーマンスを比較し、キャッシュによる違いを整理します。併せて、iOS15から追加されたformattedを使った場合、前述の実装とどう異なるかを比較します。そして、パフォーマンスに悪影響を与えることなくアプリ内で日付を表示するには、どのような実装が最適であるかを提案します。

Redux Saga は単方向データフローの Redux を拡張し、非同期処理や副作用を直感的に管理できるようにしたアーキテクチャです。JavaScript で実装され、Web（React）や React Native でよく利用されています。同じ宣言的 UI の SwiftUI との相性が期待できます。しかし、残念なことに Swift で Redux Saga を実装したライブラリはありません。

無いのであれば、自身で作成するしかありません。JavaScript と Swift の言語設計と性質の違いを考慮しつつ、Swift の言語特性を活かす形で、Redux Saga の主要な機能をどのように実装するかを解説します。Redux Saga の特性や利点を紹介して、iOS アプリ開発における Redux Saga の可能性を探求します。

弊社「株式アンドパッド」では、「幸せを築く人を、幸せに。」をミッションに建設DXに取り組んでいます。
この超巨大な建設業界というドメインに対し、弊社では１つの巨大アプリ（スーパーアプリ）ではなく、複数のアプリを提供する「マルチアプリ戦略」という手段を用いて課題解決に取り組んできました。
現在「施工管理」「図面」など10個近くのiOSアプリを運用しています（Flutter製も含む）。

そこから見えてきたマルチアプリ戦略の良かったこと・課題に感じていること・うまく解決できたこと、などを記事にまとめます。具体的には、

• 「社内ライブラリ」の運用の難しさ
• ユーザ体験の一体感
• アプリ間でのiOSエンジニアの知見共有の取り組み
• 「アプリ横断チーム」の是非

などになります。
iOS開発の「詳細」というよりは、「アーキテクト」だとか「組織論」的な話も幾分含むことになります。

アプリ開発の中で、画面要素と内部ロジックとを結合する処理等でCombineを利用する場合もあると思います。Combine+SwiftUI（場合によってはUIKit）の組み合わせをより強力に生かしていく際には、仕様把握・機能担保の観点でのUnitTestは大きな意義を持つと考えております。

本稿では、

1. Model - ViewModel - View構成でCombineを活用する際の基本事例
2. @Published や PassthroughSubject を利用した処理で画面要素と内部ロジック間を結合する処理のポイント
3. 値変化を基準としたCombineベースの処理におけるUnitTestへの工夫

等のトピックをRxSwiftを利用した場合と見比べた事例や、CombineでのUnitTestを実施する際に便利なOSSを活用した事例も交えてながら解説できればと思います。

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

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

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

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