Pelayanan Perbarui Hidup Ionic: Panduan 2026

Pemilihan pelayanan perbarui hidup Ionic sebenarnya adalah tugas perancangan rilis. Perbarui OTA dapat memperbaiki bug layer web tanpa membangun toko baru, tetapi mereka tidak dapat menggantikan rilis native. Saya menggunakan alur kerja di bawah ini untuk menentukan batas perbarui, membandingkan layanan, mengatur Capgo, dan menambahkan aturan perbarui aman.

Daftar Isi

• Langkah 4: Atur Capgo untuk pembaruan Ionic yang aman dan diferensial
• Langkah 1: Tentukan persyaratan pembaruan live untuk aplikasi Ionic Anda
• Langkah 2: Periksa konsistensi, lingkup pembaruan, dan batasan native-code
• Langkah 3: Bandingkan layanan pembaruan live Ionic yang paling kuat
• Langkah 5: Bangun peluncuran berdasarkan saluran ke dalam pipeline CI/CD Anda
• Langkah 6: Pantau rilis dan atur rollback otomatis
• FAQ
• Kesimpulan

Langkah 4: Atur Capgo untuk pembaruan Ionic yang aman dan diferensial

Capgo memberikan tim Ionic jalur yang fokus untuk pembaruan OTA yang terenkripsi. Tujuan di sini adalah untuk mengirimkan bundle layer web yang kecil dengan satu perintah, kemudian menjaga cara kembali yang jelas jika rilis tersebut tidak berfungsi.

Buka sebuah Capgo Organisasi dan gunakan uji coba gratis selama 14 hari. Capgo harga adalah langganan per organisasi, bukan pembelian satu kali atau biaya per kursi. Rencana mulai dari $12 per bulan pada harga yang dipublikasikan. Periksa detail rencana saat ini sebelum Anda menetapkan anggaran.

Instal Capgo CLI di proyek. Simpan versi CLI di pengaturan proyek Anda agar build masa depan menggunakan alat rilis yang sama. Lalu, hubungkan aplikasi ke proyek Capgo dan pilih saluran sepertidevelopmentatauproduction.

ataulatestSebelum Anda mempublikasikan, bangun layer web. Tinjau kode HTML, CSS, JavaScript, dan file aset yang dihasilkan. Hapus kunci uji dan flag debug. Pastikan bundle mengarah ke lingkungan __CAPGO_KEEP_0__ yang tepat. Perbarui dapat datang dengan cepat, jadi nilai lingkungan yang salah dapat menyebar dengan cepat juga.

API menggunakan alur kerja CodePush yang terjaga dengan enkripsi akhir-ke-akhir. Pendekatan perbarui diferensialnya dapat mengurangi data yang dikirim ketika hanya bagian dari bundle yang berubah. Hasil yang tepat tergantung pada bundle dan file yang berubah. Tatalah angka itu sebagai hasil yang mungkin, bukan janji untuk setiap rilis.

Capgo uses a maintained CodePush-style workflow with end-to-end encryption. Its differential update approach can reduce the data sent when only part of the bundle changes. The exact result depends on the bundle and the files that changed. Treat that figure as a possible outcome, not a promise for every release.

Sebelum Anda mempublikasikan, tentukan versi native yang dapat menerima bundle. Bundle web harus menyatakan rentang kompatibilitasnya. Jika bundle memanggil plugin native yang tidak dimiliki oleh biner yang lebih tua, blokir update. Ini adalah salah satu periksa keselamatan yang paling penting dalam sistem OTA apa pun.

Gunakan CLI untuk mengunggah bundle ke saluran uji. Pasang aplikasi native yang sesuai pada perangkat. Buka aplikasi, pull update, tutup aplikasi, dan buka kembali. Uji mulai dingin, koneksi jaringan yang buruk, dan perangkat yang memiliki bundle yang lebih tua yang disimpan.

Capgo mendukung rollback dan saluran, dengan dukungan sebagian untuk kontrol peluncuran berdasarkan saluran. Artinya, rencana rilis Anda harus menyatakan siapa yang dapat memindahkan bundle antara saluran. Jangan biarkan promosi dilakukan oleh klik manual terakhir oleh satu orang.

Untuk tim yang membutuhkan pandangan yang lebih luas tentang sistem update, perbandingan sistem update live untuk aplikasi seluler memberikan konteks lebih lanjut tentang muatan layer web, rollback, enkripsi, dan pilihan hosting.

