Senang kamu bertanya.
Saya tidak memberikan nasihat hukum. Saya berbagi apa yang praktis dan luas digunakan di tim yang mengirimkan aplikasi Capacitor dengan aman.
Perbedaan penting adalah ini:
- Penyampaian asli masih diperlukan untuk perilaku asli baru dan kemampuan utama.
- Perbarui secara langsung adalah untuk perbaikan JavaScript/web dan penyesuaian di dalam lingkungan aplikasi yang ada.
Kedua iOS dan Android dapat menggunakan model ini, tetapi Anda harus menganggapnya sebagai alur kerja yang aman dari kebijakan , bukan sebagai celah.Apa yang diizinkan oleh Apple dan Google dalam istilah sederhana
Kamu dapat menganggap Apple dan Google sebagai memiliki batas yang sama:
]}
- Anda dapat menyampaikan code yang ditafsirkan oleh layer web yang terintegrasi (HTML/CSS/JS) tanpa mengirim ulang.
- Anda tidak boleh menggunakan saluran tersebut untuk menambahkan fitur utama yang mengubah tujuan aplikasi.
- Anda tidak boleh mengubah kontrol keamanan atau distribusi yang kritikal melalui JS saja.
Pedoman resmi Apple seputar WebKit/JavaScript adalah inti dari model ini. Google biasanya kurang restriktif untuk pembaruan web-based, tetapi prinsip yang sama berlaku: simpan perubahan native dalam rilis native.
Apa yang Capgo baik untuknya
Capgo untuk:
- mengatasi bug web secara cepat
- perbaikan UI yang aman / gaya / aliran
- perbaikan logika kecil di halaman yang ada
- eksperimen cepat untuk QA internal
Capgo tidak untuk:
- menambahkan izin atau kemampuan native baru
- mengirimkan kemampuan inti baru yang harus melewati tinjauan.
- mengubah perilaku tanda tangan, enkripsi, atau identitas paket.
Strategi rilis yang direkomendasikan
Pikir dalam dua jalur:
Jalur 1: jalur native (tinjauan toko)
Gunakan proses rilis normal Capacitor Anda untuk:
- perbarui plugin baru,
- perubahan shell aplikasi atau manifest,
- perubahan izin,
- perubahan fungsi khusus platform.
Hal ini memerlukan:
bun run build
bunx cap sync
# then App Store / Google Play submission flow
Jalur 2: jalur JS (Capgo)
Untuk perubahan runtime yang aman dan kecil:
bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production
Hal ini memberikan iterasi cepat tanpa unggah ulang biner baru sementara menjaga biner itu stabil.
Bagaimana menghindari “oops, ini memerlukan rilis native”
Sebelum setiap Capgo rollout, jalankan pintu cepat ini:
- Apakah perubahan memerlukan dependensi native baru atau izin?
- Apakah perubahan mengubah kemampuan yang diiklankan aplikasi?
- Apakah perubahan mengubah batasan autentikasi/keamanan?
- Apakah kita dapat mendeskripsikan sebagai perbaikan JavaScript yang tidak memecah?
Jika jawaban ya pada (1)-(3), kirimkan rilis native. Jika ya hanya pada (4), kirimkan melalui Capgo.
Apa yang ini berarti untuk tim kepatuhan
- Anda menjaga bandwidth ulasan aplikasi untuk perubahan yang bermakna.
- Anda melestarikan kontrol rollback dan patching yang cepat.
- Anda mengurangi risiko produksi dengan menguji pembaruan di saluran sebelum peluncuran penuh.
Pendekatan ini sama seperti yang digunakan orang-orang pada program besar Capacitor di produksi: pembaruan cepat untuk perbaikan JS-only, tinjauan native hanya untuk biner nyata.
Jika Anda ingin lebih dalam, pasang strategi lingkungan ketat berdasarkan saluran sehingga QA tidak menerima kesalahan produksi. Itu adalah cara Capgo-native untuk menjaga staging, beta, dan produksi bersih.
Teruslah dari Cara mengupdate Capacitor JS apps tanpa ulang tinjau toko.
Jika Anda menggunakan Cara mengupdate Capacitor JS apps tanpa ulang tinjau toko untuk merencanakan persetujuan toko dan distribusi, hubungkannya dengan @capgo/capacitor-in-app-review untuk detail implementasi di @capgo/capacitor-in-app-review, Menggunakan @capgo/capacitor-in-app-review untuk kemampuan native di Menggunakan @capgo/capacitor-in-app-review, @capgo/capacitor-native-market untuk detail implementasi di @capgo/capacitor-native-market, Menggunakan @capgo/capacitor-native-market untuk kemampuan asli di Menggunakan @capgo/capacitor-native-market, dan Capacitor Pembaruan OTA: Panduan Persetujuan App Store untuk konteks praktis di Capacitor Pembaruan OTA: Panduan Persetujuan App Store.