トーク

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

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

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

iOSアプリ開発のチュートリアルや入門書は多く存在しており、学校の授業で扱われることもあります。しかし一方で、実際のアプリ開発の業務では、より多くの知識が求められます。このギャップに初学者がとまどうことも少なくありません。

このトークでは、初学者が業務レベルに到達するには何が求められるのか、いくつかのポイントについて具体的にお話しします。初学者への学習の方向性を示すとともに、中級〜上級者にも初学者が感じるギャップを捉える機会になればと考えています。より俯瞰的な内容は、パンフレット記事をご覧ください。

・UIフレームワーク（UIKit、SwiftUI）：どのくらい使われているのか、どちらを学ぶべきか
・LinterやFormatter：なぜこれらを導入する必要があるのか
・プロジェクト構成、パッケージ管理（SwiftPMなど）：プロジェクト構成で何を考えておくのか
・デザインや設計のガイドライン（HIGなど）：何を知っておくべきか、ガイドラインの読みかた

UIKit から SwiftUI への移行、進んでいますか？
私が開発に携わっているアプリでは、画面内の一部のコンポーネントにのみ SwiftUI を利用しており、現在画面全体の SwiftUI 移行を検討しています。
すぐにも移行を進めたいところですが、そのためにはユーザの行動ログを収集するためのインプレッショントラッキング基盤が必要不可欠です。

基盤実装には、分析要件を満たすための I/F 設計・ユーザ体験を損なわないためのパフォーマンス・OSバージョンごとの品質担保・デバッグ容易性など考慮すべき観点がいくつもあります。
本トークでは、インプレッショントラッキング基盤を実現する上での UIKit と SwiftUI の違いや、これらの観点に対するアプローチについてお伝えします。

みなさん、Meta社（旧Facebook社）が開発したモバイルアプリ開発のためのデバッグツール「Flipper」をご存知でしょうか。

Flipperはデスクトップアプリを通じて様々な情報を取得したり操作を行ったりと、幅広くデバッグを支援してくれる便利なツールです。
類似のデバッグツールとしては、HTTPプロキシを立てて端末の通信をキャプチャし、リクエストやレスポンスの内容を参照・改変するCharlesが有名かと思いますが、FlipperにはCharlesにはないカスタムプラグイン機能が存在します。自分たちのアプリの要件に合わせたカスタムプラグインを作成することで、バグ調査や開発効率の改善に役立てることができます。

このトークでは、Flipperの基本的な解説からユースケース、カスタムプラグインの作成方法、活用事例までを以下の流れに沿って、ソースコードと共に解説していきます。

• Flipperで出来ること、出来ないこと
• カスタムプラグインの作成方法
• iOSアプリへの組み込み
• Mirrativで利用しているカスタムプラグインの紹介
  • WebSocketベースのPub/Subライブラリのデバッグ
  • Unityとの双方向通信のデバッグ

このトークを通じて、みなさんのモバイルデバッグの選択肢が広がれば幸いです。

弊社では、モジュール分割による影響範囲の限定化とともに、UIViewControllerから呼び出すサブビューの位置付けでSwiftUIを利用しています。
最大限SwiftUIの力を活用できているとは言えず、UIViewControllerから呼び出すことでオーバーヘッドがあるのも事実ですが、UIKitやStoryboard中心の開発を行っていた頃と比較して開発体験の向上が見られるようになりました。

本トークでは、UIKitベースのプロジェクトにおいてSwiftUIを適用したいと迷っている方向けに、具体的な事例を交えながら以下のポイントについて順を追って解説します。

• コードベースの課題認識とゴール設定
  • SwiftUIをどこまで適用するか
• 施策実装と並行し隙間時間でコード改善する進め方
• 修正による影響範囲を明確化、限定化するためのモジュール分割の指針立て

SwiftのData型はバイナリデータを扱うための型です。
RandomAccessCollectionなどの便利なプロトコルに準拠しているおかげで、気軽にバイナリデータの読み書きができます。

でも「ほぼUInt8の配列でしょ」と思っているとそんなことはなく、Data型にしかない、面白くも「あぶない」特徴がいくつかあります。
それらを知らないとプログラムをクラッシュさせてしまうこともしばしば。

コードレビューでこの関数をLGTMしてしまいそうになったら、ぜひこのトークを聴いてください。

func getUInt32(from data: Data) -> UInt32 {
　switch data.count {
　case 0:
　　return 0
　case 1:
　　return UInt32(data[0])
　case 2, 3:
　　return UInt32(data[1]) * 256 + UInt32(data[0])
　default:
　　return data.withUnsafeBytes { $0.load(as: UInt32.self) }
　}
}

