iPhoneのカメラは年々進化しており、iPhone一台で高品質な写真を撮影することが一般的になっています。

例えばハードウェアの性能が向上したことで、48MPの高解像度撮影や、Apple ProRAWやApple Logなどの特殊な撮影機能も利用できるようになっています。

こうした進化したカメラ機能を自分のアプリに組み込むことで、独自のUIを使ってカメラを操作するだけでなく、標準のカメラアプリでは実現できないホワイトバランスや焦点位置の細かな調整、VisionやDockKitなど他のフレームワークと連動したユニークなアプリの開発が可能になります。

しかし、カメラの性能が向上しているにも関わらず、開発者がどのような新しい機能を利用できるのかについてはあまり知られていません。こうした新機能はAVFoundationやAVCaptureのAPIを利用してアプリに組み込むことができますが、実際にドキュメントを読んで実装しようとすると、不十分な記述に惑わされ、試行錯誤してなんとか実装することになります。

このセッションでは、近年のAVFoundationやAVCaptureのAPIのアップデートについて体系的に紹介します。48MP撮影やApple ProRAW / Apple Logなどの最新のカメラ機能の概要と実装方法についてデモを交えて説明します。

iOSエンジニアであれば誰しも一度はApple公式のドキュメントやSwiftUIのチュートリアルを読んだり、プロダクトやライブラリのドキュメントをDocCを用いて書いたりしたことがあるのではないでしょうか。swift-doccはこれらのドキュメント生成をSwiftベースで実現する強力なライブラリです。

本トークではswift-doccの仕組みに着目し、その動作原理について解説します。ドキュメント作成にはシンボル生成やMarkdownのパースなど、普段のアプリ開発ではあまり触れる機会のない技術が関わっています。それらについても一つずつ丁寧に取り上げます。

このトークを通じて、swift-doccのコードを理解し、OSS貢献やSwiftを使用したツール開発への第一歩を一緒に踏み出しましょう！

内容

• DocCの概要
• APIリファレンスや記事、チュートリアルを生成するまでの流れ
• ArgumentParserについて
• SymbolKit、swift-markdown、swift-docc-render、swift-nioなど重要な構成要素について
  • 記事（Article）の生成方法
  • .tutorialファイルのパース方法
  • Web上でのプレビュー機能の仕組み
• swift-doccの本当の役割

当方は某企業でiOSエンジニアをしている傍ら、某離島にある商船高専の情報工学かでテクニカルアドバイザー的なことをしています。アドバイスをしている中で、実践的な教育カリキュラムをどう実現するかというのがちょこちょこ話題に上がることがあります。

高専には教育の質を担保するモデルコアカリキュラムというものが設定されています。
その中にはプログラミング・アルゴリズムに関する項目も定義されています。

参考文献
https://www.kosen-k.go.jp/nationwide/main_super_kosen

ただし、ここにはカリキュラムとして最低限学ぶべき内容が定義されているのみであり、実現方法などについては言及がありません。
今回はMac, Xcode, Swift Playgroundsを使った高専生のモデルコアカリキュラムの具体的な実現について考察した内容を発表します。

Swift Concurrency が導入されてから「Swiftが難しくなった」という声をよく耳にします。
実装者はこれまで見えていなかったデータ競合や再入可能性などの問題に対処する必要が出てきており、これまで以上に高いレベルの言語知識が求められています。
しかし、実装者がSwift Concurrency を正しく活用することで、複雑なロジックやユーザーの操作が絡んだ非同期なフローを抽象化し、再利用性の高い形でよりシンプルなインターフェースを利用側に提供することが可能です。

本トークでは、タップルの認証フローをフルスクラッチで刷新した事例を通じて、以下のような複雑な課題を Swift Concurrency を活用して解決した方法を共有します。

