How to update Capacitor JS apps without repeat store review

Senang Anda bertanya.

Saya tidak memberikan nasihat hukum. Saya hanya berbagi apa yang praktis dan luas digunakan oleh tim yang mengirimkan aplikasi Capacitor dengan aman.

Perbedaan penting adalah ini:

• Penyampaian asli masih diperlukan untuk perilaku asli baru dan kemampuan utama.
• Pembaruan langsung adalah untuk perbaikan JavaScript/web dan penyesuaian di dalam lingkungan aplikasi yang sudah ada.

BOTH iOS dan Android dapat menggunakan model ini, tetapi Anda harus menganggapnya sebagai proses kerja yang aman dari kebijakan, bukan celah.

Apa yang diizinkan oleh Apple dan Google dalam istilah sederhana

Anda dapat menganggap Apple dan Google sebagai batasan yang sama:

1. Anda dapat menyampaikan code yang diinterpretasikan oleh layer web yang terintegrasi (HTML/CSS/JS) tanpa mengirim ulang.
2. Anda tidak boleh menggunakan saluran tersebut untuk penambahan fitur utama yang mengubah tujuan aplikasi.
3. Anda tidak boleh mengubah kontrol keamanan atau distribusi kritis melalui JS sendiri.

Pedoman resmi Apple mengenai pembaruan WebKit/JavaScript adalah inti dari model ini. Google biasanya kurang restriktif untuk pembaruan berbasis web, tetapi prinsip yang sama berlaku: jaga perubahan asli dalam rilis asli.

Apa Capgo baik untuknya

Capgo digunakan untuk:

• Mengatasi bug web secara cepat,
• Mengembalikan UI, gaya, dan aliran yang aman,
• Mengoreksi logika kecil pada halaman yang sudah ada,
• Mengadakan eksperimen cepat untuk QA internal.

Capgo tidak digunakan untuk:

• Menambahkan izin atau kemampuan native baru,
• Mengirimkan kemampuan inti baru yang harus melalui tinjauan,
• Mengubah perilaku tanda tangan, enkripsi, atau identitas paket.

Strategi rilis yang direkomendasikan

Pikirkan dalam dua jalur:

Track 1: trek native (ulasan toko)

Use your normal Capacitor release process for:

• perbarui plugin baru,
• perubahan shell aplikasi atau manifest,
• perbarui izin,
• perubahan fungsi khusus platform.

Hal ini memerlukan:

bun run build
bunx cap sync
# then App Store / Google Play submission flow

Track 2: trek JS (Capgo)

Untuk perubahan runtime kecil dan aman:

bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production

Hal ini memberikan iterasi cepat tanpa unggah binary baru sementara menjaga binary tetap stabil.

Cara menghindari “oops, ini memerlukan rilis native”

Sebelum setiap rilis Capgo, jalankan pintu gerbang cepat ini:

1. Apakah perubahan ini memerlukan dependensi native baru atau izin?
2. Apakah perubahan ini mengubah kemampuan yang diiklankan aplikasi?
3. Apakah perubahan ini mengubah batasan autentikasi/keamanan?
4. Apakah kita bisa menggambarkannya sebagai perbaikan JavaScript yang tidak mempengaruhi?

Jika jawaban ya untuk (1)-(3), kirimkan rilis native. Jika ya hanya untuk (4), kirimkan melalui Capgo.

Apa yang ini berarti bagi tim kepatuhan

• Anda menjaga bandwidth tinjauan aplikasi untuk perubahan yang bermakna.
• Anda mempertahankan kontrol rollback dan patching cepat.
• Anda mengurangi risiko produksi dengan menguji update di saluran sebelum peluncuran penuh.

Ini adalah pendekatan yang sama orang gunakan pada program Capacitor besar di produksi: update cepat untuk perbaikan JS hanya, tinjauan native hanya untuk biner nyata.

Jika Anda ingin lebih dalam, pasangkan ini dengan strategi lingkungan ketat berdasarkan saluran sehingga QA tidak pernah menerima kesalahan produksi. Itu adalah cara Capgo-native untuk menjaga staging, beta, dan produksi bersih.