トーク

皆さん、Swift 6.0のリリースに向けた対応は順調ですか？
年数が経ち肥大化していったプロジェクトや、開発速度の要求が高いプロジェクトほど、対応が難しい課題だと思います。

私たちのプロジェクトであるタップルは、3000以上のファイルと24万行以上のコードからなる11年目の大規模サービスです。
完全に対応が完了したわけではありませんが、日々の対応を進めることで、Strict Concurrency Checkingを

• 新規の機能に関してはほぼ100%
• 既存の機能に関しても約半数

まで前進させることができました。

本トークでは、大規模なコードベースでどのように段階的に取り組んでいくかについて以下の事例をお話しします。

• Fluxベースの旧アーキテクチャからSwift Concurrencyベースの新アーキテクチャへの段階的移行の方法
• Module単位での段階的なStrict Concurrency Checking対応の事例とロードマップ

また、下記の組織としての取り組み方についても触れ、皆さんのプロジェクトでどのように推進していけば良いかについての知見を提供します。

• チームでのSwift Concurrencyの知識の学習方法
• 移行時の組織とのコミュニケーション
  • どのように工数を確保するか
  • どのように便益を説明するか

みなさんは iOS 6時代のデザインをご存知ですか？ーーあるいは、覚えていますか？
最も特徴的だったのは、光沢のある美しいガラス箱のようなアプリアイコンではないでしょうか。
しかし、iOS 7を境にフラットデザインへと移行し、アイコンを含むあらゆる外観が一新されました。
それでも、「過度に単純化」される前のデザインは、今なお忘れがたい輝きを放っています。

本セッションでは、iOS 6が主流だった2012年版と現行の2024年版のHuman Interface Guideline (HIG) を比較し、デザイン思想の違いについて探ります。
美的完成度に一貫性、数々のコントロールーー
スキューモーフィズムに彩られたデザインがどのように生まれ、今どう変化したのかをHIGや関連資料を用いて辿っていきます。

といっても、デザイン哲学を40分で説明するのは無謀ですから、今回のトークはiOSインターフェースデザインの本質に少し近づく程度になるでしょう。
とはいえ、現代の「フラットなデザイン」の価値を再認識し、未来のデザインの方向性を見据える機会になりうると信じています。

今とは異なる美学と思想を持つリッチなデザインは、すでに過去のものであるとは言え、iOSの進歩の過程で生まれたかけがえのないものです。
過去や現在のiOSデザインに少しでも興味がありましたら、ぜひ本トークにお越しください。

開発には失敗がつきものです。突然障害が発生したり、施策がうまくいかなかったりします。
そこで同じ過ちを繰り返さないように、失敗を振り返ってまとめることが重要です。
しかし、以下のような問題に直面したことはないでしょうか？

• 例：過去事例のレポートを読んでも、しっかりと理解できない
  • 「何が起きたのかはおおよそわかるけれど……。原因は本当にこれだけ……？」
• 例：自分もレポートを書こうとして根本対策を考えてみるが、ピンとこない
  • 「再発防止策はこれで十分だろうか……？もっと他にあるのでは……？」

失敗の振り返りが重要だとわかっていても、失敗を伝えることも理解することも難しいと感じることが多くあります。

本セッションでは、「失敗学」について紹介し、実際のプロジェクトで経験した事例を題材に「失敗の伝達に必要な記述」についても具体例を交えながら解説します。

トピック

• 失敗学とは
• 失敗情報は孤立しがち
• 失敗は知識にしなければ伝わらない
  • 「失敗の伝達に必要な記述」

本セッションの想定対象

• モバイルアプリの開発・運用に携わっている方
• 失敗の振り返りの質を高めたいと思う方
• 製品や現場を少しでも良くしたいと思っている方

参考図書

• 畑村 洋太郎. 技術の創造と設計. 岩波書店, 2006.

皆さんはバリデーション付き入力フォームを50個実装しないといけなくなった場合どのようにコードを設計しますか？

これに限らず広範囲のコードの設計を行う際

• 人によって実装にばらつきがない
• テストが書きやすい
• 読みやすい
  といったことを目標にすると思います。

しかし最初から理想の形を目指すのは至難の業です。
理想を追い求めすぎて過剰設計になったり、流行りのアーキテクチャを試したもののうまくマッチしなかったり…

このトークでは実際にあった大量のバリデーション付きフォーム画面を題材にスケールする設計の考え方を紹介します。

