トーク

私がiOSエンジニアとしてのキャリアをスタートしたのはiOS 6がリリースされた頃でした。当時はAppleの公式ドキュメントの和訳が少なく、必然的に英文を読む機会が増えたことで、少しずつ英語そのものにも興味を持つようなりました。知りたいことが英語で書いてあるので、英語ももっとわかるようになりたいと思ったのです。その後、本格的に学習を始めた2016年の夏から今日まで、iOSアプリ開発を通してどのように英語学習に取り組み、英語力を高めていったのかを、英語の4技能であるリーディング、リスニング、スピーキング、ライティングに分けて振り返ってみたいと思います。

▼ 概要
私たちは「あたらしい旅行を、デザインする。」をミッションに旅行アプリ「NEWT」を日々開発しています。
旅行の予約から準備、旅行中の旅程の確認やサポートなど、直感的なUI/UXでストレスフリーな旅行体験をカスタマーに提供することを目指しています。
そのため、プロダクト開発において機能要件はもちろんのこと、非機能要件についても重視しています。
その中でも今回は、カスタマーに楽しく快適にアプリを利用してもらうために必要となるアニメーションに関するお話をできればと思います。

▼ 内容

• SwiftUIにおけるアニメーションの種類
• iOS17で追加されるアニメーションのあれこれ
• アニメーションの活用事例

突然ですが、Swift2からSwift3へのメジャーアップデート時の破壊的変更をご存知でしょうか？
私自身はまだiOSエンジニアにもなっていなかったので破壊的変更を経験したわけではないのですが、アップデート対応が非常に大変だったとよく聞きます。

もし、そのようなSwiftの破壊的変更がもう一度来るとすれば…。

本トークでは、Swift6で大きく変更されると予想される内容や、変更内容に対して今からどう備えておくことができるかなどに焦点を当て、解説していきます。
本トークを通じて、Swift6に向けてのロードマップや、具体的なアップデート内容まで、わかりやすく簡単にキャッチアップすることができます。
また、みなさんとSwift6のアップデートについて意見交流ができればと考えております。

Swift 5.1からsome、Swift 5.6からanyという新しいキーワードが加わりました！
anyキーワードはSwift 6.0から明示的に付与しなければコンパイルエラーになります。 対応に迫られた時、よくもわからずanyをつけていくという状態では心許ないですよね、、、

本トークで、2つの切り口からsomeとanyの理解を深めていきましょう

1. 汎用的なコード実装がより簡単に！
   ジェネリクスは汎用的なAPIを作成する上で強力ですが、慣れていないと実装しづらいところがあります。それをsomeキーワードで実装した場合にどうなるか、実際のコードで比較しながら把握してみましょう

2. プロトコルの役割を明確に！
   Swiftのプロトコルは型を抽象的にする役割と、制約を設ける役割の両方があります
   それぞれの役割に応じてanyとsomeを使い分け、それによって得られるメリットをお伝えします

ヤプリではSwift Concurrencyを適用していく試みを継続して取り組んでいます
最近ではプライバシーを扱う処理にも適用しており、その時に発生した問題やその後に得られたメリットを紹介します

個人情報の保護を担うプライバシー設定は、アプリ開発者において大きな関心ごとの一つです。アプリ機能に制限がかからないよう、適切な説明をしてプライバシー設定のダイアログを表示するなど、柔軟な呼び出しに対応できる実装とする必要があります。ただ、プライバシーの種類によっては、表示に必要なAPIがasync/awaitで提供されるものもあれば、位置情報やBluetoothのようにDelegateパターンで提供されるものもあります。それらを独自に同一のAPIから好きなタイミング・順序で制御できるように対応しました
本トークで対応実装とその時の課題を解説し、それによって新たに実現できたことをお伝えします！

Swift UIの登場によって、私たちはデータの画面反映に関するロジックの管理から解放されました。

これに加え、複数のAPI結果を画面ごとのStateに変換するまでの処理を、サーバーサイドにまるっと移譲することで、
アプリは最適なUXの提供に専念できるだけでなく、ストア審査やリリースから独立した変更が可能になります。

本トークでは、AirbnbやLyftなどの海外企業で導入されているServer-Driven UI アーキテクチャについて、下記について深く掘り下げてお話しします。

• Server-Driven UIは何を解決するものか？
• 先行事例、各社がどういった形で実現しているか？
• タップルでのSwiftUIとBackends for Frontends（BFF）を活用した取り組みと運用
• 運用の中で得られたメリット

みなさん、DI（Dependency Injection, 依存性注入） をどのように行っていますか？

