エンジニアリングマネージャー（以下、EM）という仕事について、みなさんはどんなイメージを持っているでしょうか？

「EMはツラい仕事」「EMになるとコードが書けないから嫌」と敬遠されがちな役割ではありますが、一方で、iOSDCの参加者の中にはすでにEMとしてお仕事をされている方、（ポジティブにせよネガティブにせよ）将来のキャリアパスとしてEMをイメージしている方もいるのではないでしょうか。

近年、マネジメントに関する記事・書籍は増えてきたものの、環境や組織によって異なるEMの仕事について、具体でイメージするのはなかなかに困難です。

そこで本トークでは、私自身のトータル5年ほどのマネジメント経験をもとに、EMが普段どのような視点で業務をしているかをお話しします。
具体的には下記のようなトピックでお話をする予定です。

• マネージャーとは何をする仕事か？
• マネージャーの持つべきスキルとマインドセット
• マネージャーにとってのエンジニアリング
• マネージャーの悩みと苦しみ、それらへの対処

本トークをEMの一つのサンプルとして、将来のキャリアとしてマネージャーを考えている方や、すでにマネージャーとして活躍されている方にとってのヒントになれば幸いです。

Flutterでは宣言的UIが利用され、SwiftUIもいわゆる宣言的UIとなっています。
ドメイン層を設計し、その上でUI層を考えて設計することが非常に重要です。
特に、画面のデザインに設計が引っ張られることで以下のような問題が発生することがあります。

・DDDのコアドメインにUIの知識が混入する
・ドメイン層の知識がUI側に漏れる
・ドメイン層の設計がうまくできていないため、拡張性が低い

これらのアンチパターンを避けるためには、しっかりとした設計と実装が必要です。
本セッションでは、よくあるCRUDの初歩的なシステムを例に、DDDの知識を基にした設計とその後の実装方法について解説します。
独自の視点や経験を交えながら、システム構築のアプローチを総合的に紹介します。

話の進め方としては以下の通りとなります。

1. CRUDの要件定義
2. DDDの基本概念
3. 設計プロセス（ドメインモデル図とユースケース図の作成）
4. ドメイン層の実装
5. UI層の実装
6. テストコードの作成
7. まとめ

この流れを通じて、個別の知見を総合的にどう活かしてシステム構築を行うか、大きな視点でのアプローチを紹介します。
これにより宣言的UIを用いたシステム開発において、DDDの知識をどのように適用し、良い設計と実装を実現するかの手助けとなれれば幸いです。

次世代の空間コンピュータである Vision Pro は、クリエイターに新たな可能性を提供します。この画期的なデバイスは、リアルとデジタルの境界を曖昧にし、今までにない没入感とインタラクティブな体験を実現します。特に、Blender で作成した 3D モデルを Vision Pro で使用することにより、これまで想像していた以上の現実感を持つプロジェクトを構築することが可能です。あなたも自慢の自作 3D モデルを目の前に配置してみたいと思いませんか？

トークでは、Blender で作成した 3D モデルを Vision Pro で活用するための具体的な方法を解説します。

• Blender で作成した 3D モデルの連携方法
• アニメーション付き 3D モデルの連携方法
• RealityConverter を使用して、USDZ 形式に変換する手順
• モデルのテクスチャやマテリアルの最適化方法、インタラクティブ要素の追加

Blender に馴染みの薄い iOS 開発者でも自身のプロジェクトにすぐに応用できる情報を得ることができます。Vision Pro の可能性を最大限に引き出すためのノウハウをこのセッションで学び、次世代の Vision Pro 体験を共に創り上げましょう！

Apple Vision Proで見ている視界に、手元で操作しているiPhoneの画面をリアルタイムで表示する実装方法について解説します。

通常、visionOSではiPhoneの画面を直接表示することはできません。
しかし、送信側のiOSアプリと受信側のvisionOSアプリを実装し、連携させることでこの表示を実現しました。

空間に浮かぶ美麗なiPhone画面は、存在感がありとても魅力的です。
この表示を実現するためには、多くの試行錯誤と調査が必要でした。

このセッションでは、以下の要素をどのように連携させるかについて、具体的なソースコードと共に解説していきます。

• Multipeer Connectivity
• CAMetalLayer
• ReplayKit: iOS System Broadcast
• VideoToolbox
• WebSocket
  さらに、会場でライブデモも行いますので、実際の動作をその目で確認いただけます。