• 認証SDKを通じた状態の更新や判定など、クライアントから切り離せないロジックの肥大化
• Sign in with Apple、SMS認証などの画面呼び出しを伴う認証フローの共通化
• 外部SNSや認証SDK周りのエラーハンドリング

このトークを通じて、Swift Concurrency のポジティブな側面や柔軟なコード表現力を学び、
自分たちの業務での複雑なユースケースに活用するイメージを持つことができるようになるきっかけを提供します。

RealityKitはiOS・visionOSにおいて、ARアプリケーションを開発する最適解の一つです。

ARと聞いて少しハードルを感じるかもしれませんが、RealityKitはSwiftネイティブなAPIで提供されているため、3D空間を扱うための座標や行列計算などの独特な要素はありますが、普段のiOS開発とほとんど変わらない方法で記述することができます。
この独特な要素に関しても、概念を理解し、ちょっとしたコツを知るだけで簡単に扱えるため、RealityKitを使ったARアプリケーションの開発は本当にとても簡単なのです。

本セッションでは、「好きなイラストを現実世界に呼び出すARアプリ」を例に、RealityKitを用いた基本的なARアプリケーションの作り方と、開発中に直面しがちなハマりどころを、以下のステップに沿って解説します。

1. ARKitとRealityKitの役割と関係性
2. 現実世界の特定の場所にオブジェクトを配置する方法
3. オブジェクトにテクスチャを貼り付ける方法
4. オブジェクトに環境効果を適用する方法
5. オブジェクトの位置や方向を自由に変える方法

日本でのVision Proの発売に備え、今こそRealityKitに入門しましょう。

refreshable() はSwiftUIのモディファイアであり、 List や ScrollView などのビューに付けるだけでPull-to-Refreshを実現できます。
例えばSNSのタイムラインを下に引っ張るだけで最新の投稿を取得できます。

非常に便利なrefreshableですが、このような経験はありませんか？

• 処理の完了を待たずにインジケータ（くるくる）が消える
• 処理中に画面が固まる
• 処理が途中でキャンセルされる

私はすべて経験しました。
これらはSwiftUIにおけるビューの再描画やSwift Concurrencyを正しく理解していないことで起こります。

本トークではrefreshableが正しく動作しないコードを修正していき、それを通してビューの再描画やSwift Concurrencyについての理解を深めます。

もくじ

1. refreshableの概要
2. 悪いサンプルコードの紹介
3. サンプルコードの修正
   • 処理の完了までインジケータを表示し続ける
   • 処理中に画面が固まらないようにする
   • 処理が途中でキャンセルしないようにする
4. まとめ

refreshableはSwiftUIやSwift Concurrencyを学ぶいい教材でもあるので、一緒に学んでいきましょう！

ダークモード対応の意義は単に見た目のかっこよさにとどまりません。
特にモビリティアプリにおいて、ダークモードは安全性の向上にも寄与します。例えば夜間にルートナビを見せる状況で、周囲の暗さにあわせた表示方法があれば、目にかかる負担を極力減らし運転への集中を保つことにつなげられます。

Luupでは、このような安全性の観点からアプリのダークモード対応を実施しました。

このセッションでは、なぜダークモード対応が必要なのかについて、HIGやいくつかのプロダクトの実例を交えて考察します。
その後、4年以上運用されているUIKitおよびSwiftUI製のコンポーネントを含む規模の大きなアプリで、どのような手順でダークモード対応を進めたのか、直面した課題とその解決策を解説します。
また、このような大規模なUIの変更を伴うリリースの際に品質を落とさないためのポイントについても合わせて紹介します。

Kotlin Multiplatform（KMP）はここ数年で導入事例も増え、ノウハウも多く公開されるようになりました。
2023年末に安定版となったこともあり、その導入のハードルもかなり下がってきているのではないでしょうか。

弊社でも、2023年にリリースした「P!TNE」というアプリでKMPを採用しています。
このアプリはApp Clipに対応しているため、アプリ本体・App Clip間のデータ連携や、アプリサイズの最適化が重要な課題でした。