突然ですが、みなさんが開発しているアプリで一番古くからある画面はどこですか？

マッチングアプリ『タップル』は今年でリリースから10周年を迎え、Swiftのアップデートに伴ってその姿形を変えてきた歴史があります。
iOS業界の中でも古いプロダクトになりつつあり、時代の流れとは裏腹に、何年もの間メンテナンスされてこなかった実装が健在しています。

しかし、これらの実装はSwift 6.0の登場により変遷の時を迎えるかもしれません。
そこで本セッションでは実録と称して、IBベースの画面で作られていたタブ直下の画面をフルSwiftUI化し、さらにSwift 6.0対応までのリプレイスの記録を以下の流れに沿って解説します。

• IBからSwiftUIへの移行
• リアーキテクチャ（RxSwiftからSwift Concurrencyへの移行）
• そしてSwift 6.0対応へ

共に古き悪しきコードを討伐していきましょう！

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

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

チーム開発をしていてコードレビューに課題を感じることはありませんか？
私たちのチームでは12人のエンジニアがフルタイムでiOSアプリ開発を行なっており、レビューの属人化やリードタイムがチーム内での大きな課題となっていました。

このセッションではどのようにしてチームのコードレビューを改善したのか以下の点を中心にお話しします。

• コードレビューやマージまでのリードタイムの短縮するための仕組み
• Code Ownerと自動アサインを活用して属人化を減らす
• トランクベース開発の推進

このセッションを通して皆さんのチームのコードレビューがより良いものになれば幸いです。

「（舞台上でしゃがみながら）ログビューアのUI/UXについて、マジで今日全員で考えたくて」

os.Logger という、iOS 14.0から使えるロギングのAPIがあります。
print よりもログに特化しており、使っている方も多いと思います。

私はOSログを確認できるSwiftUIのビューをOSSで公開しています。
わずか1行でiOSアプリ上にログビューアを表示できます。

Xcode 15から、OSログビューアが一新されました。
UI/UXについて、できる限りそれに近づけようとしています。

しかし難しい…！
macOSアプリであるXcodeのUI/UXを、iOSアプリ上でどう表現するか。

「検索バーでフィルタリングを実現するのは難しいから、文字列検索と分けて用意しよう」
「スマホはパソコンと比べて画面が小さいので、折り返しを多用するのもよくないよな」

など工夫しました。

本トークでは、私がログビューアのUI/UXをどう考えて設計したかと、改善の余地について紹介します。

もくじ

• OSログの出力と取得
• 自作ログビューアのUI/UX解説
• ログビューアのUI/UXを全員で考えよう

「どうでもいい正解を愛するよりも、面白そうなUI/UXを愛せよ」
全員で一緒に、よりよいログビューアのUI/UXを追求しましょう！

iOSアプリのUI設計に慣れているエンジニアでも、visionOSアプリのUI設計には新しい知識が求められます。
特に、iOSとは特性の異なるコンポーネントや独自のデザイン要素に注意する必要があります。

このトークでは、iOSアプリエンジニアの自分が実際にvisionOSアプリのUIデザインと開発をする中で直面した課題や得た知見等をまとめます。
そして、特にiOSアプリエンジニアがvisionOSアプリを開発する前に知っておくべきデザイン原則や、
iOSとは異なる部分、visionOSの罠と制約、実装時に役立つテクニックなどを端的に紹介します。

このトークを聴くことで、美しいvisionOSアプリをスムーズに開発するために、iOSアプリエンジニアにとって必要な知識が簡潔に得られるでしょう。

iPhoneのカメラは年々進化しており、さまざまな用途で使用されるようになってきています。例えば、近年ではiPhoneのカメラを使用して、映画やYouTube動画を撮影するクリエイターも登場しています。

このようにiPhoneのカメラがさまざまな用途で使われる中、DockKitフレームワークが発表されました。DockKitフレームワークのAPIを組み込んだビデオカメラアプリを、DockKit対応スタンドにセットすることで、人物を自動で追尾するようにDockKit対応スタンドを動かすことができます。

しかし、DockKitフレームワークはWWDC2023で発表されていたものの、DockKit対応スタンドが発売されたのはつい先日で、DockKit対応スタンドを使用して、開発者がどのような機能を利用できるのかについてはあまり知られていません。

