トーク

SwiftUIでSwift Package Manager（SPM）を使用したマルチモジュールプロジェクトにおいて、循環参照を回避するための依存関係解決方法を紹介します。本LTは、循環参照の問題にフォーカスし、具体的かつシンプルな解決策をお伝えすることを目指しています。

具体的には、以下の構成でトークします。

1. 循環参照の発生例の紹介
2. 循環参照を回避するためのモジュール構成を考える
3. 依存解決するためのコードを5行で実装

依存関係解決にお悩みのそこのあなた、即実践可能な解決策をお届けします。

皆さんもご存知の通りXcodeにはショートカットがあります。
タブの移動、ビルド、コンソールの表示/非表示、シミュレータの選択、カーソルの移動などなど…。
いちいちトラックパッドやマウスまで手を動かさなくてもキーボードだけで完結できるのではないかと思えるほど多様です。
手間を減らすだけでなく、Xcodeの機能を深く知るきっかけにもなります。

そんな素敵なショートカットを時間の限り紹介します。

タップルでは、毎年最新技術への対応とセキュリティ向上を目的に、一定の閾値を任意の数値が下回った場合、下位iOSバージョンのサポートを終了してきました。
しかし、iOS15のサポートを終了すると、iOS16にアップデートできない端末が複数あるため、アプリが使用できなくなるユーザが発生してしまいます。
都度課金でもなくフリーミアムでもない、課金ユーザからの売り上げがほとんどを占めているタップルにとって、iOS15のサポート終了は"売り上げに大きく関わる"決断です。

当然ビジネスチームからは、「売上に大きな影響が出るのでは？」という懸念が出ました。
今回私たちは、ビジネスチームと一方的に対立するのではなく、ユーザの利益、会社の利益、そしてiOSチームの利益のバランスを考えながら、適切な決断を行うために協力しました。

本LTでは、我々がどのようにビジネスチームや分析チームとコミュニケーションを行ったのか、また、その過程でどのような解決策を提案し、どのようにしてiOS15のサポートを終了するに至ったのかをお伝えします。
目次

1. ビジネスチームとの売り上げ影響に関する議論
2. 売り上げ影響を可能な限り下げるための提案と実践
3. 結果と改善点

iOS16(iPadOS)以降に提供させれているSwiftAPIであるRoomPlanはすごい速度でお部屋をスキャンしてミニチュアハウスを作れます。

普段地図や位置情報で楽しく遊んでいる私が、どのように自身の活動にiOSのアプリ作成を取り入れ、RoomPlanにより作成したデータを利用しているかを5分で話し切ります。
モバイルアプリケーションを専業とされている方のみならず、測量や建築、環境デザインに携わっている方など周辺領域に広く届くように、アプリケーション構築が気軽に行えることをお伝えすることもテーマの一つです。

旅行先でもスキャンがしたくてたまらないようなモバイルスキャン星人を増殖させます。

友人と 2 人で参加したハッカソン．
私たちは推しのフラクタル図形であるマンデルブロ集合を描画するアプリの制作を決意する．
ただマンデルブロ集合を描画するため，先人たちの築いてきたUIライブラリを無視して 1 枚の長方形を設置する．

このLTではほぼ初めてであったiOSアプリの開発の体験をもとに，MetalKitによるシェーダーの利用とマンデルブロ集合についての紹介をします．

※マンデルブロ集合：数学的に定義される複素数の集合であり，複素平面上では自分自身のミニチュアがそっくりそのまま自分の中に入っているような特徴を持つフラクタル図形の一種である．描画には膨大な計算量を要するが，シェーダーをはじめとした並列計算によってより効率的に描画することができる．

普段はIoTエンジニアをやっています。最近はUWBで遊んでいます。UWBのモジュール同士で通信させてもつまらないです。やっぱりスマホでUWBを捕まえて遊びたい！ でもAndroid勢はUWB搭載してるやつがほとんどいない。そうだ、久しぶりにiPhone用のアプリを作ろう！ 大丈夫！だって12年前まではObjective-CでiOSアプリ何個も作ったことあるもん！ ・・・はい、大変でした。そんな話です。

みなさん、「SwiftUIを用いたプロジェクトのビルド時間を短縮したい」と考えたことはありませんか？