しかし、KMPについては設計やSwiftとの互換性などについてよく論じられる一方、
これらの点についてはノウハウは少なく、開発時にかなり苦労しました。

そこで、私が実際にどのような苦しみを味わい、それをどう乗り越えたかをご紹介します。

このトークを通じて、皆様が私と同じような苦しみを味わうことなく、
KMPを活用してアプリ以外のターゲットの開発も効率化できることを期待しています。

話すこと

• KMPを用いたターゲット間のデータ共有について
  • UserDefaults
  • アプリ内DB
• KMPとアプリサイズ最適化について
  • SwiftとKotlinの言語仕様的な違い
  • KMPでFrameworkを生成する際のビルド設定
  • KMPコードを導入するiOSアプリ側の設定

ファンタジーコンソールという言葉を聞いたことがありますか？直訳すれば「空想上のゲーム機」となります。これは1980年代の別の世界線で存在しえたかもしれない、架空のレトロゲーム機のエミュレーターのようなものです。ファンタジーコンソールの祖である"PICO-8"の作者、zepことJoseph Whiteさんがこの概念の生みの親です。

PICO-8はたんなるゲーム機エミュレーターではなく、Lua言語によるコーディングのためのエディター、ドット絵を描くペイントツール、効果音や音楽を作るトラッカーを内包した統合開発環境です。開発したゲームはmacOS、Windows、Linux、Raspberry Piでの実行形式のほか、HTML5にも書き出すことができ、iPhoneやiPadで遊ぶことができます。

ところで、App Reviewガイドラインの改定により、HTML5のミニアプリやミニゲームをアプリの一部として提供することが可能になりました。これはPICO-8を使って開発したゲームをApp Storeに展開することができることを意味するはずです。

このトークでは、PICO-8を使ったレトロ風ゲーム開発の基礎と、iOSネイティブアプリとしての仕上げ方について紹介します。楽しくも低解像度なツールでのゲーム開発を試してみませんか？

私が実装を担当する『家計簿プリカ B/43』で支出をグラフで可視化する機能をリリースしました。
このグラフは、横軸に日にち、縦軸に累積支出額を取り、月ごとに折れ線グラフで支出の経過を可視化できるようになっています。
グラフをタップするとHaptic Feedbackを発しながらその日の支出額, 決済店舗を表示し、グラフ上をドラッグすることでパーティクルアニメーションを描画しながら別日の支出の詳細を確認できます。
このようなリッチなグラフを実装する上で、我々はApple純正のSwift Chartsフレームワークやその他OSSのライブラリではなく、SwiftUIのCanvas Viewを用いたカスタム実装を採用しました。
このセッションでは、グラフの実装においてChartsや他OSSとの比較をしながら、SwiftUIでCanvasを利用したリッチなグラフの実装について基本的なグラフの描画からジェスチャーでの操作を含む実際のプロダクトでの実装事例を紹介します。

1年前、私たちのチームにはQA担当が存在せず、テストコードもなく、エンジニアが手動でテストを行っていました。
この結果、品質にばらつきが生じ、リリースサイクルも不安定でした。
さらに、SwiftUIへの移行も進行中で、エンジニアのみの限られたリソースでこれらの問題に対処するため、スナップショットテストの導入を決定しました。
スナップショットテストは、手動テストでは検出できないような細かいUIの変更を即座に検出できます。

本セッションでは、導入の背景、プロセス、運用開始後に直面した課題とその解決策、そして1年間の運用で得られた成果についてお話しします。

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

• 導入の背景: なぜはじめにスナップショットテストを選択したのか
• 導入プロセス: ツールの選定、導入ルールとCIへの統合方法
• 運用開始後の課題と解決策: 直面した課題とその解決策
• 導入成果: スナップショットテストを導入した結果得られた成果

