トーク

昨年11月、OpenAIはGPTsを発表しました。この機能により、ユーザーは特定のタスクを実行するためのカスタムGPTを作成できるようになりました。
例えば、Appleの公式ドキュメント2万ページを基に、SwiftUIに関する質問に回答するGPTsが作成されています。

さらに、OpenAIはGPTsの開発者に収益を分配するプログラムを開始予定であるとアナウンスしています。
これにより、さらに多くの開発者がGPTsの開発に取り組むようになるでしょう。

著者は、個人でGPTsを開発し、GPTストアで公開した経験があります。本トークでは、この経験を基に、GPTsの開発方法を前提知識なしに解説します。
具体的には、APIリクエストをおこなうアクションを登録し、GPTsを外部サービスと連携させる方法を述べます。
さらに、GPTストアに公開する際の注意点（実名を公開しない方法やJailbreakingへの対策など）についてもフォローします。

本トークを聞くことで、自分のアイデアをGPTsとして形にする方法を学ぶことができます。
あなたがオリジナルのGPTsを開発し、世界へと公開するきっかけになれば幸いです。

普段iOSアプリを開発している皆さん。 たまにはバックエンドの開発にも挑戦してみたいと思いませんか？
VaporやHummingbirdといったWebフレームワークを使うとなるとハードルが高く感じるかもしれません。

しかし、これらのフレームワークで使われているSwiftNIOというライブラリさえあれば、簡単かつお手軽にCloud RunやAWS Lambdaで動作するWeb APIを作ることができます。

本トークでは、SwiftNIOの紹介から、実際にSwiftがCloud RunやAWS Lambdaで動作する流れを説明します。
皆さんのバックエンド開発の一歩を後押しできれば嬉しいです。

概要:

1. SwiftNIOの紹介
2. AWS Lambdaの利用例 (echo bot)
3. Cloud Runの利用例 (echo bot)

登壇者: kntk, koher, niw, omochimetaru, まつじ

Swiftの次期バージョンであるSwift 6は、開発者にとって大きな変革をもたらします。特に注目すべきは、Swift ConcurrencyのStrict Concurrencyチェックによる完全なデータ競合の防止です。これにより、コードの安全性が大幅に向上し、開発効率も向上します。また、他にもコードの品質を高めるアップデートがいくつも存在します。

しかし、アップデートをするためには、コードの変更が必要となる可能性があり、「どう対応すればいいのか？」と思っている方も多いのではないでしょうか？

このセッションでは、座談会形式で、以下のテーマについて登壇者ならびに参加者の皆さんと一緒に考えていきます：

• Strict Concurrencyチェックのメリットと導入してみてわかったことや注意点
• 下位バージョンと互換性のない変更への対応策
• Swift 6への移行準備を始めるタイミングと進め方

Swift 6はオプトイン方式であり、正式リリース後すぐに対応する必要はありません。しかし、今後導入される新機能を活用するためにも、早めに対策を考えておくのはいかがでしょうか？

このセッションが、Swift 6へのスムーズな移行に向けて、皆さんの疑問や不安を解消する一助となることを願っています。

みなさんはアプリのパフォーマンス計測、やっていますか？

スクロールがカクついたり、タップしたときの応答性が悪い、意図せずCPU・メモリ・ネットワークリソースを大量に消費してバッテリー消耗を早めてしまっているなど、これらの直接目に見えにくいアプリの不具合は利用者に不満をもたらし、アンインストールにつながる恐れがあります。
アプリがアンインストールされないためにも、日々快適に動作しているかどうかを知っておくことは非常に重要です。

MetricKitはユーザー環境でアプリの電力やパフォーマンス・診断データを収集し、パフォーマンス改善に役立てるためにAppleが提供するフレームワークです。
MetricKitを活用することで継続的にメトリクスが得られ、アプリの健康状態に問題がないかどうかを開発者が知ることができます。
本セッションでは、MetricKitの基本的な使い方から実際の活用事例、活用して得られた知見をお話しします。
具体的には以下の内容を扱います。