まずは「良いコードを書こう」と考えず愚直に動くコードを実装します。
そこから気になる部分を見つけて改善するステップを繰り返していきます。
改善の際にはコードの良し悪しだけでなくチームの状況やプロジェクトの要件も加味していきます。

各ステップごとにコードの Before / After を提示するので「何をしたことでどんな効果があったか」がわかります。
コードが洗礼されていく過程を一緒に体験できるので設計を行う考え方を学べます。

コードの量は多めですがライブラリは使いませんので初学者の方でも楽しめる内容です。
Swift の新機能の PropertyWrapper や ResultBuilder をフルに使うので Swift のおさらいにもなります。

コンピューター上で3次元のオブジェクトを回転させるとき、3次元回転操作のコンパクトな表現としてクォータニオンがよく使われます。

クォータニオン（四元数）は19世紀に生まれた概念です。数学者ハミルトンが、3次元回転を表現するために複素数を拡張してクォータニオンを考案しました。数学では3次元回転の表現としてベクトルや行列がよく使われるため、クォータニオンはさほど注目されてきませんでした。しかし、コンピューターの3次元グラフィックスの発展により再評価されるようになりました。クォータニオンを使うと、行列よりもメモリ効率が良く計算も高速になるためです。

iOSのAccelerateフレームワークには、クォータニオンを扱えるsimdモジュールがあります。simdを活用すると、iOSアプリで3次元オブジェクトの計算がしやすくなります。また、クォータニオンは回転の軌跡を補間する際にも有用です。これによって、滑らかな回転アニメーションが実現できます。

このトークでは、まずクォータニオンを基本から解説して、simdモジュールを使ったクォータニオンの使い方を述べます。そして、3次元オブジェクトを回転させ、SceneKitで実際に描画するコードを紹介します。3次元グラフィックスの基礎を知りたいiOSアプリ開発者におすすめのトークです。

皆さん、Apple Silicon使っていますか？
ビルド時間の短縮によってその強力な性能を開発現場で実感している方も多いと思います。

このApple Siliconですが、実はCPUとGPU以外にも様々な機能があることを知っていますか？
例えば代表的な例として機械学習を高速化するNeural Engineが挙げられます。
実はその他にもVideo EncoderやML Acceleratorなど一部の処理を高速化するハードウェアが搭載されています。

またiPhoneに搭載されたAシリーズから始まり、近年Macに搭載されたことで全AppleプラットフォームでApple Siliconが搭載されています。
これによりMacを含めてWatchやTV、Vision ProでもiPhoneと同じアプローチで高速化することが可能になりました。
このトークではApple Siliconに搭載されている特殊エンジンの概要と、それらを効果的に利用するためのテクニックについて解説します。

• Apple Siliconの各種専用エンジンの基本的な概要とその機能
• 高速化を担当するフレームワークの概要
• 実際にどれほど高速化されるのか
• 高速化以外でのパフォーマンスへの影響
• プラットフォームごとの違いとその影響

「レガシーコードとはテストのないコードである」という言葉があります。
iOSアプリの開発において、ユーザに長く使われる持続可能なアプリを作るためにユニットテストは欠かせません。
多くの開発者がXCTestを利用していますが、Objective-Cランタイムへの依存やSwiftで利用できないAPI、Swift Concurrencyとの統合の難しさなど、複数の課題があります。

そこで注目したいのが、Appleが新たに公開したユニットテスト用ライブラリであるswift-testingです。
swift-testingは現代的な設計を取り入れ、Objective-Cランタイムの依存を最小限に抑え、Swift Concurrencyとのシームレスな統合を可能にしています。
これにより、効率的なテストの検出や実行、パラメータ付きのテストや高度なテストケースのサポートが実現されます。

このトークでは、まずXCTestの歴史とその限界について触れ、続いてswift-testingの特徴と利点を詳しく解説します。
さらに、swift-testingがiOSアプリ開発に与える影響や、具体的な導入方法、そして私達の開発プロセスにどのような変化をもたらすのかを探ります。
このトークを通じて、次世代のユニットテストの在り方を理解し、より良いテスト戦略を構築するための知識を提供します。

StoreKit2はiOS 15から導入された新しいアプリ内課金フレームワークで、より安全で効率的な課金実装が可能になります。2024年2月より、ABEMAではこれまでの「ABEMAプレミアム」に加えて、新たな課金商品の提供を開始し、同時にStoreKit2を用いた課金システムの全面的なリニューアルを実施しました。このセッションでは、新たな商品の検討からリニューアルの設計、実装、テストに至る全フローを詳細に解説します。

