モバイルアプリのアップデート
ほとんどのアップデートはpublish時に即時反映されます。アプリストアへの再申請が必要になるのは、メタデータやネイティブシェルの変更のみです。
Proyecta アプリをPWAとしてラップしてアプリストアに申請している場合、アップデートの方法は変更内容に応じて2つの段階に分かれます。
Tier 1: コンテンツと機能のアップデート(即時反映)
Section titled “Tier 1: コンテンツと機能のアップデート(即時反映)”ラップされたPWAは実際のコンテンツをあなたのPublish済みProyecta URLから読み込むため、ほとんどのアップデートは新しいアプリストアビルドを必要としません。
- Proyecta builderで変更を加える
- builderのツールバーで Publish をクリックする
- ユーザーが次回アプリを開いた際に変更が反映される
このTierに含まれる変更:
- 新しいページ、機能、レイアウト
- バグ修正
- テキストや画像の変更
- コンテンツやデータの変更
- 新しいページ、機能、および各種capabilities
- ほとんどのスタイル調整
これはPWAラッパーモデルの最大のメリットのひとつです。通常のプロダクト作業のために、レビューキューの待ち時間が発生しません。
Tier 2: ネイティブシェルのアップデート(再申請が必要)
Section titled “Tier 2: ネイティブシェルのアップデート(再申請が必要)”以下の変更はラッパーの再生成と新しいパッケージの申請が必要です。
- アイコンの下に表示されるアプリ名
- アプリアイコン自体
- スプラッシュスクリーン
- ラッパーに組み込まれるマニフェストの設定(テーマカラー、displayモード、画面の向きのロック)
- ネイティブのパーミッション宣言(
Info.plistやAndroidManifest.xmlへの新規追加が必要なカメラ、位置情報など) - ラッパーのバージョンアップ
これらの変更を行う場合:
- Publish済みURLを使って pwabuilder.com でパッケージを再生成する
- 初回に使用したのと同じ署名キーで署名する(重要 — 下記参照)
- Google Play Console、App Store Connect、またはPartner Center経由で申請する
- レビューを待つ
署名キーを失わないようにする
Section titled “署名キーを失わないようにする”Androidアプリのアップデートで最も重要なことは、すべてのアップデートを最初のバージョンと同じキーで署名しなければならないという点です。signing.keystore を紛失すると、Google Play はそれ以降のアップデートを受け付けません。別のパッケージ名で新しいアプリとして公開し直し、ユーザーを移行させる必要が生じます。
iOSの場合、プロビジョニングプロファイルと配布証明書はBundle IDに紐付いています。証明書を失効させても新しいものを作成できますが、アップデート申請時の遅延を避けるためにプロファイルはいずれにせよバックアップしておきましょう。
バージョン管理のヒント
Section titled “バージョン管理のヒント”新しいパッケージを申請する際は、アプリのユーザー向けバージョン番号をProyecta のdeployと同期させておきましょう。そうしないと、クラッシュレポートが新しいビルドのものか古いビルドのものかをユーザーが判断できなくなります。
近日公開予定
Section titled “近日公開予定”- 再生成、署名、申請をまとめて処理できる、builderのアップデートウィザード
- Proyecta のバージョン履歴と同期するバージョンマニフェストの追跡