トーク

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

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

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

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

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

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

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

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

皆さん自動テストやアプリ配布の待ち時間に満足していますか？
その待ち時間をいかに短縮するか？がやはりCI/CD上でのキャッシュ戦略だと思います。
また、今日様々なCI/CDサービスがある中でも、ライブラリ管理やビルド環境の組み合わせは限定されており、
キャッシュ可能なポイントはある程度絞られています。

本トークでは、以下のポイントを含む幅広いユースケースで有効なCI/CD上でのキャッシュポイントとその方法について、5分間で紹介します。

• SwiftPM
• Ruby製ツール（CocoaPods、 fastlaneなど）
• homebrew管理のツール（Mint、 rbenvなど）
• Kotlin Multiplatformなどを利用した際のビルドキャッシュ

これらの情報を通じて、明日からあなたのCI/CDの実行時間が一分一秒でも短くなる知識を提供します。

アプリを取り巻く要件の中にはUIデザイン、機能仕様、リリース要件などさまざまなものがあります。この中でもリリース要件は選択肢が少ないため、自由度がかなり低いと言えます。

そんなリリース要件の中で、限定されたユーザーにだけアプリを配布し、利用できる仕組みが必要な場合があります。そんな要件を受けたときに、どのような選択肢があるでしょうか？
Firebase App Distribution、TestFlight、Apple Business Manager など、さまざまな手法がありますが、私の所属するチームでは、その中でも Unlisted App Distribution を採用しました。

このセッションでは、数ある手法の中からUnlisted App Distributionを選択するに至った経緯と、他の配信方法との比較検討の結果についてお話しします。また、Unlisted App Distributionを選択した際に気をつけるべき点についても詳しく説明します。

みなさん、認証機能のエラーハンドリングはどのように行っていますか？
近年のアプリの認証機能は、自社のサーバーだけでなく、Firebase Authorizationなどの認証系SaaSを活用していたり、Apple、Google、LINEといったSNSアカウントを利用した外部システムと連携したものがほとんどだと思います。

それに伴い、私たちがハンドリングしなければならないエラーの種類はどんどん増えており、

• ユーザーに適切なエラーダイアログを出すことが困難
• エンジニアの不具合の原因特定の難易度が高い

といった課題があります。

本トークでは、タップルが認証機能を刷新する中でおよそ140ものエラーを分類し向き合った経験をもとに、
上の句、下の句を扱う百人一首のように

• 「エラーコード」に対してどんな「エラーダイアログ」を出すべきか
• 「ユーザーからの問い合わせ」に対してどんな「回答」をすべきか

を “問題解決までのスピード” に着目してお話しします。

本トークを通じて、いままで雰囲気で扱っていたエラー分類への解像度が上がることで、
皆さんのサービスでユーザーが自己解決できる認証エラーが増え、認証の突破率やユーザーの獲得数が増加すること、そして今まで時間を使っていた不具合調査の時間が短縮されることを目指します。

SwiftUIでSwift Package Manager（SPM）を使用したマルチモジュールプロジェクトにおいて、循環参照を回避するための依存関係解決方法を紹介します。本LTは、循環参照の問題にフォーカスし、具体的かつシンプルな解決策をお伝えすることを目指しています。

具体的には、以下の構成でトークします。

1. 循環参照の発生例の紹介
2. 循環参照を回避するためのモジュール構成を考える
3. 依存解決するためのコードを5行で実装

依存関係解決にお悩みのそこのあなた、即実践可能な解決策をお届けします。

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

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

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

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

手塩にかけて育てたミュージックライブラリがぶっ壊れた経験はありますか？私はあります。

5年前、OSX Catalinaの登場時にiTunesが廃止され機能ごとにアプリが分かれました。
その後、新しいミュージックアプリでは様々な問題が起こりました。

• アルバムアートワークが消えた
• 読み仮名のコピーができない
• ジャンルが勝手に書き換わる

(※全部筆者が経験したことです)

万単位にのぼる楽曲を1個1個精査して正しい状態に復旧するのは当然ながら非現実的です。
更にミュージックアプリの使い勝手の悪さも相まって泣き寝入りを余儀なくされました。

ですが、そこに救世主が現れました。そう、 ScriptingBridge です。
しかし ScriptingBridge はObjective-CがベースなのでSwiftで扱うには一工夫が必要です。

本セッションでは、macで他アプリケーションと連携するための仕組みである ScriptingBridge をSwiftのみで扱う方法と、それを使ってミュージックライブラリから楽曲情報を取得・編集する方法を紹介します。

また、壊れた楽曲情報を半自動で復旧する為のガワとしてNowPlayingアプリを実装した話をします。

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

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

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

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

トピック

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

本セッションの想定対象

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

参考図書

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

SwiftUIが登場してからおよそ5年が経ちましたが、複雑なレイアウトを表現する場面では、依然としてUICollectionViewが力強い味方です。

