トーク

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

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

アプリサービスを運営する中で次の施策を検討する際には、Google Analytics for Firebase 等のアプリ測定ソリューションを使用してデータ分析することが多いです。アプリからイベントを送信して蓄積し、あとで SQL 等で分析できるソリューションですが、イベント送信の実装は注意深く行う必要があります。特に iOS アプリと Android アプリの両方がリリースされており、コードベースが異なる場合、実装差異に注意する必要があります。

実装差異を防ぐ方法の1つに Firebase のコンソールを利用した iOS / Android エンジニア間の相互確認があります。しかし表示に遅延が生じるため、細かい条件やタイミングが同じかどうかを確認するのは困難です。そこで、私たちのチームではイベントを送信するとすぐにその内容をアプリに表示するデバッグ機能を開発しました。この機能は、ユーザから見えるアプリの表示を崩さないようにオーバーレイ（最前面に半透明）で表示され、必要に応じてドラッグで移動できます。

この LT では、このデバッグ機能開発の経緯と iOS での実装方法を解説します。これにより、ユーザから見えない内部実装で iOS / Android 間の差異が発生することへの対策をしたいモバイルエンジニアに向けて、開発体制構築のヒントを提供することを目指します。

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

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

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

ObservationとSwiftマクロは、WWDC23で発表された新機能です。ObservationはSwift 5.9から導入されたデータ監視の新しいフレームワークです。Observationは対象の型にObservableマクロを付与することで、簡単に値監視可能なコードを生成し、これまで以上にシンプルなモデルを作成することができます。
Observationがどのようにプロパティを監視しているのか？に焦点を当て、Observableマクロの生成するコードを展開し、Swiftマクロで生成されたコードの解説を行います。

