プロポーザル

PlaydateはmacOS向けエディターなどでも知られるPanic社が、イケてる電子楽器メーカーteenage engineeringと組んで開発した小さな黄色い携帯ゲーム機です。パッと見ゲームボーイのようにも見えますが、その最大の特徴は手回しクランクがついていること！

Playdateゲームの開発はLuaやCで行えますが、2024年からSwiftもサポートされました。Playdateの開発環境がおもしろいのは、音響関係のAPIが充実していることです。サイン波を鳴らしてディレイをかけ、フィルターをLFOで揺らして…といったシンセいじりの遊びを簡単にコードで書けるようになっています。件のクランクも、シンセサイザーのパラメーターや音程を調整する「つまみ」として使ったら楽しそうです。

このトークでは、SwiftによるPlaydateゲーム開発の基本と音響APIを使ったシンセサイザーおもちゃの開発事例を紹介します。さらに、そのシンセおもちゃの実演デモも行います。トークタイトルは略語がSwift Package Managerと同じSPMとなるように決めました。うまく音楽を奏でることができれば、題に偽りなしですね。乞うご期待。

名前をつけることはプログラマーの仕事の大きな割合を占めます。プロパティやメソッドの名付け方でコードの可読性やメンテナンス性が大きく変わります。Swiftプログラマーにとっては、Swift API Design Guidelinesがその命名法の指針になります。しかしそれは当然ながら英語の知識を前提としていて、そのことが非英語話者/日本語ネイティブ中心のチームにとっては障壁となります。ソフトウェアエンジニアとして各自高い英語力を持っているのが理想ですが、現実には以下のような問題や疑問が生じます：

・英語では自然な言い回しでも、チームの皆に馴染みのないメソッド名を採用すべき？
・和製英語や直訳英語がわかりやすい場合でも却下すべき？
・英語での自然な読み下し vs 接頭辞や接尾辞の当てはめルール
・コードレビューで英文法の指摘ばかりしているワタシ、実は煙たがられてない？

私たちのチームでは、これらの問題を解決するために”アベレージ日本語話者向け”コード命名法ガイドラインを作成しました。このガイドラインは、Swift API Design Guidelinesをわかりやすく噛み砕いた命名規約とその運用ルールを含んでいます。

このトークでは、ガイドラインを作成するに至った過程を紹介しながら、英語力のばらつきがあるチームでもスムーズに開発を進めるための具体的なアプローチをお伝えします。

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

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

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

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

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

毎年新しい機能が発表されますが、実際のプロジェクトでは古いOSをサポートしなければならない都合でこれらの機能をすぐに採用することが難しいことが多いです。そこで、導入したい新しい機能を古いOSにバックポートしてすぐに使えるようにする方法について説明します。

• Apple純正のバックポート
  • @_backDeployでバックポートされる機能
  • ライブラリのインターフェイスでバックポートされる機能
• OSSとして提供されているバックポート
  • SwiftUIの機能、Observability、その他の実例
• 自分でバックポートを実装する
  • どういう機能がバックポートに向いているか
  • 実装範囲の決め方

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

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

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

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

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

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

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

音は重要な要素であり、よりリッチな体験を実現するためには不可欠です。
効果音やBGMが鳴ることで、アプリの世界観を強調するだけでなく、使い勝手やユーザーの満足度を高めてくれます。
しかし、タイミングを誤ると、ユーザー体験が損なわれる可能性もあります。

例えば、多く使われているフレームワークとしてAVAudioPlayerがありますが、もしサイレントモードでも音を鳴らしたい場合には他のアプリのバックグラウンド再生を止めてしまうことがあります。また、アプリ内で特定の画面でBGMを鳴らす際には、ライフサイクルを考慮しないとアプリを閉じてもBGMが鳴り続けてしまうこともあります。

本トークでは、iOS / iPadOS アプリにおける音の取り扱いに焦点を当て、ユーザー体験への影響と対処法について解説します。
具体的には以下の内容をお話しします。

• AVAudioPlayerを使用した音の再生・停止のライフサイクルの理解
• 利用シチュエーションでの課題
  • 効果音を鳴らすと、他のアプリがバックグラウンド再生を止めてしまう
  • SwiftUIでBGMを追加したら、BGMが流れない画面でも鳴ってしまう
  • 音量の調整とその影響
