Swift Package Manager(SPM)ではC++ライブラリもパッケージとして管理することができます。また、WWDC23ではC++ interoperabilityが紹介されSwiftからC++を利用することが一層簡単になりました。
一方で、C++ライブラリを利用したいシーンの多くではライブラリは巨大であることが多いです。実運用しているプロジェクトでそうしたライブラリを運用するにあたってSPM管理に置き換えたりするには多くのハードルあります。
本稿では、まず実際のC++ライブラリをSPM管理下に置く方法を解説します。また、外部ファイルを読み込んで設定に反映させることでPackage.swiftの肥大化を防ぐ方法を示します。最後に、これら以外で注意が必要なXCodeの設定等を示すことでC++ライブラリのSwiftプロジェクトでの運用時の問題を解決します。
現在、iOS1人・Android2人の少数チームで新規動画配信アプリを開発しています。
技術選定やアプリのアーキテクチャ設計に際しての工夫点やハマり所、そしてTCA, KMMを活用した開発Tipsについてお話します。
これから新規アプリ開発を予定している方々にとって、技術選定やアーキテクチャ設計の参考としていただければ幸いです。
キーワード:
・iOS Deployment Target 16.0+での新規iOSアプリ開発
・swift-composable-architecture (TCA)
・Kotlin Multiplatform Mobile (KMM)
・kotlin-inject
SwiftUIの導入と既存の不完全なMVVM改修による課題を解決するため、新しいアーキテクチャとしてSVVSを開発しました。
SVVSはStore、View、ViewStateから構成され、複雑な依存関係と大規模なリファクタリングの問題を解決する設計として採用しました。SVVSはSingle Source of Truthを考慮してMVVMにStoreを追加し、現代的なiOSアプリ開発においてシンプルでオーソドックスな構成を実現します。特にSwiftUIとの相性が良く、すぐに取り入れることができ、学習コストも低く、サードパーティのライブラリやフレームワークに依存しない点が魅力です。本トークでは、SVVSを他のアーキテクチャやフレームワークと比較しながら、実際に業務で取り入れた実例を交えて紹介していきます。
WWDC23ではDesign with SwiftUIというセッションが公開されAppleがデザイナーのSwiftUI習得を公式に推奨するようになり、またvisionOSの登場によりSwiftUI自体の使い道も広がりました。
もちろん、デザイナーがSwiftUIを書けるようになることは協業という面でも理想的な世界ですが、一方でそれはエンジニアの役割がなくなるということではありません。
デザイナーのデザインをエンジニアが実装するにしろ、デザイナーと同じSwiftUIのコードベースを触るにしろ、今後よりエンジニアのデザイン理解度の重要性は高まってくると思います。
そこで本トークではSwiftUIを通してデザインの基本的な知識や考え方、エンジニアが知っておくべきことなどを紹介することで、エンジニアとデザイナーの協業をスムーズにし、より高品質なアプリを開発できるようになることを目指します。
自分や同僚の作ったメソッド、何が起きるか分かりづらい…コードが読みにくい…そんな経験ありませんか?
本トークでは、SwiftのAPI Design Guidelines(ADG)が示すAPIの理想像を整理したうえで、実際のコード例をもとに
を繰り返し、API設計での大事な観点をまとめます。
ADGに沿ってAPIを改善する過程とその効果を体感し、今後のコーディングやコードレビューにご活用ください。
メソッド名から引数ラベル、返り値型に至るまで、APIの構成要素すべてを洗練させ、簡潔明瞭で美しいAPIをデザインしましょう!
こんな方におすすめ:
やらないこと:
iOSアプリ開発では、機能そのものの開発以外に気にかけることが多々あります。
例えば、各種証明書の有効期限、ライブラリの選定・バージョンアップなどです。
さらに、社内にiOSアプリが数多くあるとどうでしょう。
例えば証明書の有効期限が切れていたり、脆弱性を含んだバージョンのライブラリを使い続けていたり、といった問題が各所で起きる可能性があります。
社内にある全てのアプリで、これらの問題に漏れなく対応できる状態を作るのは、複数アプリを管理する上での大きな課題です。
これを解決するために、社内全てのアプリについて、証明書や依存ライブラリなどの情報をまとめて管理するツールを作りました。
本トークでは、これを実現するにあたって利用したApp Store Connect API利用の際のTipsやライブラリの情報収集の方法、これによってアプリの複数運用がどのように便利になったのかを紹介します。
日付・時刻・時間・数値・測定値・名前などの情報を、ローカライズ済の String との間で変換してくれる Formatter。有名なのは DateFormatter・NumberFormatter でしょうか。
iOSDC Japan 2021 では、当時のすべての Formatter を紹介しました。あれから2年、今年は iOS 15+ で使用できる FormatStyle を使用した formatted メソッドを、使用機会の多いと思われるものを中心に紹介します。これは Formatter の強力な機能はそのままに、自分でインスタンスを作る必要がなく、より Swift らしく書け、さらに iOS 17 ではパフォーマンスも向上します。
まだまだ Web 検索での情報が乏しい FormatStyle の使い方をこのトークでマスターし、従来の Formatter から移行しましょう。
ABEMAでは、iOSアプリとAndroidアプリのアーキテクチャの統一を図っているだけでなく、コード自体も共通化されている状態を目指して一部実装にKotlin Multiplatformを採用しています。これらの取り組みの中で、両プラットフォームで共通して採用できるアーキテクチャとはどのようなものか、どの実装が共通化できてどの実装はそれぞれ実装すべきかなど、OSの境界を跨いで多くの議論を行ってきました。
このトークでは、こうした議論を経た現在、ABEMAがモバイルアプリのアーキテクチャをどのように議論し、どのように定義して、どのように運用しているのかを実例を交えてご紹介します。
STORES 予約アプリは店舗などの管理者様向けの予約管理アプリで、2021年にiOS版をSwiftUIでフルリニューアルしました。
その後も追加機能の開発をし続け、今年の4月には待望のカレンダーUI (https://x.gd/GwDja) をリリースしました。
カレンダーUIとは「予約の入り具合や空き状況をカレンダーで閲覧するための画面」で、実装にあたり3つの壁に直面しました。
・既存ライブラリは使用せずにSwiftUIフルスクラッチで実装する
・予約スケジュールの時間の重複を可視化する
・予約情報の取得処理をKMMを利用してiOS/Android版で共通化する
本トークでは、カレンダーUI検討の背景から本実装、リリースに至るまでの過程をソースコードを交えながら解説します。
トークを聞いてくださった皆さんにSwiftUIで複雑なレイアウト画面を実装するためのヒントとなれば幸いです。
▼ 概要
私たちは「あたらしい旅行を、デザインする。」をミッションに旅行アプリ「NEWT」を日々開発しています。
旅行の予約から準備、旅行中の旅程の確認やサポートなど、直感的なUI/UXでストレスフリーな旅行体験をカスタマーに提供することを目指しています。
そのため、プロダクト開発において機能要件はもちろんのこと、非機能要件についても重視しています。
その中でも今回は、カスタマーに楽しく快適にアプリを利用してもらうために必要となるアニメーションに関するお話をできればと思います。
▼ 内容
ヤプリではSwift Concurrencyを適用していく試みを継続して取り組んでいます
最近ではプライバシーを扱う処理にも適用しており、その時に発生した問題やその後に得られたメリットを紹介します
個人情報の保護を担うプライバシー設定は、アプリ開発者において大きな関心ごとの一つです。アプリ機能に制限がかからないよう、適切な説明をしてプライバシー設定のダイアログを表示するなど、柔軟な呼び出しに対応できる実装とする必要があります。ただ、プライバシーの種類によっては、表示に必要なAPIがasync/awaitで提供されるものもあれば、位置情報やBluetoothのようにDelegateパターンで提供されるものもあります。それらを独自に同一のAPIから好きなタイミング・順序で制御できるように対応しました
本トークで対応実装とその時の課題を解説し、それによって新たに実現できたことをお伝えします!
複雑なアプリケーションが増えた近年ではバグを生まないためや検証コスト削減のために自動テストの導入が重要です。
テスタビリティを考えたアーキテクチャや知見も浸透し、テストを導入することの大切さが広まってきました。
しかし開発スケジュールやリソースの都合上、どうしても「テストが書けない」「カバレッジが低い」「テスト自体のメンテナンスができない」等の問題が出てきてしまいます。
一方、ChatGPTをはじめとするLLMやGithub Copilotなどの開発支援ツールの登場は、開発速度や体験を大きく向上させることが期待されています。
そこで本セッションではChatGPTのAPIを使用し、UnitTestの実装コストを下げる方法や限界について検証していきます。
https://cha-chat.henteko07.com/
ChaChatという、かわいいキャラクターと楽しくお話ができるアプリを開発しました。
感情表現豊かなキャラクターと楽しくお話しすることで、日頃仕事で疲れた心を癒すことができます。
このChaChatは、ChatGPTやStable Diffusion、midjourneyなどのAI技術を使って作られています。
そんなChaChatを開発してみて気づいた、Promptエンジニアリングや、Stable Diffusionを使って同じキャラクターによる表情差分の作成方法などをご紹介します。
このセッションでは、Kotlin Multiplatform Mobile(KMM)とCompose Multiplatformを活用したiOSアプリのクロスプラットフォーム開発について紹介します。KMMの基本的な設定方法、共有コードの記述、モジュール構成、プラットフォーム固有の実装と共有に加え、Compose Multiplatformの特徴や共有コードを利用したマルチプラットフォーム対応の開発の効率化についても詳しく紹介します。
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のビルド時間をいろいろな方法で遅くしていきます。
具体例を交えてビルド時間の推移を見ていくことで、アンチパターンとしてビルド時間を遅くしない手助けになればと思います。
最近、自社サービスアプリの認可方式をOAuth 2に置き換えました。
私たちのアプリは、10年以上前から基本的には同じ認証方法を採用していました。単純である一方で、現代のニーズに合わない部分が目立つようになっていました。
サービスプラットフォームチームに所属する私は、サービス基盤機能の改善の一環で、この問題に取り組むことにしました。様々な方法を検討して、OAuth 2による認可を採用すると決め、認可サーバーとリソースサーバー、アプリ向けのSDKを開発し、ついにアプリを改修しました。
本トークでは、私がこのプロジェクトに関して検討し、実装していく過程を、OAuth 2の基本的な知識とともに紹介します。このトークによって、認可方式についてどのようなことに注意するべきか学ぶことができます。
Core Dataを用いると、背後のデータベース(SQLite)の知識がなくとも、簡単にデータの永続化を行うことができます。しかし、SQLiteの基本知識があればより高性能で安定したアプリを構築できるでしょう。今後、他のSQLiteベースのデータフレームワークを使用する際にも、これらの知識は非常に役立つはずです。
以下のようなトピックに興味がある方は、ぜひ一緒に探求しましょう!
残りはトークで!
MapKitとGoogle Maps SDKは、地図機能を提供するアプリケーションにとって重要なフレームワークです。それぞれに独特な機能やパフォーマンスがあり、使用状況や要件によって最適な選択は異なります。
本トークでは、これら二つのフレームワークを徹底的に比較し、それぞれの独自性、長所、短所、そして適用シーンの詳細や実際のアプリケーション開発での具体的な事例を解説します。フレームワーク選択の際に影響を及ぼす可能性のある要素、例えばアプリのユーザーインターフェース、パフォーマンス要件、開発の複雑さ、コストなどを考慮することで、アプリケーションの要件と目標に最適なフレームワークの選択をサポートします。
このトークを通じて、フレームワーク選択のプロセスをより理解し、現時点での最適な選択を提示します。