急速に変化していくiOSアプリ開発において、様々なDI手法が乱立しており、 "どのようなDI手法を選択するかベストなのか" と違和感を感じることがあるのではないでしょうか？

本LTでは、 私が現段階でDIのベストプラクティスだと考えている swift-dependencies を用いた DIからテストまで "具体例をもとに" 紹介し、DI手法の選択肢拡大に貢献したいと考えています。

swift-dependencies は TCAから派生して生まれたDIライブラリで、とても簡単に依存を登録し、柔軟な依存注入が可能です。
そのため、新規/既存のプロジェクトに対して導入が容易に行えます。
DI手法について再検討したい方 や TCAを用いた開発を考えている方 の支えになれば幸いです！

複雑なアプリケーションが増えた近年ではバグを生まないためや検証コスト削減のために自動テストの導入が重要です。
テスタビリティを考えたアーキテクチャや知見も浸透し、テストを導入することの大切さが広まってきました。
しかし開発スケジュールやリソースの都合上、どうしても「テストが書けない」「カバレッジが低い」「テスト自体のメンテナンスができない」等の問題が出てきてしまいます。
一方、ChatGPTをはじめとするLLMやGithub Copilotなどの開発支援ツールの登場は、開発速度や体験を大きく向上させることが期待されています。
そこで本セッションではChatGPTのAPIを使用し、UnitTestの実装コストを下げる方法や限界について検証していきます。

https://cha-chat.henteko07.com/
ChaChatという、かわいいキャラクターと楽しくお話ができるアプリを開発しました。
感情表現豊かなキャラクターと楽しくお話しすることで、日頃仕事で疲れた心を癒すことができます。

このChaChatは、ChatGPTやStable Diffusion、midjourneyなどのAI技術を使って作られています。
そんなChaChatを開発してみて気づいた、Promptエンジニアリングや、Stable Diffusionを使って同じキャラクターによる表情差分の作成方法などをご紹介します。

https://cha-chat.henteko07.com/
ChaChatはかわいいキャラクターと楽しくお話ができるアプリです。
感情表現豊かなキャラクターと楽しくお話しすることで、日頃仕事で疲れた心を癒すことができます。

またChaChatはChatGPTやStable Diffusion、midjourneyなどのAI技術を使って作られたAIアプリです。
そんなChaChatを開発してみて気づいた、Promptエンジニアリングや、Stable Diffusionを使って同じキャラクターによる表情差分の作成方法などをご紹介します。

このセッションでは、Kotlin Multiplatform Mobile（KMM）とCompose Multiplatformを活用したiOSアプリのクロスプラットフォーム開発について紹介します。KMMの基本的な設定方法、共有コードの記述、モジュール構成、プラットフォーム固有の実装と共有に加え、Compose Multiplatformの特徴や共有コードを利用したマルチプラットフォーム対応の開発の効率化についても詳しく紹介します。

1. Kotlin Multiplatform MobileとCompose Multiplatformの紹介
2. KMMの基本的な設定方法と共有コードの記述
3. モジュールの構成と管理
4. プラットフォーム固有の実装の分離と共有
5. Compose Multiplatformの特徴
6. マルチプラットフォーム対応UIの開発効率化
7. まとめ

現在、iOS1人・Android2人の少数チームで新規動画配信アプリを開発しています。
技術選定やアプリのアーキテクチャ設計に際しての工夫点やハマり所、そしてSwiftUI, TCA, KMMを活用した開発Tipsについてお話します。

これから新規アプリ開発を予定している方々にとって、技術選定やアーキテクチャ設計の参考としていただければ幸いです。

キーワード：
・iOS Deployment Target 16.0+での新規iOSアプリ開発
・swift-composable-architecture (TCA)
・Kotlin Multiplatform Mobile (KMM)
・kotlin-inject
・Apple TV対応も踏まえたSPMでのマルチモジュール化
・多言語対応, Localize
・iOS ⇔ Androidの技術トランスファー

昨年公開されたSwift 5.7から、ついにprotocolにジェネリクスを使えるようになりました。
これにより、型消去のようなテクニックを用いることなく、associatedtypeを持つprotocolをより便利に・簡単に扱うことができます。
今回はこの新機能の活用方法を、実際にアプリをリアーキテクチャした実例とともにご紹介します。

iOSアプリ、Swift化してますか？ではCI/CDや業務効率化は？これらはfastlaneやGoogle Apps Scriptを使っており、iOSエンジニアには馴染みが薄いRubyやJavaScriptを使うことが多いでしょう。

「それ、Swiftで実装しませんか？」

メリットの一つはSwiftで読み書きできることです。アプリと同じ言語ならば、慣れない言語を使う頭の切り替えは不要で実装も捗ります。またWWDC22でも登場したVaporを使いより幅広い機能を実現することもできます。