• プロダクトに適合した音の利用方法の提案

このトークが、音の体験について考えるきっかけとなれば幸いです。

iOSで地図を扱うには通常、MapKitが広く利用されています。MapKitを使用すれば地図上の現在位置情報を容易に扱えますが、このトークではMapKitを使用せずに任意の地図画像上に現在位置を表示する方法について解説します。

これを実現するために、以下のポイントについて詳しく説明します。

1. 位置情報の基準点設定
2. 位置情報の許可設定
3. 現在地の表示方法
4. 位置情報が更新された際に呼ばれるデリゲートメソッド
5. 地図上の2点の緯度経度情報から現在位置のXY平面座標を算出する際の計算処理
   これらの要素を組み合わせることで、MapKitを使用しない地図アプリの基礎から実装までを網羅的に理解できるようになります。

アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「REALITY」では、デザインの一貫性や生産性を向上するためにデザインシステムを導入しています。
デザインシステムを構築するには、タイポグラフィ、カラー、UIコンポーネントなど多くの要素が必要であり、既存のプロダクトに取り入れるのは非常に労力がかかります。
このトークでは、機能開発の傍らでデザインシステムを少しずつ導入していった経験と、その中でも特に効果的だったカラーと画像アセットの自動エクスポートについて、「REALITY」のiOSアプリにおける実例を元に紹介します。

• アプリにデザインシステムを少しずつ導入していくステップ
• デザインシステムによって、アプリ全体のカラーテーマの調整が容易になったこと
• FigmaからXcodeへ画像アセットを自動エクスポートすることで効率化したこと

「家族アルバム みてね」(以下「みてね」)では、2023年10月から本格的にSwiftUIを導入し、新規画面の実装を中心にSwiftUIを積極的に使ってきました。現在約15%の画面がSwiftUIで実装されています。

みてねには「職能にとらわれずにタスクを取る」という文化が根付いているため、iOSやSwiftに詳しくない人にもわかりやすくなるよう、以下の特徴を持ったシンプルな設計を採用しています。

• プレビューがしやすい
  • 高速にプレビューできる
  • さまざまなUIの状態を簡単に用意できる
• OSSライブラリに依存していない
• みてねAndroidアプリと似た設計
• Observationフレームワークへの移行が容易

本セッションでは、どのようにして上記特徴を実現しているのか、具体的なコードを交えてご紹介します。

現在、多くのアプリではABテストが広く使われていますが、次のステップとして個別最適化が求められています。
AとBを比較するだけでなく、ユーザーの行動パターンに基づいたセグメント分割を行い、ABテストでは拾えなかったユーザーにもアプローチすることでより高い効果を得ることができます。
私たちのアプリではユーザーごとに異なる最適な課金画面を提供することで、収益の最大化を目指しました。

このセッションでは、複数パターンの課金UI検証を通じて得た以下の内容についてお話しします。

• 複雑な検証をデグレさせることなく、高速に実現するための設計と、その実装手法
• 複数パターンの課金画面を安全に運用するための工夫とその課題
• 個別最適化の成果として、ユーザーの課金率にどのような影響を与えたか

このセッションを通して、皆さんのアプリでも効果的なUIの個別最適化を実現しましょう。

Swiftは型安全な言語です。
しかし、Swiftで書かれたものが全て型安全になるわけではありません。
Swiftで書かれたコードの中にも、より型安全なコード、あまり型安全ではないコード、のように「型安全の度合い」は異なってきます。
型安全性が低いと、安全でないキャストが必要だったり、不正な入力値がコンパイルエラーにならなかったりし、開発者は多くのことを考えコードを書く必要があります。
一方で型安全性が高いと、より多くのことをコンパイラに委ねることができ、開発者が考えるべきことは減ります。