このLTでは、以下の内容をお話します。
・ Observationの概要
・ Expand Macroで、Observableマクロの生成するコードを展開し、のぞいてみよう！
・ 展開したObservableマクロの生成するコードの解説(Observableマクロ・ObservationTrackedマクロ・ObservationIgnoredマクロ）
・ 計算プロパティを初期化する新しい方法(SE-0400 Init Accessors)

Observationの裏側で生成されているSwiftマクロの世界がどのように広がっているのかを共有できれば幸いです。

Swift 5.9でObservationが導入されました。これはCombineのObservableObjectを置き換えるもので、iOS 17から利用可能です。iOS 17のシェアが高まるにつれ、今後Observationを採用するプロジェクトが増えると予想されます。

Observationを導入する際には、単にObservableObjectと@Publishedを@Observableで置き換えることも可能です。しかし、より積極的にObservationの利点を活かすこともできます。たとえば、エンティティをstructではなく@Observable classとして実装することでパフォーマンス上の利益が得られるケースがあります。しかし、これは値型中心の言語であるSwiftにおいては異質なアプローチです。また、CombineではViewModelが別のObservableObjectを監視する際に一手間必要だったので、そのような設計は避けられることがありました。しかし、@Observableでは同様の問題は発生しません。このように、Observationの導入がコーディング上の設計に影響を与える可能性があります。

本セッションでは、まずObservationについて説明し、その後、Observationを使ってどのようにiOSアプリを作れるのか、パターン別に解説します。

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

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

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

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

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

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

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

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

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

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

ホットリロードは、アプリを実行したまま再起動せずに実行コードを差し替えるテクニックです。Swiftは初めから動的な振舞いが少ない言語でしたが、今ではホットリロードの実現に必要な一部の機能がSwiftでも提供されています。

このトークでは、Swiftの @_dynamicReplacement の仕組みを解説し、ホットリロードを実践するためのノウハウをお伝えします。
Xcode Previewsでも使われているこの機能は、アプリの中でも使えます。例えば、アプリを再起動せずにビューを変えたり、APIレスポンスを変えたり、カメラのセッションを切らずにフィルターの実装を変えたりもできます。

下記の内容を特に詳しく解説します。動作についてはiOS/macOS/visionOSのシミュレーターと実機で確認済みです。

• ホットリロードできるバイナリのビルド
• Swiftが関数置き換えをする仕組み
• 実機向けのsandboxやコード署名

トークの対象は、提供されているツールを単に使うだけではなく、Swiftの機能を深く理解したうえで使いたい人や、ホットリロードを自分で実装してみたい人です。この機能を活用する予定が今は無かったとしても、このトークでSwiftの実行環境の理解を深める楽しみをお伝えできればと思います。

無料５分で、ディレクトリ構造の重要性や実際にプロダクトを整理した時の流れが分かる「ライトニングトーク」。
掛けた時間は40時間を突破！
効果もすぐわかると大人気だ。

CHECK!

あなたのプロジェクト構造はきれいですか？

本トークでは私が担当しているiOSアプリのプロジェクトにおいて、どのような流れでソースコードディレクトリを整理できたのか、どのような知見を得られたのかを共有します。ちょっと関係なさそうで、実は大きく関係ある熱力学の法則「エントロピー増大の法則」から始まり、ここからどのように私がディレクトリ構造に向き合い、そして解決していったかについて紹介します。

本トークを通じて、あなたのディレクトリ構造も整理するきっかけにしませんか？

Unlock the Power of Query Parameters with Moya: Dive into the intricacies of crafting dynamic API requests using Moya, the elegant networking library for iOS development. Learn how to effortlessly handle arrays, dictionaries, and complex nested structures within query parameters. Sometimes the server side demands the app's native side pass these kinds of complex parameters. This knowledge is not written on the internet enough, so you must check out this session. Elevate your app's networking capabilities and streamline your code for maximum efficiency in just 5 minutes!

標準SwiftUIでは美しいインターフェースが提供されています。
一方、ディベロッパがViewを構築する際のガイドラインは提供されておらず、どのようにコードを書けば良いか迷うことも多いかと思います。

2019年のSwiftUI発表以来サイボウズではプロダクションでSwiftUIを使ってきました。
その中でモジュール分割やライブラリ化を経験し、優れたViewインターフェース設計に共通の性質があることがわかってきました。

• Single-responsibility Modifier
• Applying appearances with ViewStyle
• Injecting Content
• Operate via proxy

このトークではこれらの性質を踏まえて、標準のSwiftUI APIによく馴染み、メンテナブルで美しいコードを設計するためのiOS向けテクニックをコード例と共に紹介します。

このトークが皆様のView設計の助けとなることを期待します。

人類は数多のマルチ・クロスプラットフォームに夢を見てそして枕を濡らしてきました。
今宵、もう少し夢を見ましょう。

KotlinはJVM互換の言語かと思いきや、iOS・WebフロントなどのプラットフォームでもKotlinでかける技術「Kotlin Multiplatform(KMP)」のプロジェクトが始まり、つい最近Stableバージョンまでたどり着きました。
アプリ全体をKotlinにする必要は無く、ビジネスロジックの一部分だけの置き換えでも使えるというのが大きな特徴です。

また、Androidアプリ開発では、Googleが開発しているAndroid Jetpackと呼ばれるライブラリ群があります。
これらにはAndroidアプリでの推奨アーキテクチャを実現するためのライブラリ(ViewModel)やSQLラッパー(Room)などが存在します。
そして、これらのJetpackライブラリ群も最近KMPに対応したバージョンがどんどんリリースされており、iOSプラットフォーム上でも使えるようになっています。

このLTでは、そのようなKMP対応のJetpackライブラリの使い方を紹介します。
そして、KMPとJetpackライブラリを既存のiOSアプリに組み込むことで、Android側とどの段階までコードの共通化ができるのかを紹介します。

夢が現実になるといいですね。

「あなたが一番使い慣れたIDEは何ですか？」この質問に対する私の答えは「Visual Studio」です。Swift以外の言語をメインで開発していた人がiOS開発を始める際、基本的にXcodeを使うことになると思います。
しかし、Xcodeで開発をしているとき、無意識に慣れ親しんだショートカットキーを押してしまうことがありませんか？

Xcode以外のIDEからXcodeを使うことになった開発者は、そんな経験をしたことがあるのではないでしょうか。
本LTでは、元々Visual Studioユーザーだった私が、Xcodeで開発する際に、Visual Studioと同じ使用感で開発できないかと試行錯誤した取り組みをご紹介します。

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

・XcodeのKey Bindingsカスタマイズ方法
・Visual StudioのショートカットキーをXcodeに再現する方法

これらのポイントを通じて、Xcodeを自分にとって快適なIDEにする方法をお伝えします。

UIテストの代替手段として、意図しないデザインやレイアウト崩れを検出できるsnapshot testが広く採用されつつあります。
一方、Scrollableな画面はそのままでは画面全体のsnapshotが撮れないため画面外の要素で検知漏れが発生するなどFlaky Testになりがちです。

UIKitの時代はScrollView内部のviewを直接取得してsnapshotを撮るといったことが可能でした。
しかし、SwiftUIではViewというprotocolで隠蔽されるため正攻法ではScrollViewを取得することができません。

本トークでは、UIKitからSwiftUIへ移行する過程で躓いたScrollViewのsnapshot test問題を力技で解決した後、プライベートAPIを使ってその力技を不要にするべく試行錯誤した話をします。

話すこと

• UIKitでScrollView内部のsnapshotを撮る方法
• SwiftUIでScrollView内部のsnapshotを撮るために行った力技
• プライベートAPI(_VariadicView)を使ってScrollViewの中身を取り出す方法

話さないこと

• snapshot testのライブラリについて
• _VariadicViewそのものの深堀り

皆さんはThe Composable Architecture(TCA)をご存知でしょうか？TCAはSwiftでアプリケーションを構築するためのライブラリで、状態管理が容易、コードが小さく分割できる、テストコードが書きやすいなどのメリットがあります。こちらのライブラリはリリースされてから4年が経過していますが、頻繁にアップデートされており、これまでに7回のマイグレーションガイドが発表されています。

私も個人開発でTCAを使用しながら学習を進めていますが、最新の実装方法がわからずに苦労することがありました。
本LTではTCAのマイグレーションガイドを読み解き、以下のポイントについて発表します。

・TCAの実装方法の変遷
・TCA最新版での実装方法

TCAの変遷と現時点での最新の実装方法を知ることで、これからTCAを導入したい！という方の負担を少しでも楽にしたいと思います。

iOSエンジニアといえど、XcodeGen、SwiftLint、GitHub Actions、Bitriseの設定などでYAMLを書く機会はありますよね？さてこのYAMLというやつ、何者なのか理解していますか？

このトークでは、iOSアプリエンジニアでも知っておくべきYAMLの基本について話します。YAMLときちんと向き合うことで、きっと前より設定ファイルがスラスラ書けるようになるはずです…！

Topics
・YAMLとは
・YAMLの基本的な書き方
・どっちが正しい書き方？クイズ形式で学ぶYAML

▼ 概要
私たちは「あたらしい旅行を、デザインする。」をミッションに旅行アプリ「NEWT (ニュート)」を日々開発しています。
NEWTは初期の開発初期段階からSwiftUIの導入を行なっており、開発開始から3年が経ちました。
みなさん、SwiftUIでの記法のルールは定めていますか？
宣言的UIの登場で開発のしやすさが増すと同時に、複数人で開発を行うと自由度が高いがゆえに記法揺れが起きると思います。
その一例としてStack.space/padding/Spacerをどのように利用しているか、ルール化しているかをお伝えします。

▼ 内容

• SwiftUIにおけるスペースの付け方の種類について
• スペースの付け方を間違えることで起きうる問題
• 記法揺れを防ぐために具体的に定めているスペーシングのルール

海外で作られたアプリで、デザインのクオリティは高いのに日本語フォントが残念でチープな見た目になっているアプリを見たことはないでしょうか？

グローバルに展開するアプリではローカライゼーションはもちろんのこと、現地に馴染みがあるフォントを選ぶこともアプリの魅力度を上げる1つの手段です。
本セッションでは各言語ごとに異なるフォントをどのように管理しているかについてご紹介します。

【ポイント】
・ロケールごとに異なるフォントを用意するべきケースとは？
・メリット＆デメリット
・iOSプロジェクトでフォントの使い分けを簡単に管理するには

▼ 概要
私たちは「あたらしい旅行を、デザインする。」をミッションに旅行アプリ「NEWT」を日々開発しています。
その中で、カスタマーに届ける「品質」と「スピード」を両立させるための手段の1つとして、「GraphQL」・そのクライアントとして「apollo-ios」を利用しています。

カスタマーは、「予約時に知りたい人気ツアーやホテルの情報」・「実際の旅の途中で必要な自身の予約情報」など、場面ごとに最適な情報を、最速で閲覧・利用したいと考えています。私たちは、カスタマーに旅行の出発前から帰国後まで、一生の思い出となるような最高の体験を提供する責任があります。そこで、そうしたニーズに応えるための有効な手段の１つとして、実際にどのようなキャッシュ戦略を駆使しているのかをご説明します。

また、高速なデリバリースピードは高い品質維持の上で成り立ちます。GraphQLを用いた開発過程おいて、スピードを落とさずに品質を高め続けるために、どのようにして土台を整えているかの具体的な方法についてもお話しします。

▼ 内容
・ NEWTはなぜGraphQLを採用しているのか
・ apollo-iosを用いたキャッシュ戦略
・ GraphQL Schemaから自動生成されたSwiftコードを、TestDoubleとして利用するための自動生成戦略