iOSDC2021以降、SPMマルチモジュール構成をプロジェクトへ採用するサービスが多く見られます。
マルチモジュール構成では、小さくモジュール分割を行い依存を疎結合に保つことでビルド時間の短縮が期待できますが 画面遷移時にFeatureモジュール同士で呼び出しを行い、依存関係が密結合になっている場合、ビルド時間の短縮が効果的ではありません。

本LTでは、Protocolに各画面の生成処理を記述し、画面遷移先を抽象化してDIする手法を紹介します。
これによって、SPMマルチモジュールにおいて、疎結合な画面遷移が可能となり、効果的にビルド時間の短縮が可能となります。
また、複数のDI手法や画面遷移実装を比較し各手法のメリットデメリットを紹介していきます。

以下の順番に従い、各実装の問題点と解決策を交えながら説明します

• SPMマルチモジュールの導入
• NavigationStack を用いた MainApp での"単純な"画面遷移
• RouterProctocol を定義し画面生成処理を抽象化
• DIを用いた疎結合な画面遷移を可能に
  • @Environment を用いた一般的なDI
  • swift-dependencies を用いたリッチなDI

「急にグラフを実装することになったけど、Swift Chartsを使えばSwiftUIでグラフを実装できるってのは聞いたことあるなぁ〜」「iPhoneの標準アプリでこんなグラフの機能があるからできると思ってたけど、触ってみたらAPI多すぎるし、ドキュメント見ても実例とかほぼ無いしよく分かんないな〜」「他の開発も並行しているから1個1個検証してる時間なんてないし…」「あ〜〜〜！どこかに、グラフでよくある機能の実装方法を、時間がないから5分で…しかも一気に知りたいから『10選』も教えてくれる…そんなLTがないかな〜〜〜！」

…と思ってるそこのあなた！！！
このLTではSwift Chartsを使って、よくあるグラフ機能の実装方法10選を5分で共有します！
グラフの見た目や軸のカスタマイズ、注釈の表示、タップやスクロールを可能にしたり、アニメーションをさせたりなどよくある機能の実装方法について話します。

Swift Chartsでこんなグラフを描画したいと思ってもドキュメントは文字だらけで実際どう実装するかは中々探せません。自分はドキュメントのほとんどを読んでまとめ記事を書いた程です。
https://qiita.com/yamakentoc/items/55a7d7264691b2caf592

このLTを通じて、あなたのアプリにすぐにグラフと便利な機能を追加してみませんか？

SwiftのInt型は、数値計算からコレクションのインデックスとしての利用まで、幅広い用途で使用されています。しかし、Int型がどのプロトコルに準拠しているのか、具体的にはどのような機能を提供しているのかを深く理解している開発者は意外に少ないかもしれません。そこで、私がApple Developer Documentationを調査し、Int型が準拠しているすべてのプロトコルをリストアップしました。

しかし、これらすべてを時間内に紹介するのは難しいため、特に興味深いプロトコルを厳選してご紹介いたします。例えば、数値操作に関連するプロトコルや、CustomStringConvertibleプロトコルといった意外な用途に対応しているプロトコルについて解説します。

Swift でできることは最近どんどん増えています。その中に Swift でマイコンを開発するツールもあります。

特に有名なのは Mad Machine が作った開発ボード、SwiftIO です。しかし、SwiftIO だと、専用の開発ボードが必要で、始めるには、ハードルがかなり高いです。

実は専用のハードウェアがいらない、今すぐ始めるものがあります！それは Swift for Arduino です！Arduino があれば、Swift でマイコン開発できます！

みなさんも Swift でマイコン開発始めよう！

Apple Vision Proの登場は、空間コンピューティングという新たなパラダイムを私たちにもたらしました。3Dインターフェース、視線・ジェスチャー操作、そして圧倒的な没入感。これらの要素は、アプリ開発にどのような変革をもたらすのでしょうか？本トークでは、Apple Vision Pro開発の基礎から、visionOSの主要機能、そして空間コンピューティング時代のUI/UXデザインまでを網羅的に解説します。

対象者
Apple Vision Pro開発に興味があるエンジニア、デザイナー
空間コンピューティング、3Dインターフェースに興味がある方
SwiftUIを用いたアプリ開発経験のある方
新しいテクノロジーに挑戦したい方

