Cara memublikasikan aplikasi Lovable ke App Store: PWA vs Capacitor vs bangun ulang, dan hindari 4.2 (2026)

Jika Anda mencari cara memublikasikan aplikasi Lovable ke App Store, hal pertama yang perlu diketahui adalah Lovable tidak bisa melakukannya untuk Anda. Dokumentasi publikasi Lovable menyebutkan bahwa "Lovable membangun aplikasi web dan publikasi selalu di-deploy ke URL web" serta "tidak ada alur bawaan yang mengemas dan mengirimkan proyek Anda ke App Store atau Google Play." Berikut tiga opsi yang sebenarnya, berapa biaya masing-masing, dan langkah-langkah agar aplikasi Lovable yang dibungkus terhindar dari Guideline 4.2.

Bisakah aplikasi Lovable dipublikasikan langsung ke App Store?

Tidak. Per Oktober 2026, Lovable memublikasikan ke subdomain lovable.app atau domain kustom, dan untuk masuk ke toko aplikasi Anda harus mengemas aplikasi di luar Lovable lalu mengirimkannya dari akun developer Anda sendiri.

Dokumentasi Lovable menyarankan dua solusi alternatif: jadikan situs yang dipublikasikan sebagai PWA yang bisa diinstal, atau "bungkus URL yang dipublikasikan dalam shell native dengan Capacitor di luar Lovable" lalu kirim shell tersebut sendiri. Dokumentasi itu juga menegaskan dua hal. Lovable tidak menghasilkan proyek React Native, dan aplikasi mobile Lovable hanya untuk membangun proyek dari ponsel Anda. Aplikasi itu "tidak mengubah proyek Anda menjadi aplikasi native untuk pengguna akhir."

PWA vs wrapper Capacitor vs bangun ulang: jalur mana yang sebaiknya dipilih?

Pilih PWA jika Anda tidak butuh listing di toko, Capacitor jika Anda butuh listing dan mampu menambahkan fitur native yang nyata, dan pembuatan ulang native jika aplikasi Anda harus terasa dan berperilaku seperti produk yang mengutamakan ponsel.

Biaya tersebut berasal dari halaman pendaftaran Apple Developer Program ("99 USD per tahun keanggotaan. Harga dapat berbeda menurut wilayah") dan Bantuan Google Play Console ("biaya pendaftaran sekali bayar sebesar US$25"). Di Google Play, akun pribadi baru juga harus menjalankan pengujian tertutup dengan 12 penguji selama 14 hari sebelum mendapatkan akses produksi. Panduan pengujian tertutup kami membahas langkah tersebut.

Bagaimana cara membungkus aplikasi Lovable dengan Capacitor?

Ekspor kode Lovable ke GitHub, build secara lokal, tambahkan Capacitor, dan arahkan webDir ke output build. Lalu buka proyek native di Xcode dan Android Studio, kemudian buat archive-nya.

1. Di Lovable, hubungkan GitHub. Sinkronisasinya dua arah dan selalu membuat repositori privat baru, jadi Anda tetap bisa mengedit di Lovable sambil mengerjakan shell native secara lokal.
2. Clone repo, jalankan npm install, lalu npm run build. Periksa di mana Vite menulis output, biasanya dist. Capacitor membutuhkan index.html dengan tag <head> di root tersebut.
3. Instal Capacitor dan platformnya menggunakan perintah pada blok kode di bawah, dari dokumentasi memulai Capacitor.
4. Di capacitor.config, atur webDir ke dist. Jangan atur server.url ke domain Lovable Anda yang live: referensi konfigurasi Capacitor menyebut opsi ini "tidak dimaksudkan untuk digunakan di produksi."
5. Tambahkan plugin native (push, haptics, share, biometrik, notifikasi lokal) serta ikon aplikasi dan splash screen native.
6. Jalankan npx cap sync setiap kali selesai build web, lalu buat archive di Xcode dan unggah ke App Store Connect. Checklist pengiriman App Store kami membahas sisanya.

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm i @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios
npm run build && npx cap sync
npx cap open ios

Kirim dari akun Apple Anda sendiri. Guideline 4.2.6 menolak aplikasi yang dibuat dari layanan pembuat aplikasi kecuali "dikirimkan langsung oleh penyedia konten aplikasi tersebut." Panduan Guideline 4.3 dan 4.2.6 kami menjelaskan bagaimana hal itu berlaku untuk aplikasi buatan AI.

Bagaimana menghindari penolakan Guideline 4.2 untuk aplikasi Lovable yang dibungkus?