Key Takeaway: Hanya publikasikan perubahan layer web yang sesuai dengan biner native yang terinstal, lalu uji bundle melalui saluran non-produksi terlebih dahulu.

Langkah 1: Tentukan kebutuhan update live untuk aplikasi Ionic Anda

Sebelum membandingkan layanan update live Ionic, tuliskan apa yang aplikasi Anda mungkin ubah di luar toko aplikasi. Daftar satu halaman ini akan menghilangkan banyak kebisingan dari demo vendor.

Mulai dengan stack aplikasi. Rekam versi Ionic, Capacitor versi, target iOS dan Android native, dan plugin native yang digunakan. Tambahkan versi aplikasi yang terinstal minimal yang dapat menerima bundle OTA. Simpanlah catatan ini di samping pipeline rilis.

Sekarang, sortir perubahan yang direncanakan menjadi dua kelompok.

• Perubahan layer web: HTML, CSS, JavaScript, gambar, dan aset lain yang dapat dimuat oleh shell native yang terinstal.
• Perubahan native: izin, hak istimewa, pembaruan native SDK, plugin native baru, dan perubahan konfigurasi native.

Kirim kelompok pertama melalui OTA hanya setelah kebijakan dan aturan toko aplikasi Anda memungkinkannya. Kirim kelompok kedua melalui build iOS atau Android normal. Perubahan kamera baru adalah perubahan native. Salah ketik label layar biasanya adalah perubahan layer web.

Selanjutnya, daftarkan orang dan perangkat yang membutuhkan setiap rilis. Anda mungkin perlu saluran uji internal, saluran pilot pelanggan, dan saluran produksi. Anda juga mungkin perlu saluran yang berbeda untuk versi native yang berbeda. Semakin banyak versi yang Anda dukung, semakin penting peta yang Anda buat.

Tulis aturan peluncuran dalam bahasa yang sederhana. Misalnya: “Bundle menghabiskan satu hari di uji coba internal. Manajer rilis memindahkannya ke pilot setelah tes asap melewati. Promosi produksi memerlukan peninjau kedua.” Aturan seperti ini lebih berguna daripada tujuan yang kabur seperti “rilis dengan aman.”

Pastikan sinyal gagal Anda sebelum Anda mengirim. Pilih event yang harus menghentikan proses rollout. Mungkin termasuk peningkatan gagal start, crash terkait bundle baru, jalur login yang rusak, atau laporan bahwa aplikasi menampilkan layar kosong.

Koveran analitik tidak merata di pasar ini. Hanya tiga dari layanan yang dibandingkan di sini yang menyebutkan analitik. Capgo menampilkan log perangkat, sementara OtaKit menampilkan analitik dan Microsoft CodePush menampilkan analitik dan diagnostik untuk periode tertentu. Jika layanan Anda tidak menampilkan signal yang Anda butuhkan, rencanakan jalur monitoring eksternal.

Putuskan juga berapa cepat update buruk harus meninggalkan perangkat. Perbaikan salinan yang tidak berbahaya dapat menunggu tinjauan manual. Layar checkout yang rusak mungkin memerlukan rollback otomatis. Jangan pilih aturan rollback yang tim Anda tidak akan memiliki waktu untuk menguji.

Capgo cocok untuk tim yang ingin memiliki jalur CodePush yang dipelihara dengan enkripsi, saluran, rollback, dan hook CI/CD. Layanan ini juga mendukung GitHub Actions, Jenkins, dan GitLab CI. Saya masih akan menguji jalur penuh di aplikasi kecil sebelum memindahkan aplikasi produksi yang berisiko tinggi.

Tes tersebut harus menjawab empat pertanyaan:

• Apakah seorang pengembang dapat menerbitkan bundle dari CI?
• Apakah seorang reviewer dapat melihat versi native mana yang akan menerima bundle tersebut?
• Apakah tim dapat menghentikan atau membalikkan proses rollout?
• Apakah tim dukungan dapat mengidentifikasi bundle pada perangkat yang terkena?

Jika jawaban salah satu pertanyaan tidak jelas, maka persyaratan belum selesai. Perbaiki proses sebelum Anda membandingkan halaman rencana.

Langkah 2: Periksa konsistensi, lingkup update, dan batasan native-code

Jasa pembaruan hidup Ionic yang paling sesuai tidak dapat membuat perubahan native melalui JavaScript. Langkah ini menarik garis keras antara pekerjaan OTA dan rilis toko.

