トーク

SPIDERPLUSは、外部機器で検査結果を計測する機能があります。
外部機器との接続にはBluetoothを利用しており、ハマりポイントなどを紹介します。

• 機器の調達
• お客さんのところでは再現するが
• Bluetoothのバージョンアップ
• 機器の不具合
  など

ある日、「UIは同じで、APIの向き先・アプリ内で使用するリソース・アプリの名前・BundleID等だけを変えたアプリをいくつか作りたい」といった要望が社内で上がりました。

同じようなUIなのに別々にアプリを作り、それを一つずつ運用していくのって面倒ですよね。
Targetで分けるにしても、xcodeprojファイルをレビューする必要が出てきて同じく面倒ですよね。

そんな課題をXcodeGenを用いて解決した（swiftファイルは共通で、makeコマンドで各アプリごとのプロジェクトファイルを作成し、必要な値を全て切り替わるように対応した）内容になります。
また、アプリ完成後の運用方法についても触れようと思います。

トークの構成としては、以下を想定しております。

1. 概要の説明
   • トーク概要について説明いたします。
2. 背景の説明
   • そもそもなんでこのような要望が社内で上がったのかについて、私が所属している企業の説明も交えて説明いたします。
3. XcodeGen/実装内容の説明
   • XcodeGenとはなんぞやについて説明いたします。
   • makefile/project.yamlの中身を解説しながら、実装について説明いたします。
4. 運用について
   • このアプリの運用方法について簡単に説明いたします。

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の点滅）を実演します。

みなさんは、業務の効率化のためにちょっとしたツールを探していたのに、時間だけが過ぎてしまったという経験はありませんか？
また、やっと見つけても会社のMacに入れるには手続きが必要で、簡単には入れられなかったというような経験はありませんか？

そんな時は思い切って、自分でツールを作ってみてはいかがでしょうか！

普段iOSアプリを開発している方であれば、SwiftUIを使って簡単にmacOSアプリを開発することができます。
このトークでは、私が実際に業務改善のために開発したmacOSアプリを例に、開発の手順やiOSとの違いを詳しく紹介します。

業務改善ツールを開発しながら、macOSアプリについて知識を深めていきましょう！

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

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への移行をスムーズに進めるための参考になれば幸いです。

SFSpeechRecognizerは音声認識を利用して音声をテキストに変換することができます。
この技術を活用して、視聴者のデバイス上で完結する自動字幕起こし機能を実装しました。
本セッションでは、その過程で直面した課題とその解決方法について共有したいと思います。

紹介トピック

• 自動字幕起こし機能の概要
• SFSpeechRecognizerの実装方法とその制限
• デバイス上で処理できる言語の条件

アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「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. 自動翻訳のライブデモ