iOSアプリ開発はMacが無いとできないと言われており、ハードルが高いと感じる方も多いですよね？

Macはもちろん、iPhoneなどのApple製品を一切持っていない方。 また、WindowsやLinuxのパソコンすら持っていない方でも、この方法でアプリをリリースすることができるかも？！
世界一のローコストで行う、限界iOSアプリ開発の実践方法をお伝えします！ SwiftUIで作ります！ (まっとうなiOSエンジニアにはガチでお勧めしません！)

※ キーワード: CI (Xcode Cloud, GitHub Action), fastlane (fastlane Snapshot)

皆さんは Crashlytics の非重大ログを活用したことはありますか？
非重大ログを収集する際には Objective-C の NSError オブジェクトを使用する必要があります。
しかし、日常的には Swift の Error 型を使用して開発することが多いため、NSError を直接利用する機会は少ないのではないでしょうか。

本発表では、Swift の Error 型から情報量豊かな NSError に変換する具体的な方法について解説します。
例えば、LocalizedError や CustomNSError を活用することで、Swift の Error 型の概念を保ちながら NSError に豊富な情報を付加できます。
これにより、NSError の存在をあまり意識することなく、Crashlytics の非重大ログをより価値の高いログへと進化させることができます。

ここ最近、Flutterでの開発に注力してきましたが、SwiftUIも試してみたいと考えています。

SwiftUIとFlutterは、どちらも宣言的な記述でUIを構築するためのフレームワークです。
本トークでは、SwiftUIとFlutterを使って実際にUIを構築してみたコードサンプルを通して、
それぞれのフレームワークの特徴や利点、または欠点について比較します。
具体的なコードの記述の違いだけでなく、開発環境含む開発体験の違いについても語ります。

SwiftUIかFlutterかどちらを採用すべきか悩んでいる方や、
他のフレームワークの書き味や考え方もなんとなく掴んでおきたい方の参考になれば幸いです。

昨今のモバイルアプリの開発現場では、マルチモジュールというのが一つのトレンドになっています。
また、WWDC2019で発表されたSwiftUIを採用するプロジェクトも増えており、モバイルアプリの開発環境、トレンドは大きく変わりました。
開発環境やトレンドが遷移した一方で、企業が求める変わらない要件というものは多くあると思います。
そのうちの一つにディープリンクが挙げられます。
しかし、業界において、SwiftUIを採用したマルチモジュール構成のプロジェクトでディープリンクを考慮に入れた画面遷移戦略の知見が不足している様に感じました。

本セッションは上記の様な構成のプロジェクトにおける実装戦略の提言と、業界でのSwiftUIとマルチモジュール構成を採用したモダンな開発環境の採用を促進することを目的としています。

本セッションで取り扱う内容
・SwiftUIにおける画面遷移方法の簡単な比較
・マルチモジュール構成のプロジェクトにおけるNavigationStackを活用した画面遷移戦略
・上記の実装の中でのディープリンク対応戦略とTIPS

本セッションで取り扱わない内容
・マルチモジュール構成のメリット/デメリットについて
・ディープリンク対応のためのライブラリ選定について

#SwiftUI #マルチモジュール #SPM #ディープリンク #NavigationStack

SwiftUIの登場により、iOSアプリ開発におけるアーキテクチャ設計は新たな局面を迎えています。宣言的UIというパラダイムシフトの中で、状態管理やデータフローはどのようにあるべきでしょうか？本トークでは、SwiftUIと相性の良いアーキテクチャとして注目を集めるThe Composable Architecture（TCA）について、基礎から実践的な活用方法までを解説します。

対象者
・SwiftUIを用いたiOSアプリ開発に興味があるエンジニア
・従来のアーキテクチャに課題を感じているエンジニア
・The Composable Architectureについて学びたいエンジニア
・SwiftUIでより保守性、再利用性の高いコードを書きたいエンジニア

Swift6からSwift Concurrencyにおけるコンパイル時のデータ競合のチェックが厳しくなり、今まで動いていたコードがコンパイルエラーになる可能性があります。
Xcodeでは、Strict Concurrency Checkという機能が用意されており、Swift5の時点から段階的に移行できるようになっています。