Buat aplikasi mampu melakukan hal-hal yang tidak bisa dilakukan situs web. Guideline 4.2 meminta "fitur, konten, dan UI yang mengangkatnya melampaui situs web yang dikemas ulang," dan 4.2.2 menolak aplikasi yang pada dasarnya hanya "kliping web, agregator konten, atau kumpulan tautan."

Gunakan checklist ini sebelum mengirimkan:

• Build web disertakan di dalam binary dan bisa dibuka tanpa koneksi jaringan, dengan menampilkan data cache atau layar offline yang layak.
• Navigasi memakai tab bar di bawah, bukan menu hamburger, dan tidak ada footer khas web atau banner cookie.
• Login, pendaftaran, dan reset kata sandi semuanya berlangsung di dalam aplikasi. Tidak ada yang mengarahkan pengguna keluar ke Safari.
• Setidaknya satu alur kerja inti bergantung pada perangkat, misalnya pengambilan foto dengan kamera, notifikasi lokal yang terkait dengan data milik pengguna, widget, atau biometrik.
• Tautan eksternal ke halaman donasi, toko, atau media sosial dihapus atau dibatasi seminimal mungkin.
• Catatan untuk App Review menjelaskan mengapa aplikasi berguna di ponsel dan menyertakan login demo.

Apa yang terjadi saat aplikasi berbasis web lain ditolak berdasarkan 4.2?

Thread publik menunjukkan pola yang sama: reviewer menolak UI yang terasa seperti web dan tautan yang membuka Safari, dan menambahkan fitur native kecil saja tidak mengubah keputusan mereka.

Pada Desember 2020, seorang developer di Ionic Forum mengalami penolakan aplikasi keanggotaan klub dengan alasan "Aplikasi Anda memberikan pengalaman pengguna yang terbatas karena tidak cukup berbeda dari pengalaman menjelajah di browser seluler," disusul "sebagian besar konten aplikasi menautkan keluar ke Safari." Menghapus InAppBrowser dan memperbaiki dukungan offline tidak cukup, dan pengiriman kedua juga ditolak. Percobaan ketiga disetujui setelah developer tersebut membangun ulang layar beranda dengan daftar dan kartu gambar bergaya native, menambahkan lebih banyak konten berita di dalam aplikasi, dan menghapus sebagian besar tautan eksternal.

Pada Januari 2026, seorang developer di Apple Developer Forums melaporkan aplikasi penjadwalan yang ditolak karena "tidak cukup berbeda dari pengalaman menjelajah web" meskipun sudah menggunakan notifikasi push, Core Location, dan akses kontak. Mereka berencana menambahkan haptics, quick actions, dan integrasi kalender yang lebih dalam, serta bertanya apa yang dianggap "lebih native." Saat artikel ini ditulis, thread tersebut belum memiliki balasan maupun hasil yang terkonfirmasi.

Perbandingannya: developer pertama lolos dengan mengubah hakikat aplikasinya (konten di dalam aplikasi, tata letak native, tanpa tautan keluar). Developer kedua hanya menambahkan API perangkat dan masih ragu. Fokuskan usaha Anda pada pengalaman inti, bukan pada daftar izin yang lebih panjang.

Kapan sebaiknya membangun ulang daripada membungkus?

Bangun ulang secara native jika nilai utama aplikasi Anda adalah konten web, atau jika Anda sudah dua kali ditolak berdasarkan 4.2 untuk UI yang sama.

Contoh kasus: sebuah alat pemesanan buatan Lovable untuk studio yoga menampilkan daftar kelas, formulir pemesanan, dan tautan checkout Stripe. Jika dibungkus apa adanya, aplikasi ini terkena ketiga tanda bahaya 4.2: UI web, tautan keluar, dan tidak bisa dipakai offline. Sebagai PWA, aplikasi ini bisa dirilis hari ini tanpa biaya tambahan. Untuk mendapatkan listing di toko, pertahankan backend Lovable, bangun ulang daftar kelas dan alur pemesanan dengan layar native, tambahkan pengingat lokal sebelum setiap kelas, dan tangani pembayaran sesuai aturan App Review Guideline 3.1. Backend dan model data Anda tetap terpakai. Yang Anda tulis ulang adalah UI-nya.

Jika Anda ingin pendapat kedua tentang jalur mana yang cocok untuk proyek Lovable Anda, layanan The App Guy mencakup pembungkusan, pembuatan ulang, dan pengiriman ke toko aplikasi, atau kirim email ke yagyeshsrbobde@gmail.com.