• MetricKitの概要
• MetricKitから読み取れる情報・読み取れない情報
• メトリクスを得られるタイミングと注意点
• 事例: Crashlyticsではハンドリングできない、予期せぬアプリの終了を計測する

SwiftUIが登場してから数年経ちました。リリース当初より機能がかなり充実してきているので、SwiftUIの導入を検討するプロダクトも多くなってきたのではないでしょうか？
今回、自社のプロダクトでUIKitを用いていたプロジェクトにSwiftUIを導入したので、その経緯と導入に際して困ったこと等をお話しできればと思います。

・ UIKitの実装で解決したい問題点
・ 導入にあたって考えたこと
・ 移行の段階について
・ アーキテクチャ
・ チームメンバーの移行に対する温度感
・ データの持ち方
・ 導入にあたって困ったこと
・ OSバージョンによるSwiftUIの機能差異
・ これから目指すこと

このセッションを通じて、既存プロダクトでSwiftUIの導入を検討している方へ情報を共有できればと思います！

アプリでは起動時に様々な処理をさせたいことが多々あるかと思います。
例えば、お知らせの表示や利用規約への同意取得などが挙げられます。
また、iOSアプリは通常の起動に加えて、Push通知やUniversal Linkなど、複数の起動パターンも存在します。

メタバースプラットフォームclusterではそういった要件が増えるたびにロジックが増え、クラスが肥大化して可読性が低下し、大きな技術的負債となっていました。
また、バーチャル空間での体験をUnityで開発し、Unity as a Libraryとして取り込んでいるため、UnityFrameworkと連携する起動処理にも苦労していました。

このセッションでは、私たちが複雑な起動処理にどのように立ち向かっていったかを紹介します。

• 責務過多になっていたViewControllerからの分離
• 任意のタイミングで起動処理を実行する
• UnityFrameworkとの連携

プロダクトにおいて、共通デザインが定義されていないために、頻繁に利用されるボタンなどのUIを画面ごとに独自に作成していませんか？

メタバースプラットフォームclusterではiOS、Android、Web、macOS、Windows、Questといった複数のプラットフォームで展開しています。
サービスの成長と共に新しいデザインも増えてくる中、画面ごとに微妙に異なったボタンなどのUIデザインが散見されるようになりました。その結果、エンジニアが独断で共通化したコンポーネントを実装したり、各画面で同じような実装することも増えていました。

この問題を解決するため、各プラットフォーム共通のUIを「UI Component」という概念で統一してバラつきのあったコンポーネントをデザイナーとエンジニアで協力しながら整備していきました。
デザインシステム上で統一されたコンポーネントが定義されることで、デザイナーは管理や指定がしやすくなり、エンジニアも実装が容易になり、デザイントークンに対する認識齟齬も防げるようになりました。

このセッションでは、私たちが行った以下の取り組みについて紹介します。

• 共通コンポーネントをどう整備していったか
• 整備したコンポーネントを浸透させる
• あえて共通化しなかったUI

みなさんは、iOSエンジニアとして成長する中で、キャリアについて多くの選択肢を考えることになるかと思います。マネージャー、専門職、大企業、スタートアップ、フリーランスなど、これらはすべて重要な決断です。

私はエンジニアとして20年のキャリアを積んできました。その中で、iOSDCに関わったことが私の人生とキャリアの大きな転換点となり、モバイルエンジニアとして貴重な経験をして、今もエンジニアとして色々な経験をさせていただいています。このトークでは、私のキャリアの軌跡を基に、iOSエンジニアとしてキャリアを築き、さまざまな組織との関わりを経て、どのようにして失敗や挑戦をしてきたのか、そして、働き方の考えがどう変わっていったのかの経験や教訓を共有します。これからの皆さんの成長と生存戦略に役立つ具体的なヒントをお伝えします。なるべく一般的な話だけではなく発表ギリギリの泥臭いところを皆さんに共有していければと思います、、