特に、Compositional LayoutとDiffable DataSourceの導入により、App Storeのような複雑なレイアウトも簡潔に、かつ容易に実装することが可能になりました。
セクションの順番さえ決まっていれば、その特定のセクションに対してアイテムのグルーピング方法を適切に指定するだけで、複雑なレイアウトを表現することができます。

しかし、セクションが不定の場合はどうでしょうか？たとえば、セクションによっては大きな単体のCellを表示したり、複数のCellを横方向に並べてスクロールさせたいが、その順序がサーバーサイドの都合により変化するような場合です。
UICollectionViewCompositionalLayoutでは、セクションに対して直接表現方法を指定するため、順序が不定では実現が難しいかと思われがちです。
しかし、セクションのenumに一工夫することで、このような動的なレイアウト生成も実現することができました。

本セッションでは、このように「受け取るデータの種類によってCellを自由に出し分ける必要がある場面」での、我々の成功パターンについてお話しします。

iOSアプリで動画を作成したことはありますか？
難しそうに思える画像生成や動画生成も順を追って理解していくことで意外とできるようになるものです

このトークではクライアント側での動画生成を試してみた経緯とそこで学んだ実際の動画の演出などについてお話しします。

• なぜクライアント側で動画生成することになったのか？
• AVAssetWriterによる動画生成の流れ
• 動画で使われてる効果（移動・回転・拡大縮小・ドロップシャドウ・ブラー・フェードイン・アウト）の実装

このトークを通じて、AVAssetWriterを使った簡単な動画生成の流れとCore Graphicsを使ったレンダリングの基本を学ぶことができます。

SwiftDataを使用して1:Nの親子関係のモデルをPreviewする際にエラーが発生した経験はありませんか？本トークでは、SwiftDataを用いたモックデータの実装方法について解説します。

SwiftDataの基本概念: SwiftDataの基本的な使い方と、1:Nの親子関係のモデルの定義方法について説明します。
モックデータの作成方法: Preview用のモックデータを作成するための具体的な手法を紹介します。

皆さんもご存知の通りXcodeにはショートカットがあります。
タブの移動、ビルド、コンソールの表示/非表示、シミュレータの選択、カーソルの移動などなど…。
いちいちトラックパッドやマウスまで手を動かさなくてもキーボードだけで完結できるのではないかと思えるほど多様です。
手間を減らすだけでなく、Xcodeの機能を深く知るきっかけにもなります。

そんな素敵なショートカットを時間の限り紹介します。

タップルでは、毎年最新技術への対応とセキュリティ向上を目的に、一定の閾値を任意の数値が下回った場合、下位iOSバージョンのサポートを終了してきました。
しかし、iOS15のサポートを終了すると、iOS16にアップデートできない端末が複数あるため、アプリが使用できなくなるユーザが発生してしまいます。
都度課金でもなくフリーミアムでもない、課金ユーザからの売り上げがほとんどを占めているタップルにとって、iOS15のサポート終了は"売り上げに大きく関わる"決断です。

当然ビジネスチームからは、「売上に大きな影響が出るのでは？」という懸念が出ました。
今回私たちは、ビジネスチームと一方的に対立するのではなく、ユーザの利益、会社の利益、そしてiOSチームの利益のバランスを考えながら、適切な決断を行うために協力しました。

本LTでは、我々がどのようにビジネスチームや分析チームとコミュニケーションを行ったのか、また、その過程でどのような解決策を提案し、どのようにしてiOS15のサポートを終了するに至ったのかをお伝えします。
目次

1. ビジネスチームとの売り上げ影響に関する議論
2. 売り上げ影響を可能な限り下げるための提案と実践
3. 結果と改善点

一般的なユースケースであればSwiftLintやSwiftFormatなどにコントリビュートするのが良いと思われるが、プロジェクト固有のルールやガイドラインとしてこうしたい、こう揃えておきたいというケースもあるはずです。このトークではそんな時に固有のLinterやFormatterをどう実現するのが良いかを追っていきます。

iPhone / iPad Proに搭載されているLiDARセンサを利用したリアルタイムスキャンにより、お家の間取り図を簡単に作成できるRoomPlanはもう触ってみましたか？
LiDARを利用した3Dスキャンは、すでに様々なデベロッパーよりApp Storeで提供されていますが、
WWDC2022においてAppleが提案した新しいSwiftAPIであるRoomPlanは、膨大な情報量を保持するスキャン結果から、非常にシンプルに壁、床、そして家具を再構築できます。

このセッションでは

• RoomPlan APIことはじめ
• RoomPlan の簡単な仕組み
• RoomPlan で作成した3Dオブジェクトの活用

を中心にiOSを彩るAR環境の一端をお話していきます。