このトークではNotificationCenterのラッパーを題材に型安全性を高める方法を取り上げます。
NotificationCenterはObjective-C由来のインターフェースを持つため、安全でないキャストが要求され、不正な値を渡してもコンパイラエラーにならず、型安全性はあまり高くないといえます。
そんなNotificationCenterのラッパーの作成を題材に、Swiftの言語機能であるジェネリクスやマクロを用いて、型安全性を高めていく技術について紹介します。
題材はNotificationCenterですが、皆さんがこれからデザインするインターフェースにも通じる考え方と技術を紹介します。

このトークを通して、皆さんが"より"型安全なコードを書けるようになることを目指します。

多くのプロジェクトでは何らかのライブラリを活用してアプリの機能開発や自動化等を行っていると思います。
「家族アルバム みてね」でも、現在約30個のライブラリを活用して日々開発を行っております。

しかし、ライブラリのおかげで効率化できている一方で、ライブラリ起因の負債も多々ありました。具体的には、「更新が止まっているライブラリに依存している」「古いバージョンのライブラリを使い続けている」などです。これらの負債によって、Xcodeのアップデートでビルドエラーが発生して予想外に時間を取られたり、ライブラリの新しい機能を使えないことで追加の開発が必要になるなど、作業のスピード感に影響が出てしまっていました。

本セッションでは、依存するライブラリ起因の負債を解消するまでの具体的なステップと、負債を生まないために導入した仕組み、実際に運用してみた成果をお話します。特に以下のポイントについて詳しく説明します。

• ライブラリ周りの負債の分類と対応方法
• ライブラリのアップデートにおける仕組みづくりとQA

「Tint Colorをデフォルトのまま使うと、初心者感がありチープに見えるから避ける」
ある日の自分はそう考えていました。しかし、Appleが推奨する色をこのような理由で軽率に変更するのは適切なのでしょうか？いいえ、デフォルトの設定には、それなりの理由が存在するはずです。実際、デザインの一貫性やユーザー体験の向上を考慮した結果として、デフォルトの青色が選ばれている可能性があります。

本トークは、青色が選ばれた背景を以下の観点から考察していきます。

・他OSとの比較から見える共通点
・初代iPhone OSから現在のiOSまでのデザイン変化
・iOSとMac OS のデザインの共通点と違い
・カラーディスプレイの登場による影響
・ハイパーリンクが青色である理由
・青色が持つ視覚的効果と心理的影響について

このトークを通じて、Appleのデザイン哲学や、その背後にある考え方を深く理解することができるようになります。デフォルトの青色を軽視せず、その価値を再評価することで、より洗練されたデザイン選択ができるようになるでしょう。

「SwiftってAppleデバイスでしか動かないじゃん？」
そう言われ続け10年、しかし現状は大きく異なります。
Swiftは現在、LinuxやWindowsのような他OSでも動作することに加えて、組み込み機器での利用を想定した軽量なバージョンも提供されています。
つまりSwiftは多種多様な環境で実行できるポテンシャルを秘めているのです。

そして、それはゲームボーイアドバンス（以降、GBA）のようなレガシーなデバイスも例外ではありません。
GBA開発は誰でも手軽に実行環境を用意できるという魅力があります。
今年4月からApp Storeでのエミュレータ配布が認められたのは記憶に新しいかと思います。

しかし、GBA向けに開発をするにはいくつかの工夫が必要です。
GBA向けにコンパイルの設定をしたり、リンク時に参照できないシンボルの解決をする等、開発環境を整えるのにも一手間かかります。
本セッションでは、SwiftのプログラムをGBAで動作するようにコンパイルする方法を解説します。また、Swift Packageを使った開発環境構築、BreakPointの貼り方等のデバッグ方法、および具体的なプログラム例も併せて紹介します。

このセッションを通じてGBAの開発環境を構築する方法や、swiftcやEmbedded Swiftについての知識を得ることができます。

アプリが成熟してくると、プロユース向けに複雑なジェスチャーを実装することがしばしばあります。
本セッションでは、有名なアプリに組み込まれているユニークなジェスチャーを紹介し、その実装方法について考えます。
また、既存のアプリを壊さないように安全に実装するコツや、アクセシビリティを考慮した設計の重要性についても触れます。

• ジェスチャー例 (YouTube のシークジェスチャー や Googleマップの片手ズーム)
• ジェスチャーの実装を想像してみる
• 複数のジェスチャーを実装するときの勘所
• アクセシビリティを考慮した設計