発表内容：
・モバイルエンジニアとしての生存、そして成長
・大企業とスタートアップで考えるべきこと
・スタートアップでの経験、そして失敗（ポジション、報酬、組織）
・CTOになるということと会社との関わり
・成長戦略と生存戦略
・今後の展望

このトークが皆さんのエンジニアとして生存していくためのヒントとなり、次のステップに進むための道標となることを願っています。

Flutterは、単一のコードベースでiOSとAndroidの両方に対応するアプリを作成できるクロスプラットフォームフレームワークです。しかし、ネイティブアプリと比較すると、ユーザーエクスペリエンスやパフォーマンスに違いが生じることがあります。

多くの開発者はデザインを一つに統一して省エネを図るかもしれませんが、iOSネイティブの魅力に惚れ込んでいる自分としては、できる限りiOSネイティブに近づけたいと思っています。

このセッションでは、FlutterでiOSとAndroidのネイティブ感をどのように演出するかについて具体的な例を用いて説明します。具体的には、それぞれのプラットフォームに適応したウィジェットの作成方法や、プラットフォームチャネルを使ったネイティブコードの統合方法などを取り上げます。そして試行錯誤の過程で得た難しかったポイントやTips、Flutterでできること・できないことについて共有します。

ネイティブ好きだけどFlutterを使わないといけないとなっている方々にぜひ聞いてほしい発表です。

API設計に悩んだことはありませんか。例えば、以下のような点で困ることがあるでしょう。

• ネーミングが自然でわかりやすいか
• どのプログラミング言語やフレームワークの機能を利用すべきか
• 汎用性に過不足があるか
など

ガイドラインが存在するものの、全てのケースをカバーできているわけではありません。そのため、参考にしてもなかなか明確な答えが得られないことが多々あります。
そんな時に頼りになるのが、公式APIです。

本トークでは、Appleの公式APIを参考にし、具体的なAPI設計の悩みを解決する手法を解説します。この手法を活用すれば、API設計の悩みを解消するだけでなく、公式APIに対する理解も深めることができるでしょう。

Swiftが好きだけど何もわからん。自分よりSwiftを愛してて詳しい人ばかり。つらい。

Swiftコンパイラを勉強しようとして返り討ちにあった方は多いでしょう。どこから手をつけるとよいかもわからん！
「型推論ハンズオン」[omochi 2019]はSwiftの型推論にフォーカスして学ぶ合宿用ハンズオンです。未実装の部分に正しいコードを書いて型推論器を完成させ全テストをパスできたらクリアです。SwiftSyntaxを使った本物そっくりの言語が題材で、Swiftを理解したい私にはありがたい教材です。

私は「Swiftの型推論を学ぼう」[omochi 2024]を聞き、発表の元ネタであるというこのハンズオンで勉強することにしました。合宿は5年前に終了しているため1人で挑みます。

あれ？ハンズオン壊れてるよ？テスト通すどころかハンズオンをコンパイルできなくて挑戦できないよ？？
果たして私は5年前のハンズオンをSwift 5.10に対応させSwiftの型推論を†完全理解†できるでしょうか？

話すこと

• Swift 5.10対応にもコンパイラの知識を要するハンズオン
• コンパイラは入出力を理解すれば大丈夫（本当に？）
• 生存戦略：サポートを受けて成功体験を積む
• ソロ攻略の感想

昨年の『複雑さに立ち向かうためのコードリーディング入門』ではコードの読み解き方に焦点を当てましたが、今回はソフトウェア開発全体における複雑さについて詳しく解説します。

