トーク

Swift Concurrencyは、従来のマルチスレッドのコーディングに比べて、データ競合を効果的に回避しながら非同期のコードを簡単に書くことができるようになりました。
しかし、実装者が慎重にコードを書かないと、再現性の低いバグが発生する可能性があることに変わりありません。
また、CPUの効率的な利用を放棄することにもつながりかねません。

このトークでは、Swift Concurrencyの要素であるactorやasync/awaitなどを理解し、安全で効率的な非同期処理のコードを書く方法に焦点を当てます。
Swift Concurrencyのコードを書いたことがあるけれども、自信がない方や雰囲気で書いている方にとって、道しるべとなることを願っています。

課金機能における快適なユーザー体験設計はユーザーの満足度を向上させる重要な要素です。
ユーザーフレンドリーな課金体験は、継続的な利用や再購入を促進するだけではなく、そのサービスに対するポジティブな印象を形成し、サービスの信頼度向上にも繋がります。
また、適切なユーザー体験設計によってユーザーが自身で問題を解決できる可能性を高めることで、カスタマーサポートの負荷やエンジニアのログ調査コストを軽減するメリットもあります。

本セッションではABEMAのサブスクリプションを設計、開発する上で着目したユーザー体験設計について、実際の課金処理を紐解きながら以下の流れでお話しします。

• ABEMAの課金処理（サブスクリプション、PPV）の仕組み
• ユーザー体験向上のための具体的な設計と実装のポイント
• 課金処理中や成功、失敗時のユーザーへの効果的なフィードバック方法とその観点
• 過去の問い合わせ事例に基づく、課題発見とユーザー体験の改善ポイント

WWDC23で密かに公開されたTestFlightの新機能、「TestFlight Internal Only」をご存じでしょうか？
この機能を利用することで、誤ったIPAファイルが本番環境にリリースされるのをシステム的に防止できます。
しかし、TestFlight Internal Onlyを有効に活用するためには、さまざまな設定が必要です。

本トークでは、私が実際に経験した大規模サービスでのCI/CD環境構築の実例を交え、
TestFlightとCI/CDツールとの連携部分にも焦点を当てながら、安全で安心なCI/CD環境の構築方法をご紹介いたします。

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

1. TestFlight Internal Onlyとは何か
2. TestFlight Internal Onlyの有効的な活用方法
3. 大規模サービスにおけるCI/CD環境への応用

本トークを通じて、皆さんが安全で安心なCI/CD環境を構築する上でのヒントを提供できればと期待しています。
また、皆さんが考える安全で安心なCI/CD環境についても一緒に考察していきたいと思います。

あなたのアプリ、カメラを使った認証機能（QRコード読み取り、本人確認書類）搭載されてませんか？
もし搭載されている場合、実は裏でこんな問題が発生しているかも知れません。

それは、
『iPhone14Pro移行のデバイスで近距離撮影のピントが合わなくなってしまう問題』です！

iPhoneが搭載するレンズはUI以外にも変化を遂げており、実は世代やモデルによってカメラのフォーカス位置、広角から超広角にスイッチする距離などが異なります。
iPhone11の登場によりPro以上の上位モデルにはトリプルカメラが搭載されるようになってから5年の月日が経ちますが、実は年々撮影最短距離も変わってきています。
そんな中、実際発生した14Pro移行のピントが合わなくなってしまう問題をケーススタディとして、原因と対応策について解説していきます。

このセッションではカメラレンズの歴史に触れつつ、具体的には以下の内容に触れていきます。

• カメラレンズの沿革
• 最短撮影距離とは
• 実際に発生した問題とその対策

本セッションを通じて、普段触れないレンズの挙動について詳しくなりませんか？

iOSにおけるSwiftUIやAndroidにおけるJetpack Composeの利用拡大でモバイルアプリ市場における宣言的UIフレームワークの利用拡大は増加の一途を辿っている道半ばでしょう。
宣言的UIフレームワークの利用が拡大することで現代フロントエンドの進化やエッセンスがモバイルアプリ界隈にも徐々に取り入れられ、さらなるハイブリットが生まれることも推測できます。
2021年中頃から末にかけてJetpack Compose / SwiftUIに「Atomic Design」と呼ばれるデザイン手法を実験的に採用された事例が増えていたことも記憶に新しいです。