Mulai dengan matrix kompatibilitas. Masukkan versi aplikasi native di kolom pertama. Masukkan saluran di atas. Di setiap sel, tandai versi bundle web yang aman untuk binary tersebut. Langkah ini mungkin terlihat sederhana, tetapi menghentikan aplikasi lama dari menerima code yang mengharapkan jembatan native baru.

Untuk setiap pembaruan yang direncanakan, tanyakan apa yang dipanggil code. Perubahan yang menambahkan plugin Capacitor baru memerlukan plugin di dalam binary yang terpasang. Perubahan yang hanya menyesuaikan template halaman mungkin sesuai dengan shell saat ini. Jika Anda tidak yakin, kirimkan build native terlebih dahulu.

Ulas aturan toko aplikasi yang berlaku untuk rilis Anda. Pengiriman OTA dimaksudkan untuk layer web. Tidak boleh menjadi jalan rahasia untuk perubahan yang mengubah tujuan utama aplikasi atau menghindari tinjauan yang diperlukan. Tim hukum dan rilis Anda harus mengelola kebijakan tersebut.

Pakai perubahan kecil untuk tes kering pertama. Ubah satu label yang terlihat atau tambahkan marker debug yang tidak berbahaya. Publikasikan ke saluran pengembangan. Pasang aplikasi dari build native yang sama yang akan menerima pembaruan. Lalu verifikasi pembaruan di kedua platform.

Pakai kontrol saluran jasa untuk menentukan rilis binary mana yang menerima pembaruan hidup, dan definisikan kapan aplikasi menerapkan pembaruan setelah di background.

Jadwalnya sangat penting. Pengguna mungkin tidak melihat bundle OTA sekaligus. Aplikasi mungkin menunggu hingga peluncuran berikutnya, setelah periode latar belakang, atau setelah metode sinkronisasi lainnya berjalan. Dokumentasikan aturan ini agar staf dukungan tidak menjanjikan perilaku instan ketika aplikasi menggunakan strategi tertunda.

Tetapkan fallback di dalam aplikasi. Jika update tidak dapat diunduh, bundle saat ini harus masih dimuat. Jika bundle baru gagal melakukan pengecekan, aplikasi harus mempertahankan versi yang diketahui baik. Uji fallback saat perangkat dalam keadaan offline. Rencana rollback yang hanya berfungsi pada jaringan Wi-Fi cepat bukanlah rencana rollback.

Periksa ukuran bundle sebelum rilis. Update diferensial membantu ketika hanya bagian kecil dari layer web berubah, tetapi penggantian aset besar masih dapat menghasilkan download besar. Kompres aset di mana saja yang sesuai. Hindari mengirimkan file yang tidak digunakan. Biarkan peta dan file uji keluar dari bundle produksi kecuali Anda membutuhkannya.

Pengecekan keamanan juga termasuk di sini. Pastikan bagaimana layanan menandatangani atau mengenkripsi bundle. Periksa di mana kunci hidup. Batasi siapa yang dapat menerbitkan ke produksi. Capgo’s enkripsi akhir-ke-akhir dan aliran CodePush-style membuatnya cocok untuk tim yang ingin mengontrol jalur OTA, tetapi kebijakan kunci Anda masih penting.

Gunakan tes kompatibilitas untuk menolak kasus-kasus berikut:

• Bundle memanggil metode native yang hilang dari biner.
• Bundle mengharapkan bentuk data yang lebih baru daripada aplikasi yang dapat membacanya.
• Bundle mengubah izin atau hak.
• Aplikasi tidak dapat pulih jika download berhenti setengah jalan.

Kasus-kasus tersebut lebih tepat dimasukkan ke dalam rilis native atau migrasi yang telah dipersiapkan. Jangan memaksa mereka ke dalam OTA karena antrian toko terasa lambat.

Tips Pro: Tetapkan satu binary produksi lama di perangkat uji. Setiap bundle web baru harus melewati perangkat tersebut sebelum peluncuran yang lebih luas.

Langkah 3: Bandingkan layanan pembaruan hidup Ionic terbaik

Saat Anda membandingkan layanan pembaruan hidup Ionic, jadikan jalur rilis sebagai kriteria daripada jumlah fitur. Saya akan memeriksa enkripsi, kompatibilitas bundle, pengendalian saluran, pengembalian, akses CI/CD, analitik, dan status jangka panjang layanan.

