👋

今から新規iOSアプリを作るなら 2022年版

2022/12/01に公開

iOS

Swift

Apple

tech

この記事はarasan01 Advent Calendar 2022の1日目です。

こんにちは、あらさん(@arasan01_me)です。10周年を迎えたドラゴンクエストXオンラインを今更始めてみました，めちゃめちゃ面白いです。ぜひ始めてみてください。

https://twitter.com/arasan01_me

iOSアプリの開発環境について

iOS開発の環境はここ数年で大きく変わりました。Swift Package Manager（SPM）と銘打たれたコード配布管理ツールは、想像以上の汎用性によりプロジェクト構築に大きく変化をもたらしました。Point-Freeのisowordsが発端となって広く知られるようになったプロジェクト構成に応用できる発見は，開発ツールとして必須となっていたXcodeGen, tuistなどのXcodeプロジェクト生成ツールの必要性を再考する機会を開発者に与えました。また，SPMによるパッケージ配布が一般化することにより今までCocoapdosやCarthageに依存していたことによるRubyへの強い依存からの脱却，Cocoapodsの依存を持つことによるプロジェクトの制約からの脱却，SPMによるマルチモジュールができることにより軽量なディレクトリ構成とビルド時間の短縮の実現などが挙げられます。これらの進化により今まで開発者にとって必須だったツールは必須ではなくなり非推奨となるものが増えてきました。

またUIフレームワークに視点を切り替えると、UIKitからSwiftUIの移行は眼を見張るものがあります。UIKit, AppKit, WatchKitからSwiftUIへの統合をキャッチフレーズとしてAppleが喧伝していることから様々なUIの構築に宣言的フレームワークの恩恵がもたらされています。それに伴いこれまではUIKitで実装がかなり面倒であったり，時間がかかるためOSSに頼ってきた処理も自前で書きやすくなりOSSに依存しなくても良くなりました。この開発体験の実現はSwiftがDSLを作りやすくなる進化に支えられています。ResultBuilderやOpaque Typeの導入，Property Wrapper等の実現によりSwiftでの開発体験は素晴らしいものになってきました。

ここまでの内容から，新しくiOSアプリを作る場合にどのような技術選定をするべきなのかの道標としてこの記事を残します。

プロジェクト構成について

Swift Package Managerを活用したプロジェクト構成

大きく変わってきたプロジェクト構成としてSPMによるプロジェクト構成があります。今までであればFrameworkを内部で生成してXcodeプロジェクトで頑張って管理して運用していくなどの努力をしていた部分がプロジェクトに一つのPackage.swiftを用意するだけで簡潔に管理できます，しかも単体では.xcodeprojや.xcworkspaceの依存から脱却できるようになりました。これによるプロジェクトの構成方法によりビルド時間の短縮や依存関係を明示的にimportすることから誤った依存関係を持つことが分かりやすく表面化することによりレビューなどもしやすくなります。詳しくはiOSDC2021での@d_dateさんの動画を参照してください。分かりやすく掘り下げています。

拙著のgithubにて公開しているプロジェクトの最小構成も参考にしていただければ幸いです。

UI構築について

SwiftUI App

現在のXcodeにて新規プロジェクトを作るときにはInterfaceとしてSwiftUI, Storyboardのどちらかを選択できるようになっています。UIKitの機能はSwiftUI Appからでも呼び出すことができるため積極的にStoryboardを選択する理由も減っています。SwiftUIではAppDelegateが標準で提供されていません，modifierにより画面状態の変化を取得します。もしもAppDelegateに何かしらの処理をさせたい場合は@UIApplicationDelegateAdaptorに自作したAppDelegateを読ませる必要があります。

宣言的フレームワークはSwiftUIだけのものなのか

