react-native-update

React Native Update / Pushy / Cresc

概要

このスキルを使うと、「未統合」のプロジェクトを「リリースビルドでホットアップデートが機能する」状態にできます。 コピーしてそのまま使える手順、必要最小限の変更、明確な確認ポイントを優先してください。

エージェントとホスト間の移植性

• Agent Skills を読み込める任意のエージェントでこのスキルを使用できます。特定のホスト、モデル、プラグインシステム、ワークスペースの構成、ツール名を前提にしないでください。
• references/ と scripts/ は、アプリのルートやプロセスの作業ディレクトリではなく、この SKILL.md があるディレクトリを基準に解決してください。ホストで利用できるファイル読み取りツールを使って、リファレンスを読み込んでください。
• agents/openai.yaml はホスト固有の任意のメタデータであり、依存関係でも、エージェントの許可リストでもありません。agents/ がなくても、手順は引き続き使用できます。必須の統合動作をアダプターだけに含めないでください。
• ファイルの編集とコマンドの実行は、ホストで利用できるツールと承認ポリシーに合わせてください。実行環境または Node.js が利用できない場合は、手動チェックリストを使い、コマンドをユーザーに提示し、該当するチェックは未実行として報告してください。このスキルを使うためだけに、特定のエージェントをインストールしないでください。
• Node.js 22+ と実行権限がある場合は、node <skill-root>/scripts/integration_doctor.mjs <app-root> を優先してください。隣接する .sh ラッパーは任意の Bash 用の補助であり、必須ではありません。スキルのルートとアプリのルートは分けて指定し、スペースを含むパスは引用符で囲んでください。
• スキルのインストールと更新は、所有するホスト／インストーラー、または明示的に設定された外部マネージャーが行います。アプリの統合手順の一部として、リポジトリのメンテナンスや自己更新ツールを実行しないでください。

サービスの振り分け

• 中国向けサービスには Pushy を使用します。pushy CLI、new Pushy(...)、Pushy ダッシュボードを使用してください。
• グローバルサービスには Cresc を使用します。cresc CLI、new Cresc(...)、Cresc ダッシュボードを使用してください。
• CLI、ダッシュボード、アプリのレコード、update.json、JS クライアントのクラスは、すべて同じサービスにそろえてください。pushy createApp と new Cresc(...) を組み合わせたり、その逆を行ったりしないでください。
• サービスが不明な場合は、ユーザーの表現、既存のインポート、レジストリ／ドメイン、ドキュメントのロケールから推定してください。それでも不明な場合は、中立的な構成を実装し、ユーザーが選ぶ必要のある箇所として Pushy と Cresc のどちらか一方を明示してください。

ワークフロー

1. アプリのルート、パッケージマネージャー、インストール済みの React Native／Expo／react-native-update のバージョン、グローバル CLI のバージョン、サービス、対象プラットフォーム（ios、android、harmony。Apple TV は ios を使用）を確認します。
2. 手順を提示または適用する前に、references/integration-playbook.md を読みます。tvOS、RN 0.87、RN 0.88 の SceneDelegate、メタデータ／ソースマップ、非対話型の公開、Hermes ベースの診断については、references/modern-integration.md も読みます。
3. アプリに react-native-update をインストールし、react-native-update-cli をグローバルにインストールします。pushy または cresc を直接実行し、プロジェクトローカルの CLI や npx に切り替えないでください。
4. 検出したプラットフォームとアプリの構成に合わせて、ネイティブのバンドル読み込みを設定します。
   • iOS／tvOS では RCTPushy.bundleURL() または Expo の自動統合を使用します。RN 0.88+ のテンプレートでは、bundleURL() のオーバーライドは AppDelegate ではなく SceneDelegate にあります。
   • Android では、ReactHost、ReactNativeHost、またはカスタムのインスタンスマネージャーを通じて UpdateContext.getBundleUrl(...) を使用します。
   • Harmony では、パッケージ／プロバイダー／バンドルプロバイダーの配線を行います。
   • Brownfield では、ホストの継承を変更する代わりに、ランタイムフックを使用します。
5. ルートコンポーネントの外部に Pushy または Cresc のクライアントを1つだけ追加し、実際のアプリツリーを UpdateProvider でラップします。
6. 実行環境が利用できる場合は、node <skill-root>/scripts/integration_doctor.mjs <app-root> を実行し、対応可能な不足項目を修正します。自動化には --strict --json を使用します。不足要件がある場合は 2、診断エラーの場合は 1 が返されます。それ以外の場合は手動チェックリストを適用し、診断は未実行として報告します。静的チェックでは、デバイス上のネイティブバイナリは検証できません。
7. エンドツーエンドの統合をユーザーが希望する場合は、リリースビルドの検証、ベースラインのアップロード、ホットアップデートの公開チェックまで行います。

ガードレール