1. ABEMAの既存の課金体系と商品追加によるユーザー体験への影響
2. 課金システムのリニューアルに至る背景とその過程
3. StoreKit2を使った具体的な設計・実装の詳細
4. 新しいオファーの種類とユーザーの課金行動に与える影響の分析
5. 課金システムへの変更点とアプリパフォーマンスへの影響
6. リニューアル後のリリースフローと新商品の詳細

アプリ内課金はユーザー体験とビジネスに非常に重要ですが、その実装は複雑でエラー対策も多岐にわたります。このセッションでは、StoreKit2を用いて効率的にこれらの課題を解決する具体的な方法を示します。皆様のアプリ開発に役立つ情報提供を目指します。

みなさんのチームではどのようにアプリを配布・リリースしていますか？
便利なCI/CDサービスの恩恵に預かる、自前で環境を構築する、Xcode Cloudを利用するなど様々かと思います。

いずれの場合でも普段のiOSアプリ開発とは異なる知識・経験・技術が必要となるためこの領域は属人化しやすく、多くの方がメンテナンスに苦労した経験を持っていることでしょう。
これがもし、iOSアプリ開発と同じ感覚でCI/CD環境を構築することができたならどうでしょうか？

弊社ではアプリの配布・リリース自動化のほとんどをSwiftで実装しており、アプリの定期配布、デザイナー向けテスト配布、リリースノートの作成からアプリ申請までのほとんどの作業が自動化されています。

本トークではSwiftを使ってCI/CD環境を構築する方法と導入・運用する際に得た多くの知見についてお話しいたします。特にCD環境の構築に焦点を当て、自動化の面白さとSwiftを最大限活用する方法を余すことなくお伝えします。

話すこと
・App Store Connect APIの基本機能と進化の歴史
・App Store Connect APIの認証プロセス、エラーハンドリングとSwiftでの実装例
・セキュアなCDパイプラインの設計と構築方法 ~GitHub Actionsを添えて
・具体的な導入事例、運用方法、その効果と実績

近年のハイエンドiOSデバイスにはLiDARセンサーが搭載され、APIを通じて点群データを取得可能になりました。またiOS 17で追加されたObject Capture APIによりLiDAR搭載デバイスで3D物体のスキャンが可能になりましたが、その中身の処理はブラックボックスです。

本セッションでは、回転やサンプリングといった点群データの基礎から始めて、別々の視点から撮影された2つの点群データを「位置合わせ」する方法を解説します。またこれらの処理をiOSで行うための実装方法についても解説します。

このセッションを通じて、Object Captureの3Dスキャンのような処理がブラックボックスではなく、どのように動作しているのかを理解できるでしょう。Object Captureは高レベルのAPIのみ公開されておりあまりカスタマイズ性に乏しいですが、本セッションの内容を学ぶことで、自前の3Dモデル生成機能を実装するための基礎を身に付けることができます。

Apple Vision Proには、2D動画を再生するとその場面に応じて現実空間に対して演出効果が表示されるという、
とても面白い機能を持つアプリがあります。

例えば、突然飛行機が上空を通り過ぎたり、周辺がヨーロッパの街並みに変わったり、たくさんの風船が表示されたり。

グラス型端末の没入感と相まって、これまでとは一線を画した斬新な体験です。

この面白い機能はどうやって実装するのでしょう。
何がきっかけで演出が始まるのでしょうか？
演出はどう作るのでしょうか？
動画のスキップ、一時停止には対応しているのでしょうか？

これらの疑問に答えるため、このセッションでは、Swiftネイティブの環境でその機能をいくつか実装していきます。
作業手順を説明しソースコードを解説し、ライブデモを行います。

具体的には以下の内容をカバーします：

• HLS動画へのmeta data埋め込み
• OSCによる外部からの制御
• 演出開始、任意発火、発火制御ボタンの実装と作法
• 周辺を変える演出、戻る演出
• Particleによる演出

このセッションを通じて、参加者は実際にvisionOSでの空間演出を実装するための具体的な手法を学び、自分で独自の体験を作り上げるスキルを身につけることができます。
visionOSの可能性を知り、今後も体験が進化していくワクワクを届けたいと思います。