類似の3Dオブジェクトの構築技術であるフォトグラメトリを利用したObject Captureとの比較や、LiDARセンサより得られるデータの取得、開発の中で困った点や、Reality ConverterやReality Composerとの連携について共有していきます。

Screen Time APIで利用できる機能の一つに、アプリの利用時間を可視化できるDeviceActivityReport機能があります。iOSの設定画面では棒グラフでのレポートを閲覧できますが、DeviceActivityReport機能を使えば、自身のアプリに任意のSwiftUIベースのレポートを組み込むことが可能です。

このLTでは、DeviceActivityReportを組み込んだアプリを気軽に作れるように、以下の内容をカバーします。

1. DeviceActivityReportで取得可能なデータ一覧
   どのようなデータが取得可能かを具体的に説明します。

2. DeviceActivityReport有効化に必要な手順
   初心者でも分かりやすいように、具体的なステップを順を追って説明します。

3. DeviceActivityReportの実装時に培った知見
   実装過程で得た知見や注意点について具体例を交えて紹介します。

これらの内容を通じて、参加者が自分のアプリにDeviceActivityReportを簡単に組み込めるようになることを目指します。

友人と 2 人で参加したハッカソン．
私たちは推しのフラクタル図形であるマンデルブロ集合を描画するアプリの制作を決意する．
ただマンデルブロ集合を描画するため，先人たちの築いてきたUIライブラリを無視して 1 枚の長方形を設置する．

このLTではほぼ初めてであったiOSアプリの開発の体験をもとに，MetalKitによるシェーダーの利用とマンデルブロ集合についての紹介をします．

※マンデルブロ集合：数学的に定義される複素数の集合であり，複素平面上では自分自身のミニチュアがそっくりそのまま自分の中に入っているような特徴を持つフラクタル図形の一種である．描画には膨大な計算量を要するが，シェーダーをはじめとした並列計算によってより効率的に描画することができる．

普段はIoTエンジニアをやっています。最近はUWBで遊んでいます。UWBのモジュール同士で通信させてもつまらないです。やっぱりスマホでUWBを捕まえて遊びたい！ でもAndroid勢はUWB搭載してるやつがほとんどいない。そうだ、久しぶりにiPhone用のアプリを作ろう！ 大丈夫！だって12年前まではObjective-CでiOSアプリ何個も作ったことあるもん！ ・・・はい、大変でした。そんな話です。

みなさん、「SwiftUIを用いたプロジェクトのビルド時間を短縮したい」と考えたことはありませんか？

iOSDC2021以降、SPMマルチモジュール構成をプロジェクトへ採用するサービスが多く見られます。
マルチモジュール構成では、小さくモジュール分割を行い依存を疎結合に保つことでビルド時間の短縮が期待できますが 画面遷移時にFeatureモジュール同士で呼び出しを行い、依存関係が密結合になっている場合、ビルド時間の短縮が効果的ではありません。

本LTでは、Protocolに各画面の生成処理を記述し、画面遷移先を抽象化してDIする手法を紹介します。
これによって、SPMマルチモジュールにおいて、疎結合な画面遷移が可能となり、効果的にビルド時間の短縮が可能となります。
また、複数のDI手法や画面遷移実装を比較し各手法のメリットデメリットを紹介していきます。

以下の順番に従い、各実装の問題点と解決策を交えながら説明します

• SPMマルチモジュールの導入
• NavigationStack を用いた MainApp での"単純な"画面遷移
• RouterProctocol を定義し画面生成処理を抽象化
• DIを用いた疎結合な画面遷移を可能に
  • @Environment を用いた一般的なDI
  • swift-dependencies を用いたリッチなDI

「急にグラフを実装することになったけど、Swift Chartsを使えばSwiftUIでグラフを実装できるってのは聞いたことあるなぁ〜」「iPhoneの標準アプリでこんなグラフの機能があるからできると思ってたけど、触ってみたらAPI多すぎるし、ドキュメント見ても実例とかほぼ無いしよく分かんないな〜」「他の開発も並行しているから1個1個検証してる時間なんてないし…」「あ〜〜〜！どこかに、グラフでよくある機能の実装方法を、時間がないから5分で…しかも一気に知りたいから『10選』も教えてくれる…そんなLTがないかな〜〜〜！」

…と思ってるそこのあなた！！！
このLTではSwift Chartsを使って、よくあるグラフ機能の実装方法10選を5分で共有します！
グラフの見た目や軸のカスタマイズ、注釈の表示、タップやスクロールを可能にしたり、アニメーションをさせたりなどよくある機能の実装方法について話します。

Swift Chartsでこんなグラフを描画したいと思ってもドキュメントは文字だらけで実際どう実装するかは中々探せません。自分はドキュメントのほとんどを読んでまとめ記事を書いた程です。
https://qiita.com/yamakentoc/items/55a7d7264691b2caf592

このLTを通じて、あなたのアプリにすぐにグラフと便利な機能を追加してみませんか？