私たちエンジニアは、日々さまざまなタスクに取り組んでいます。仕様の理解、ドキュメントの作成、タスクの見積もり、チャットやミーティングでの議論、新しい技術の学習など、多岐にわたる作業があります。このような状況で、「やることが多すぎて頭がフリーズしてしまった」という経験をしたことはありませんでしょうか？

人間の脳には限界があり、その限界を超えると物事を複雑に感じてしまいます。では、この複雑さに立ち向かうために、私たちができることは何でしょうか？

実は、私たちが日常的に行っている活動の中には、必要以上に脳へ負荷をかけているものが多く存在します。この負担を認識し、軽減することができれば、複雑さから解放され、より重要なことに注力できるようになります。

本トークでは、以下のテーマについてお話しします。

• 人の脳の限界とは何か？
• 実は必要以上に脳に負荷をかけているもの
• 研究結果から見る脳の負荷を軽減するための対策
  対策には些細なものも含まれますが、そういった細かい部分にこそ落とし穴があります。そして仕組みがわかれば、多くのことに応用できます。

本トークが、皆さまの日々をより充実させる一助となりましたら幸いです。

SwiftUIで独自のボタンを実装したことがあれば、ButtonStyleを使ったことがあると思いますが、標準のスタイルはPrimitiveButtonStyleで実装されていることをご存知ですか。

本トークでは、この二つの似て非なるプロトコルについて解説します。
まず、ButtonStyleとPrimitiveButtonStyleの基本的な違いを説明し、それぞれの使い方と具体的な例を紹介します。次に、PrimitiveButtonStyleの活用方法に焦点を当て、以下のポイントについて詳しく説明します。

• Styleの組み合わせ 
• Labelのカスタム
• Actionのカスタム

本トークを通じて、ButtonStyleとPrimitiveButtonStyleの違いを理解し、実際の開発でどのように使い分けるのが適切か明確になるでしょう。

Swift Playgroundsは、iPadで動作する開発環境です。MacやXcodeを使わずにiPadで開発できるため、iOSエンジニア以外の人でも手軽にiOS開発に挑戦できます。このトークでは、DevRelである私が初めてのiOSアプリとしてごくシンプルなお絵描き練習ゲームを開発した学びを紹介します！
開発したアプリは、絵の定番の基礎練習である「正確な円を描くこと」をスコア化するゲームです。

• Swift Playgroundsとは
• 作ったアプリ
• ここが良かった！
  • ゲームで学べる
  • 操作が直感的
  • そのまま実機で動く
  • 寝転んで開発できる
• ここで詰まった！
  • OSのアップデートに8時間
  • なぜかアプリが開けない
  • なぜかアプリが増える
  • デバッグで求められる、正確に円を描くスキル
• まとめ
  • 学習アプリとしての優秀さ
  • Xcodeとの使い分け

このLTにより、人事や広報など非エンジニアのiOSDC参加者がアプリ開発に挑戦する助けになれば良いなと思います。またSwift Playgroundsを使ったことがないiOSエンジニアの方にも新たな発見と気付きになることを期待しています！

CI環境などでxcodebuildのログ出力を整形したり、テスト結果をJUnit形式のXMLとして出力するために、まだまだ（意識せずとも）xcprettyを使用している方も多いと思います。しかし、xcprettyはほとんどメンテナンスされておらず、Xcodeのここ数年の新機能に対応できていない部分があります。

そこで、xcprettyからの置き換えとしてxcbeautifyを使用してみましょう。実は、fastlaneでもxcodebuildのフォーマッターとしてxcbeautifyが推奨されるようになっています（参照: https://docs.fastlane.tools/best-practices/xcodebuild-formatters/）。

このLTでは、私たちのプロジェクトでの実体験を元に、以下の内容を紹介します:

• xcpretty使用時に直面した問題点
• それらの問題をxcbeautifyでどのように解決したか
• xcbeautifyのその他の優位性
• xcbeautifyへの移行方法