Swiftの新しい並行処理モデル「Swift Concurrency」の一環として追加された「Actor」を深掘りします。
ActorはなぜSwiftに追加されたのかという基本的な概念から、具体的にどのようにしてiOSアプリの安全性を高めるか、実際の業務でどの様なメリットがあるのか、Actorで解決できない課題は何か？など実践的な内容についてお話しします。
ただActorを使うだけでなく、その背景や制約を理解することで、実際の業務で並行処理に関する課題に直面した際に解決するための知識を得ることを目指します。

本トークで想定している内容は以下の通りです。
【 Actorの基本概念と動機】
・なぜActorが導入されたのか。
・従来の並行処理でどのような課題があったのか。
【Actorが解決する課題】
・どのようにして問題を解決するのか。
・実際の業務でどのようなメリットがあるのか。
【Actorの制約と限界】
・Actorにも限界がある？
・Actorが解決できない問題。
・data raceとrace conditionの違い。

名前をつけることはプログラマーの仕事の大きな割合を占めます。プロパティやメソッドの名付け方でコードの可読性やメンテナンス性が大きく変わります。Swiftプログラマーにとっては、Swift API Design Guidelinesがその命名法の指針になります。しかしそれは当然ながら英語の知識を前提としていて、そのことが非英語話者/日本語ネイティブ中心のチームにとっては障壁となります。ソフトウェアエンジニアとして各自高い英語力を持っているのが理想ですが、現実には以下のような問題や疑問が生じます：

・英語では自然な言い回しでも、チームの皆に馴染みのないメソッド名を採用すべき？
・和製英語や直訳英語がわかりやすい場合でも却下すべき？
・英語での自然な読み下し vs 接頭辞や接尾辞の当てはめルール
・コードレビューで英文法の指摘ばかりしているワタシ、実は煙たがられてない？

私たちのチームでは、これらの問題を解決するために”アベレージ日本語話者向け”コード命名法ガイドラインを作成しました。このガイドラインは、Swift API Design Guidelinesをわかりやすく噛み砕いた命名規約とその運用ルールを含んでいます。

このトークでは、ガイドラインを作成するに至った過程を紹介しながら、英語力のばらつきがあるチームでもスムーズに開発を進めるための具体的なアプローチをお伝えします。

株式会社ヤプリでは、プログラミング不要で高品質なネイティブアプリを作成・配信できるアプリプラットフォームを提供しています。現在、800 以上のアプリを同じコードベースからビルドしており、これらのアプリには共通機能の他に、一部のアプリにのみ含まれるオプション機能が存在します。

オプション機能が要求するパーミッションや外部 SDK のインポートは、その機能を利用しない他のアプリにおいては、アプリサイズの増加やリジェクトの懸念があるため含まれるべきではありません。

従来、アプリの内容に応じた処理の分岐は Active Compilation Conditions を利用して実現していましたが、テスト・静的解析・デバッグのしづらさ・考慮漏れといった多数の課題がありました。

このセッションでは、それらの課題を解決するためにヤプリで導入した、オプション機能を含むマルチモジュール構成をビルド時に決定している仕組みについて詳しくお話しします。具体的には、どのような技術を選択し、どのように問題を解決したかについて説明します。

このセッションを通じて、技術選択や問題解決の一助になれば幸いです。

株式会社ヤプリでは、プログラミング不要で高品質なネイティブアプリを作成・配信できるアプリプラットフォームを提供しています。現在、800 以上のアプリを同じコードベースからビルドしており、これらのアプリには共通機能の他に、一部のアプリにのみ含まれるオプション機能が存在します。

オプション機能が要求するパーミッションや外部 SDK のインポートは、その機能を利用しない他のアプリにおいては、アプリサイズの増加やリジェクトの懸念があるため含まれるべきではありません。

従来、アプリの内容に応じた処理の分岐は Active Compilation Conditions を利用して実現していましたが、テスト・静的解析・デバッグのしづらさ・考慮漏れといった多数の課題がありました。

