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アプリ側の設定

Swiftの新しい並行処理モデル「Swift Concurrency」の一環として追加された「Actor」について、たった5分でその基本概念と利点について解説し、ActorでRace Conditionを防げない要因を明らかにします。
このトークを通して、Actorの基本概念、その背景、そしてどのようにして実務で直面する並行処理の課題を解決できるのかを簡潔に理解することができます。
短い時間ながらも、具体的かつ実践的な知識を身につけられる内容となっています。
以下のポイントを簡潔に取り上げます。

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

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

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

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

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

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

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

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

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

ファンタジーコンソールという言葉を聞いたことがありますか？直訳すれば「空想上のゲーム機」となります。これは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ネイティブアプリとしての仕上げ方について紹介します。楽しくも低解像度なツールでのゲーム開発を試してみませんか？

Firebase Dynamic Links はアプリ内の特定コンテンツへ直接遷移できるディープリンクサービスとして重宝されてきましたが、来年の2025年8月25日に完全に終了するとアナウンスされています。

Google が無料で提供していたことや導入の容易さから、個人アプリでも広く導入されていたことでしょう。
私が担当しているプロダクトにおいても、機能仕様およびマーケティング施策の観点から中核サービスとして利用していました。

そのような中 Firebase Dynamic Links の廃止が突如発表されました。
Firebase 公式からは Dynamic Links 非推奨に伴う移行ガイドが公開されていますが、期日の猶予や対応観点の不明瞭さから、実際に移行を始めているサービスはまだ多くないでしょう。

Firebase Dynamic Links に替わる案として様々な選択肢が挙げられますが、私が担当しているプロダクトでは Adjust を利用した方針に舵を切りました。

この発表では、数ある選択肢から何故 Adjust を採用したのか、また実際の置き換え事例を踏まえ、詳しくご紹介します。

私が実装を担当する『家計簿プリカ 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の違い。

PlaydateはmacOS向けエディターなどでも知られるPanic社が、イケてる電子楽器メーカーteenage engineeringと組んで開発した小さな黄色い携帯ゲーム機です。パッと見ゲームボーイのようにも見えますが、その最大の特徴は手回しクランクがついていること！

Playdateゲームの開発はLuaやCで行えますが、2024年からSwiftもサポートされました。Playdateの開発環境がおもしろいのは、音響関係のAPIが充実していることです。サイン波を鳴らしてディレイをかけ、フィルターをLFOで揺らして…といったシンセいじりの遊びを簡単にコードで書けるようになっています。件のクランクも、シンセサイザーのパラメーターや音程を調整する「つまみ」として使ったら楽しそうです。

このトークでは、SwiftによるPlaydateゲーム開発の基本と音響APIを使ったシンセサイザーおもちゃの開発事例を紹介します。さらに、そのシンセおもちゃの実演デモも行います。トークタイトルは略語がSwift Package Managerと同じSPMとなるように決めました。うまく音楽を奏でることができれば、題に偽りなしですね。乞うご期待。

WWDC23 ではさまざまなツールやフレームワーク、アップデートが施されました。
しかし、多くの方が「iOS 17からしか使えない・・・」と落胆されたのではないでしょうか。

新しい技術を導入してみたい一方で、実務や個人アプリに取り入れるのは難しいと感じることもありますよね。

しかし、心配ご無用です！iOS エンジニアの皆さん！
そのお悩みにお答えします。

本LTでは、 iOS関連のニュースを定期的に配信する Web サイト「iOS Osushi🍣」が iOS 17専用のアプリ「Osushi」 の開発秘話や開発で得られた知見を紹介します。

具体的には、以下のポイントについて解説します。

• このアプリを作った経緯
• Osushiで使われている技術の紹介
• iOS 17の新機能を活用する方法
• 実際の開発プロセスと課題克服の方法

この LT を通じて、最新技術を使ったアプリ開発の具体的な方法を学びましょう！

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

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

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

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

皆さんは「OSSなモバイルアプリ」と聞いて、いくつ思い浮かぶでしょうか？
そして、Webアプリやライブラリと比べると、その数が少ないと感じることはありませんか？