Capgo adalah layanan pertama yang saya akan tes untuk aplikasi Capacitor yang memerlukan pengiriman OTA yang terenkripsi tanpa biaya tahunan platform yang besar. Data rencana yang disediakan mulai dari $12 per bulan per organisasi. Layanan ini juga terhubung dengan GitHub Actions, Jenkins, dan GitLab CI, yang membantu tim untuk terus menerus menerbitkan di dalam pipeline yang sudah digunakan.

OtaKit dan Capawesome Cloud memerlukan tinjauan teknis langsung ketika perlu peluncuran yang bertahap atau perlahan. Penelitian tersebut secara khusus menyoroti kontrol-kontrol tersebut untuk kedua layanan. Hal tersebut tidak menghilangkan kebutuhan untuk menguji cek versi asli atau perilaku rollback di aplikasi Anda sendiri.

Ionic Appflow memiliki bentuk yang berbeda. Layanan ini menggabungkan update hidup ke dalam platform berbayar yang lebih luas dengan fitur pembangunan asli dan CI/CD. Hal tersebut dapat membuat sense ketika satu vendor menguasai sebagian besar sistem rilis. Namun, hal tersebut tidak cocok untuk evaluasi baru jika status ketersediaan atau status layanan jangka panjang tidak pasti.

CodePush Standalone adalah kasus khusus. Layanan ini mempertahankan protokol asli, namun repositori yang diarsipkan mengalihkan pekerjaan keamanan ke tim Anda. Anda harus mengelola patch, hosting, pengawasan akses, dan tanggapan insiden. Protokol yang familiar tidak menghilangkan kewajiban-kewajiban tersebut.

Pengeluaran juga sulit dibandingkan. Survei yang disediakan mengatakan 57% layanan mengungkapkan pengeluaran. Di antara entri-entri tersebut, median adalah $14 per bulan, sementara rentang mencapai tagihan tahunan $5.000 untuk Appflow. Harga sendiri tidak memberitahu Anda banyak tentang kontrol bundle atau risiko operasional.

Untuk melihat jalur migrasi yang lebih luas, Alternatif CodePush untuk Capacitor dan Ionic Langkah 5: Bangun roll-out berbasis saluran ke dalam pipeline CI/CD Anda

Layanan pembaruan hidup Ionic yang baik harus sesuai dengan jalur CI/CD yang sama dengan aplikasi Anda. Tujuan sederhana: bangun sekali, verifikasi bundle, publikasikan ke saluran, lalu promosikan dengan aksi yang direkam.

Mulai dengan membagi pipeline menjadi tahap.

Bangun:

1. instal dependensi yang terkunci dan generate bundle web. Tunggu:
2. jalankan tes, atur aturan lint, periksa keamanan, dan pengaman kompatibilitas native. Publikasikan:
3. Publish: unggah bundle ke saluran pengembangan atau pratinjau.
4. Promote: pindahkan bundle yang telah disetujui ke pilot atau produksi.

Jangan biarkan pekerjaan produksi membangun code lagi. Bangun ulang kedua mungkin menarik ketergantungan yang berubah atau nilai lingkungan yang berbeda. Promosikan artefak yang telah diuji alih-alih. Ini menjaga bundle yang dalam tinjauan sama seperti bundle yang digunakan pengguna.

Simpan Capgo API token di penyimpanan rahasia CI Anda. Berikan token akses yang paling sempit yang mendukung pekerjaan. Tidak pernah tempatkan token di bundle aplikasi atau komitkannya ke repository. Rotasikan token ketika anggota tim meninggalkan atau sistem bangun ulang berubah tangan.

Capgo mendukung hook CI/CD untuk GitHub Actions, Jenkins, dan GitLab CI. Ini memberikan beberapa jalur untuk pengembangan satu perintah. Perintah harus gagal ketika bundle menargetkan versi native yang tidak kompatibel atau ketika saluran yang diperlukan tidak ada.

Buat promosi saluran memerlukan tinjauan eksplisit. Permintaan pull dapat menampung code tinjauan. Persetujuan rilis dapat menampung promosi produksi. Simpan kedua catatan. Nanti, dukungan dapat menjawab siapa yang menyetujui bundle dan versi native mana yang ditarget.

Gunakan saluran yang terpisah untuk tingkat risiko yang berbeda. Konfigurasi umum seperti ini:

• devuntuk pekerjaan pengembangan aktif.
• pilotuntuk kelompok kecil pengguna internal atau undangan.
• productionuntuk aplikasi publik.

Untuk aplikasi dengan beberapa versi native, tambahkan saluran yang spesifik versi atau ketatkan jangkauan kompatibilitas. Pilihan yang tepat tergantung berapa lama biner lama tetap aktif. Jangan membuat satu saluran membawa aturan rilis yang tidak kompatibel.

Tambahkan jeda antara langkah promosi. Bahkan jendela pengamatan singkat dapat menangkap jalur path asset yang rusak atau kesalahan API sebelum bundle mencapai setiap perangkat. Jika layanan Anda mendukung rollout bertahap, gunakanlah. Jika tidak, buatlah saluran pilot sebagai pintu darurat.

Pastikan output pipa tetap berguna. Cetak versi bundle, hash komit, saluran target, rentang kompatibilitas native, dan tautan persetujuan. Log yang hanya mengatakan “deploy berhasil” tidak akan membantu selama insiden.

Terakhir, latih perilaku rilis gagal. Publikasikan bundle uji yang tidak berbahaya. Tandai sebagai gagal. Pastikan pipa berhenti promosi dan aksi rollback Anda mengembalikan bundle sebelumnya. Satu perintah harus mempublikasikan. Satu aksi yang jelas harus menghentikannya.

Tim yang ingin mendapatkan detail lebih lanjut tentang pilihan OTA juga dapat memeriksa hal ini Capacitor Panduan pilihan OTA sambil mengatur pipa mereka sendiri.

Langkah 6: Pantau rilis dan atur rollback otomatis

Pantauan berubah layanan update OTA Ionic menjadi proses operasional. Anda perlu tahu mana bundle yang dimiliki perangkat, apakah aplikasi menerima, dan apa yang terjadi setelah perubahan.

Mulai dengan adopsi bundle. Pantau bagian dari perangkat aktif pada setiap versi bundle. Kurva adopsi lambat mungkin menunjukkan pengaturan sinkronisasi latar belakang, koneksi yang buruk, atau aturan kompatibilitas yang mengesampingkan banyak perangkat.

Kemudian, track kegagalan update. Pisahkan kegagalan download dari kegagalan instalasi. Masalah download mungkin memerlukan perbaikan jaringan atau CDN. Masalah instalasi mungkin menunjukkan bundle yang rusak, tanda tangan yang tidak valid, atau kesalahan startup aplikasi.

Amati layar pertama setelah update. Layar kosong dapat menghentikan pengguna sebelum tracking acara normal Anda dimulai. Tambahkan acara startup yang mencakup versi bundle, versi aplikasi native, dan saluran. Hindari mengirimkan data pengguna pribadi dalam log-log tersebut.

Capgo mencakup analitik log perangkat. Gunakan log-log tersebut untuk menghubungkan laporan ke bundle. Jika aplikasi Anda memiliki alat crash yang terpisah, gabungkan rekaman dengan ID rilis daripada bergantung pada nama yang dapat dibaca manusia.

Setel aturan rollback sebelum produksi. Misalnya, Anda mungkin menghentikan promosi setelah tingkat kegagalan startup melebihi ambang batas yang disepakati tim Anda. Ambang batas itu sendiri harus berasal dari basis data aplikasi normal, bukan dari angka yang dicopy dari produk lain.

Rollback otomatis memerlukan target yang aman. Simpan bundle yang terakhir diketahui baik tersedia. Tandai sebagai disetujui. Pastikan bundle rollback mendukung setiap versi native yang masih ada di saluran yang terkena.

Uji rollback dalam tiga keadaan:

• Perangkat yang telah mengunduh tetapi belum menginstal bundle yang buruk.
• Perangkat yang telah menginstal bundle yang buruk dan telah di-restart.
• Perangkat yang kehilangan koneksi jaringan selama rollback.

Aplikasi harus tetap dapat digunakan dalam setiap kasus. Jika tidak, maka shell native memerlukan jalur pemulihan yang lebih kuat.

Gunakan kontrol kanal untuk membatasi ukuran ledakan. Mulai dengan perangkat internal. Pindah ke kelompok pilot. Amati rilis. Kemudian promosikan. Ini adalah tempat Capgo’s kanal dan alur kerja rollback dapat mengurangi jumlah pengguna yang terkena perubahan layer web yang buruk.

