Lovable uygulamasını App Store'da yayınlama: PWA, Capacitor veya yeniden yazma ve 4.2'den kaçınma (2026)

Bir Lovable uygulamasını App Store'da nasıl yayınlayacağınızı araştırıyorsanız, bilmeniz gereken ilk şey Lovable'ın bunu sizin yerinize yapamayacağıdır. Lovable yayınlama dokümanları, "Lovable web uygulamaları oluşturur ve yayınlama her zaman bir web URL'sine dağıtım yapar" ve "projenizi paketleyip App Store'a veya Google Play'e gönderen yerleşik bir akış yoktur" der. Aşağıda üç gerçek seçeneği, her birinin maliyetini ve sarmalanmış bir Lovable uygulamasını Guideline 4.2'den uzak tutan adımları bulacaksınız.

Lovable uygulaması doğrudan App Store'da yayınlanabilir mi?

Hayır. Ekim 2026 itibarıyla Lovable, bir lovable.app alt alan adına veya özel bir alan adına yayın yapar; mağazaya girmek ise uygulamayı Lovable dışında paketleyip kendi geliştirici hesabınızdan göndermek anlamına gelir.

Lovable dokümanları iki geçici çözüm önerir: yayınlanan siteyi yüklenebilir bir PWA'ya dönüştürmek ya da "yayınlanan URL'nizi Lovable dışında Capacitor ile native bir kabuğa sarmak" ve bu kabuğu kendiniz göndermek. Dokümanlar iki konuyu da netleştirir. Lovable React Native projeleri oluşturmaz ve Lovable mobil uygulaması yalnızca telefonunuzdan proje geliştirmek içindir. Bu uygulama "projenizi son kullanıcılar için native bir uygulamaya dönüştürmez."

PWA, Capacitor sarmalayıcı veya yeniden yazma: hangi yolu seçmelisiniz?

Mağaza listesine ihtiyacınız yoksa PWA'yı, listeye ihtiyacınız varsa ve gerçek native özellikler ekleyebiliyorsanız Capacitor'ı, uygulamanızın telefon odaklı bir ürün gibi hissettirmesi ve davranması gerekiyorsa native yeniden yazmayı seçin.

Ücretler Apple Developer Program kayıt sayfasından ("üyelik yılı başına 99 USD. Fiyatlar bölgeye göre değişebilir") ve Google Play Console Yardım sayfasından ("tek seferlik 25 USD kayıt ücreti") alınmıştır. Google Play'de yeni kişisel hesapların, üretim erişimi almadan önce 14 gün boyunca 12 test kullanıcısıyla kapalı test yürütmesi de gerekir. Bu adımı kapalı test rehberimiz ele alıyor.

Bir Lovable uygulaması Capacitor ile nasıl sarmalanır?

Lovable kodunu GitHub'a aktarın, yerelde derleyin, Capacitor'ı ekleyin ve webDir değerini derleme çıktısına yönlendirin. Ardından native projeleri Xcode ve Android Studio'da açıp arşivleyin.

1. Lovable'da GitHub'ı bağlayın. Senkronizasyon çift yönlüdür ve her zaman yeni bir özel depo oluşturur; böylece native kabuk üzerinde yerelde çalışırken Lovable'da düzenlemeye devam edebilirsiniz.
2. Depoyu klonlayın, npm install ve ardından npm run build komutunu çalıştırın. Vite'ın çıktıyı nereye yazdığını kontrol edin; bu genellikle dist klasörüdür. Capacitor, bu kök dizinde <head> etiketi içeren bir index.html dosyasına ihtiyaç duyar.
3. Capacitor'ı ve platformları, Capacitor başlangıç dokümanlarından alınan aşağıdaki kod bloğundaki komutlarla yükleyin.
4. capacitor.config içinde webDir değerini dist olarak ayarlayın. server.url değerini canlı Lovable alan adınıza ayarlamayın: Capacitor yapılandırma referansı bunun "üretimde kullanılmak üzere tasarlanmadığını" belirtir.
5. Native eklentiler (push, dokunsal geri bildirim, paylaşım, biyometrik doğrulama, yerel bildirimler) ile native uygulama ikonları ve açılış ekranları ekleyin.
6. Her web derlemesinden sonra npx cap sync komutunu çalıştırın, ardından Xcode'da arşivleyip App Store Connect'e yükleyin. Gerisini App Store gönderim kontrol listemiz ele alıyor.

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

Kendi Apple hesabınızdan gönderin. Guideline 4.2.6, bir uygulama oluşturma hizmetiyle yapılmış uygulamaları, "uygulamanın içeriğinin sağlayıcısı tarafından doğrudan gönderilmedikçe" reddeder. Guideline 4.3 ve 4.2.6 rehberimiz bunun yapay zekâyla oluşturulmuş uygulamalara nasıl uygulandığını açıklıyor.

Sarmalanmış bir Lovable uygulamasında Guideline 4.2 reddinden nasıl kaçınılır?

