Use Xcode to develop a multiplatform app

ハイライト

Xcode 14 では、単一のアプリターゲットで iPhone、iPad、Mac、Apple TV などの複数のターゲットを同時にサポートできるため、プラットフォームごとに条件付きでコンパイルおよび構成する機能を維持しながら、コードとデフォルト設定を共有することで作業の重複を削減できます。

主要内容

あなたは iOS アプリを開発しましたが、それはうまく機能しました。次に、それを Mac に持ち込んでみましょう。

Xcode 14 より前では、これは 2 つの別々のターゲットを作成し、コードの 2 つのコピーを維持し、2 セットのビルド設定を管理することを意味していました。コードの変更は両側で同期する必要があり、署名証明書と説明ファイルは個別に構成する必要があります。

(01:29) Xcode 14 ではそれが変わります。単一のアプリターゲットで複数の宛先のサポートを宣言でき、コードと設定はデフォルトで共有され、必要な場合にのみプラットフォームごとにカスタマイズできます。

マルチプラットフォームターゲットを使用する場合

(01:02) プロジェクトに異なるプラットフォーム上で大幅に異なるコードベースがある場合、または各プラットフォームが完全に異なる基盤テクノロジに依存している場合は、独立したターゲットを使用し続ける方が適切です。

アプリケーションが共通のコードベースを使用し、ほとんどの設定を共有できる場合は、マルチプラットフォームターゲットを選択することをお勧めします。 SwiftUI アプリは、各プラットフォームの完全な SDK にアクセスできるため、このモデルに特に適しています。

Mac の宛先を追加

(02:37) セッションフードトラックアプリケーションを例に挙げます。このアプリはすでに iPhone と iPad でうまく機能しており、現在 Mac のネイティブサポートが追加されています。

ターゲットの「全般」タブで、現在サポートされている宛先リストを確認できます。このアプリはすでに「iPad 用に設計」されており、Apple シリコン Mac で未修正の iOS アプリを実行できます。ただし、真の Mac エクスペリエンスを実現するには、「Mac」の宛先を追加する必要があります。

(03:26) Mac には 3 つのオプションがあります。

Mac: ネイティブ macOS アプリケーション、完全な macOS SDK、SwiftUI プロジェクトに適しています
Mac Catalyst: iPad アプリを Mac アプリに変換します。UIKit を頻繁に使用するプロジェクトに適しています。
iPad 用に設計: Apple シリコン Mac は、変更を加えずに iOS アプリを直接実行します。

Food Truck は SwiftUI を使用するため、ネイティブ Mac が選択されます。

(04:19) 追加後、Xcode はターゲットを自動的に更新し、Mac でサポートされている依存関係とフレームワークのみを保持します。 Xcode はコードを変更しないため、Mac で使用できない API がある場合は、手動で処理する必要があります。

条件付きビルド設定

(05:45) Xcode 14 のターゲットエディターは、条件付きの値の設定をサポートしています。たとえば、表示名はビルド構成と SDK によって個別に設定できます。

設定値の横にある「条件付き」ボタンをクリックして、デバッグ、リリース、ベータなどの構成の値を指定するか、SDK (iOS/macOS) ごとにさらに細分化します。

署名と機能

(06:42) 自動署名がオンになっている場合、Mac の宛先を追加した後、対応する証明書と説明ファイルが自動的に生成されます。 iOS アプリと macOS アプリはデフォルトで同じバンドル識別子を使用し、ユニバーサル購入は App Store に公開されるときに自動的に実装されます。

機能も自動的に処理されます。 macOS で利用可能な iOS で有効な機能は、Mac バージョンに自動的に適用され、単一の資格ファイルにマージされます。

プラットフォームの違いの処理

（07:41）切换到 “My Mac” destination 后构建，会发现一些平台相关的问题。

ARKit は Mac では利用できず、条件付きインポートが必要です。

#if canImport(ARKit)
import ARKit
#endif

(09:15) You can also directly specify a file to be compiled only on a specific SDK in Build Phases.このアプローチは、プラットフォーム固有の API を頻繁に使用するファイルにとってよりクリーンです。

EditMode は、Mac 上のユーザーがコンテンツを直接選択して編集できるようにする iOS 固有の概念です。関連する環境プロパティ、onChange 修飾子、および EditButton ビューを使用する必要があります。#if os(iOS)それをまとめてください。

アダプテーションプラットフォームのエクスペリエンス

(10:59) Being able to compile and run the application on Mac is only the first step.プラットフォームの違いによって生じるエクスペリエンスの問題も考慮する必要があります。

Mac では、Food Truck のグリッドビューのドーナツサムネイルが大きすぎて表示されます。これは、Mac には正確なポインティングデバイスが搭載されているのに対し、Mac はタッチ操作用に設計されているためです。

（11:48）把常量改为计算属性，按平台返回不同值：

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

Mac では 80 ピクセルサイズの方が自然に見えます。

(12:21) iOS 固有の機能を調整することに加えて、macOS 固有の機能を利用することもできます。 SwiftUI には、メニューバーにアプリケーションコンテンツを配置できる MenuBarExtra が追加されました。

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