Jaga manusia dalam loop untuk rilis yang berisiko tinggi. Rollback otomatis berguna, tetapi jumlah kejadian rendah dapat menyembunyikan masalah. Masalah checkout yang mempengaruhi kelompok kecil mungkin tidak melebihi ambang batas global. Gabungkan metrik dengan laporan dukungan dan pengecekan produk.

Ulas setiap rollback setelah insiden. Rekam bundle gagal, versi native, kanal, trigger, dan waktu pemulihan. Kemudian tambahkan tes yang akan menangkap masalah lebih awal. Tujuan adalah rilis yang lebih tenang kali ini, bukan laporan insiden yang lebih cantik.

Kunci Pemahaman: Ikuti bundle yang dijalankan perangkat, amati kesehatan startup setelah promosi, dan siapkan bundle yang teruji dan baik.

FAQ

Konteks: Halaman/area: Capgo Builder / produk halaman build native cloud. Peran: Judul atau tagline bagian. Dilihat di: halaman native-build.astro. Pesan kunci `native_build_builder_faq_eyebrow` (FAQ Pembangun Native Build). | Halaman/area: Halaman pemasaran solusi Capgo. Peran: Judul atau bagian halaman. Dilihat di: halaman solutions/cordova-to-capacitor.astro. Pesan kunci `solutions_cordova_to_capacitor_faq_title` (Judul FAQ Solusi Cordova To Capacitor).

An Ionic live update service delivers approved web-layer changes to an installed app without a new store submission. It can update HTML, CSS, JavaScript, and assets. It can’t safely replace native code, permissions, or native plugins. The right service also needs compatibility checks, channel control, security, and a way to reverse a bad bundle.

Layanan pembaruan hidup Ionic mengirimkan perubahan layer web yang disetujui ke aplikasi yang terpasang tanpa pengajuan toko baru. Layanan ini dapat memperbarui HTML, CSS, JavaScript, dan aset. Namun, layanan ini tidak dapat menggantikan native __CAPGO_KEEP_0__, izin, atau plugin native dengan aman. Layanan yang tepat juga memerlukan pengecekan kompatibilitas, kontrol kanal, keamanan, dan cara untuk membalikkan bundle yang buruk.

Ya, aplikasi Ionic dapat menerima pembaruan lapisan web yang layak tanpa rilis aplikasi baru di App Store atau Google Play. Perubahan native masih memerlukan proses pembangunan aplikasi normal dan toko. Simpan perubahan OTA dalam kebijakan rilis Anda, uji mereka terhadap shell native yang terpasang, dan hindari menggunakan pembaruan hidup untuk menyembunyikan perubahan yang memerlukan tinjauan platform.

Apakah Capgo kompatibel dengan Capacitor?

Ya, Capgo dibangun untuk aplikasi Ionic dan Capacitor yang memerlukan pengiriman OTA. Alurnya mengikuti model CodePush dan mendukung saluran, rollback, enkripsi akhir-ke-akhir, bundle diferensial, dan koneksi CI/CD. Uji kinerja kompatibilitas native dalam saluran pengujian sebelum mengirim bundle ke pengguna produksi.

Berapa biaya layanan pembaruan hidup Ionic?

Harga berbeda-beda antara layanan. Capgo mulai dari $12 per bulan sebagai langganan per organisasi, dengan uji coba gratis selama 14 hari. Biaya Appflow sebesar $5.000 per tahun adalah harga tertinggi yang dipublikasikan di antara layanan ini. Bandingkan alurnya penuh, bukan hanya angka bulanan.

Apakah pembaruan OTA dapat mengubah native code?

Tidak, pembaruan OTA tidak boleh mengubah native code. Mereka dimaksudkan untuk lapisan web yang dapat dijalankan oleh shell native yang terpasang. Plugin baru, izin, hak istimewa, dan perubahan native SDK memerlukan pembangunan toko. Tambahkan pengecekan versi native agar bundle yang tidak kompatibel ditolak sebelum startup.

Kesimpulan

Untuk tim Capacitor atau Ionic yang membutuhkan pengiriman OTA yang terenkripsi dengan kontrol saluran dan rollback, saya akan memulai dengan menguji Capgo di aplikasi pengujian. Buatlah saluran pengembangan, publikasikan satu bundle kecil, dan jalankan latihan rollback sebelum produksi. Lihat detail alternatif Appflow, kemudian mulai uji coba 14 hari gratis jika alur kerja sesuai dengan kebutuhan rilis Anda.