このLTでは、 iOS 関連のニュースを定期的に配信する Web サイト「iOS Osushi🍣」のモバイルアプリ版 「Osushi」をOSSとして公開する際に行った対応についてご紹介します。

具体的には以下のトピックを取り上げます。

• OSSの魅力
• 公開する際の準備と対応
• 遭遇した課題とその解決
• 他のOSSプロジェクトの事例

このLTは、「これからOSSなアプリを作ってみたい」「自分の開発したアプリをOSSにしてみたい」と考えている方々にとっての必見のトークです。

ジオフェンスとは、特定の地理的エリアにデバイスが入ったり出たりしたことを検知できる仕組みです。

iOSでは、中心の緯度経度と半径を指定するだけで簡単にジオフェンスを設置できます。この機能はアプリを起動していなくても検知が可能で、アイデア次第で便利なサービスを提供できます。

しかし、iOS/Android両方開発してみると、各OSごとの挙動の違いがあったり、確認方法にも工夫が必要です。

今回のトークでは、ジオフェンス機能をiOS/Androidの両OS対応した際の経験をもとに、以下のポイントについて詳しくお話しします：

・ ジオフェンス機能の仕様の違い
・ デバッグの際の工夫とTips
・ 開発時に苦労したこと

VRM（Virtual Reality Modeling）とは3Dキャラクターモデルを作成し、それをデジタル空間で使用するためのフォーマットです。
VRM形式のモデルは、さまざまなアプリケーションやゲームで広く利用されています。
恋するAIのアプリでは、WebViewを活用してVRMアバターの表情やモーションなどリッチな表現を実現しました。

本セッションではWebViewでVRMを利用してAIアバターアプリを実装するまでの以下の内容についてお話しします。

• VRM×WebViewでモーションや表情の変化を実装する手法
• WebViewでVRMを利用する際に直面した課題とその解決策
• 恋するAIアプリでの実装例

このセッションを通じて、VRMを活用したアプリの開発手法を習得し、皆さんも3Dアバターを活用したアプリを開発してみましょう。

WWDC2024に初めて現地参加し、iOSエンジニアとしてこれまでにない貴重な学びと経験を得ることができました。

このLTでは、参加に至るまでの準備とその過程で直面した困難について触れつつ、WWDC2024の現地参加で得られた新しい知識やインスピレーションについて詳しくお話しします。

まず、WWDC参加するための準備として、チケットの入手方法、渡航計画、宿泊施設の確保など、具体的なステップや注意点を含めて、特に初参加者が直面する不安に対して、WWDCを120%楽しめる実践的なアドバイスを紹介します。

次に、WWDC2024のセッションやワークショップで得られた最新技術や知識について紹介します。また、直接Appleのエンジニアと交流することで得られたインサイトや、iOSエンジニアたちとのネットワーキングの重要性についても触れます。

最後に、WWDC2024への参加がもたらした価値について、個人的な視点からお伝えします。高額な旅費を支払ってでも参加する価値があるのか、実際に体験したことを基にした率直な感想を共有します。参加することで得られる技術的な成長だけでなく、プロフェッショナルとしての成長や新たな視点を得ることの重要性についてもお伝えできればと考えております。

このLTを通じて、皆さんが「来年のWWDC2025に参加したい！」というモチベーションになることを願っています。

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

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

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

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

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

毎年新しい機能が発表されますが、実際のプロジェクトでは古いOSをサポートしなければならない都合でこれらの機能をすぐに採用することが難しいことが多いです。そこで、導入したい新しい機能を古いOSにバックポートしてすぐに使えるようにする方法について説明します。

• Apple純正のバックポート
  • @_backDeployでバックポートされる機能
  • ライブラリのインターフェイスでバックポートされる機能
• OSSとして提供されているバックポート
  • SwiftUIの機能、Observability、その他の実例
• 自分でバックポートを実装する
  • どういう機能がバックポートに向いているか
  • 実装範囲の決め方

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

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

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

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

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

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

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

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

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

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

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

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