Mac ユーザーは、メニューバーから今日の情報をすぐに確認できるようになりました。

アーカイブして公開する

(14:02) 単一のターゲットは単一の製品を意味するものではありません。各プラットフォームは個別にアーカイブし、個別に App Store Connect にアップロードする必要があります。

Xcode Cloud ワークフローでは、iOS と macOS にそれぞれビルド、テスト、アーカイブアクションを追加でき、App Store Connect への自動アップロードや内部 TestFlight テストチームへの配布を構成することもできます。

詳細

条件付きコンパイル

(08:48) Swift は、さまざまな条件付きコンパイル方法を提供します。

// 按模块可用性条件化导入
#if canImport(ARKit)
import ARKit
#endif

// 按操作系统条件化代码
#if os(iOS)
@Environment(\.editMode) private var editMode
#endif

// 条件化视图修饰符
#if os(iOS)
.onChange(of: editMode?.wrappedValue) { newValue in
    if newValue?.isEditing == false {
        selection.removeAll()
    }
}
#endif

// 条件化视图
#if os(iOS)
EditButton()
#endif

キーポイント:

canImportフレームワークレベルの可用性の処理に適しており、プラットフォームのリストを維持する必要はありません
os(iOS) / os(macOS)SDKレベルの違いを処理するのに適しています
条件付きコンパイルはコンパイル時に処理され、実行時のオーバーヘッドは生成されません。
条件付きコードブロックは構文的にはそのままである必要があり、条件付きの境界を越えて分割することはできません

ファイルレベルのプラットフォーム制限

(09:17) プラットフォーム固有の API を多数使用するファイルの場合、ビルドフェーズでコンパイル条件を設定できます。

ターゲットを開く > ビルドフェーズ > ソースのコンパイル
目的のファイルを見つけます
右側の条件欄に指定します"$(SDKROOT)" == "iphoneos*"または同様の条件

このようにして、ファイル全体が一致する SDK 上でのみコンパイルされ、ファイル内のあらゆる場所に SDK が存在することを避けます。#if。

プラットフォーム適応原則

(13:09) SwiftUI は、プラットフォームの期待を API に直接組み込みます。多くのインターフェイス要素は、プラットフォーム固有の外観を自動的に取得します。

これはつまり：

各プラットフォームに自動的に適応できるように、SwiftUI のネイティブコントロールを使用してみてください。
コントロールを過度にカスタマイズすると、この自動適応が失われます
タッチ用に設計された寸法は、デスクトッププラットフォームでは大きすぎることがよくあります
各プラットフォームのインタラクションパラダイムの違いを考慮する (タッチとポインター、ジェスチャーとメニュー)

重要ポイント

内容: 既存の iOS SwiftUI アプリを Mac に拡張します
実行する価値がある理由: Xcode 14 のマルチプラットフォームターゲットにより、メンテナンスコストが大幅に削減され、同じコードセットがより多くのユーザーにサービスを提供できるようになります。
開始方法: ターゲットの [全般] タブに Mac の宛先を追加し、ビルドエラーを処理し、徐々に Mac の操作習慣に適応させます。
何をすべきか: Mac バージョンのメニューバーショートカットエントリを追加します。
価値がある理由: MenuBarExtra は、Dock を占有することなくいつでもアプリを利用できるようにする macOS の独自の機能です。
開始方法: アプリ構造で使用します#if os(macOS)メニューバーのラップ追加シーン
やるべきこと: 各プラットフォームの強みを活用するクロスプラットフォームの生産性ツールを構築する
実行する価値がある理由: iOS バージョンはモバイルシナリオでのデータ収集を担当し、Mac バージョンはデータ分析とバッチ処理を担当します。
開始方法: を使用して、SwiftUI で共有 UI レイヤーを構築します。#if os()プラットフォーム固有の機能を分離し、アプリグループを通じてデータを共有する
内容: マルチプラットフォームアプリを自動的に構築して配布するように Xcode Cloud を構成します
実行する価値がある理由: 1 回のコミットで iOS および macOS バージョンを自動的にビルドし、TestFlight に直接プッシュします
開始方法: iOS と macOS の宛先をそれぞれ指定して、複数のアーカイブアクションを Xcode Cloud ワークフローに追加します。

Use Xcode to develop a multiplatform app

ハイライト

主要内容

マルチプラットフォームターゲットを使用する場合

Mac の宛先を追加

条件付きビルド設定

署名と機能

プラットフォームの違いの処理

アダプテーションプラットフォームのエクスペリエンス

アーカイブして公開する

詳細

条件付きコンパイル

ファイルレベルのプラットフォーム制限

プラットフォーム適応原則

重要ポイント

関連セッション

コメント

ハイライト

主要内容

マルチプラットフォーム ターゲットを使用する場合

Mac の宛先を追加

条件付きビルド設定

署名と機能

プラットフォームの違いの処理

アダプテーション プラットフォームのエクスペリエンス

アーカイブして公開する

詳細

条件付きコンパイル

ファイルレベルのプラットフォーム制限

プラットフォーム適応原則

重要ポイント

関連セッション

コメント

マルチプラットフォームターゲットを使用する場合

アダプテーションプラットフォームのエクスペリエンス