このセッションでは、それらの課題を解決するためにヤプリで導入した、オプション機能を含むマルチモジュール構成をビルド時に決定している仕組みについて詳しくお話しします。具体的には、どのような技術を選択し、どのように問題を解決したかについて説明します。

このセッションを通じて、技術選択や問題解決の一助になれば幸いです。

プレビューを書いてみたものの、動作が重くて使いづらい、時間が経つと全く動かなくなってしまう、手間がかかるから書くのはやめた、などの経験がある人は多いでしょう。本トークでは、実際の経験に基づいてプレビューを書きやすく、保守しやすくする方法について話します。

• そもそもなぜプレビューを書くべきか
  • プレビューを書くメリット
  • プレビューの適切な粒度
• 設計でプレビューを書きやすくする
  • プレビューが動作しやすい設計の原則
  • 状態の分離、依存注入
  • コンポーネント化
• プレビューを快適に使うためのTips集
  • プレビューがビルド失敗する一般的な理由とデバッグ方法
  • プレビュー用画像の管理

音は重要な要素であり、よりリッチな体験を実現するためには不可欠です。
効果音やBGMが鳴ることで、アプリの世界観を強調するだけでなく、使い勝手やユーザーの満足度を高めてくれます。
しかし、タイミングを誤ると、ユーザー体験が損なわれる可能性もあります。

例えば、多く使われているフレームワークとしてAVAudioPlayerがありますが、もしサイレントモードでも音を鳴らしたい場合には他のアプリのバックグラウンド再生を止めてしまうことがあります。また、アプリ内で特定の画面でBGMを鳴らす際には、ライフサイクルを考慮しないとアプリを閉じてもBGMが鳴り続けてしまうこともあります。

本トークでは、iOS / iPadOS アプリにおける音の取り扱いに焦点を当て、ユーザー体験への影響と対処法について解説します。
具体的には以下の内容をお話しします。

• AVAudioPlayerを使用した音の再生・停止のライフサイクルの理解
• 利用シチュエーションでの課題
  • 効果音を鳴らすと、他のアプリがバックグラウンド再生を止めてしまう
  • SwiftUIでBGMを追加したら、BGMが流れない画面でも鳴ってしまう
  • 音量の調整とその影響
• プロダクトに適合した音の利用方法の提案

このトークが、音の体験について考えるきっかけとなれば幸いです。

iOSで地図を扱うには通常、MapKitが広く利用されています。MapKitを使用すれば地図上の現在位置情報を容易に扱えますが、このトークではMapKitを使用せずに任意の地図画像上に現在位置を表示する方法について解説します。

これを実現するために、以下のポイントについて詳しく説明します。

1. 位置情報の基準点設定
2. 位置情報の許可設定
3. 現在地の表示方法
4. 位置情報が更新された際に呼ばれるデリゲートメソッド
5. 地図上の2点の緯度経度情報から現在位置のXY平面座標を算出する際の計算処理
   これらの要素を組み合わせることで、MapKitを使用しない地図アプリの基礎から実装までを網羅的に理解できるようになります。

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

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

「家族アルバム みてね」(以下「みてね」)では、2023年10月から本格的にSwiftUIを導入し、新規画面の実装を中心にSwiftUIを積極的に使ってきました。現在約15%の画面がSwiftUIで実装されています。

みてねには「職能にとらわれずにタスクを取る」という文化が根付いているため、iOSやSwiftに詳しくない人にもわかりやすくなるよう、以下の特徴を持ったシンプルな設計を採用しています。

• プレビューがしやすい
  • 高速にプレビューできる
  • さまざまなUIの状態を簡単に用意できる
• OSSライブラリに依存していない
• みてねAndroidアプリと似た設計
• Observationフレームワークへの移行が容易

本セッションでは、どのようにして上記特徴を実現しているのか、具体的なコードを交えてご紹介します。