iOSアプリアーキテクチャはさまざま存在しますが、多くはUIKit時代に誕生したものです。これらをSwiftUIで採用すると、SwiftUIの特色である状態管理やEnvironmentの仕組みをフルに活用できず、使い心地の良い設計になかなかなりません。

また、SwiftUIは毎年の変化が激しく、新しいUIコンポーネントはもちろん、ConcurrencyやObservabilityといった新しい言語仕様、ウィジェットやApp Intentsなどの新しい活用場面が登場してきました。これらの変化に対応できる柔軟な設計でないと、新機能の採用に難航してしまうでしょう。

せっかくSwiftUIを使うなら、純正の機能をなるべく活用したいものです。実際の案件や個人アプリの開発経験を元に、SwiftUIの使いやすさを最優先にする設計とは何かを探求します。

本トークでは、以下の点に焦点を当てます。

• SwiftUIの案件で従来のアーキテクチャを採用して課題と感じたこと
• Environmentを使った依存解決
• 状態とアクションの分離
• プレビューやモックのためのビュー・プロパティラッパーの抽象化
• SwiftPMを使ったマルチモジュール化

アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「REALITY」では、デザインの一貫性や生産性を向上するためにデザインシステムを導入しています。
デザインシステムを構築するには、タイポグラフィ、カラー、UIコンポーネントなど多くの要素が必要であり、既存のプロダクトに取り入れるのは非常に労力がかかります。
このトークでは、機能開発の傍らでデザインシステムを段階的に導入していった経験と、2年間にわたり続けた結果どのような効果が得られたか、「REALITY」のiOSアプリにおける実例を元に紹介します。

• アプリにデザインシステムを少しずつ導入していくステップ
• デザインシステムによって、アプリ全体のカラーテーマの調整が容易になったこと
• FigmaからXcodeへ画像アセットを自動エクスポートすることで効率化したこと
• Figmaを使ったUIコンポーネントの管理と、SwiftUI/UIKitでの実装

非同期処理は、プログラミングにおける難題の一つとしてよく挙げられます。これはiOSアプリ開発においても同様です。黎明期から非同期処理は存在し、また開発者の頭を悩ませ続けてきました。

本トークでは、iOS開発における非同期処理のこれまでの歴史と進化について紐解きます。非同期処理のパラダイムがどのように進化してきたかを知ることで、最新のSwift ConcurrencyによるAPIが過去の課題をどのように解決しているかを深く理解することができるでしょう。

まず、非同期処理の基本概念とその重要性を簡単に紹介します。次に、iOS開発における非同期処理の歴史を振り返り、Grand Central Dispatch、操作キュー、Promiseなどの主要な技術の導入と進化を時系列で説明します。その後、現在主流となっているSwift Concurrencyに焦点を当て、その特徴と利点を過去の技術と比較しながら解説します。

このトークを通じて初学者や中級者の方が様々な非同期処理のパラダイムに触れる機会を作り、新鮮な視点でSwift Concurrencyに向き合うきっかけを提供します。

Swift5.9ではSwift Macrosが導入され、マクロによるコード生成が可能になりました。

また、マクロの実装時に用いるSwiftSyntaxは、それ単体でコード生成の仕組みを提供しており、Build Tool Pluginと組み合わせればビルド毎にマクロよりも自由度の高いコード生成を行うことも可能です。

