XcodeでマルチプラットフォームAppを開発する

XcodeでマルチプラットフォームAppを開発する

Xcode 14を使用して、複数のAppleプラットフォーム用のAppをビルドする方法をご覧ください。Appターゲットを合理化する方法、共通のコードベースを維持する方法、デフォルトの設定を共有する方法を紹介します。また、設定やコードの条件設定により、各プラットフォームに合わせてAppをカスタマイズする方法についても解説します。

リソース
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC22
- SwiftUIの最新情報
- Xcodeの最新情報
ダウンロード

こんにちは XcodeチームデザイナーのJakeです Xcode14ではマルチプラットフォーム App開発が進化しています単一のAppターゲットで複数のプラットフォームにわたって対応できるようになりました単一の共通コードベースを維持しデフォルトで設定を共有し必要に応じて新しい方法で条件付けができますまずマルチプラットフォーム Appのターゲットとは何かどのような場合に最適かについて説明します
複数の実行先とプラットフォームに対応するためにプロジェクトを修正し新しいプラットフォームでビルドし実行できるようプロジェクトを更新します
各対応プラットフォームで Appが美しく見えるよう設定し...
そして最後に Xcode Cloud をプロジェクト変更と統合します
Appをマルチプラットフォームに対応させるためにどのようなテクニックを使うのかを理解しましょう Xcode 14以前では AppをiOSとmacOSに対応させたい場合 2つのターゲットが必要でしたプロジェクトが大幅に異なるコードベースを必要とする場合や異なるプラットフォーム間でほとんど設定を共有しない場合各Appターゲットが異なる基礎技術に大きく依存している場合に有効です
もし現在もあなたのプロジェクトがそうであるなら最善策は各プラットフォームごとに別のターゲットを使い続けることです Xcode14では 1つのAppターゲットで iPhone iPad Mac Apple TVなど多くの実行先への対応を宣言することができます共通のコードベースを使用し全実行先で設定の大部分を共有しながらも必要に応じてカスタマイズを行うAppに最適です Xcode 14でマルチプラットフォーム Appがどう機能するか見てみましょうゼロから始める場合 Xcodeで新規プロジェクト作成時に改良されたマルチプラットフォームApp テンプレートを使用するのが良い方法です
このテンプレートはライフサイクルとインターフェースにSwiftUIを使い iPhone iPad Macをサポートするようデフォルトで設定されたターゲットからスタートします新規プロジェクトのための素晴らしい構成です SwiftUIを使用しているため各プラットフォームの SDK全機能にアクセスでき各プラットフォームが提供するものを活用した素晴らしい新Appを作成することができます既存のプロジェクトでも Appターゲットで複数の実行先のサポートを宣言し SwiftUIで各プラットフォームの SDKのフルパワーにアクセスできますここでは既存のiOS Appに Macの実行先を追加する方法を説明します Food TruckのAppを作っていて iPhoneやiPadでうまく動作しますこのiOS Appにはかなり満足しているので今度はMacでプラットフォームとその機能を受け入れようと思います Xcodeでプロジェクトがどう見えるか見てみましょう
Appのターゲットを見ると私のAppがサポートする全実行先のリストが表示されます
iPad用にデザインされたMac用の実行先があるのがわかります Appleシリコンを搭載した Macで iOS Appを動作できますこれでMacのサポートを始めることができましたが私はMacのサポートを次レベルに進めたいのですいわば「Mac用デザイン」的な体験を加えましょう
対応する実行先リストを簡単に編集し Macの実行先を Appに追加できます Macの実行先にはいくつか選択肢があります： Mac　Mac Catalyst Designed for iPadのうち最後の1つはすでにサポートしておりグレーアウトされています
MacとMac Catalystのどちらを選ぶかは主にどちらの技術を使いたいかで決まります AppのコアにUIKitやStoryboardsが多用されている場合 Mac Catalystは既存のiPad Appを互換性のある MacApp変換する素晴らしい方法となるでしょうしかし SwiftUIを使うため「Mac」オプションが Mac Appを作るための最良の選択となります macOS SDKのフルパワーで制限なく箱から出してすぐに Macの見た目と感覚が手に入ります iOS AppではUIKitを macOS AppではAppKitを必要に応じて柔軟に使い分けることができるようになるのですこれを踏まえて SwiftUIで作業するのに最適な「Mac」を選んでみましょう一度選択すると Xcodeはプロジェクトを Mac対応にするためにいくつかの変更を警告しますこの場合 Xcodeはターゲットを更新して Macでサポートされる依存関係や構成のみを含めます Xcodeは私のコードに変更を加えないのでもしMacで利用できない APIを呼び出している場合は自分でその問題を解決する必要があります Macのオプションを選ぶと対応する実行先リストに追加されます Xcodeで開発しているときに複数のMacの実行先があるのも全く有効なことです特に「Mac Catalyst」や「Designed for iPad」から完全なMacAppに移行する場合これは便利です
Xcodeの中でMacの各製品をテストし続けることができますまた Appを開発する際一つの選択肢に縛られませんしかしネイティブのMac AppをApp Storeに公開すると Designed for iPad Appは私のユーザーが利用できなくなりますそこでXcodeはこの実行先を削除する迅速な方法を提供しますしかし Macのネイティブな体験に満足したらこの実行先を削除することも考えていますゼロから始める場合でも既存Appに新しい実行先を追加する場合でも Xcodeで単一のターゲットを使用するとデフォルトでコードとビルド設定を共有することができます Appの表示名や最小デプロイメントバージョンなど個別の設定をカスタマイズしたい場合があります Xcode 14で改良されたターゲットエディタでその方法を見てみましょう多くのAppのターゲット設定にその値の条件付け方法が含まれますサポートされている設定ではプロジェクトの各ビルド構成にデフォルト値を設定できるエディタを表示できます私は新しいXcodeプロジェクトに付属する標準の DebugとReleaseの構成だけでなく追加したカスタムBetaの構成を持っていますベータ構成でビルドしたとき Appに別の表示名を付けたいのでここで名前を編集すればいいのです XcodeのApp表示名が表示名が取り得るすべての値で置き換えられていることがわかります必要であれば条件を追加しどのSDKを使用するかに応じ値を指定することもできますこれにより Mac用にビルドする際にベータ版の構成に特定の名前を設定ができます
さて「General」タブで行いたい編集は終わったはずです Signing and Capabilitiesタブで他に必要な変更を確認しましょう
自動署名をオンにしておけば余計な手間がかかりません Macの実行先を追加すると Macに必要な署名証明書とプロビジョニングプロファイルが代理で生成されました iOSとmacOSのApp製品は既定で同じバンドル識別子を使いますこれは素晴らしいことで App Storeに公開するとユニバーサル購入で利用できるようになります iOS Appを購入した人は自動的にMac Appも手に入りますプッシュ通知などの機能も活用しています iOS Appで使っていた機能が macOS Appにも適用され余分な作業をすることなく利用できるようになりますさらに 1つのエンタイトルメントファイルにまとめられます Appに複数の実行先のサポートが追加されたので次の目標はビルドすることです新しいMacサポートのように新しいSDKが関係する場合新しい実行先でのビルド時に問題が発生するのはよくあることですそのよくある問題点をご紹介しましょう一部のフレームワークは全プラットフォームで使用できません利用できないフレームワークをインポートやリンクしていないことを確認する必要があります Xcodeは新しい実行先のサポート追加時にコードを変えず App設定を条件付きにしたのと同じように SDKに基づいてコードを条件付きにする必要がありますこれはAPIにも言えることですどのSDKで構築しているかで利用できない機能が表示されます Swiftは構築しているSDK で利用可能な機能のみを含むようコードの一部を条件付けする方法を提供します Xcodeでは一部のSDKビルド時に個々ファイルをコンパイルするか指定することができますもし今プロジェクトをビルドしたら... 特に問題はないようですそれはツールバーでiOS SDKを使用する実行先が選択されたままだからです macOS SDKにビルドするためリストから「My Mac」を選びます
今回ビルドを行いいくつか新しい問題が明らかになり予想通りそれは主に可用性に関するものでしたあるファイルで Macでは利用できないARKitをインポートしていますこのimport文を#if canImportで包んで条件分岐させます
フレームワークが利用可能な既知のプラットフォームのリストを管理せず単に利用できない場合は含めない場合に便利ですただこのファイル全体でARKitを使用していることに変わりはないので SDKのためにファイル全体を条件分岐させる方が理にかなっていますターゲットに戻り「Build Phases」タブを開くとファイルを検索ができます...
iOS用にのみコンパイルされるよう指定します
ビルド後それらの変更を行った後 Xcodeは新しい問題を報告します Macで利用可能なフレームワーク SwiftUIには利用不可とマークされている機能があります具体的には iOSでは EditModeを使いユーザーが TableやListで編集やコンテンツの選択をできますが macOSではEditModeが存在しません！ Macではユーザーが自由にコンテンツの行を選択・編集できるのでこのコードはiOSでのみ実行されるようにしましょう環境プロパティと下のEditModeを使っていたところならどこでも条件出しができます
このonChange修飾子のようにこのプロパティを使用していた場所も条件から外されていることを確認しますモディファイア全体を「if os」の条件で囲えます
最後にツールバーのEditButton ビューもiOS限定です
では Appを実行してみましょう
動いています！私たちのAppが Mac上でビルド動作します！新プラットフォームで Appがビルド動作しても私たちの仕事は終わりではありません新プラットフォームのユーザーの期待に合わせて App体験を洗練させたいケースもあるはずです iOS専用の機能を切り捨てることは私たちの旅の終わりではありませんこれでmacOS SDKの全機能を遊べるようになりました私のAppがMac上で動いているのを見て新しいコンテキストでは私のAppが自然でないと感じる点がありましたこのグリッドビューのドーナツは大きすぎるような気がします私たちのグリッドアイテムがタッチ前提に設計されているためですこのような状況は UI要素のポイントサイズを宣言するなど単一プラットフォームのみを意識したカスタマイズで発生します Macではより精密なポインティングデバイスを使うためボタンやサムネイルを大きくする必要はありませんプロジェクト内の定数をどのSDK向けにビルドしているかに応じて変化させるための条件付けに最適なケースです私たちのAppを他のプラットフォームに移行時は新プラットフォームの期待に合わせ選択肢の多くの再考が重要ですどのSDK向けにビルドするかによって異なる値の指定を見てみましょうよく使う手法のひとつは定数を計算されるプロパティにし #if osを使って返答を条件付きで指定しますこれを計算されたプロパティに変換して以前は定数だったものを返してみましょう... しかしiOSではその値しか返しません
80はもっと自然な大きさに感じますね
macOS SDKの活用ですが SwiftUIにはメニューバーに独自のUI要素を追加できる新機能があります Appにはサマリービューがありユーザーに素早く簡単にアクセスできるようにしたいと思っています App 宣言に移動して Menu Bar Extra 用に新しいScene を追加しますただしこれはmacOS だけの機能なので macOS SDKのために条件付けの必要があります
ビルドして実行し見てみましょう
すごい！トラックのアイコンがメニューバーに表示されました私のMacユーザーはメニューバーから今日の情報を一目で見ることができるようになりました SwiftUIを使うと各プラットフォームのフルSDKにアクセスできその素晴らしい機能を利用することができます重要なのは Appを他のプラットフォームに移行時新プラットフォームの文脈で作業する場合過去の選択を再考する必要があるということです SwiftUI はプラットフォームの期待をAPI に直接実装します多くのインターフェース要素が各プラットフォームで見栄える自動的な外観を獲得できます逆にコントロールなどのUIを大幅にカスタマイズすると自動的なスタイリングが失われる可能性もありますよって UIが常に美しく見えることを再確認する必要がありますクールなAppを作るにはヒューマンインターフェースガイドラインのベストプラクティスに沿っていることを確認する必要があります Appのローカル変更に満足したら App製品をアーカイブし App Store Connectにアップロードします Xcode から行うことも Xcode Cloudで自動化もできます準備が整ったら TestFlightで社内外のテスターとAppを共有し App Storeにリリースすることができます App Store Connectにアップロードする為プロダクトをアーカイブする必要がありますターゲットが 1つだからといって 1つのプロダクトしかないわけではありません各プラットフォームにアーカイブを作り個別にアップロードする必要がありますローカルでビルドしてアーカイブする場合作成したい SDKがある保存先を選択する必要があります macOS Appを作りたい場合実行先リストから「My Mac」を選択する必要がありそうでない場合 iOS Appを作る為iOSデバイスを選択します
実行先を選択したら「Product Archive」を選択しアーカイブを作成できます
アーカイブが完成したら XcodeのOrganizerウインドウで App Store Connectにアップロードできます
Xcode Cloudを使う場合ワークフローにアクションを追加しプロダクトのビルドテストアーカイブを行えますワークフローのアクションリストでは各プロダクトのビスとテスト分析アーカイブのための新項目を作成できます今回は iOS Appと macOS Appがあります一歩進み App Store Connect へのAppアップロードを自動化するためのデプロイメント準備を含められますこれらのビルドを社内の TestFlightチームに送信しプレスからすぐに変更のフィードバックを得られますまとめると Xcode 14はマルチプラットフォームApp開発を次レベルに引き上げ合理化されたAppターゲットで複数プラットフォームでさらに多くの実行先をサポート可能です単一のAppターゲットで共通のコードベースと共有設定をデフォルトで維持することができますニーズに応じて設定やコードを条件付けすることでプラットフォームの期待に最適にAppをカスタマイズできますあとは皆様次第です今年のXcodeの新機能や改善点については「Xcodeの新機能」をご覧ください XcodeとSwiftUIのパワーでどんな素晴らしいアイデアを実現するのか楽しみでなりません

#if canImport(ARKit)
import ARKit
#endif

10:02 - Condition Property

#if os(iOS)
@Environment(\.editMode) private var editMode
#endif

10:13 - Condition View Modifier

#if os(iOS)
.onChange(of: editMode?.wrappedValue) { newValue in
    if newValue?.isEditing == false {
        selection.removeAll()
    }
}
#endif

10:19 - Condition View
```
#if os(iOS)
EditButton()
#endif
```

11:48 - Computed Property

var thumnailSize: Double {
    #if os(iOS)
    return 120
    #else
    return 80
    #endif
}

12:37 - Menu Bar Extra

#if os(macOS)
MenuBarExtra {
    MiniTruckView(model: model)
} label: {
    Label("Food Truck", systemImage: "box.truck")
}
.menuBarExtraStyle(.window)
#endif

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC22