トーク

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

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

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

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

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の普及により、連絡先の管理は後回しにされがちです。
連絡先を管理できていない方も多いのではないでしょうか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

みなさんはiOS 17で登場したTipKitフレームワークを利用したことがありますか？ポップオーバービューを使用して、ヒントをアプリのUI上に表示させたり、ボタンなどの要素を直接指すような表示がとても簡単に実装できるようになりました。しかし、TipKitでは表示要素のカスタマイズにはタイトル、メッセージ、画像のみという制限があります。このため、デザイン要件によっては実際のプロダクトへの採用が難しい場面も多いのではないでしょうか。

TipKitを使わなくても、SwiftUIには対象要素にスポットライトを当てた上でポップオーバービューを表示するようなオンボーディングUIを構築する道具が揃っています。Shapeプロトコルを使った吹き出しコンポーネントの作成、Preferencesによる子要素のアンカーの収集、マスキングのためのModifierなどがそれにあたります。

このトークでは、実際のプロダクト開発を通して得た経験をもとに、実際の要件を想定しアプリケーションに導入する際の設計アプローチ例も交えながら、独自のオンボーディング機能をSwiftUIで実装するアプローチをご紹介します。

WWDC23 ではさまざまなツールやアップデートが発表されました。
あれから1年・・・
皆さんはこれらの技術を日常の開発に取り入れましたか？
個人アプリに導入しましたか？
まだ導入できていなくても、安心してください！
このトークを聞けば、まだ最新技術に間に合います！

本トークでは iOS Osushi のモバイルアプリ開発で得た知見を紹介します。
具体的には、以下のツールについて基本的な使い方と導入する上でのポイントについて解説します。

• Observation
• 進化したAnimation
• ContentUnavailableView
• TipKit
• SwiftData

本トークを聞けばよりパワフルなアプリケーションを作ることができるでしょう！

iPhone Xの登場とWWDC18で発表された『Designing Fluid Interfaces』により、Fluid Interfaces（流れるような接点）を意識したUIデザインが一層注目されるようになりました。直感的でストレスの少ない、体の動きと連動した操作を実現するためには、アニメーションやインタラクション、特に画面遷移に関する理解が欠かせません。

しかし、これらの表現を実装する際、技術的なハードルを感じる方も多いでしょう。また、画面の遷移元と遷移先の「つなぎ目」に対する細部までの配慮や、滑らかな見た目と触り心地を実現するための微調整が必要です。

本トークでは、UIKitおよびSwiftUIを利用した画面遷移の基本的な処理から、アニメーションの工夫、さらにはオリジナリティを持たせるためのカスタマイズ手法まで、具体的なコード例と共に解説します。

具体的には以下のポイントをカバーします：

• 基本的な画面遷移の実装方法
• 直感的で滑らかな遷移を実現するアニメーションの工夫
• 画面遷移の「つなぎ目」を自然に見せるためのテクニック
• UIKit・SwiftUI利用時のアプローチ

このトークを通じて、参加者はUIKitとSwiftUIを駆使した美しい画面遷移の実現方法を理解し、実装へのハードルを下げることができるでしょう。

皆さん、Apple Vision Proにあわせて登場した「空間ビデオ」で撮影していますか？
私はこれまで、従来の動画に加え、VR180カメラや360度カメラで家族との思い出を記録してきましたが、立体的で没入的に再生される「空間ビデオ」は“記録”を超えて“記憶”に近い体験をもたらします。

この「空間ビデオ」はApple Vision Proだけでなく、iPhone 15 Pro/Pro Maxでも撮影できます。
まだお持ちでない方も、この体験のためだけに機種変更を検討する価値があります。

再生するためのApple Vision Proをまだ持っていない方も心配ありません。
今のうちに撮りためておけば、いずれその魅力を体験できる日が来るでしょう。
Meta Quest 3をお持ちの方なら、ソフトウェアアップデートにより再生可能です。
厳密には同じ見え方ではありませんが、十分に楽しめます。

本セッションでは、「空間ビデオ」で思い出を残すことの良さとともに

• より奥行き感を感じられる撮影方法
• 空間ビデオのフォーマットであるMV-HEVCの背景とSBS形式
• Apple Vision Pro、iPhone 15 Pro/Pro Max以外で空間ビデオを作る方法と変換する方法
  をお伝えします。

「空間ビデオ」であなたの思い出を残しましょう！

AIの著しい発展に伴い、近い将来Siriがより賢くなることが予想されます。
反面これまでを振り返るとSiriにまつわる技術はショートカットアプリやWidgetの登場とともに大きく変遷してきました。
このセッションではSiriの歴史を振り返りながら、Siri対応の開発ノウハウを紹介します。具体的には以下の内容に触れていきます。

・SiriKit
・Custom Intents と Siri
・App Intents と Siri
・「Siriからの提案」

Siriをフル活用するための開発に乗り遅れないよう、キャッチアップに役立ててください！

バグの早期発見には、コードの手戻りを早い段階で減らすことが重要です。コードレビューは、コードが仕様通りに動作し、品質が高いかどうかを評価する代表的な手法です。しかし、コードレビューの段階で根本的なアーキテクチャの問題が指摘されると、既に書かれたコードが無駄になる可能性があります。したがって、設計段階でのアーキテクチャレビューも重要です。

ただし、アーキテクチャガイドラインに基づく設計レビューでは十分な成果が得られないことがあります。これは、アーキテクチャには早期対応が必要な部分とそうでない部分があるためです。例えば、MVVMアーキテクチャでは、Viewの修正はコードレビュー時でも対応可能ですが、ViewModelの修正は早い段階で対応しないと、その影響がModelやViewに広がり修正が困難です。これは、ViewModelがビジネスロジックなど多様な責務の間でデータの受け渡しを行うためです。この例からも分かるように、重要な責務におけるデータのやり取りに関するコードは早期対応が必要です。

そこで、重要な責務のまとまりをプレゼンテーションレイヤー、ドメインレイヤー、データレイヤーの3層に分類し、各レイヤー間のデータフローをレビューすることで、早期対応が必要な手戻りを減らすことを狙います。このトークでは、設計レビューにおける各レイヤーの重要性と具体的なレビュー方法について紹介します。

iOS 開発において非同期処理を Swift Concurrency で書くことが当たり前になってきました。しかし、日々 Swift Concurrency を利用しているにも関わらず、その知識が初リリースの Swift 5.5 時点で止まっている...、なんていうことはありませんか？ Swift Concurrency は登場以降も進化を続けており、仕様変更や新機能の追加が行われています。今後も、 Region based isolation の導入や AsyncSequence への Primary associated types の追加をはじめとして、 iOS 開発がより便利かつ安全になるような変更が予定されています。

このセッションでは、基本的な Swift Concurrency の知識は前提として、主に Swift Evolution を参照しながら Swift 5.5 以降に入った、あるいはこれから入る予定の Swift Concurrency 周りの変更を噛み砕いて、できるだけ網羅して紹介することを目指します。 最新の仕様と今後の方向性にキャッチアップしておくことで、いざという時のトラブル解決や、安全で開発しやすいアプリ設計に役立つかもしれません。

ヘルスケアアプリから「すべてのヘルスケアデータを書き出す」機能を使用すると、これまでのヘルスケアデータを取り出せることをご存じでしょうか。このデータはzip形式で保存され、シェアすることが可能です。zipデータを解凍すると、いくつかのCSVデータや2GBを超える巨大なXMLデータなどが含まれています。これらのデータは一体どうやって活用すれば良いのでしょうか。

このセッションでは、iOSの巨大なXMLデータの解析方法やCSVデータの処理方法について詳しく解説します。エクスポートされたヘルスケアデータの内容を理解し、他のプラットフォームでインポートする際にも役立つ知識を提供します。具体的には、以下のポイントに焦点を当てます：

• iOSのXMLデータ解析手法
• CSVデータの効率的な処理方法
• 他プラットフォームでのデータインポート方法

このセッションに参加することで、ヘルスケアデータを効果的に活用するためのスキルを身につけることができます。

Apple から WebKit 以外のブラウザエンジンを搭載したアプリを作成するためのフレームワーク「BrowserEngineKit」が登場しました。
この機能は EU 地域で、かつ Apple の定めた要件を満たしたサービス提供者のみに限られているものの、開発者は独自のブラウザエンジンを作成することが可能になります。

しかし BrowserEngineKit はセキュリティ向上のために複数の Extensionを組み合わせてアプリが構成されるため、どのように作成すればよいのかが難解です。

本トークでは Apple が公開したサンプルをベースに独自のブラウザエンジンの作り方が学べます。具体的には以下の内容をカバーします。

• BrowserEngineKit の概要
• NetworkExtension、RenderingExtension、WebContentExtension それぞれの役割
• 各 Extension とのプロセス間通信について（XPC）

Swift Chartsは、棒グラフ、折れ線グラフ、散布図など6種類のグラフ描画をサポートし、iOS 17からは新たに円グラフも追加されました。しかし、実際の開発では仕様やデザインの要件に応じて、Chartsをカスタマイズしたり、自作する必要があるため、Swift Chartsのみでは表現しきれません。そこで今回、Swift Chartsでは実現できないグラフをPathを用いて自作する方法をご紹介します。

• Swift Chartsについて
  • 基本機能の紹介
  • Swift Chartsの拡張例
• Swift Chartsの限界
  • Swift Chartsで表現が難しいケースの紹介
  • OSS「Charts」などの他手法との比較