Appleが提供する機械学習フレームワークであるCoreMLと、そのモデル生成に使用されるCreateMLを用いて、ユーザ個別に最適化された筋トレ自動計測アプリを開発しました。

一般的な流れでは、データセットとXcode付属のCreateML（GUIツール）を使用してモデルを作成し、CoreMLを用いてiOSアプリに導入することが一般的です。

しかし、以下の方法を用いることで、アプリ内でモデルの新規学習や追加学習を完結させることが可能です。

• 新規学習: 一部のモデルは、アプリ内でCreateMLから直接学習可能です。
• 追加学習: Updatableなモデルは、アプリ内でCoreMLのMLUpdateTaskを使用して追加学習が可能です。

これらの方法は、特に”ユーザ依存性の高いコンテンツ”の開発に有効です。今回は、Updatableなモデルを使用して、端末のセンサーデータを基にユーザ定義の筋トレメニューの実行回数を自動計測するアプリを開発しました。

このテーマは開発だけでなく、研究的な要素も含んでいます。以下の内容についてお話しします。

• アプリ内部でのCoreMLモデルの追加学習の手法
• センサーデータ（時系列データ）を用いたモデルにおける判定精度向上の研究
  • 学生時代に近しい研究をしていた際のノウハウ

皆さんはカメラアプリを実装したことがありますか？
iOS標準の操作感を持つカメラを簡単に実装するなら、UIImagePickerControllerが便利です。
一方で、シンプルに撮影する機能だけで良い場合や、カスタマイズが必要な場合、AVFoundationを選択することが多いでしょう。

SPIDERPLUSでは、UIImagePickerControllerで実現できない要件があり、AVFoundationを使用してiOS標準風の操作感を持つカメラを自作しました。
本トークでは、AVFoundationでiOS標準風の操作感を持つカメラを実現するまでの過程について詳しくお話しします。

<トピック>

• iOS標準風の操作感がなぜ重要か？
• UIImagePickerControllerで実現できなかったこと
• iOS標準風に感じる操作感の具体的な機能とは？
• AVFoundationを使ってiOS標準風の操作感を実装する方法

現代のiOSアプリ開発において、Web APIとの連携は避けて通れない重要な要素です。本トークでは、HTTPの標準を上手に利用する方法を中心に、効率的で信頼性の高いWebバックエンドとの通信方法を探ります。また、RESTfulなアプローチだけでなく、GraphQLなどの新しい技術を活用したデータ取得の方法についても解説します。

主なトピックは以下の通りです：

・HTTPの基本と効果的な利用法
・RESTful APIの設計と実装のベストプラクティス
・iOSアプリでのエラーハンドリングとリトライ戦略
・GraphQLの基本概念とiOSアプリでの導入事例
・バックエンドに優しいアーキテクチャ

このトークは、iOSアプリ開発者がWebバックエンドとの連携をより円滑にし、アプリの信頼性とパフォーマンスを向上させるための具体的なアドバイスと実践的な知識を提供します。初心者から中級者まで幅広いレベルの開発者に役立つ内容となっています。

モバイルアプリ開発では、たとえ新しいバージョンをリリースしてもいきなり全ユーザーが最新バージョンのアプリを利用するようになるわけではありません。旧バージョンを利用し続ける人も一定数いるため、我々は新旧バージョンにおけるデータの互換性や将来想定される仕様変更に対する拡張性を意識しながら設計していく必要があります。

例えば、アプリに永続化したデータの構造を新バージョンで変更する場合やサーバーから取得するレスポンスのフィールドに新しい要素を追加する場合、さらには旧バージョンで不具合が生じたときに新バージョンへの更新を促したい場合など、新旧バージョンと向き合わなければならないケースというものは多岐に渡ります。

すべてに対して丁寧に対応していくことも可能ですが、考慮しなければならないパターンが多く、ある程度折り合いをつけながら落とし所を探っていくことも重要です。

本トークでは、この新旧バージョンと向き合って開発していく上での戦略的な設計方針から、具体的に求められる戦術的な実装パターンまでを、体系的にお話しします。