このセッションでは、DockKitフレームワークの基本的な概要やAPIの説明から始め、DockKitフレームワークで開発者ができることを体系的に紹介します。セッション中はベルキンのAuto-Tracking Stand Pro with DockKitを使用したデモを交えて説明します。

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

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

iOSアプリエンジニアなら、一般的なiOSアプリのUIデザインでアプリを作ることはお手の物ですよね？では、visionOSアプリを作ることになったらどうでしょうか？

各コンポーネントのスタイルやレイアウトはどうするべきか、何ができて何ができないのか、AppleのvisionOSアプリのUIはどうやって実現されているのかなど、多くの悩みどころが出てくると思います。

このトークでは、iOSアプリエンジニアである私が実際にvisionOSアプリのUIデザインと開発を行う中で直面した課題や得た知見を、特に以下のポイントに焦点を当てて紹介します。

・基本概念とデザイン原則：visionOSのUIデザインにおける基本的なコンセプトやガイドラインなどを紹介。
・デザイン要素：iOSとは異なるUIコンポーネントの特性やデザイン要素などの紹介。
・開発効率を上げるテクニック：visionOSアプリ開発を効率化するためのXcode Previewsやシミュレータの活用法。
・制限と工夫：visionOSの様々な制限を紹介しつつ、実現したいUIをどのようにして実装するか紹介。

このトークを聴くと、visionOSアプリとして使いやすく美しいUI/UXになっているか、実現できるUIなのかを判断できるようになり、チームでの開発もさらにスムーズに進められるようになるでしょう。

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

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

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

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

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

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

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

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

TipKitはiOS17で導入された新しいフレームワークです。

TipKitを使うことでアプリ内でユーザーに対して柔軟なヒント（Tips）をパーソナライズして提供することや、
アプリ内でのTipsを管理して提供することができるようになります。

今回のLTではTipKitでのできることや、実際のユースケースをまとめて話そうかと思います。

最近、かなり注目を浴びているLLMベースの「AIアシスタント」にかなりの熱を感じています。

そこで、LLMのアシスタント（Copilot、OpenAIなどで）、自然言語間の翻訳だけでなく、プログラミング言語間の翻訳も得意そう。
そこでどこまでできるのかを試してみました。
チャレンジをしてみた感想と今後の展望の考えについて話す！

詳細

発展途上のAIのアシスタントを用いて、マルチプラットフォームの開発をどこまでできるかちょっとやってみる？！

• Swiftでデータモデルを書いたら、Kotlinで排出して再利用できそう？
• ビジネスロジックをJavaでサーバサイドで書いたら、ネイティブのSwift/Kotlinのクライエントで使用できる？
• UIをSwiftUIで書いたら、KotlinのJetpack Composeに直接転換できる？？

最後に

• それぞれのAIによりNative開発の新時代が来るなら、どのような支障があるのか、どのような開発フローを要するかについて考察を話す

※ スライドだけではなく、ライブコーディングをチャレンジしながらやるつもりです！

Mobile Actとは、フェンリルのエンジニアが主催するモバイルアプリ開発の勉強会です。以前は定期的に開催されていましたが、コロナ禍や運営メンバーの退職などの影響により、2021年を最後に開催が途絶えてしまいました。

そのような中、新しい運営チームはMobile Actを復活させるべく、様々な取り組みを行いました。
以前の運営メンバーがほとんどいない中で運営ノウハウが少ししか残っておらず、またポストコロナの時代となりリモート参加の需要など状況は以前とは大きく変わっていました。
このため、多くの試行錯誤を繰り返し、2024年5月に無事にMobile Actを再開することができました。

このトークでは、2年半ぶりに復活を遂げたMobile Actの裏側についてご紹介します。運営初心者たちがどのようにしてこの大きな挑戦を乗り越えたのか、そのストーリーをぜひお楽しみください。

アプリにおいてABテストが広く普及していますが、次のステップとして個別最適化が主流になりつつあります。
単に2つの画面を比較するだけでなく、ユーザーの行動パターンに基づいたセグメント分割を行い、ABテストでは拾えなかったユーザーにもアプローチすることでより高い効果を得ることができます。
私たちのアプリではユーザーごとに異なる18パターンの課金画面を提供することで、収益の最大化を目指しました。

このセッションでは、複数パターンの課金UI検証を通じて得た以下の内容についてお話しします。

• 複雑な検証をデグレさせることなく、高速に実現するための設計と、その実装手法
• 個別最適化がユーザーの課金率にどのような影響を与えたか

このセッションを通して、皆さんのアプリでも最強の課金UIを実現しましょう。