本トークではヤプリで行っている業務効率化、Swift化の過程や既存ツールとの共存、Swift化のメリットを下記の実例と共にお伝えします。
①アプリ審査ステータス取得：Vaporを使い、GASでは難しい機能を実現
②リリース自動化：Swiftで実装しfastlaneから呼ぶことで、既存ツールとの共存を実現

AndroidのJetpack Composeと、iOSのSwiftUI。
どちらも宣言的UIという共通点もあり、片方が使えればもう一方も想像以上にスムーズに実装できます。
両方の実装経験をもとに、iOSエンジニアのみなさんに共通点を踏まえて実装方法をお伝えしていきます！

【トピック詳細】
・SwiftUIとJetpack Composeの相似点と相違点
SwiftUIの知識を持つ皆さんに、Jetpack Composeの基本概念とシンタックスの共通点と違いを解説します。
・AndroidアーキテクチャとJetpack Compose
SwiftUIに慣れた皆さんに、Jetpack Composeのアーキテクチャとその特徴を紹介します。
・ハプニング対策マニュアル
Jetpack Composeでの開発においてよく遭遇するハプニングや落とし穴について、予防策と対処法をお伝えします。

要旨:
SwiftUIを既存のUIKitベースのプロジェクトへの導入は容易ではありません。私たちVoicyの開発チームもその困難を体験しました。このセッションでは、我々が直面した問題、解決策、そして導入後の成果について具体的に話します。

内容:
1.VoicyプロジェクトとSwiftUI導入の背景:
2.SwiftUIとUIKitの共存問題
3.カスタマイズの困難性
4.本番で発生した問題を晒す
5.SwiftUIの基本をおさえる
6.UIKitと一緒に生きていく
7.VoicyプロジェクトにおけるSwiftUI導入の成果と学び

ビルド時間は、アプリケーション開発において大きなフラストレーションとなります。
特に大規模なプロジェクトでは、ビルド時間の増加は効率性を損ない、生産性を低下させる可能性があります。
とはいえ大抵のプロジェクトではある程度ビルドの最適化を行なっている現状もあり、大幅に遅くなることはあっても、早くなることは少ないです。

本セッションでは、新規のプロジェクト作成してXcodeのビルド時間をいろいろな方法で遅くしていきます。
具体例を交えてビルド時間の推移を見ていくことで、アンチパターンとしてビルド時間を遅くしない手助けになればと思います。

ネイティブアプリからWeb APIを利用するとき、なんらかの認証・認可の仕組みが必要になることがほとんどです。こんなとき典型的なアイデアは、OAuth 2で認可すること。でもOAuth 2って、10年も前に標準化された規格だし、RFCもたくさんあるし、なんだかとっつきにくいですよね。
ということで本トークでは、OAuth 2がどういうもので、どういう問題を解決し、あるいは解決しないのか、その全てを説明します。特にネイティブアプリにはアプリならではのポイントがあり、正しく実装することでセキュリティリスクを軽減させられます。
トークの内容は、自社のアプリの認証をOAuth 2に移行させるため、認可サーバーとリソースサーバー、自社アプリ向けのSwift SDK、そしてアプリの実装まで手がけた私の経験に基づきます。

最近、自社サービスアプリの認可方式をOAuth 2に置き換えました。
私たちのアプリは、10年以上前から基本的には同じ認証方法を採用していました。単純である一方で、現代のニーズに合わない部分が目立つようになっていました。
サービスプラットフォームチームに所属する私は、サービス基盤機能の改善の一環で、この問題に取り組むことにしました。様々な方法を検討して、OAuth 2による認可を採用すると決め、認可サーバーとリソースサーバー、アプリ向けのSDKを開発し、ついにアプリを改修しました。
本トークでは、私がこのプロジェクトに関して検討し、実装していく過程を、OAuth 2の基本的な知識とともに紹介します。このトークによって、認可方式についてどのようなことに注意するべきか学ぶことができます。

iOSに限らず、アプリを使っているとエラーはつきものです。
そんなエラーを回復するために、ユーザーに引き続きアプリを使ってほしい一心で一律エラーに対しリトライなどを行なっていると、
ネットワーク通信で絶対に成功しない同じリクエストを送り続け、400エラーや500エラーに対して延々とリトライしてしまうことになります。

そんなErrorですが、protocolとしてRecoverableErrorというものが用意されているのはご存知でしょうか？
これは本来はmacOSなどで使うよう設計されているものですが、iOSをはじめとした他プラットフォームでも使えるものになっています。
本セッションではRecoverableErrorの使い方とiOSでの有効性について検証します。