私が開発したSword (https://github.com/rockname/sword) というDIコンテナのライブラリでは、この両者のコード生成の仕組みを併用しています。

本トークではSwordの開発から得られた知見をもとに、Swift MacrosおよびSwiftSyntaxにおけるコード生成にはそれぞれどのような特徴があるのか具体的なコードを交えながら説明し、それぞれが活きる利用パターンについて体系的にお話しします。

本トークを通じて聴講者のみなさまが、コード生成によりどのような課題を解決できるのかより鮮明にイメージできるようになり、プロダクトやライブラリの開発へすぐに活かすことができるようになることを目指します。

Dependency Injection（DI）とは、オブジェクトに必要な依存関係を外から注入する設計パターンです。オブジェクト間の依存を疎に保つことで、コードを再利用しやすくなり、保守性を高めることができます。

Androidアプリ開発ではDagger(Hilt)というDIライブラリの使用が推奨されていますが、iOSアプリ開発においてはまだまだデファクトスタンダードと呼べるDIライブラリは存在しません。

そこで私はSword (https://github.com/rockname/sword) というDaggerライクなiOS向けのDIライブラリを開発し、Swift Macros等の言語機能を活用したコード生成による静的なDIのアプローチを探求しました。

本トークでは、そもそもDIとはどのような設計パターンであるかを説明しつつ、Androidアプリ開発におけるDaggerによるDIのアプローチについて具体的に紹介します。その上でiOSアプリ開発においてはどのようなDIのアプローチが考えられるのか、Swordの開発から得られた知見をもとにお話しします。

本トークを通じて、iOSアプリ開発における最適なDIのアプローチについてみなさんの考えるきっかけやヒント、あるいは答えを提供できれば幸いです。

ZOZOでは、ショップスタッフ向けの販売サポートアプリ「FAANS」を開発しています。FAANSアプリを利用することで、スタッフはコーディネートを投稿し、その閲覧数や売上などの成果を確認できます。これまでは画像のみの投稿が可能でしたが、新たに動画投稿機能が追加されました。私は、この動画投稿機能の開発を担当しており、AVFoundationを用いて動画の編集や再生機能を実装しました。本トークでは、FAANSにおける動画機能の開発過程で直面した課題と、それを克服するために用いたテクニックについて紹介します。

具体例として、FAANSではエンコードされていない動画と音楽を同期して再生する機能が求められました。単に再生を開始するだけでは動画と音楽のズレが発生するため、AVPlayerのreadyToPlayステータスを監視して、両者が再生可能になった時点で再生を開始するように実装しました。また、アップロードされた動画を再生する際には、動画が再生可能かどうかをObserverを用いて監視し、再生できない場合には適切なエラーハンドリングを行うことで、再生の待機やアラート表示を実現しました。

本トークでは、動画機能の開発における具体的な課題とその解決策について、実際のコード例を交えながら詳細に解説し、新たな知識と知見を提供します。

iOSエンジニアとしてアプリ開発に携わる上で、さまざまな画面要件を実装へ落とし込む経験を繰り返していることと思います。

「多様な画面の実装に備えて取り得るUI実装のアプローチは何か？」
「デザインや画面要件を把握したエンジニアは個々のUI実装へ向けて何を思考するのか？」

これらの一連のアプローチは暗黙的な経験則になりがちで、体系的に示される機会はそう多くありません。

本セッションは「複雑性の高いUI実装と向き合う “戦略” と ”戦術”」と題し、複雑性の高いUI実装における思考法や知見を紹介します。前半では画面状態の抽象化や類似画面における設計の構造化など、大局的なアプローチへフォーカスしてお話しします。後半では個々のUI要素にフォーカスし、仕様の複雑性を紐解きつつ破綻なく実装に落とし込むための思考法を示します。その思考においては、SwiftUIの機能群やXcode Previewsの活用を通した "iOS Specific" な考え方も模索していきます。

The os_signpost API was introduced in 2018 as a tool to work in Instruments.app to analyze and fix the performance of an application

Profiling an application with os_signposts periodically will allow us to catch performance regressions

Instruments.app with os_signpost gives the developer a visual and intricate picture of what is happening in the application during performance critical segments of the app

アプリケーションのパフォーマンスを向上させるには、次のことが必要です

1. 処理に時間のかかるタスクを特定して測定する
2. そのイベントを分析して、そのタスク内でどのようなイベントが発生しているかを把握する
3. Instruments のタイムライン グラフを使用すると、アプリを高速化するために同時に実行できる操作を特定できる

昨今、世の中を席巻している大規模言語モデル（LLM）をはじめ、音声認識、画像生成、物体検出やセグメンテーションなど、多くのタスクで機械学習（ML）モデルが大活躍しています。これらのモデルをiOS/macOS/visionOS/watchOSのハードウェア性能を最大限に引き出しつつ動かすには、Core MLモデルに変換する必要があります。

逆にいえば、モデル変換の技術をマスターすることで、最先端のモデルをいち早く利用したり、自前データで学習したモデルをアプリに組み込むことが可能になります。

Core MLモデルへの変換には「coremltools」というツールを利用します。ドキュメントもあり、その変換手順は一見シンプルに見えますが、実際のところまず一発ではうまくいかないでしょう。多くの場合、モデルの一部を切ったり置き換えたりする「手術」が必要となります。

本セッションでは、Core MLモデル変換に必要な技術や知識、落とし穴、問題の回避方法について、実際のモデルを題材に解説します。その中で、Appleデバイスの性能を最大限引き出すコツや、モデルサイズを圧縮する方法なども紹介します。