SwiftUIは宣言的にUI構築ができるように作られました。しかしUIKitでも同じことができないでしょうか？SwiftUIは内部的にUIKitが使われています。またSwiftUIを支える技術はSwiftの機能により実現されているため、自分たちでUIKitを宣言的に構築する機能を作ることができます。この内容は崎山さんのQiitaにてUIKitで宣言的に構築する実装として解説されています。詳しくはこちらを参照してください。

またSwift Zoominというコミュニティにて「SwiftUIを支えるSwiftの言語機能」という題目で要素技術の解説しています。こちらも合わせて参照してください。

The Composable Architecture(TCA)

直近のiOS開発の世界を語る上で大きな影響力を持ち始めたライブラリについて避けることはできません。Redux-LikeやElm Architectureと呼ばれる要素をiOSの世界に持ってきたものであり，ActionとStateをReducerに入れることにより次のStateを出力するreduce機能を基礎としてアプリ開発ができるようになるものです。

アプリを開発する上で責務の分割などを意識しないと神クラスとよばれるなんでもする単一のクラスが生成されてしまう場合があります。これを避けやすく，かつテストが書きやすいためアプリが将来的にメンテナンスに長けたものになるというものです。非常に便利なため大規模〜中規模レベルでは導入すると良いとされています。

個人的な懸念としてTCAはXcodeのコード補完周りに大きく負荷をかけます。高度な推論に頼るコード補完となるため型の補足を部分的に記述してあげないとコード補完が効かなくなる場合があります。また単純に学習コストも大きいため初学者が多い開発のチームでは足枷となってしまう場合があります。チームのレベルに応じて導入の検討をしたほうが良いです。

Asset周りの管理

SwiftGen

Xcodeでの画像や文字列の管理はそこまで楽ではありません。また，リソースの名前はXcodeの補完にて効いてほしいと強く願うものです。そのための解決ツールにSwiftGenがあります。リソースそれぞれに対するアクセスができるコードを自動生成してコードで出力してくれるため快適なリソースへのアクセスを提供してくれます。また個人的に一番の利点として感じている機能にstring周りの扱いを簡単にしてくれるというものがあります。L10n.alertMessageとして書くだけでstringファイルに定義された内容をかけるというありがたさは導入する価値があります。

https://github.com/SwiftGen/SwiftGen

DB周りの管理

これについては人それぞれ，チームのデータベースによる取り組み方により大きく変わる部分です。

Firestore

Firestoreにはオフラインキャッシュがあるため、ユーザのデータをデバイスを跨いで管理する用途がある場合には検討できます。FirestoreでのデータはCodableに対応するため通常のデータの構造をそのまま永続層としてもつような設計にすることも可能です。難点は複雑な検索が少し難しいことかもしれません。

SQLite系

GRDB.swiftやSQLite.swiftを検討できます。こちらは通常のSQLiteのツールキットとして開発されているため王道の永続化に対するアプローチです。

https://github.com/groue/GRDB.swift

Core Data

SPMを利用する場合は避けたほうがよいです。SPMでのCore Dataはうまく開発段階で機能せず本体に組み込むこととなります。またXcodeもSPMでのプロジェクトを作っている場合にCore DataのGUIでのサポートがされないです。

Firebaseとの付き合い方

Firebaseは大変ありがたいフレームワークです。しかしiOSアプリ開発となるとかなりの曲者でもあります。素直にSPMでFirebaseを導入するとビルド時間がかなり長くなり，SwiftUI Previewは高確率で機能しなくなります。そのためできる限りビルドを避けるように分離して積極的にキャッシュが効くようにすること，もしくはxcframeworkとしてビルド済みのものを使うなどの工夫を行ってFirebaseのビルドが発生する機会をなるべく避けるほうが良いです。

終わりに

他にも開発を助けるものは多くありますが，開発をする上で検討したほうが良いのではと考えた内容と自分が新しく開発をする場合に最初に選ぶものを書いてみました。明日の記事はiOSアプリでテストを導入する上で最初から考えたいテストを簡単に行う方法についてです。