トーク

iOSでチーム開発をしていると、iMacやMacBookを数年おきに買い替えることが多いかと思います。
その際、使用しなくなったがまだ動作するMacマシンの使い道に困っている方はいませんか？

このトークでは、古くなったiMacの具体的な有効活用方法についてご紹介します。

弊社での活用事例としては、以下の方法があります。

1. CI/CDマシンとしての活用
   古いiMacをCI/CD専用のマシンとして利用することで、新しい機材を購入するコストを削減できます。具体的な導入手順や設定方法についてもご説明します。

2. QAチームでの不具合検証マシンとしての活用
   QAチームが不具合を迅速に検証できる環境を提供するため、古いiMacを再利用します。これにより、迅速な問題解決が可能となり、顧客満足度の向上にも寄与しました。

これにより、会社全体のコスト削減やリソースの有効活用が実現できました。

本トークを通じて、古くなったMacマシンの再活用のヒントを提供できればと期待しています。

Go on a deep dive into the commands of the Low Level Debugger

Understand from the ground level how Xcode uses LLDB under the hood:

Compile, Run, Attach, Detach, Breakpoint, Backtrace and more all from the Xcode console or Terminal command line.

Learn how to run expressions while paused in execution, reading variables in scope and printing the contents of registers

Swiftで組み込みシステムが開発できるようになると、どのような環境でもSwiftの強力な言語機能を活用できます。これにより、開発の効率性やコードの再利用性が向上し、多くの開発者にとって魅力的な選択肢となります。

これまで、Swiftは組み込みシステムなどのベアメタル環境で利用することが難しいとされてきました。しかし、最近では組み込みシステム向けのSwiftが登場し、新たな可能性が広がっています。

従来、組み込みシステムの開発は主にC言語が使われていましたが、現在ではSwiftでの実現も近い将来の話ではありません。
このトークでは、以下の内容をお伝えし、皆さんがSwiftで組み込みシステムを開発するための第一歩を踏み出せるようにサポートします。

1. Embedded Swiftとは
   • Embedded Swiftが目指す世界と、どのように実現できるのかを説明します。
2. Embedded Swiftの制約
   • 馴染みのあるFoundationライブラリは利用できません。では何が利用できるのかを解説します。
3. SwiftでRaspberry Pi Picoを動かしてみる
   • どのようにしてSwiftコードがRasberryPi Picoで動作するのか解説します。
   • Raspberry Pi PicoでLチカ（LEDの点滅）を実演します。

Swift5.9からif式/switch式が使えるようになりました。
これまでのif文/switch文とは何が違うのでしょうか？どんな嬉しいことがあるのでしょうか？swift-evolutionのプロポーザル SE-0380 を読むと、答えが書いてあります。

さて、ここで気になることがあります。そもそも、式とは何でしょうか？文とは何でしょうか？それぞれ何が違うのでしょうか？

このトークでは、Swift5.9からのif式/switch式に触れたあと、Swiftのドキュメントを読みSwiftにおける式と文の概要を理解します。次に、式と文それぞれを中心にプログラムを構成した場合の違いを比較・分析することによって、それぞれに適した使い所を考察します。

• Swift5.9からのif式/switch式
• 式、文、評価
• Swiftの4種類の式
• Swiftの3種類の文
• 式を中心にプログラムを構成する
• 文を中心にプログラムを構成する
• 式と文を比較し、それぞれの使い所を考える

本トークでは、ADPのユーザに割り当てる「役割」と権限に焦点を当てます。

ADPには、Admin / App Manager / Developer など7種類の「役割」がありますが、適切な割り当て方については余り論じられてきませんでした。

Appleは「役割」に紐づく権限仕様を公開していますが、どう割り当てるべきかのガイドラインはありません。そのためか、「できることが一番多い Admin で招待して貰っている」「依頼されるまま App Manager で招待している」といったように、何となく割り当てる運用が多い印象です。

しかし、過大な権限はリスクを増大させます。例えば、カスタムApp開発で社外メンバーに App Manager を割り当てると情報漏洩のリスクが高まります。また、委託先に Admin や Finance を割り当てると全アプリの情報を見せてしまうことになります。ADPに招待されるデベロッパー視点でも、必要以上に強力な権限は持ちたくないでしょう。

このトークでは、そうしたリスクを避けつつ、開発プロジェクトの円滑な進行を妨げないADPの権限設計について解説します。企業規模や開発体制に合わせたお勧めの「役割」割り当てモデルもご紹介します。

Predicateは、与えられた入力値に対して真/偽のテストを行うために使用される論理条件です。Core Data(もちろんSwiftDataも)、Spotlight、iCloud File Search、HealthKit、EventKitなどを使ったことがあるなら、きっとPredicateに馴染みがあるでしょう。

