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

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

このLTでは、以下について紹介します

• なぜダークモード対応が必要なのかをHIGやいくつかのプロダクトの実例を交えて考察
• 4年以上運用されている規模の大きなアプリでダークモード対応を進める上で出てきた課題やその解決策

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

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

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

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の変更を伴うリリースの際に品質を落とさないためのポイントについても合わせて紹介します。

Unlock the power of ChatGPT to revolutionize your job-hunting process as an iOS engineer or others. Discover how to gather critical information about potential employers efficiently and gain a competitive edge in the job market. Learn how to quickly gather details on salaries, job conditions, requirements, and company performance metrics like sales. This session will provide practical tips on using AI to streamline your search, save time, and focus on what matters most—landing your dream job, like . Join us to explore this cutting-edge approach and elevate your career trajectory.

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の違い。

ファンタジーコンソールという言葉を聞いたことがありますか？直訳すれば「空想上のゲーム機」となります。これは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の違い。

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にしてみたい」と考えている方々にとっての必見のトークです。

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 を利用して実現していましたが、テスト・静的解析・デバッグのしづらさ・考慮漏れといった多数の課題がありました。

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

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

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

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

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

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

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

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

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