Pengujian Apple 9.100.620 pengajuan aplikasi pada tahun 2025 dan ditolak 2.093.244 di antaranya, dengan 387.087 kemudian disetujui setelah ditolak, according to Data transparansi App Store Apple. Hal ini berarti sekitar 23% ditolak awalnya, sehingga penyerahan aplikasi iOS bukanlah langkah upload formal. Ini adalah proses peluncuran yang ketat pengawasan, di mana tanda tangan, perilaku biner, metadata, kebijakan toko, dan akses reviewer semua perlu berjalan bersama.
Pengujian Apple juga mengatakan 90% pengajuan diuji dalam waktu kurang dari 24 jam di atasnya halaman Tinjauan Aplikasi. Tinjauan cepat berguna, tapi tidak membuat persetujuan otomatis. Dalam prakteknya, tim-tim yang mengirimkan dengan tenang menganggap pengiriman sebagai sistem ketahanan penolakan sistem ketahanan penolakan: they make the native shell stable, prepare a reviewer-friendly build, stage changes carefully, and keep a safe path for fixing web-layer issues without turning every urgent copy or styling bug into a new store submission.
Isi Kandungan
- Apa yang Sebenarnya Terlibat dalam Pengiriman Aplikasi iOS
- Persyaratan yang Mencegah Gagal Tanda Tangan
- Membangun dan Mengunci Aplikasi Capacitor Anda untuk Rilis
- Mengunggah Uji Coba dengan TestFlight dan Menyelesaikan Metadata Toko Aplikasi
- Mengatasi Tinjauan Aplikasi dan Menghindari Penolakan Umum
- Pemeriksaan Akhir dan Mengirimkan Perbarui Tanpa Mengirim Semua Lagi
Apa yang Sebenarnya Terlibat dalam Pengiriman Aplikasi iOS
Pertimbangkan pola kegagalan yang umum: sebuah tim menyelesaikan sebuah Capacitor aplikasi terlambat pada hari Jumat, mengarsipkannya di Xcode, mengunggahnya, dan menganggap bagian yang sulit sudah selesai. Selama tinjauan, Apple menemukan bahwa akun login gagal, endpoint backend tidak tersedia, atau fitur yang dijelaskan dalam metadata tidak dapat dijangkau. Pengembalian mungkin datang dengan cepat, tetapi perbaikan masih memerlukan sebuah build baru, unggahan lainnya, siklus tinjauan lainnya, dan rencana peluncuran yang tidak pernah memungkinkan gangguan.
Tangani pengiriman sebagai sistem ketahanan pengembalian sistem ketahanan penolakanTidak sebagai daftar checklist unggah. Jalur lengkap dimulai sebelum Xcode:
- Daftar sebagai Anggota Program Pengembang Apple dan pastikan orang yang mengelola tanda tangan dan App Store Connect memiliki akses yang tepat.
- Buat dan atur identitas aplikasiTermasuk ID Paket, kemampuan, sertifikat, dan pengaturan sertifikasi.
- dengan ID bundle yang sesuai. Buat arsip rilis yang ditandatangani
- Buat dan tandatangan arsip rilis di Xcode atau melalui alur kerja CI yang dikendalikan.
- Upload file binerSetelah itu gunakan TestFlight untuk menguji artefak yang tepat untuk distribusi.
- Selesaikan informasi metadata dan tinjauanSetelah itu kirimkan versi, dan jawab keputusan Apple.
Tiga lapisan yang dievaluasi oleh Apple
Paket memiliki tiga lapisan yang terkait.
Lapisan Lapisan biner adalah aplikasi yang dikompilasi, tanda tangan, hak istimewa, plugin native, deklarasi privasi, dan perilaku runtime. Lapisan Lapisan metadata termasuk tangkapan layar, deskripsi, kata kunci, URL, tanggapan usia, informasi privasi, dan Informasi Ulasan Aplikasi. layer kebijakan menutupi bagaimana aplikasi berperilaku, apa yang dijual, bagaimana mengelola data pengguna, dan apakah implementasi toko aplikasi mengikuti aturan Apple.
Sebuah aplikasi Capacitor menambahkan kompleksitas tertentu. JavaScript dan CSS mungkin dapat digunakan secara lintas platform, tetapi wrapper iOS masih memiliki target Xcode, dependensi native, pengaturan hak akses, pengaturan tanda tangan, dan set aset web yang diintegrasikan. Perubahan pada plugin, skema URL, kemampuan notifikasi push, atau pengaturan native dapat mengubah rilis web biasa menjadi rilis native yang harus melewati ulasan.
Prinsip praktis: Tangani setiap pengajuan sebagai artefak rilis yang dapat direproduksi, bukan sebagai folder terbaru di laptop pengembang.
Antrian tinjauan Apple juga mempengaruhi perencanaan rilis. Apple memungkinkan paling banyak Dua pengajuan sedang dinilai secara bersamaan pada sebuah platformsatu versi aplikasi dan satu item seperti Acara Dalam Aplikasi, menurutnya layer kebijakan. Batching release-critical changes into one queue position creates avoidable risk. Stage the app version first, complete App Review Information before submission, and keep native changes separate from web-layer fixes where possible.
A web-layer fix dapat seringkali dikirim melalui pembaruan hidup yang dikendalikan, asalkan tidak mengubah kemampuan asli atau melanggar aturan Apple. Perubahan asli masih masuk dalam antrian tinjauan normal. Tim dapat mendokumentasikan kepemilikan, pengecekan status, dan prosedur tanggapan dengan Manajemen Tinjauan App Store, sehingga penolakan menghasilkan pembaruan yang dikendalikan daripada pembangunan darurat.
Prasyarat yang Mencegah Gagal Tanda Tangan
Gagal tanda tangan biasanya dimulai sebagai perubahan konfigurasi. ID Paket di App Store Connect berbeda dari target Xcode, kemampuan ada di proyek tetapi tidak ada di portal Pengembang, atau mesin CI memiliki sertifikat tanpa profil pengaturan yang mengizinkannya. Mengatasi masalah ini setelah arsip gagal lebih lambat daripada memverifikasi sebelum pengembangan mencapai minggu rilis.
Establislah model akun dan kepemilikan
Pastikan bahwa akun Pengembang Apple aktif dan orang-orang yang bertanggung jawab atas rilis dapat mengakses baik portal Pengembang maupun App Store Connect. Tim sering kali memisahkan tugas, sehingga orang yang mengelola sertifikat mungkin tidak sama dengan orang yang mengirimkan metadata. Tuliskan siapa yang menguasai setiap aksi, terutama jika perusahaan, konsultan, atau pendiri startup terlibat.
Buatlah rekaman aplikasi App Store Connect sebelum mengunggah. Pilih platform yang benar, bahasa utama, nama aplikasi, ID paket, dan SKU. ID paket harus sesuai dengan identifier yang digunakan oleh target Xcode secara tepat. Catatan yang dibuat dengan identifier yang salah tidak dapat diperbaiki dengan mengubah nama file kemudian.
Verifikasi identifier dan kemampuan
Pada portal pengembang Apple, periksa ID aplikasi yang terkait dengan aplikasi. Aktifkan hanya kemampuan yang diperlukan oleh produk, seperti notifikasi push, domain terkait, masuk dengan Apple, atau penyimpanan kunci. Kemudian bandingkan pengaturan tersebut dengan tab Tanda Tangan & Kemampuan di Xcode.
Untuk Capacitor, periksa identifier di capacitor.config atau capacitor.config.ts, the iOS project target, and the app record. If you’ve changed the app ID, run the appropriate Capacitor synchronization command and inspect the native project instead of assuming the generated configuration updated every target.
Use automatic signing when the team wants Xcode to manage routine certificate and profile relationships. Manual signing can be appropriate for tightly controlled CI, multiple targets, or organizations with strict credential ownership, but it creates more objects that must remain aligned.
Lakukan penerbangan pre-flight
Sebelum mengarsipkan, pastikan:
- Akses Akun: Tim Apple yang dipilih adalah organisasi yang dimaksud, bukan tim pribadi atau tim warisan.
- Identitas Paket: Target Xcode, Capacitor konfigurasi, ID Aplikasi, dan catatan App Store Connect menggunakan identifikasi yang sama.
- Kemampuan: Entitlements sesuai dengan layanan yang diaktifkan untuk ID Aplikasi.
- Tanda Tangan Distribusi: Identitas distribusi yang dipilih valid dan tersedia untuk lingkungan pembangunan.
- Penyediaan: Profildengan sesuai dengan ID Aplikasi, sertifikat, dan metode distribusi yang benar.
- Target: Ekstensi, layanan pemberitahuan, dan target yang terkompilasi lainnya menggunakan pengaturan tanda tangan yang kompatibel.
- Rahasia: CI memiliki sertifikat dan profil yang diperlukan tanpa mengeksposnya di repository.
Sebuah build pengembangan sukses membuktikan bahwa tim Anda dapat menjalankan aplikasi. Namun, hal itu tidak membuktikan bahwa Anda dapat mendistribusikan aplikasi.
Untuk tim yang mengelola beberapa aplikasi atau lingkungan, kepemilikan sertifikat layak memiliki proses sendiri. Simpanlah catatan tentang tanggal kedaluwarsa, pemilik bertanggung jawab, langkah-langkah perpanjangan, dan di mana profil dipasang. Manajemen sertifikat Capacitor adalah referensi yang berguna untuk mengatur alur kerja tanpa bergantung pada setup lokal satu pengembang.
Membangun dan Menandatangani Aplikasi Capacitor untuk Rilis
The release archive should contain the web assets you intend to ship. In Capacitor projects, that means building the frontend first, syncing the native project, checking the iOS target, and only then creating the archive. Archiving an old www Seorang pengembang menggunakan Xcode di laptop untuk menyelesaikan penandatanganan dan pembuatan arsip aplikasi iOS.
Sebuah urutan yang dapat diandalkan seperti ini:
Membangun aplikasi web dengan konfigurasi produksi.
- Bangun aplikasi web dengan konfigurasi produksi.
- Jalankan
npx cap sync iostergantung native dependencies dan aset web sudah berada di garis lurus. - Buka workspace di Xcode, bukan file proyek yang sudah ketinggalan zaman.
- Pilih skema aplikasi yang diinginkan dan tujuan distribusi iOS yang umum.
- Konfirmasi versi pemasaran dan nomor build.
- Ulangi proses Signing & Capabilities untuk aplikasi dan setiap target ekstensi.
- Jalankan build rilis atau arsip.
Versi yang ditampilkan di App Store Connect harus sesuai dengan versi yang dikonfigurasi di target Xcode. Nomor build harus meningkat untuk setiap artefak yang diunggah yang terkait dengan versi tersebut. Simpan nilai-nilai tersebut di kontrol sumber atau generate mereka di CI, karena mengeditnya secara manual di beberapa target adalah cara yang mudah untuk mengunggah artefak yang salah.
Jika Xcode melaporkan bahwa ia tidak dapat menemukan profil pengaturan, pertama-tama konfirmasi tim dan ID Bundle. Jika ia mengatakan bahwa sertifikat tanda tangan tidak valid, inspect kunci di mesin yang melakukan arsip. Jika hak istimewa ditolak, bandingkan .entitlements file dengan kemampuan yang diaktifkan untuk ID Aplikasi. Jangan selesaikan kesalahan-kesalahan ini dengan menyalakkan opsi tanda tangan secara acak. Temukan kesalahan yang ada.
Arsip dan inspect artefak
Pilih di Xcode Produk, kemudian Arsip. Setelah itu, buka Organizer dan pilih Distribusikan Aplikasi, diikuti oleh jalur distribusi untuk TestFlight dan App Store. Xcode akan memvalidasi arsip sebelum mengunggahnya, tetapi validasi bukanlah pengganti untuk tes instalasi build yang diinstal.
Instal build yang diunggah melalui TestFlight dan lakukan alur-alur yang mungkin diperiksa oleh Apple:
- Pertama kali meluncurkan dan onboarding
- Pembuatan akun dan login
- Reset Kata Sandi atau Akses Tautan Sihir
- Pembelian dan pemulihan langganan
- Izin kamera, mikrofon, lokasi, dan notifikasi
- Tautan dalam dan autentikasi eksternal
- Kinerja offline dan pemulihan setelah permintaan gagal
- Fitur apa pun yang dijelaskan dalam tangkapan layar atau metadata
Aplikasi Capacitor dapat melewati kompilasi sementara gagal pada runtime karena URL backend produksi, jalur aset web, string izin native, atau konfigurasi plugin berbeda dari pengembangan. Uji coba pada perangkat bersih atau simulator bersih, dan uji coba dengan detail akun yang akan Anda berikan ke App Review.
Tim tanpa lingkungan rilis Mac yang dapat diandalkan dapat menggunakan infrastruktur pembangunan terkelola atau CI. Mengotomasi Capacitor pembangunan iOS dengan GitHub Aksi Bisa membantu formalisasi pembuatan arsip, penandatanganan, dan pengelolaan artefak. Bagi organisasi yang merekrut untuk mengelola proses ini secara internal, Perekrutan Pengembang iOS untuk Perusahaan Startup Memberikan konteks tentang menemukan insinyur yang dapat mengelola Swift, Xcode, tanda tangan, dan operasi rilis daripada hanya implementasi frontend saja.
Video di bawah ini berguna sebagai panduan visual untuk bagian Xcode dari alur kerja.
Before upload, inspect the archive’s identity, version, build number, included architectures, entitlements, and embedded assets. Keep the archive associated with its commit, web build, environment configuration, and release notes. When review raises a question, that traceability lets you answer precisely.
Mengunggah Pengujian Dengan TestFlight dan Menyelesaikan Metadata Toko Aplikasi
Proses rilis terkendali dimulai dengan mengunggah biner, bukan pengiriman selesai. Xcode Organizer dapat mengirimkan arsip ke App Store Connect, sementara Transporter cocok untuk tim yang lebih suka menggunakan alat pengiriman terpisah. App Store Connect memproses unggahan sebelum build muncul di TestFlight atau tersedia untuk pemilihan versi. Atasi gangguan proses dan peringatan validasi sebelum jendela rilis menjadi sangat mendesak.
Gunakan TestFlight sebagai pintu rilis
Instal build yang diproses melalui TestFlight. Launch Xcode lokal mungkin melewatkan perilaku distribusi, hak istimewa, dan perbedaan konfigurasi. Pengujian internal dapat memastikan aliran inti dengan cepat. Pengujian eksternal membantu mengungkapkan masalah yang mungkin dialami orang di luar tim App Store Connect. Tambahkan kelompok dengan tujuan yang jelas: kelompok produk dapat memvalidasi perilaku fitur, sementara kelompok rilis memeriksa pembaruan, autentikasi, izin, dan jalur yang rentan terhadap crash.
Catatan beta harus menjelaskan apa yang berubah dan di mana tester harus melihat. Gunakan bukti yang sama untuk mempersiapkan Informasi Ulasan Aplikasi. Berikan akun demo yang berfungsi ketika login diperlukan, jelaskan langkah-langkah pengaturan, dan identifikasi fitur yang tidak jelas dari layar pertama.
Selesaikan halaman produk sebagai paket
Metadata membuat janji yang harus dipenuhi oleh biner.
Siapkan nama aplikasi, judul, deskripsi, kata kunci, tangkapan layar, kategori, jawaban rating usia, detail privasi, URL dukungan, dan URL pemasaran. Uji setiap URL di luar jaringan pengembangan. Sebuah kebutuhan VPN internal, kesalahan sertifikat, atau login perangkat bersih yang rusak dapat melemahkan pengajuan yang stabil lainnya.
Tangkapan layar harus sesuai dengan interface saat ini dan fungsi yang tersedia. Hapus teks contoh, label debug, state kosong yang belum selesai, dan konten spesifik lingkungan. Untuk beberapa toko aplikasi atau bahasa, ulangi setiap versi lokal daripada mengasumsikan string yang diterjemahkan sudah cukup. Petunjuk metadata App Store untuk pengembang menawarkan daftar checklist lapangan yang praktis, tetapi lapangan yang lengkap tidak menjelaskan alur produk sendiri. Pemirsa masih perlu mencapai nilai yang ditampilkan di halaman produk.
Kirimkan pengajuan secara sengaja
Anggap pengajuan versi dan item promosi sebagai keputusan rilis yang terpisah. Kirimkan versi yang kritis rilis terlebih dahulu ketika aplikasi fix mengontrol ketersediaan. Jika sebuah Acara Dalam Aplikasi terkait dengan versi tersebut, siapkan aset dan tanggalnya bersamaan dengan rencana rilis, lalu kirimkan hanya ketika acara tersebut dapat berfungsi dengan bangun yang diperiksa. Ini mencegah item pemasaran menjadi alasan versi paket menunggu, sementara menjaga pekerjaan peluncuran terkait dapat diikuti.
Setelah App Store Connect memproses build, pilihnya untuk versi, jawab pertanyaan tentang kewajiban ekspor dan hak cipta konten, lampirkan catatan tinjauan, dan kirimkan. Catat nomor build yang dikirimkan dan snapshot metadata yang tepat. Jika Apple bertanya tentang alur, akun, atau versi backend yang ditemui oleh reviewer, catatan tersebut dapat mendukung jawaban yang tepat.
Untuk tim Capacitor, simpan perbaikan layer web terpisah dari perubahan rilis native. Kontrol live update yang terkontrol dapat menangani kecacatan JavaScript atau asset yang layak tanpa mengirimkan setiap perbaikan kecil web kembali melalui antrian native. Native code, izin, plugin, dan konfigurasi masih memerlukan jalur pembangunan dan tinjauan normal. Pembagian tersebut mengubah pengiriman menjadi sistem ketahanan terhadap penolakan: tes biner yang ditinjau secara menyeluruh, kemudian simpan pengiriman darurat untuk perubahan yang memerlukan persetujuan native.
Pengelolaan Tinjauan Aplikasi dan Menghindari Penolakan Umum
Data penolakan menunjukkan kesimpulan yang praktis: tim seharusnya menghabiskan waktu yang lebih sedikit untuk menebak preferensi reviewer yang tidak jelas dan lebih banyak waktu untuk membuktikan bahwa aplikasi sudah lengkap, berfungsi, dan dapat diakses. Analisis Apple pada tahun 2025 mencatat 1.354.418 kasus penolakan terkait kinerja, dan Apple’s Pedoman Tinjauan Aplikasi memerlukan versi akhir dengan metadata lengkap, URL fungsional, layanan backend yang aktif, akses demo jika diperlukan, dan catatan rinci untuk fitur-fitur yang tidak jelas.
Buatlah build yang dikirimkan tahan
A reviewer mungkin menemukan aplikasi tanpa konteks tim Anda. Jika layar pertama memerlukan akun, berikan kredensial yang dapat digunakan. Jika langganan disembunyikan di jalur navigasi tertentu, catatnya. Jika fitur perangkat keras memerlukan pengaturan, jelaskan langkah-langkahnya. Jika backend memiliki jendela perawatan, jadwalkan pengiriman sekitar periode ketika aliran kritis tersedia.
Masalah kinerja sangat berbahaya karena dapat muncul hanya di kondisi nyata. Uji peluncuran dingin, jaringan lambat, permintaan terganggu, akun besar, penolakan izin, dan kembali dari latar belakang. Kesalahan layer web di dalam shell Capacitor dapat terlihat seperti kerusakan aplikasi asli pada reviewer, jadi tangkap kesalahan frontend dan laporan kecelakaan native bersama-sama.
Tangani aturan toko sebagai input rilis
Perubahan Apple pada tahun 2025 mempengaruhi aplikasi toko US dan mengubah aturan yang melibatkan tombol, tautan eksternal, dan panggilan aksi untuk metode pembelian alternatif. Apple mengidentifikasi area yang terpengaruh sebagai Pedoman 3.1.1, 3.1.1(a), 3.1.3, dan 3.1.3(a) dalam pengumuman tentang perubahan pedoman tersebut. Aliran monetisasi yang melewati asumsi toko satu mungkin memerlukan penanganan yang berbeda di tempat lain.
Itu tidak berarti Anda harus menyembunyikan jalur pembelian dari review. Artinya Anda harus memetakan toko yang diharapkan, aliran pembayaran, tombol, tautan, dan teks penjelasan sebelum pengiriman. Reviewer harus melihat perilaku yang sama seperti analisis kebijakan Anda.
| Pengemudi Penolakan | Tindakan Pemulihan | Perlu Pengiriman Ulang |
|---|---|---|
| Alur aplikasi tidak lengkap | Hapus tempat penempatan, selesaikan pendaftaran, dan tes setiap fitur yang diiklankan | Biasanya, jika perilaku biner tidak lengkap |
| Masalah login atau backend tidak tersedia | Sediakan akses demo yang berfungsi dan jaga layanan produksi tetap aktif selama tinjauan | Ya, ketika gagalnya ada di dalam biner atau kontrak layanan |
| Masalah kinerja dan stabilitas | Tes peluncuran dingin, gangguan jaringan, izin, dan aliran panjang | Biasanya, terutama ketika native atau code yang diintegrasikan berubah |
| Fungsi tidak terlihat | Tambahkan catatan tinjauan aplikasi yang singkat dengan langkah navigasi yang tepat | Belum tentu, jika masalah hanya kekurangan konteks dan bangunannya sudah berfungsi |
| URL yang rusak atau metadata yang tidak lengkap | Validasi tautan privasi, dukungan, pemasaran, dan fitur dari lingkungan yang bersih | Ya, jika URL tersebut sudah diintegrasikan ke dalam aplikasi atau metadata tidak bisa diperbaiki secara independen |
| Ketidaksesuaian kebijakan pembelian dan tautan luar | Ulasan implementasi toko-toko khusus terhadap bagian-bagian pedoman saat ini | Seringkali, ketika tombol, tautan, atau perilaku pembelian asli harus berubah |
Pisahkan perbaikan asli dari perbaikan layer web
Untuk tim Capacitor, sistem ketahanan penolakan harus mengklasifikasikan perbaikan sebelum membangun ulang. Perubahan pada Swift code, plugin, hak akses, izin, konfigurasi asli, SDK yang diintegrasikan, atau perilaku dasar aplikasi harus masuk dalam antrian ulasan App Store yang biasa. JavaScript, CSS, teks, dan aset web bisa kadang-kadang disampaikan melalui mekanisme live-update yang tepat, asalkan pembaruan tetap dalam aturan Apple dan tidak mengubah aplikasi menjadi sesuatu yang berbeda secara material dari produk yang telah direview
Capgo adalah salah satu pilihan untuk menyampaikan bundle web yang ditandatangani ke saluran-saluran yang spesifik, dengan kontrol pengembalian dan pengembalian yang dipersiapkan. Hal ini bisa mengurangi resubmisi darurat untuk label yang rusak, masalah tata letak, atau pengaman layer web, sementara perubahan asli masih mengikuti jalur ulasan biasa. Ini bukanlah kerja sama untuk memenuhi kebijakan. Kulit asli aplikasi dan fungsionalitas yang dideklarasikan masih perlu lengkap dan dapat direview
Pemeriksaan Akhir dan Pengiriman Pembaruan Tanpa Mengirim Semua Lagi
A reliable release loop ends with verification, not optimism. Before submission, confirm the Versi dan nomor buildDistribusi tanda tangan, hak istimewa, instalasi TestFlight yang diproses, tes perangkat bersih, metadata, URL privasi dan dukungan, kredit reviewer, alur pembelian, dan ketersediaan backend.
Setelah disetujui, amati laporan kegagalan, kesalahan frontend, gagal login, dan tiket dukungan. Setelah ditolak, baca pesan Pusat Penyelesaian dengan hati-hati, reproduksi masalah yang tepat, dan balas dengan langkah navigasi konkrit atau kirimkan build yang diperbaiki. Jika penolakan tampaknya tidak tepat, gunakan saluran komunikasi dan saluran banding Apple daripada menebak kerja sama diam.
Alur pembaruan live dapat memperpendek jalan untuk perbaikan layer web yang layak. App Store-safe OTA updates dengan Capgo Menggambarkan model operasional: publikasikan bundle yang ditandatangani ke saluran yang dikendalikan, keluarkan ke audiens yang dipilih, amati adopsi dan gagal, dan simpan perlindungan rollback. Tahan rilis produksi yang sempit, uji perbarui melalui saluran pengujian, dan memerlukan pengiriman asli setiap kali perubahan mempengaruhi permukaan asli yang ditinjau.
Kadensi yang berkelanjutan adalah sederhana: Kirimi perubahan asli dengan sengaja, uji setiap alur yang dijanjikan, dan kirimkan perbaikan layer web yang layak melalui sistem rilis yang dikendalikan.. Itu mengubah pengiriman aplikasi iOS dari latihan api yang berulang menjadi proses rilis yang tim dapat mengoperasikan.
Capgo membantu Capacitor tim mengirimkan pembaruan JavaScript, CSS, salinan, konfigurasi, dan aset melalui saluran yang ditargetkan dengan pemantauan peluncuran dan perlindungan rollback, sementara perubahan asli terus melalui Tinjauan Aplikasi. Kunjungi Capgo untuk melihat bagaimana Anda dapat menambahkan jalur pembaruan yang tahan penolakan ke dalam alur rilis iOS Anda.