• Pathを用いてSwift Chartsでは実現できないグラフを自作する方法
  • レーダーチャート、メーター、多重ドーナツグラフ、ヒートマップなどの具体的な自作例の紹介

メルカリでは開発の効率化とスケーラビリティを目的としてマイクロモジュールアーキテクチャを採用しています。メルカリiOSアプリは600以上のモジュールから構成されており、各カンパニーや部署が並行して開発を進めることが可能です。Bazelによるビルドキャッシュの共有により、ビルドプロセスの効率が大幅に向上します。これにより、ビルド時間の短縮と開発の効率化が可能になります。

しかし、マイクロモジュールアーキテクチャを採用する際に直面する最大の課題は、大量のモジュール間の依存関係の適切な設定と管理です。不適切な依存関係の設定は、ビルドキャッシュの非効率な利用やビルド時間の増大、さらにはキャッシュサイズの肥大化によるインフラコストの増加を引き起こします。さらに、私が所属するメルペイが提供するいくつかの機能は、マイクロモジュールアーキテクチャに最適でないレガシーな設計のモジュールを含んでおり、これらを効果的に扱うための戦略も必要です。

このトークでは、巨大なモジュール間の依存関係をどのように管理し、適切に設定するか、そしてこれまでに直面した問題をどのように解決してきたかについて詳しく紹介します。また、Bazel以外のビルドシステムを使用している開発者にとっても役立つ、マイクロモジュールアーキテクチャの実践的な採用事例としても楽しんでいただける内容にします。

iPhoneやApple Watchからクレジットカードやイベントチケットなどを簡単に利用できるようになるAppleウォレット。
Appleウォレットにイベントのチケットを登録すると受付時のQRコード提示が楽になりますが、Appleウォレットに対応しているならGoogleウォレットにも対応していて欲しいですよね・・・？

筆者は昨年末にiOSDC Japanが運営に使用しているWebシステム「fortee（フォルテ）」のAppleウォレット・Googleウォレット連携を実装しました。
つまり、今年からiOSDCではAppleウォレット・Googleウォレットにチケットを保存できます・・・！

この発表では、その実装経験を元にAppleウォレット・Googleウォレットにチケットを保存する方法を解説します。

実装方法から本番運用を始めるために必要な準備、比較して分かる両者の類似点や相違点などなど、チケットが皆さんの端末に保存されるまでには色々な要素が詰まっています。

この発表を聞いてウォレットの世界に飛び込んでみませんか？

突然ですが貴方はデザイン上想定されない画面表示、仕様上存在しない画面表示を生み出したことはありますか？
画面の表示内容を isLoading: Bool / response: Reponse? / error: Error? のようなプロパティだけで扱っていたとしたら、通信終了後に isLoading を切り替え忘れるだけで通信が終わって結果が表示されたのに通信中表示が出たままになっている、そのような存在しない画面表示がすぐ出来上がります
上記は非常に簡単な例でしたが、画面表示内容だけに注目したデータ構造で扱っているとこのような存在しない画面表示が生まれるでしょう

本トークではそのような問題に対し、状態遷移を整理しデータ構造を作り、ステートマシンを列挙型と単方向データフローのアーキテクチャで管理することで存在しない画面表示を防止する方法を、下記のような内容で話します

• 表示内容に注目したデータ構造が生む想定外の画面表示
• ステートマシンの簡単な説明
• 単方向データフローと列挙型によるステートマシンの導入
• なぜ表示内容ではなく状態遷移からデータ構造を設計するのか
• 複雑な画面を階層化されたステートマシンで整理する例

iOSアプリを開発していて、ふと「SwiftUIでスプレッドシートのような画面を作りたいなぁ」と思うことはありませんか？ありますよね？そう、あるんですよ。
そこで私たちはスプレッドシートのように「固定行・固定列を持ち、縦横スクロールが可能なScrollView」を実装しました！

スプレッドシートのようなUIを実現するライブラリはすでに存在しています。
しかし調べた限りでは UIKit 製のものが多くSwiftUI で作られているものはなかったため、私たちのアプリにはマッチしませんでした。
そこで私たちは SwiftUI を利用した独自の実装にチャレンジし、複数のScrollViewを連動させることでそれを実現しました。

本トークでは、SwiftUIで複雑なUIを作りたいと考えている方向けに、以下のポイントについて詳しく解説します。
・スプレッドシート風ScrollViewの実装に至った背景
・複数のScrollViewを連動させる実装の詳細
・実装する上で直面した課題とその解決策
・SwiftUIで実装する際のメリットとデメリット

このトークを通じて、SwiftUIのポテンシャルを最大限に活用して複雑なUIを効果的に実装するためのヒントとなれば幸いです。