これまではNSPredicateが活躍してきましたが、時間が経つにつれ、NSPredicateを使う際に、特にSwiftエコシステムを中心とする場合、時代遅れと感じる点が増えてきました。こういった点を改善するため、昨年FoundationにSwift Predicateが新たに加わりました。さらに、マクロの導入により、#Predicateを使って新しいPredicateを構築できるようになりました。

NSPredicateと比較して、Swift Predicateには以下のような利点があります：

• 型安全
• Swift型に利用可能
• @Sendableに準拠
• 比較的シンプルな構文
• 自動補完（文字列への過度な依存がなくなる）
• Codableとのシームレスな連携

このトークでは、これらの利点をもとに、実際の例と活用方法を話していきます。また、まだ絶賛開発中のものであるため、その制限や将来に向けた展望についても触れます〜

Swift Concurrency が登場して以来、私が所属するプロジェクトはasync/awaitの便利さに惹かれ、積極的に非同期処理を取り入れていました。
しかし、データ競合なんてものは考えずに利用していたため、Strict Concurrency Checking対応を進めようとすると大量の警告文が立ちはだかります。
修正範囲は、データ競合が起こりうる箇所全てです。古いコードも容赦なく警告されます。

これは、全て直すべきでしょうか？

答えは様々だと思いますが、私たちのプロジェクトではサービス案件への影響を考慮して、今すぐ直さなくても良いと判断しました。

本トークでは、データ競合を許容したStrict Concurrency Checking対応について、私が取り組んだ事案をもとにお話しします。
完璧を求めないStrict Concurrency Checking対応として参考になればと思います。

主な内容は以下の通りです。

• データ競合を完璧に防ぐ必要がないと判断した理由
• データ競合を許容したStrict Concurrency Checking対応
• サービス開発に影響を出させないStrict Concurrency Checking対応案

SwiftUIとJetpack Composeは、共に2019年に発表された宣言的UIフレームワークです。これらはViewの構成方法や状態管理、副作用の表現など、多岐にわたる差異を持ちながらも "宣言的UI" という同じパラダイムを共有しています。

私たちが開発する『家計簿プリカ B/43』はAndroid版が当初からフルJetpack Composeアプリである一方、iOS版は2021年のリリース時点で全画面がUIKitベースであったという背景を持ちます。iOS版においてSwiftUIへの移行を進める中で、Android版での経験や知見が生かされる場面も多くありました。例えば、Jetpack ComposeにおけるNavigation componentの存在は、iOS 16におけるNavigationStackの登場以前から ”画面実装と遷移の分離の必要性” を示唆してくれました。

本セッションでは「2つの宣言的UIフレームワークの活用を通じた知見の環流」をテーマに、私たちがJetpack Composeから得られた学びをSwiftUIにおいてどう活かしたのか、以下の観点に絞って紹介していきます。

・State hoistingの考え方とプレビューの効率的な活用
・画面実装と遷移の分離の必要性
・複雑性の高いUI要素の実装における思考法

アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「REALITY」は、12言語で63の地域に配信されており、海外ユーザーが約8割を占めています。

グローバルユーザーに愛されるサービスになるためには、ローカライゼーションが非常に重要な課題です。
ローカライゼーションには翻訳だけでなく、各地域のフォーマットに沿った情報の表示やUIのデザインも含まれます。
このセッションでは、Swiftでの実装にフォーカスを当てた多言語対応の方法を詳しく紹介します。

紹介トピック

• 翻訳管理プラットフォーム「Lokalise」とiOSアプリへの連携の仕組み
• SwiftGenを使ったテキストリソースの安全な参照方法
• 日付・時刻のフォーマットの実装
• 数字・順位のフォーマットの実装
• UI実装の工夫と品質担保の方法

このセッションが、世界中のユーザーにシームレスにアプリを届けたい方のお役に立てれば幸いです！

問題提起:
アプリのローカライズは、多言語対応を実現するために必要不可欠なステップですが、対応するには多大なコストが伴います。
数十種類の言語に手動で対応することになれば、小さなアプリでも翻訳作業に数時間から数日、大型のアプリであればさらに膨大な労力がかかります。

解決策の提案:

1. Xcode 15で新たに導入されたxcstrings
2. Google TranslationやDeepLなどの翻訳用API
3. 翻訳自動化スクリプト
   この３つを活用して、アプリのローカライズプロセスを完全に自動化する方法について紹介します。

トークの概要:

1. 手動でローカライズを行うことによって発生するリアルなコストを説明
2. xcstringsの仕組み、従来のLocalizable.stringsとの比較
3. 自動化スクリプトの概要説明
4. プロジェクトに翻訳自動化ライブラリを組み込む方法の説明
5. 自動翻訳のライブデモ

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

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

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

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

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

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

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

プロダクトにおいて、共通デザインが定義されていないために、頻繁に利用されるボタンなどの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に対する理解も深めることができるでしょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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