• ユーザーコードの変更は最小限にし、局所的にとどめてください。
• 後方互換性を維持してください。バージョン固有の機能を使用する前に、インストール済みの SDK とネイティブバイナリの機能を確認してください。古いバイナリに存在しないネイティブメソッドを JavaScript から無条件に呼び出さないでください。機能を検出するか、従来のフローを維持してください。新しいネイティブ機能を利用するには、新しいネイティブリリースとベースラインが必要であり、OTA パッケージだけでは不十分です。
• デバッグモードで更新を適用できると約束しないでください。debug: true は開発中の確認やダウンロードに役立ちますが、パッチの適用にはリリースビルドが必要です。
• Expo プロジェクトでは、expo-updates との競合について警告してください。
• client を直接呼び出すのではなく、useUpdate() のメソッドと状態を優先してください。クライアントを直接呼び出すのは、明確に必要な低レベル統合のための回避策に限り、その理由を説明してください。
• UI や長時間継続するフローには、useUpdate() の updateInfo／lastError を優先してください。checkUpdate() は CheckResult | undefined も返すため、範囲の限られた単発アクションでその戻り値を使用するのは問題ありません。undefined はスキップまたは失敗として処理し、プロバイダーとは別の状態管理を構築しないでください。
• プロセスごとに、Pushy または Cresc クライアントをちょうど 1 つ、マウント済みの UpdateProvider をちょうど 1 つ維持してください。SDK の状態はプロセス単位のシングルトンです。
• 既存のアプリのアーキテクチャを維持し、スニペットは現在のプロジェクトのスタイルに合わせてください。
• ネイティブファイルに大きな差異がある場合（モノレポ／ネイティブ実装の混在など）は、大規模な書き換えではなく、対象を絞ったパッチの指示を提示してください。
• JS／アセットは OTA で安全に更新できるものとして扱ってください。ネイティブコード、ネイティブ設定、ネイティブアセット、Pod、Gradle 設定、HAR／AAR／XCFramework の内容、マニフェストの変更には、新しいネイティブリリースとベースラインのアップロードが必要です。
• アプリがスレッド間で動作するネイティブ SDK（Sentry のプロファイリング、パフォーマンスサンプリングなど）を使用している場合は、switchVersion() または restartApp() の前にクリーンアップするため、beforeReload（v10.42.2 以降）を推奨してください。
• ネイティブのコールドスタート復旧には、すべての対象ネイティブバイナリで react-native-update >= 10.52.1 が必要です。統合担当者がブリック復旧の喪失を明示的に受け入れない限り、有効のままにしてください。checkStrategy: null にしてもネイティブリクエストは無効になりません。
• tvOS のサポートとパージ後の復元に関する修正には、SDK 10.58.0 以降を使用してネイティブアプリを再ビルドする必要があります。10.58.0 から 10.58.1 への RN 0.87 TypeScript 修正のみは JS のみの変更です。ソースレベルの修正の代わりに skipLibCheck を使用しないでください。
• metaInfo は unknown として解析し、実行時の形状を検証してください。references/rollout-whitelist.ts を使用してください。不正なデータはクラッシュや部分文字列の一致を起こすのではなく、ロールアウトを拒否する必要があります。クライアント側のホワイトリストは認可の仕組みではありません。
• Hermes のベースライン等価性検証は有効のままにしてください。CLI 2.28.0 はアップロードされたレポートをマスキングしますが、保持されたログには生の文字列やパスが含まれる場合があります。
• クラッシュレポーターのヘルパーには metaInfo と uuid が含まれる場合があります。アプリのプライバシーポリシーに従い、診断レポートに生のユーザー識別子や認証情報を決して公開しないでください。

提供する成果物

• 正確なファイル名とスニペットを含む、最小限の統合差分。
• 検証チェックリスト：リリースビルド、ベースラインのアップロード、更新の確認、ダウンロード、今すぐ／後で切り替え、ロールバックの動作。
• 互換性に関する記述：インストール済み SDK／ネイティブの下限バージョン、ガード付きフォールバック、新しいストア／ネイティブリリースが必要な変更。
• 10.52.1 以降の復旧に関する記述：ネイティブのコールドスタートチェック、有効化ポリシー、強制起動経路、クラッシュ復旧の制限、disableNativeCheck のトレードオフ。
• よくある失敗のトラブルシューティングのヒント。エラーのデバッグでは、OTA とソースマップの正確な識別情報も含めてください。
• 要求された場合のシナリオ例：クラスコンポーネントのルート、カスタム UI、metaInfo によるロールアウトゲート、QR／ディープリンクのテスト、ブラウンフィールド統合、カナリアロールアウト、tvOS のキャッシュパージ。
• Harmony 固有のガイダンス。ファイルごとの完全なコード例（CMakeLists.txt、PackageProvider.cpp、oh-package.json5、hvigor-config.json5、hvigorfile.ts、RNPackagesFactory.ets、Index.ets）を含めてください。

リソース

• 手順を示す前に、references/integration-playbook.mdを読んでください。
• SDK 10.58.1／CLI 2.28.0の参照スナップショットと一次情報については、references/modern-integration.mdを読んでください。
• ホワイトリストを実装する際は、テスト済みのreferences/rollout-whitelist.tsの述語をコピーしてください。
• 任意のプロジェクト診断には、Node.jsを使ってscripts/integration_doctor.mjsを実行してください。scripts/integration_doctor.shは任意のBashラッパーです。両方のパスは、このスキルディレクトリを基準に解決してください。