Diulas oleh Apple 9.100.620 pengiriman 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. Ini berarti sekitar 23% ditolak awalnyaJadi, pengajuan aplikasi iOS bukanlah langkah unggah seremonial. Ini adalah proses rilis yang memerlukan perhatian tinggi, di mana tanda tangan, perilaku biner, metadata, kebijakan toko, dan akses reviewer semua harus berjalan dengan baik.
Apple juga mengatakan 90% pengajuan diperiksa dalam waktu kurang dari 24 jam di halaman Pengujian AplikasiPengujian cepat berguna, tetapi tidak membuat persetujuan otomatis. Dalam prakteknya, tim-tim yang mengirimkan aplikasi dengan tenang menganggap pengajuan sebagai sistem ketahanan penolakanUji coba yang cepat berguna, tapi tidak membuat persetujuan otomatis. Dalam prakteknya, tim yang mengirimkan aplikasi dengan tenang menganggap pengajuan sebagai
sistem ketahanan penolakan
- Apa yang Sebenarnya Terlibat dalam Pengiriman Aplikasi iOS
- Persyaratan yang Mencegah Gagal Tanda Tangan
- Membangun dan Menandatangani Aplikasi Capacitor Anda untuk Rilis
- Mengunggah Uji Coba dengan TestFlight dan Menyelesaikan Metadata Toko Aplikasi
- Pengelolaan Ulasan Aplikasi dan Menghindari Penolakan Umum
- Periksa dan Kirimkan Update Terakhir Tanpa Mengirim Semua Lagi
Apa yang Sebenarnya Terlibat dalam Pengajuan Aplikasi iOS
Pertimbangkan pola gagal yang umum: tim menyelesaikan aplikasi Capacitor terlambat pada hari Jumat, mengarsipkannya di Xcode, mengunggah build, 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 build baru, unggahan lagi, siklus tinjauan lagi, dan rencana rilis yang tidak pernah memungkinkan gangguan.
Tangani pengajuan sebagai sistem ketahanan pengembalian sistem ketahanan penolakanBukan 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.
- Jadikan build yang telah disampaikan tahan lamatermasuk ID Paket, kemampuan, sertifikat, dan pengaturan sertifikasi.
- Buat catatan App Store Connect dengan ID paket yang sesuai.
- Buat dan tandatangani arsip rilis di Xcode atau melalui alur kerja CI yang dikendalikan.
- Unggah binerlalu gunakan TestFlight untuk menguji artefak yang tepat untuk distribusi.
- Selesaikan metadata dan informasi tinjauanlalu kirimkan versi, dan jawab keputusan Apple.
Tiga lapisan yang dievaluasi Apple
Paket memiliki tiga lapisan yang terkait.
Indonesia layer biner adalah aplikasi yang telah dikompilasi, tanda tangan, hak istimewa, plugin-plugin native, deklarasi privasi, dan perilaku waktu eksekusi. Layer layer metadata Informasi yang termasuk adalah tangkapan layar, deskripsi, kata kunci, URL, jawaban pengaturan usia, informasi privasi, dan informasi tinjauan aplikasi. layer kebijakan Mengulas bagaimana aplikasi berperilaku, apa yang dijual, bagaimana mengelola data pengguna, dan apakah implementasi toko aplikasi mengikuti aturan Apple.
A Capacitor application adds a specific complication. JavaScript and CSS may be cross-platform, but the iOS wrapper still has an Xcode target, native dependencies, entitlements, signing settings, and an embedded web asset set. A change to a plugin, URL scheme, push notification capability, or native configuration can turn a routine web release into a native release that must pass review.
Aturan praktis: Tentukan setiap pengiriman sebagai artefak rilis yang dapat direproduksi, bukan sebagai folder terbaru di laptop pengembang.
Antrikueri Apple juga mempengaruhi perencanaan rilis. Apple memungkinkan paling banyak Dua pengajuan sedang dalam tinjauan pada saat yang sama di platform.Versi aplikasi dan satu item seperti Acara Dalam Aplikasi, menurut pedoman pengajuan Panduan pengajuan. Mengumpulkan perubahan kritis ke dalam satu posisi antrian dapat menghasilkan risiko yang tidak perlu. Terlebih dahulu siapkan versi aplikasi, lengkapi Informasi Ulasan Aplikasi sebelum pengajuan, dan pisahkan perubahan asli dengan perbaikan layer web di mana mungkin.
Perbaikan layer web seringkali dapat dikirim melalui pembaruan hidup yang dikendalikan, selama tidak mengubah kemampuan asli atau melanggar aturan Apple. Perubahan asli masih masuk dalam antrian ulasan normal. Tim dapat mendokumentasikan kepemilikan, pengecekan status, dan prosedur tanggapan dengan Pengelolaan Ulasan App Store, sehingga penolakan menghasilkan perbaikan 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 dengan target Xcode, kemampuan ada di proyek tetapi tidak ada di portal pengembang, atau mesin CI memiliki sertifikat tanpa profil pengaturan yang mengotorisasi. Mengatasi masalah ini setelah arsip gagal lebih lambat daripada memverifikasi sebelum pengembangan mencapai minggu rilis.
Establislah akun dan model 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 bukan orang yang mengirimkan metadata. Catat siapa yang memiliki setiap aksi, terutama jika ada agensi, kontraktor, atau pendiri startup yang terlibat.
Buatlah Catatan aplikasi App Store Connect sebelum mengunggah. Pilih platform yang tepat, 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 identifikasi dan kemampuan
Di portal pengembang Apple, periksa ID aplikasi yang terkait dengan aplikasi. Aktifkan hanya kemampuan yang diperlukan oleh produk, seperti notifikasi push, domain terkait, Sign in 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.
Gunakan tanda tangan otomatis ketika tim ingin Xcode mengelola hubungan sertifikat dan profil rutin. Tanda tangan manual dapat sesuai untuk CI yang sangat terkendali, target yang banyak, atau organisasi dengan kepemilikan kredensial ketat, tetapi menciptakan objek yang lebih banyak yang harus tetap seimbang.
Jalankan pre-flight rilis
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: Hak akses yang ditentukan cocok dengan layanan yang diaktifkan untuk ID Aplikasi.
- Tanda tangan distribusi: Tanda tangan distribusi yang dipilih valid dan tersedia untuk lingkungan pembangunan.
- Pengaturan: Profil ini sesuai dengan ID Aplikasi yang benar, sertifikat, dan metode distribusi.
- Target: Ekstensi, layanan pemberitahuan, dan target yang dibundel lainnya menggunakan pengaturan tanda tangan yang kompatibel.
- Rahasia: CI memiliki sertifikat dan profil yang diperlukan tanpa mengungkapkannya di repository.
Pembangunan aplikasi yang sukses membuktikan bahwa tim Anda dapat menjalankan aplikasi. Namun, hal ini 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 yang bertanggung jawab, langkah-langkah perpanjangan, dan di mana profil dipasang. Capacitor sertifikat manajemen adalah referensi yang berguna untuk mengatur alur kerja tanpa bergantung pada setup lokal satu pengembang.
Membangun dan Mengunci Aplikasi Capacitor Anda 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 Direktori dapat menghasilkan aplikasi yang ditandatangani dengan benar tetapi memiliki layar yang ketinggalan zaman, perbaikan yang hilang, atau konfigurasi yang tidak sesuai.
Siapkan proyek sebelum Xcode
Sebuah urutan yang dapat diandalkan seperti ini:
- Bangun aplikasi web dengan konfigurasi produksi.
- Jalankan
npx cap sync iosDependensi native dan aset web sudah berada dalam satu garis. - Jadi, dependensi native dan aset web akan sejalan.
- Buka workspace di Xcode, bukan file proyek yang sudah ketinggalan.
- Konfirmasikan versi pemasaran dan nomor build.
- Periksa Tanda Tangan & Kemampuan untuk Aplikasi dan setiap target ekstensi.
- Buat rilis atau arsip.
The version shown in App Store Connect must correspond to the version configured in the Xcode target. The build number must increase for each uploaded artifact associated with that version. Keep those values in source control or generate them in CI, because manually editing them across several targets is an easy way to upload the wrong artifact.
Jika Xcode melaporkan bahwa ia tidak dapat menemukan profil pengaturan, pertama-tama konfirmasikan tim dan ID Paket. Jika ia mengatakan sertifikat tanda tangan tidak valid, inspeksi kunci rantai pada mesin yang melakukan arsip. Jika hak istimewa ditolak, bandingkan file dengan kemampuan yang diaktifkan untuk ID Aplikasi. .entitlements File dengan kemampuan diaktifkan untuk ID Aplikasi. Jangan mengatasi kesalahan ini dengan menyalak secara acak opsi tanda tangan. Cari kesalahan yang tidak sesuai.
Arsip dan inspeksi artefak
Pilih di Xcode ProdukSetelah itu Arsip. Setelah proses, buka Organizer dan pilih Distribusi Aplikasi, diikuti oleh jalur distribusi untuk TestFlight dan App Store. Xcode akan memvalidasi arsip sebelum unggah, tetapi validasi bukanlah pengganti untuk menguji instalasi build.
Pasang build yang diunggah melalui TestFlight dan lakukan aliran-aliran yang Apple mungkin akan memeriksa:
- Pertama kali meluncurkan dan onboarding
- Pembuatan dan login akun
- Pengaturan ulang kata sandi atau akses tautan ajaib
- Pembelian dan pemulihan langganan
- Izin kamera, mikrofon, lokasi, dan notifikasi
- Tautan dalam dan autentikasi eksternal
- Behavior offline dan pemulihan setelah permintaan gagal
- Fitur apa pun yang dijelaskan dalam screenshot atau metadata
Aplikasi Capacitor dapat melewati proses kompilasi sementara gagal pada runtime karena URL backend produksi, jalur aset web, string izin native, atau konfigurasi plugin berbeda dari pengembangan. Uji pada perangkat bersih atau simulator bersih, dan uji dengan detail akun yang sama yang akan Anda berikan ke App Review.
Tim tanpa lingkungan rilis Mac yang dapat diandalkan dapat menggunakan infrastruktur pembangunan terkelola atau CI. Mengotomasi Capacitor iOS build dengan GitHub Actions Bisa membantu formalisasi pembuatan arsip, penandatanganan, dan pengelolaan artefak. Bagi organisasi yang merekrut untuk mengelola proses ini secara internal, Perekrutan pengembang iOS untuk startup memberikan konteks tentang menemukan insinyur yang dapat mengelola Swift, Xcode, tanda tangan, dan operasi rilis daripada hanya implementasi frontend.
Video di bawah ini berguna sebagai walkthrough visual dari bagian Xcode dari alur kerja.
Sebelum mengunggah, periksa identitas, versi, nomor build, arsitektur yang termasuk, hak istimewa, dan aset yang diintegrasikan dari arsip. Tahan arsip yang terkait dengan komitmen, build web, konfigurasi lingkungan, dan catatan rilis. Ketika tinjauan menimbulkan pertanyaan, itu dapat memberi Anda jawaban yang tepat.
Upload, Pengujian dengan TestFlight, dan Menyelesaikan Metadata App Store
Proses upload memulai proses rilis yang dikendalikan, bukan pengiriman selesai. Xcode Organizer dapat mengirimkan arsip ke App Store Connect, sementara Transporter cocok untuk tim yang lebih suka 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
Instalasikan build yang diproses melalui TestFlight. Pengeluaran Xcode lokal mungkin melewatkan perilaku distribusi, hak istimewa, dan perbedaan konfigurasi. Tester internal dapat memastikan aliran inti dengan cepat. Tester eksternal membantu mengungkapkan masalah yang mungkin dialami orang di luar tim App Store Connect. Tetapkan kelompok dengan tujuan: 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 mencari. 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, subtitle jika diperlukan, deskripsi, kata kunci, screenshot, kategori, respons rating usia, detail privasi, URL dukungan, dan URL pemasaran. Uji setiap URL di luar jaringan pengembangan. Persyaratan VPN internal, kesalahan sertifikat, atau login perangkat bersih yang rusak dapat melemahkan pengajuan yang stabil lainnya.
Screenshot harus sesuai dengan interface saat ini dan fungsi yang tersedia. Hapus teks copy tempat, label debug, status kosong yang belum selesai, dan konten spesifik lingkungan. Untuk berbagai toko atau bahasa, ulangi setiap versi lokal daripada asumsikan string yang diterjemahkan cukup. Pedoman metadata App Store untuk pengembang menawarkan daftar checklist lapangan yang praktis, tetapi bidang-bidang yang lengkap tidak menjelaskan aliran produk sendiri. Peninjau masih perlu mencapai nilai yang ditampilkan pada halaman produk.
Mengirimkan Submisi Secara Sengaja
Tangani versi pengiriman dan item promosi sebagai keputusan rilis terpisah. Kirimkan versi yang kritis rilis terlebih dahulu ketika kontrol perbaikan aplikasi tersedia. Jika acara In-App terkait dengan versi tersebut, siapkan aset dan tanggalnya bersamaan dengan rencana rilis, lalu kirimkan hanya ketika acara dapat berfungsi dengan bangunan yang diperiksa. Hal ini mencegah item pemasaran menjadi alasan versi paket menunggu, sementara menjaga pekerjaan peluncuran terkait dapat dilacak.
Setelah App Store Connect memproses bangunan, pilihnya untuk versi, jawab pertanyaan tentang keterbatasan ekspor dan hak cipta konten, lampirkan catatan tinjauan, dan kirimkan. Rekam nomor bangunan yang dikirim dan snapshot metadata yang tepat. Jika Apple bertanya tentang aliran mana, akun, atau versi backend yang ditemui oleh peninjau, catatan tersebut mendukung jawaban yang tepat.
Untuk Capacitor tim, jaga perbaikan layer web terpisah dari perubahan rilis native. Sebuah live update yang terkendali dapat menangani kecacatan JavaScript atau asset yang layak tanpa mengirim setiap perbaikan kecil web kembali melalui antrian native. Native code, izin, plugin, dan konfigurasi masih memerlukan jalur pembangunan dan tinjauan normal. Pembagian itu mengubah pengiriman menjadi sistem ketahanan penolakan: tes biner yang ditinjau secara menyeluruh, kemudian simpan pengiriman darurat untuk perubahan yang memerlukan persetujuan native.
Pengelolaan Ulasan Aplikasi dan Menghindari Penolakan Umum
Data penolakan menunjukkan kesimpulan 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 kinerjadan Pedoman Ulasan Aplikasi Apple Pedoman Uji Coba Aplikasi Versi akhir aplikasi harus memiliki metadata lengkap, URL fungsional, layanan backend yang aktif, akses demo jika diperlukan, dan catatan rinci untuk fitur yang tidak jelas.
Membuat build yang telah dikirim lebih tahan lama
A reviewer may encounter the app without your team’s context. If the first screen requires an account, provide usable credentials. If a subscription is hidden behind a particular navigation path, document it. If a hardware feature needs setup, explain the steps. If the backend has maintenance windows, schedule the submission around a period when the critical flows are available.
Masalah kinerja sangat berbahaya karena mereka hanya muncul di kondisi nyata. Test peluncuran dingin, jaringan lambat, permintaan terputus, akun besar, penolakan izin, dan kembali dari latar belakang. Kesalahan layer web di dalam sebuah Capacitor shell dapat terlihat seperti kerusakan aplikasi asli kepada reviewer, jadi tangkap kesalahan frontend dan laporan kegagalan asli bersama-sama.
Tangani aturan toko sebagai input rilis
Pengubahan Apple 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 perawatan yang berbeda di tempat lain.
Itu tidak berarti Anda harus menyembunyikan jalur pembelian dari review. Artinya Anda harus memetakan toko yang dimaksud, aliran pembayaran, tombol, tautan, dan teks penjelasan sebelum pengiriman. Reviewer harus melihat perilaku yang sama yang diharapkan analisis kebijakan.
| Driver Penolakan | Aksi Pencegahan | Perlu Pengiriman Ulang |
|---|---|---|
| Aliran Aplikasi Tidak Lengkap | Hapus tempat penempatan, selesaikan onboarding, dan test setiap fitur yang diiklankan | Biasanya, jika perilaku biner tidak lengkap |
| Gagal masuk atau backend tidak tersedia | Berikan akses demo yang berfungsi dan jaga layanan produksi tetap hidup selama review | Ya, ketika gagalnya berada di dalam biner atau kontrak layanan |
| Masalah kinerja dan kestabilan | Uji luncuran dingin, gangguan jaringan, izin, dan aliran yang berlangsung lama | Biasanya, terutama ketika native atau code yang diintegrasikan berubah |
| Fungsi yang tidak jelas | Tambahkan catatan App Review yang singkat dengan langkah navigasi yang tepat | Belum tentu, jika masalah hanya kekurangan konteks dan build sudah berfungsi |
| URL yang rusak atau metadata yang tidak lengkap | Validasi privasi, dukungan, pemasaran, dan link fitur dari lingkungan yang bersih | Ya, jika URL diintegrasikan ke dalam aplikasi atau metadata tidak dapat diperbaiki secara independen |
| Pembelian dan kebijakan tautan eksternal tidak sesuai | Ulasan implementasi toko-toko khusus terhadap bagian pedoman saat ini | Biasanya, 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 istimewa, izin, konfigurasi asli, SDK yang diintegrasikan, atau perilaku dasar aplikasi harus masuk dalam antrian ulasan App Store biasa. JavaScript, CSS, teks, dan aset web dapat disampaikan melalui mekanisme live-update yang tepat, selama 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 yang ditargetkan, dengan kontrol pengembangan dan pengembalian. Hal ini dapat 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. Lapisan shell asli yang dikirim dan fungsionalitas yang dideklarasikan masih perlu lengkap dan dapat direview.
Pemeriksaan Akhir dan Pengiriman Update Tanpa Mengirim Semua Lagi
Rantai rilis yang dapat diandalkan berakhir dengan verifikasi, bukan optimisme. Sebelum pengiriman, pastikan versi dan nomor pembangunanProses pengiriman aplikasi iOS melibatkan distribusi, tanda tangan, hak istimewa, instalasi TestFlight, tes perangkat bersih, metadata, URL privasi dan dukungan, kredit reviewer, alur pembelian, dan ketersediaan backend. Simpan komit, arsip, konfigurasi, dan catatan tinjauan bersama-sama.
Setelah persetujuan, amati laporan kegagalan, kesalahan frontend, gagal login, dan tiket dukungan. Setelah penolakan, baca pesan Pusat Resolusi dengan hati-hati, reproduksi masalah yang tepat, dan balas dengan langkah navigasi konkrit atau kirimkan build yang diperbaiki. Jika penolakan tampaknya salah, gunakan saluran komunikasi dan jalur banding Apple daripada menebak kerja sama diam.
Alur pembaruan hidup dapat memperpendek jalan untuk perbaikan layer web yang layak. Aplikasi OTA yang aman untuk App Store dengan Capgo menggambarkan model operasional: publikasikan bundle yang ditandatangani ke saluran yang dikendalikan, luncurkan ke audiens yang dipilih, amati peningkatan dan gagal, dan retensi perlindungan rollback. Simpan rilis produksi 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 proses pengiriman aplikasi iOS dari latihan api berulang menjadi proses rilis yang tim dapat mengoperasikan.
Capgo membantu Capacitor tim mengirimkan pembaruan JavaScript, CSS, salinan, konfigurasi, dan aset yang ditandatangani 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 itu ke dalam alur rilis iOS Anda.