フロントエンドのエッセンスがモバイルアプリ界隈に取り入れられることで
「WebアプリもモバイルアプリもTypeScriptで実装したい」というニーズが出てくるのは自然なことだと思います。現在であれば React Navive + TypeScript が最有力候補です。

しかし、私は「Nuxt Ionicを用いて Nuxt + Vue.jsで開発することも出来る」という一石を投じたいと考えています。
本登壇にて「モバイルアプリ開発でもNuxtという選択肢をあなたへ」提示したいと思います。

登壇者情報: フロントエンド開発をメインとし、Nuxtのコントリビューターなどをしています。LTの味変枠としてお聞き頂きたいです。

このトークでは、CNLabelContactRelationElderCousinMothersSiblingsSonOrFathersSistersSonについて語りたいと思います。
果たしてCNLabelContactRelationElderCousinMothersSiblingsSonOrFathersSistersSonとは何者なのか、
どうやってCNLabelContactRelationElderCousinMothersSiblingsSonOrFathersSistersSonを利用すればいいのか、
あまり語られてこなかったCNLabelContactRelationElderCousinMothersSiblingsSonOrFathersSistersSonについて説明します。
またCNLabelContactRelationElderCousinMothersSiblingsSonOrFathersSistersSon周辺の機能についても語る、
CNLabelContactRelationElderCousinMothersSiblingsSonOrFathersSistersSon尽くしの5分間となる予定です。

The Composable Architecture（TCA）はiOSアプリ開発において関数型スタイルの原則を取り入れることで実装から挙動を予測可能としテストコードを書きやすくすることに特化したOSSのフレームワークです。

このトークでは、2020年5月頃にv0.1がリリースされてから現在まで4年を経過し、さらにアップデートされ続けているTCAの良さを整理します。

そのためまずは従来のiOSアプリ開発における一般的な課題を説明し、TCAの関数型スタイルがどのように課題を解決するかを解説します。そして、新しくTCAへ追加された下記の機能が、どのように過去のTCAの短所を解決してきたかを解説できればと思います。

• swift-dependencies: 依存関係の管理を改善し、モジュール間のバケツリレー的な結合を緩和。大規模なアプリでも依存管理が容易になった。
• swift-perception: ObservationをTCAに取り入れ、iOS 17未満にはバックポートを提供する。
• ViewAction: UIコンポーネントからのアクションをより明確に管理し、ユーザーインタラクションのハンドリングを改善。
• Sharing state: 状態の共有機能を強化し、アプリ内でのデータフローの管理を容易に。複数のコンポーネント間でのデータの一貫性が保ちやすくなった。

デザイントークンとはデザインを構成する基本要素に対してトークンという呼び名を付与して管理する手法のことです。
国内では2022年にデジタル庁が公開したデザインシステムにおいてデザイントークンが導入されたり、その翌年2023年にFigmaにVariablesが導入されたことで注目を集め、実際の開発で活用される事例が増えています。筆者が担当するプロダクトでも、以前から開発チーム内でエンジニア・デザイナー間のコミュニケーションに課題を抱えており、デザイントークンの設計・導入に踏み切りました。このトークでは、すでにリリースされているアプリの開発プロセスの中にデザイントークンを導入する実例を紹介し、開発プロセスへ与えた影響をアプリ開発エンジニア・UIデザイナーの両視点から解説していきます。

具体的に以下のポイントに焦点を当ててお話します。

・ 画面を観察を軸にしてデザイントークンを設計するプロセス
・ デザイントークンの効果的な階層設計
・ デザイントークン導入によってエンジニア・デザイナーの両視点からのコミュニケーションへの効果
・ アプリ開発経験のあるエンジニアがデザイントークン設計をリードするときに意識したこと

このセッションを通じて、デザイントークンを活用し、アプリ開発が"ととのう"ための知見を少しでもシェアできればと思います！

iOS 17からiPhoneの機能としてNameDropが利用できますが、
APIを公開されていないため、私たちiOS開発者はNameDropの機能やエフェクトを利用できません。