Strict Concurrencyに完全に対応するためには全てのUIViewControllerをMainActorに隔離する必要があり、粛々と対応を進める中…
人類は思い出した。deinitはactor隔離に対応していないということを。

どうしてもdeinit内で行いたい処理があるんだがどうしようか？公式で対応する予定はあるんだろうか？
——などとやっているうちに、半年が過ぎた！
その間、特に何もなかった！

今回の発表では、UIViewControllerのdeinitのせいでStrict Concurrency対応に困った場合、どのような代替案があるのか、将来性はあるのか、についてお話しします。
俺たちの冒険はまだまだ続くのか？Kiichi先生の次回作にご期待ください！

2019年年末、私は30歳で、それまでのキャリアを捨て新たな道を選びました。
アプリ開発を独学で開始し、1年後にはリリースした筋トレ管理アプリを武器に、ヘルスケアスタートアップにiOSエンジニアとして入社しました。
その後、気がつけば3年半の年月が経ち、現在はiOSエンジニア兼プロダクトマネージャーとして活躍しています。

本トークでは、エンジニア未経験からプロダクトマネージャーになるために私が実践した具体的なステップと、その過程で学んだプロダクト思考の重要性についてお話しします。
このトークを聞けば、 価値のある機能を生み出すために必要な思考方法の基礎を身につけることができます。

1. 事業課題の深掘り - 企業が設定するKPIやKGIの背後にある意図を理解し、その目標がなぜ重要なのかを把握する。
2. ユーザーと顧客の課題を探求 - 社内の過去のデータやロードマップを解析し、ユーザーが直面している本当の問題点を明らかにする。
3. 課題の連携 - 事業課題とユーザーのニーズを結びつけ、どの課題を解決することで事業インパクトを出せるのかを理解する。
4. ソリューションの創造 - 仮説に基づいて実現可能で効果的なソリューションを検討する。
5. 投資対効果の評価 - 現状のリソースと事業の状況を考慮に入れ、最もコスト効率の良い戦略を選定する。

ユニットテストを書く際、依存先としてモックを使用することがありますよね。
みなさんは、どのようにモックを作成していますか？

手作業で1つ1つ作成することもあれば、mockoloなどの自動コード生成ツールを使うこともあるでしょう。
加えて最近では、swift-spyableなどのマクロを用いたモック生成ライブラリも開発されており、それらを使っている方もいるかもしれません。

しかし、これらのライブラリには以下のような課題が存在します。

• 同名関数をモックできない
• 少しの記述ミスでテストがクラッシュして修正に時間がかかる
• モックした関数の挙動を途中で変えるのが難しい

このような課題を踏まえ、今回の発表では、

• モック生成とはどうあるべきか？
• なぜ/どうやってマクロで実現するのか？

を中心に、テストのためのモック生成マクロにおける理想を追求してみます。

個人で複数のアプリを開発していると、同じコードを何度も書くことがあるのではないでしょうか？
一つのアプリ内では、共通処理の実装をまとめて便利に使えていても、アプリが複数にまたがると、それを諦めてしまうこともきっとあると思います。
例えば自分の場合、ローディング表示やファイル共有のUI、データ永続化や広告表示のロジックなんかはどのアプリでも同じものを使っており、毎回コピペして使っていました。
しかしアプリが増えてくると、コピペも手間だし、実装を改善しても他アプリには反映されないしで、だんだん開発のモチベーションが下がってきてしまいます。
だからと言って、一般向けOSSを作ったり、既存ライブラリにコントリビュートしたりするのはハードルが高いな…と。

そんな時に役立つのが、自分専用のライブラリです！

というわけで今回の発表では、

• 自分専用ライブラリのメリット
• ライブラリ作成・分割の考え方
• 実際に作ったライブラリの例
  を中心に説明します。
  また、気軽に素早くライブラリを作るための雛形生成スクリプトについても紹介します。

自分専用ライブラリを作って、いろんなアプリを気軽に楽しく個人開発していきましょう！

※ 対象：

• 個人開発で複数のアプリを開発している方・する可能性のある方
• swift packageの作成や公開にハードルを感じている個人開発者の方