これらのポイントを急ぎ足でご紹介し、皆さんがxcbeautifyに移行する際の参考になればと思います。

WWDCはいつから始まったか知っていますか？
2010年…？2000年…？いえ、実はWWDCの始まりは1990年代まで遡ります。もっと言えばその前身となるイベントは更に昔から開催されています。
WWDCの公式サイトはその年のものに更新されていくため、10年前や20年前の情報はもちろん、30年前の1990年代の情報なんてそう簡単に得られるものではありません。

今回私は可能な限り、創設当時のWWDCや、その前身となるイベントについて調べてみました。
私たちはその年のWWDCの情報を追いかけることが多いですが、一度昔のWWDCを覗いてみませんか？

このトークは以下について話します。

• WWDCができるまで
• 初のWWDCはどのようなイベントだったのか
• 創設期から現在までどのようなものが発表されたのか

WWDCは毎年最新の情報を得る機会となるため、今や私たちのプロダクトを成長させるためには必要不可欠なイベントとなりました。このトークを通じてその歴史を探る旅へ出ませんか？

ある日、ショッピングアプリのQA中に1つのバグ報告がありました。
ショッピングアプリの主要な機能である「価格の絞り込み」や「カート投入時の数量」などで利用するTextFieldで一律「2」が入力できなくなっていました。
この致命的なバグに、全く想像もつかず、チーム全員が固まってしまいました。

最初に疑ったのはソースコードの実装。ですが、ソースコードには特に問題は見当たりませんでした。それでは、特定のOSの問題か？どうもこれも違うようでした。

いったいなぜ「2」が入力できないのか？
そして辿り着いた原因は、我々が全く想像しなかったものでした。

笑撃の結末を見逃すな！乞うご期待ください！

Swiftのドキュメントによると、subscriptsを使って集合の要素にアクセスすることができます。この機能はシンプルで、他の多くのプログラミング言語と似たものです。私たちは皆、初心者の頃からこの機能を使いこなしてきました。

しかし、Swiftにおけるsubscriptsは他の言語とは少し異なる点があります。本トークでは、以下のトピックについて詳しく掘り下げ、subscriptsの可能性を探ります。

• オーバーロード：一つの型に複数のsubscripts
• 複数の引数：単一のインデックスやキーだけではない
• ジェネリクス：whereをさらに向こうへ
• セッター：計算プロパティのように振る舞う
• 他の言語機能との組み合わせ：構文の改善

これらのトピックを通じて、subscriptsの可能性を把握、より創造的かつ効率的にsubscriptsを活用できるでしょう。

このような経験はないでしょうか。

• 共通化せずに変更が発生するたびに、全箇所を変更する必要があったり、変更漏れが出たりする
• 共通化したものの、変更が発生する際に破綻し、実装し直す羽目になる

共通化しても、しなくても適切ではない場合があり、結局経験次第と思われがちです。

ただ、共通化するかしないかの問題よりも、コンポーザブルになっていないことが問題になるかと思います。

本トークでは、以下のトピックについて紹介します。
• 「コンポーザブル」とは何か
• 単純な共通化との違い
• コンポーザブルにするための具体的な手法

競合との差異化などの理由でブランディングデザインが広く行われています。その結果、アプリの世界は多彩で魅力的なものとなりました。しかし「このアプリはiOSアプリっぽくない」と感じた経験はありませんか。それは独特性を追求するあまり、プラットフォームの文化やユーザーの習慣を尊重できず、「形無し」のデザインになってしまっている可能性があります。

このトークでは、プラットフォームの根本的な精神を見失わずにブランディングを行い、ビジネスとユーザー体験がウィンウィンの関係を築く方法を探ります。

具体的には、以下のトピックについてお話しします。

• 見逃しやすい文化や習慣
◦ 外観のバリエーション
◦ 画面遷移
◦ アクセシビリティ
• 文化や習慣を発見する方法
• 敬意を持ちながらブランディングする手法