APIが提供されていないなら、自作してみようと考え、
NameDrop風エフェクトをMetalを利用して開発してみました。

Metalは、Appleが開発したグラフィックスおよびコンピューティングのための低レベルなフレームワークです。
ハードウェアに近いレベルで制御が可能であり、効率的なグラフィックスおよび計算処理を実現できます。
しかし、Metalを使用して開発するためには、CPUとGPUの関係、シェーダープログラミング等の
様々な知識が必要となり、理解が難しいと感じる人も多いでしょう。

今回はMetalを使用したエフェクト作成方法について、開発したコードを用いて解説します。
まずは、Metalの処理の流れやコマンドバッファ、コマンドエンコーダ、パイプラインなどの用語や概念について説明し、
次に、シェーダー関数を利用してNameDrop風エフェクトを実現する方法について要点を説明します。

Metalの知識を学習することで、エフェクトの作成時の高度なカスタマイズ等の
魅力的な視覚効果を実装することができます。
この機会にMetalプログラミングを学び、日々の開発に役立てていただければ幸いです。

Appleは毎年、学生向けにSwift Student Challengeというプログラミングコンテストを開催しています。Winnerとなるのは毎年世界で350名で、例年数名の日本の学生がWinnerに選ばれます。応募にはSwift Playgroundで制作したAppと英語でのエッセイを提出します。

私は大変光栄なことに、2024年のWinnerに選ばれました。

実は昨年は落選でしたが、多くのことを学びました。iPhoneアプリ開発とは少し異なるSwift Student Challenge用プロダクトの体験設計、Look & Feelのデザイン、実装、デバッグ法などを、過去の入賞者の分析やAppleのページなどで得た情報をもとに、私が提出に向けて取り組んだことを全て論理立ててお話しします。

本トークを通じて、Swift Student Challengeで私が取り組んだ全てを知ることができます。学生の皆さんには、来年の応募がオープンした時に迷わず制作に取り組む方法、温度感、Challengeの見え方が少し変わる時間を提供します。

また、大人のエンジニアの方々には、未来のエンジニアを育てる大事な機会として大人が手伝えることが何かがわかるように、そして普段の開発で何か課題に出会った時に、技術だけでなくプロダクト中心の考え方で解決策を想像できるようになる時間を提供します。

iPhoneは電話機です。
電話機なので連絡先の機能が標準で備わっています。
しかし、メッセージアプリやSNSの普及により、連絡先の管理は後回しにされがちです。
連絡先を管理できていない方も多いのではないでしょうか。

そんな連絡先の管理方法について、今一度、見直してみませんか？
当セッションでは、連絡先の変更履歴について、連絡先の仕様変更とともに見ていくセッションとなります。
「うっかり連絡先を消しちゃった」も、このセッションを見れば復活できるようになるかもしれません。

皆さんは、実装レビュー中に設計レベルの考慮漏れを指摘され、手戻りが発生した経験はありませんか？

そのような事態を防ぐためのツールがDesign Docです。

Design Docは実装の前段階で作成されるドキュメントで、プロジェクトの目的や実装の大まかな方向性、影響範囲、検討した代案などを示します。
事前にレビューを受けることで実装の精度を高め、手戻りを減らすことができます。

Design Docの作成は、モバイル開発ではまだ珍しいことかもしれません。
しかし複数チームに影響する開発を進める場合や、チーム全体が利用するコンポーネントを導入する場合など、iOS開発でもDesign Docを作成することで開発が効率よく進む場面が多々あります。
このトークでは、私が経験したプロジェクトを元に、Design Docの効率的な書き方や書くべき場面、その内容をお伝えします。

さらに、具体的な事例を紹介し、Design Docを元にどのように開発が進んでいったのかを詳しく解説します。
例えば、アプリ全体に影響がある追加認証としてのPasskeyの導入などです。

開発が複雑になり、変更の影響が複数チームに渡るほど、変更内容の指針が必要となります。

このトークを通じて、Design Docが大規模な開発を成功に導くための不可欠なツールであることを実感していただければと思います。

