# Expo UpdatesとPaktaの比較

Expo UpdatesとPaktaのクライアント、ホスティング、配信対象、ネイティブビルドの違いを整理し、要件に合った導入方法を選べます。

## Expo のアップデート、EAS アップデート、それとも Pakta? {#answer}

`expo-updates` は、Expo のアップデート クライアント ライブラリです。 EAS Update は、それと連携して動作するホスト型サービスです。 Pakta は、`rn-update` および `pakta` CLI を使用する別個の OTA プラットフォームです。 Expo アプリをサポートしても、Pakta が Expo Updates プロトコル サーバーまたは `eas update` の宛先になるわけではありません。

アプリがすでに EAS Update を正常に使用している場合は、既存のワークフローを評価することから始めます。ネイティブ パッケージのターゲティング、差分配信、リリース操作が必要で、新しいネイティブ統合を出荷できる場合は、Pakta を評価してください。

## 統合契約を比較します {#comparison}

|質問 | Expo の最新情報 / EAS の最新情報 |Pakta |
| --- | --- | --- |
|どのクライアントがアップデートをロードしますか? | `expo-updates` | `rn-update` |
| 配信手順はどう違いますか？ | EAS Update には EAS CLI を使用します | `pakta bundle --expo` の後に `pakta publish` を実行します |
|適格なターゲットとは何で定義されますか? |プラットフォーム、ランタイム バージョン、チャネル/ブランチ ルーティング |アプリケーション、埋め込みネイティブ チャネル、登録済みネイティブ バージョンおよび互換性チェック |
|ネイティブ Expo ビルドを使用できますか? |はい |はい、Pakta ネイティブ統合を使用します。
| ホスティング先は相互に置き換えられますか？ | `expo-updates` は互換性のある独自更新サーバーを利用できます | Pakta は独自の SDK とサーバーの仕様を使用します |
|ネイティブ コードを変更するには再構築が必要ですか? |はい |はい |

クライアント/サーバーの分離については公式の [expo-updates リファレンス ](https://docs.expo.dev/versions/latest/sdk/updates/) を、ターゲット ルーティングについては [EAS Update の仕組み ](https://docs.expo.dev/eas-update/how-it-works/) を参照してください。この表は統合の違いを説明したものであり、完全な機能や価格のランキングではありません。

## Pakta は Expo Router および EAS Build と連携できますか? {#expo-build}

はい。 Pakta の [Expo ガイド ](/docs/expo) は、ルート レイアウトで `UpdateProvider` を接続し、ネイティブ チャネル構成にパッケージ化された構成プラグインを使用し、ローカルの Expo ツールまたは既存の EAS プロダクション ビルド ワークフローを通じてリリース ビルドを生成します。このプロジェクトの自動 iOS 統合には、Expo 50 以降が必要です。実際の Expo/React Native の組み合わせを検証します。

EAS Build はネイティブ インストーラーを生成します。インストーラーに EAS Update の使用を強制するものではありません。 Pakta の統合後、正確なインストーラーを登録し、Pakta CLI を使用してアップデートをビルドして公開します。

## Expo Go で Pakta をテストできますか? {#expo-go}

いいえ。Expo Go には Pakta のネイティブ統合は含まれていません。独自のネイティブ リリース ビルドを使用します。 Expo Go での JavaScript のリロードでは、`rn-update` がアップデートをダウンロード、アクティブ化、または回復したことを証明できません。

## 既存の更新ワークフローを移動するにはどうすればよいですか? {#migration}

1. 現在の更新クライアント、ネイティブの依存関係、アクティベーション ポリシー、および互換性のあるバイナリを記録します。
2. 移行ビルドでは、古いクライアントがバンドルを読み込む処理を削除します。起動時に OTA クライアントが 2 つのバンドルを選択する状態にしないでください。
3. [Expo ネイティブ セットアップ](/docs/expo) に従って、ルート プロバイダーを構成し、新しいリリース インストーラーを構築します。
4. インストーラーを登録し、[最初のリリース](/docs/publish)を使用して、目に見える変更を内部チャネルに公開します。
5. 新しいネイティブ バージョンを配布する前に、デバイスのアクティベーションとリカバリを確認します。

EAS `runtimeVersion` またはチャネル名は、Pakta 構成に自動的に転送されません。 Pakta のチャネルはネイティブ ビルドに埋め込まれています。 [チャンネルアイデンティティ](/docs/channels#identity)を参照してください。

## コストと配送をどのように比較すればよいですか? {#evaluation}

同じアプリの変更と実際のデバイスを使用して、転送バイト数の測定、更新遅延、ダウンロードの失敗と回復を行います。各サービスの現在のプランをアクティブなデバイス、更新チェック、帯域幅、ストレージ、サポートのニーズと照らし合わせて確認します。現在のプランのソースとして [Pakta 価格](/pricing) および [Expo 価格](https://expo.dev/pricing) を使用します。想定されるパッチの割合を使用してコストを比較しないでください。

より広範な概要については、[React Native OTA アップデート ](/docs/react-native-ota-update) をお読みください。 CodePush を開始点とする場合は、[移行ガイド](/docs/codepush-alternative)。