Uygulamanın web sitesinin yapamadığı şeyleri yapmasını sağlayın. Guideline 4.2, uygulamayı "yeniden paketlenmiş bir web sitesinin ötesine taşıyan özellikler, içerik ve arayüz" ister; 4.2.2 ise ağırlıklı olarak "web kesitleri, içerik toplayıcılar veya bağlantı koleksiyonları" olan uygulamaları dışarıda bırakır.

Göndermeden önce bu kontrol listesini kullanın:

• Web derlemesi binary'nin içine paketlenmiştir ve ağ bağlantısı olmadan açılarak önbelleğe alınmış verileri ya da düzgün bir çevrimdışı ekranı gösterir.
• Gezinme hamburger menü yerine alt sekme çubuğu kullanır; yalnızca web'e özgü alt bilgiler veya çerez bannerları yoktur.
• Giriş, kayıt ve şifre sıfırlama işlemlerinin tümü uygulamanın içinde gerçekleşir. Hiçbir şey kullanıcıyı Safari'ye yönlendirmez.
• En az bir temel iş akışı cihaza dayanır; örneğin kamera ile çekim, kullanıcının kendi verilerine bağlı yerel bildirimler, widget'lar veya biyometrik doğrulama.
• Bağış sayfalarına, mağazalara veya sosyal medyaya giden harici bağlantılar kaldırılmış ya da en aza indirilmiştir.
• App Review notları, uygulamanın telefonda neden faydalı olduğunu açıklar ve bir demo giriş bilgisi içerir.

Web tabanlı diğer uygulamalar 4.2 kapsamında reddedildiğinde ne oldu?

Herkese açık başlıklar aynı örüntüyü gösteriyor: inceleyiciler web hissi veren arayüzleri ve Safari'ye giden bağlantıları reddediyor; yalnızca küçük native özellikler eklemek kararlarını değiştirmiyor.

Aralık 2020'de Ionic Forum üzerinde bir geliştiricinin kulüp üyeliği uygulaması, "Uygulamanız mobil tarama deneyiminden yeterince farklı olmadığı için sınırlı bir kullanıcı deneyimi sunuyor" gerekçesiyle ve ardından "uygulama içeriğinin çoğu Safari'ye bağlantı veriyor" notuyla reddedildi. InAppBrowser'ı kaldırmak ve çevrimdışı desteği iyileştirmek yeterli olmadı; ikinci gönderim de reddedildi. Üçüncü deneme, geliştirici ana ekranı native tarzda listeler ve görsel kartlarla yeniden oluşturduktan, uygulama içine daha fazla haber içeriği ekledikten ve harici bağlantıların çoğunu kaldırdıktan sonra onaylandı.

Ocak 2026'da Apple Developer Forums üzerinde bir geliştirici, push bildirimleri, Core Location ve kişilere erişimi zaten kullanmasına rağmen bir planlama uygulamasının "web tarama deneyiminden yeterince farklı olmadığı" gerekçesiyle reddedildiğini bildirdi. Geliştirici dokunsal geri bildirim, hızlı eylemler ve daha derin takvim entegrasyonu eklemeyi planladığını yazdı ve neyin "daha native" sayıldığını sordu. Bu yazı yazılırken başlıkta hiç yanıt ve doğrulanmış bir sonuç yok.

Karşılaştırma şöyle: ilk geliştirici uygulamanın ne olduğunu değiştirerek (uygulama içi içerik, native düzenler, dışarıya bağlantı yok) onay aldı. İkincisi yalnızca cihaz API'leri ekledi ve hâlâ emin değildi. Emeğinizi daha uzun bir izin listesine değil, temel deneyime yatırın.

Ne zaman sarmalamak yerine yeniden yazmalısınız?

Uygulamanızın ana değeri web içeriğiyse ya da aynı arayüz için zaten iki kez 4.2 reddi aldıysanız native olarak yeniden yazın.

Uygulamalı örnek: bir yoga stüdyosu için yapılmış Lovable rezervasyon aracı; bir ders listesi, bir rezervasyon formu ve bir Stripe ödeme bağlantısı gösteriyor. Olduğu gibi sarmalanırsa 4.2'nin üç uyarı işaretinin üçüne de takılır: web arayüzü, dışarıya bağlantı ve çevrimdışı kullanım olmaması. PWA olarak bugün ek maliyet olmadan yayınlanabilir. Mağaza listesi almak için Lovable backend'ini koruyun, ders listesini ve rezervasyon akışını native ekranlarla yeniden yazın, her dersten önce yerel hatırlatıcılar ekleyin ve ödemeyi App Review Guideline 3.1 kuralları çerçevesinde ele alın. Backend'iniz ve veri modeliniz olduğu gibi aktarılır. Yeniden yazdığınız şey arayüzdür.

Lovable projenize hangi yolun uyduğu konusunda ikinci bir görüş istiyorsanız, The App Guy'ın hizmetleri sarmalama, yeniden yazma ve mağaza gönderimini kapsar; dilerseniz yagyeshsrbobde@gmail.com adresine e-posta da gönderebilirsiniz.