トーク

トークの構成として以下を考えております。

1. 自己紹介

   • プロフィール、現在所属している会社と担当業務について説明します。

2. 業務未経験からiOSエンジニアになるために取り組んだこと

   • 学習方法や使用した教材、学習のスケジュールについて詳しく説明します。

3. iOSエンジニアとして業務で取り組んだこと、業務外で取り組んだこと

   • 具体的なプロジェクトやタスクの例を紹介します。
   • どのようなことを意識して実務経験を積んだか紹介します。
   • 業務外でのスキルアップ方法（例：コミュニティ参加、個人プロジェクト）についても触れます。

4. リードエンジニアにアサインされた現在から振り返って

   • リードエンジニアにアサインされるまでに特に重要だったことを振り返ります。
   • 自身の成長や学び、そして今後の目標についても述べます。

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

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

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

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

画面を作る上での典型的なシナリオとして、ネットワークからデータを読み込み、それを表示するというものがあります。このシナリオでは、データの読み込み中、エラー処理、正常系など、多くのパターンを網羅する必要があり、しっかり作り込むのは意外と難しいものです。

皆さんも、ひとまず正常系だけを作って、他の部分は後回しにしようと考えたことがあるでしょう。しかし、その結果、後からエラー処理などを追加するのを忘れてしまったり、大変な思いをした経験はありませんか？

本セッションでは、正常系に注力するために、非同期に取得する値を扱う型とそれを表示するViewを整理しました。具体的には、非同期に取得する値を扱う画面の状態を整理し、そのための値型と、それをSwiftUIでどのように扱うかを紹介します。

本トークでは、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とのシームレスな連携

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

みなさん麻雀は好きですか？僕は今めちゃくちゃに麻雀にハマっています！
麻雀は配られた手札の入れ替えを繰り返すことで役を作り点数を競うゲームです。
その腕を磨く手段として、手札の組み合わせ（牌姿）からどれを入れ替えるかを検討する「何切る問題」というものがあります。
「何切る問題」をこなすことで日々麻雀プレイヤーは雀力の向上を図っており、僕もその中の一人です。
そんな趣味が高じて牌姿の入力をサポートするアプリを作るようになりました。
今回のトークではその開発で得た知見と麻雀というゲームの素晴らしさをみなさんに共有します。

話す内容:

• 開発した牌姿入力キーボードのご紹介
• 麻雀牌にまつわるUnicodeと絵文字の関係、それらの挙動と注意点

これらの内容から麻雀にまつわる開発の知見、ひいては趣味から始めるアプリ開発の面白さを伝えます。

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

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

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

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

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

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

iOSエンジニアとしてアプリ開発に携わる上で、さまざまな画面要件を実装へ落とし込む経験を繰り返していることと思います。

「多様な画面の実装に備えて取り得るUI実装のアプローチは何か？」
「デザインや画面要件を把握したエンジニアは個々のUI実装へ向けて何を思考するのか？」

これらの一連のアプローチは暗黙的な経験則になりがちで、体系的に示される機会はそう多くありません。

本セッションは「複雑性の高いUI実装と向き合う “戦略” と ”戦術”」と題し、複雑性の高いUI実装における思考法や知見を紹介します。前半では画面状態の抽象化や類似画面における設計の構造化など、大局的なアプローチへフォーカスしてお話しします。後半では個々のUI要素にフォーカスし、仕様の複雑性を紐解きつつ破綻なく実装に落とし込むための思考法を示します。その思考においては、SwiftUIの機能群やXcode Previewsの活用を通した "iOS Specific" な考え方も模索していきます。

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要素の実装における思考法

The os_signpost API was introduced in 2018 as a tool to work in Instruments.app to analyze and fix the performance of an application

Profiling an application with os_signposts periodically will allow us to catch performance regressions

Instruments.app with os_signpost gives the developer a visual and intricate picture of what is happening in the application during performance critical segments of the app

アプリケーションのパフォーマンスを向上させるには、次のことが必要です

1. 処理に時間のかかるタスクを特定して測定する
2. そのイベントを分析して、そのタスク内でどのようなイベントが発生しているかを把握する
3. Instruments のタイムライン グラフを使用すると、アプリを高速化するために同時に実行できる操作を特定できる

iOSアプリ開発において、ユーザーに快適な操作感を提供するためには、パフォーマンスの最適化は欠かせない要素です。
最適化を行うためにはボトルネックとなっている箇所を特定する必要がありますが、どのように調査するのが効率的でしょうか？

Instrumentsはアプリのパフォーマンスを可視化するための強力なプロファイラです。メソッドの実行時間やメモリの消費量といった基本的なパフォーマンス計測から、Swift ConcurrencyのTaskやActorのトレースなど、さまざまな機能別の計測が可能です。
Instrumentsで何ができるのか、どういった情報が得られるのかを知っておくことで、パフォーマンスチューニングが必要な箇所を迅速に発見し、全体像を把握しやすくなります。

本セッションでは、Instrumentsの基本的な使い方に加え、実際のパフォーマンスチューニング事例をご紹介します。
これからInstrumentsを使ってパフォーマンス計測を始める方や、既に使っているがさらに深く理解したい方の参考になれば幸いです。

現在弊社で進めているSwift 6の対応において、Strict Concurrency Checking（厳密な並行性チェック）についてお話します。特に、弊社がCompleteモードでこの機能に対応している過程で直面した課題とその解決策に焦点を当てます。
まず、Completeモードを有効にしたことでアプリにどのような影響があったのかを詳しく説明します。そして、今後どのように対応を進めていくかについても触れます。

具体的な内容としては、以下のポイントについて詳細に解説します:
・　非同期処理で利用しているCombineフレームワークのSendable対応
・　Singletonで利用しているクラスのActor化
・　モデル層でDevice情報を取得するために使用しているUIDeviceなどの取得方法の設計見直し

これらの具体例を通じて、Completeモードへのアプローチ方法やその効果、課題について共有します。これにより、他の開発者の皆様がSwift 6への移行をスムーズに進めるための参考になれば幸いです。

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

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

紹介トピック

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

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

このLTでは、最低サポートOSをiOS15からiOS16に上げることで、アプリ開発にどれぐらいのインパクトがあるのかを説明します。

目次:

1. SwiftUIをはじめとしたiOS16の新機能や改良点を紹介し、具体例を交えて解説します。
2. 現在の世界のiOSシェアの割合を分析し、iOS 15のサポートを切ることによるリスクについても現実的な視点から説明します。
3. 世の中の有名iOSアプリがiOSをどのバージョンまでサポートしているのか、リアルなデータを紹介します。

このトークがiOS15のサポートを切るか悩んでいる開発者の判断材料として役立つことができれば幸いです。

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

解決策の提案:

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

トークの概要:

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

昨年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)

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