このセッションを通して、ワクワクする機能実装の知見を皆様と共有できることを楽しみにしています。是非ご参加ください。

UI実装において、同じViewを複数箇所で実装してしまうと、デザイン変更に対する更新漏れや、実装箇所ごとにUIの差異を生んでしまうことがあります。こうした一貫性の欠如は、ユーザーにストレスを与える要因となります。これらの課題に対するアプローチの一つにデザインシステムがあります。デザインシステムとは、コンポーネントやスタイルガイドなどのプロダクト開発に必要なリソースセットです。デザインと実装がシステムとして相互連携することで、一貫性のあるUIを効率的に実装できます。

しかし、デザインシステムの構築は容易ではありません。さまざまなリソースが必要で、構築には時間がかかります。また、デザインと実装が相互連携できるようにコンポーネントを作成する必要があります。さらに、プロダクトの進化に合わせて継続的に改善できるようにする必要があります。

本トークでは、以下のトピックを中心に、私が携わるプロダクトのデザインシステム構築におけるiOSエンジニアの具体的な取り組みをお話しします。

• 機能開発と両立させるデザインシステムの部分的な導入
• 相互連携のためのスタイルレビュー会とコンポーネントのAPI設計
• SwiftUIの標準APIを活用したメンテナブルなコンポーネント実装

このトークが、デザインシステムの構築、そして一貫性のあるプロダクトを効率的に開発するための参考になれば幸いです。

Flutter Add-to-App（以下A2A）は、既存のネイティブアプリにFlutterを部分的に統合する機能です。
2023年2月、マネーフォワード MEは新サービスのリリースに伴い、A2Aを導入しました。

この技術的挑戦から1年以上にわたる開発において、iOS/Androidの実装の共通化による開発速度の改善や、例えばアプリの仕様策定やデザインなどの業務の大幅な削減など、全体的な開発生産性が飛躍的に向上しました。
また、新しい技術を取り入れることで生じた課題にも迅速かつ効果的に対処するため、GitHub Actionsなどのツールを活用したいくつかの自動化プロセスを導入しました。
A2Aの導入はさらに、iOS/Androidエンジニア間や他チーム、他部門とのコミュニケーションを促進し、プロジェクトチーム全体の協力体制を強化できました。

今回のトークでは、これらA2Aの導入による開発環境の改善や、具体的な自動化プロセスやAndroidの連携方法などについて詳しく説明します。

ABEMAは「新しい未来のテレビ」として多様な動画コンテンツを提供しています。2024年2月から「ABEMAプレミアム」に加え、新たな課金商品の提供を開始し、課金商品の設計とAB検証が重要な役割を果たしています。本セッションでは以下の内容を解説します。

1. 課金商品設計
   ABEMAの課金商品設計は、ユーザーの利便性とビジネスの持続可能性を両立させています。サブスクリプションと都度課金の2つの商品を採用し、ビジネス面とアプリ内課金のバランスをどのように取るかを説明します。
2. AB検証の重要性
   AB検証は、課金商品の効果を測定する重要なツールです。異なる商品をユーザーにランダムに割り当て、その結果を比較して最適な設計を見つけ出します。AB検証の設計、実施、結果の解釈について詳しく説明します。
3. 課金商品設計とAB検証の実例
   具体的な事例を通じて、ABEMAの課金商品設計とAB検証のプロセスを解説します。
4. 今後の課題と展望
   最後に、課金商品設計とAB検証における今後の課題と展望を議論します。新たな課金モデルの開発や、精緻なAB検証の実施など今後の取り組みについて述べます。

このセッションを通じて、参加者がABEMAの課金商品設計とAB検証の具体的なプロセスを深く理解し、自社のアプリ開発やビジネス戦略に応用するための実践的な知識を得られることを目指します。

2019年にiOS 13とともにSwiftUIがリリースされ、早くも5年が経過しました。
SwiftUIは年月を重ねるごとに改良や進化を続け、今や多くのSwiftUI情報が世の中に溢れかえっています。

そんな時代だからこそ、少数派になりつつも、依然として使われ続けているUIKitに着目します。
UIKitにはStoryboardやxibなどのInterface Builderを使ったUI生成方法がありますが、
このトークではコードによるViewControllerの作成に焦点を当てます。

• Storyboardのコードへの移植
• loadView、viewDidLoadなどのsuperメソッドの使い分け
• コードで柔軟なレイアウトを構築する

などなど、SwiftUIの普及が進む中で、失われつつあるViewControllerのコード生成方法をまとめたいと思います。

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