WWDC23の「Meet StoreKit for SwiftUI」にてアプリの課金実装をSwiftUIで簡単に実現できるAPIが紹介されました。これまで開発ハードルが高かったアプリ内課金の実装が、誰でも簡単にできるようになっています。

本LTでは、ProductViewを使用してミニマムでアプリ内課金を実装する方法を紹介します。特に、個人でアプリをリリースしているが課金機能の実装はまだ経験がない方々に向けて、この新しいAPIを活用し、手軽に課金機能を追加する手順を説明します。

ママ向けサービス「ママリ」は今年10周年を迎えました。この節目となる年、新たに「ダークモード対応」をリリースすることができました。ダークモード対応は、数年前からユーザーの明確なニーズがあったにもかかわらず、工数の問題で優先順位が上がらず、着手できていませんでした。このような中、エンジニア主導でユーザーのニーズを認識することが突破口となり、実現に至りました。

エンジニアの皆さん、ユーザーからの問い合わせをどの程度真剣に見ていますか？バグ報告や機能要望など、日々寄せられるユーザーの声には、プロダクト開発を前進させるヒントが数多く含まれています。エンジニア自身がユーザーにどれだけ向き合えているかを再確認しましょう。

ママリの開発チームでは、エンジニアが主導してユーザー問い合わせをチームで同期的に確認する時間を週に10分間確保しています。この短い時間でどのような変化が生まれたか、特に意識の変化について共有します。

このトークでは、エンジニアがユーザーの声に向き合う時間を作ることで、プロダクト開発が具体的にどう前進したかを詳しく説明します。エンジニアが主体となって、長年議論されながらも進められていない施策の第一歩をどのように踏み出すか、その気づきを具体的な事例を交えてお話しします。

SwiftUIでUI画面を作ることが主流になり、UIKitで実装するときよりも簡単に画面の構築ができるようになりました。各UIコンポーネントの実装は直感的であり、特定のコンポーネントを選ぶ際の実装コストの差も縮小されています。しかし、UIの実装中にどのコンポーネントを使用するのが最適か迷うことはありませんか。

例えば、ユーザーに複数のアクションの選択肢を提示する際、Menu、ContextMenu、Picker、ActionSheetといった様々なコンポーネントから選ぶ必要があるでしょう。それぞれの適切な使用場面を理解し、正しいコンポーネントを選択することはアプリの体験を向上させます。

このトークでは、以下のポイントについて解説します。

・ 各UIコンポーネントの基本的な使い方と特徴
・ 特定のシナリオにおける最適なコンポーネントの選び方
・ 実際のアプリ開発での具体的な使用例

UIコンポーネントの選択基準を明確にし、SwiftUIを使ったアプリ開発においてより直感的でユーザーフレンドリーなUIを実現する方法をお伝えします。

モバイルアプリケーションの開発において、スクリーンショットはユーザーエクスペリエンス（UX）向上のための貴重なリソースです。従来は主にApp StoreやGoogle Play Storeでのプロモーションに利用されてきましたが、実はスクリーンショットにはさまざまな使い道があります。

本トークでは、スクリーンショットの新たな活用法に焦点を当て、開発者やデザイナーがアプリのユーザー体験を向上させるためにどのように活用できるかを紹介します。

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

1. プロモーション以外でのスクリーンショットの活用法
   • ユーザーフィードバックの収集
   • UI/UXデザインの改善提案
   • アプリ内ヘルプやチュートリアルの強化

2. 実際の活用事例とベストプラクティス
   • スクリーンショットを活用して成功したアプリの具体例
   • スクリーンショットを効果的に使用するためのテクニック
   • 参加者が自身のプロジェクトで即座に適用できる実践的なアイデア

本トークを通じて、参加者はスクリーンショットがどのようにユーザー行動の解析やUXの向上に役立つかを理解し、自身のアプリに取り入れることが可能になることでしょう。参加者の皆様にとって、実際のプロジェクトに役立つ具体的なヒントやアプローチを提供することを目指しています。

ARC（Automatic Reference Counting）は、Swiftのメモリ管理の基盤として知られています。
ARCは、オブジェクトの参照カウントを追跡し、メモリリークを防ぐために重要な役割を果たします。

しかし、ARCの一般的な説明だけでは、「どういう仕組みなのか」「どのように動作するのか」を完全に理解するのは難しいことがあります。
本件はARCの詳細な動作原理を深く掘り下げ、実際の使用例を通して理解を定着させることを目的としています。

基本的な仕組みとしては以下になります。
・オブジェクト作成時に参照カウントが1に設定
・参照時: 他の変数がそのオブジェクトを参照するたびにカウントが増加
・参照解除時: 参照が解除されるとカウントが減少し、カウントが0になるとオブジェクトが解放

ただし、ARCも所詮はプログラムです。
ARCには詳しく見てみると、命令は大きく分けて以下の５つの操作があり、それらの命令の組み合わせで実現しています。
この命令群は、どのように実装すればどういうふうに動いてARCを実現しているのか？
メモリの状態はどうなるのか？
最後に、どのようにstrong、weak、unownedを選定すべきか？

これらの、わかった気になっていたARCから完全にわかったARCに変える話をします

近年、ゲーム市場では高品質な3Dゲームが主流ですが、落ち物パズルゲームをはじめシンプルな2Dゲームも支持されています。また、有名ゲームエンジンのインストール料金が発表されたことで、サードパーティ製エンジンに依存しない開発の価値が再認識されつつあります。そこで、今こそApple純正の2Dゲーム開発フレームワークである「SpriteKit」が注目される時代が来たと考えています。

本トークでは、大乱闘な百人組手ゲームの開発を例に、SpriteKitを使用した2Dアクションゲーム開発の実践的なテクニックを3つのポイントに絞って紹介します。具体的なトピックは以下の通りです。

1. アーキテクチャ: SpriteKit x SwiftUI x MVVMでのクラス設計
2. 接触判定：下からのみすり抜けられる床の実装
3. UI: SwiftUIのDragGestureで実装するタップ・スワイプで方向入力可能な十字キー

このトークを通じて、SpriteKitを用いたアプリ開発のアーキテクチャ、接触判定、UIの実践テクニックを学ぶことができます。
参加者の皆様にはApple純正のSpriteKitを用いた2Dゲーム開発の魅力と実用性を感じていただき、次世代のヒット作を生み出す手助けができれば幸いです。

iOSプロジェクトにおいて、開発効率を向上させるためにマルチモジュール構成を採用する人が増えてきています。各モジュールの独立性を確保することで、スケーラビリティが高まります。

しかし、マルチモジュール構成では、一つの変更がプロジェクト全体、全てのモジュールに影響を与えるとは限りません。それにも関わらず、全てのテストを毎回実行するとテスト実行時間が長くなり、開発サイクルが遅延します。マルチモジュール恩恵を十分に受けてられていません。

この課題を解決するために、「XcodeSelectiveTesting」というツールを用いて、変更箇所に依存するターゲットのみを選定し、意図したテストターゲットのみを実行する手法を紹介します。

このトークでは、プロジェクトへの導入方法と導入で得た知見や課題を共有します。

iOSプロジェクトにおいて、開発効率を向上させるためにマルチモジュール構成を採用する人が増えてきています。各モジュールの独立性を確保することで、スケーラビリティが高まります。

しかし、マルチモジュール構成では、一つの変更がプロジェクト全体、全てのモジュールに影響を与えるとは限りません。それにも関わらず、全てのテストを毎回実行するとテスト実行時間が長くなり、開発サイクルが遅延します。マルチモジュール恩恵を十分に受けてられていません。

この課題を解決するために、「XcodeSelectiveTesting」というツールを用いて、変更箇所に依存するターゲットのみを選定し、意図したテストターゲットのみを実行する手法を紹介します。このツールはGitの変更ファイルの情報を基に、Swift Package Managerの機能などを活用して、影響を受けるターゲットを特定することができます。

このトークでは、どのように実現しているかをツール内部の仕組みを解説した上で、実際のプロジェクトでの導入事例とテスト実行時間の比較結果を共有し、具体的な適用イメージを提供します。テスト効率の向上と開発サイクルの短縮を目指す方々に有益な情報を提供します。