Web Uygulamanı Mobile Taşı: Capacitor 8 mi Yeniden Yazım mı?

Elinde çalışan bir web uygulaması varken mobile açılmanın en hızlı yolu Capacitor 8 ile sarmalamak mı, yoksa sıfırdan native yazmak mı? Bu karar özellikle 2026'da web uygulamasını mobile taşıma Capacitor 8 sorusuyla karşılaşan ekipler için maliyetle performans tavanı arasında net bir denge gerektiriyor. Bu yazıda Capacitor 8.5'in getirdiklerinden App Store kabul riskine kadar somut, kaynaklı bir karar çerçevesi bulacaksın.

💡 Pro Tip: Capacitor'a geçmeden önce mevcut web uygulamanın DOM-ağır animasyonlarını ve büyük liste render'larını gerçek bir cihazda (simülatör değil) test et — WebView performans tavanı simülatörde görünmez.

İçindekiler

• Karar çerçevesi: hangi ürün Capacitor'a uygun
• Capacitor 8.5 ne getirdi (UIScene, TypeScript 7)
• Gerçek maliyet: wrap etmek mi, yeniden yazmak mı
• Performans tavanı nerede başlıyor
• Native özelliklere erişim (plugin ekosistemi)
• App Store / Play kabul riski
• Çıkış stratejisi: sonra native'e nasıl geçilir
• Karar tablosu
• SSS
• Web uygulamamı Capacitor ile mobile nasıl taşırım?
• Capacitor 8'de neler değişti?
• Capacitor uygulaması App Store'a kabul edilir mi?
• Capacitor mı yoksa sıfırdan native mi daha ucuz?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Karar çerçevesi: hangi ürün Capacitor'a uygun

Capacitor'ı kendi dokümantasyonu "Web Native apps" oluşturan bir çalışma zamanı olarak tanımlıyor: web standartlarına olabildiğince yakın kalıp, gerektiğinde native SDK'lara tam erişim sunuyor. Resmi ifade net: "If it works in the browser, it probably works in a mobile app when using Capacitor." Bu tanım, karar çerçevesinin de temelini oluşturuyor.

Pratikte şu soruyu sor: uygulamanın çekirdek değeri _içerik ve etkileşim_ mi, yoksa _performans ve akıcılık_ mı? İçerik-ağırlıklı, form-ağırlıklı, CRUD-ağırlıklı ürünlerde (dashboard, yönetim paneli, katalog, rezervasyon akışı) web ekibinin zaten sahip olduğu kod tabanını Capacitor ile mobile taşımak mantıklı bir mühendislik kararı. Yoğun animasyon, oyun mantığı, AR/kamera-ağırlıklı veya frame-hassas etkileşim gerektiren ürünlerde ise WebView'ın render katmanı native'in gerisinde kalabilir — bu durumda native veya Flutter gibi kendi render motoruna sahip bir çözüm karşılaştırmayı hak ediyor (bkz. Flutter vs SwiftUI karşılaştırması).

İkinci soru ekip kompozisyonu: elinde React/Vue/Svelte bilen ama Swift/Kotlin bilmeyen bir web ekibi varsa, Capacitor'ın plugin API'si (aşağıda detaylandırıyoruz) bu ekibin native yetenek eklemesine izin veriyor — sıfırdan native ekip kurmadan.

Üçüncü soru zaman ufku: bir MVP'yi hızlıca mağazalara koymak mı, yoksa uzun vadeli bir ürün için doğru mimariyi baştan kurmak mı öncelikli? Capacitor'ın "web kodun neredeyse aynen çalışır" konumlandırması, MVP-hızı için doğal bir avantaj sağlıyor; ama bu avantaj sonsuz değil. Ürün olgunlaştıkça ve kullanıcı sayısı arttıkça, performans tavanının nerede başladığı sorusu (aşağıdaki bölümde ele alıyoruz) daha çok önem kazanıyor. Bu yüzden kararı tek seferlik değil, ürünün yol haritasına bağlı, gözden geçirilebilir bir karar olarak ele almak daha sağlıklı.

Capacitor 8.5 ne getirdi (UIScene, TypeScript 7)

Capacitor 8.5.0, 31 Temmuz 2026'da yayınlandı. Sürüm notlarındaki üç değişiklik bu kararı doğrudan etkiliyor:

• iOS UIScene desteği — resmi changelog'da "ios: UIScene Support (#8536)" olarak geçiyor. Apple'ın WWDC25'te duyurduğu zorunluluğa hazırlık: Flutter'ın belgelediğine göre, iOS 26'yı takip eden sürümde en güncel SDK ile derlenen her UIKit uygulamasının UIScene lifecycle kullanması gerekecek, aksi halde uygulama açılmayacak.
• CLI migrator — "cli: add migrator functionality for adopting UIScene (#8544)" ile geçişi kolaylaştıran bir CLI aracı eklendi.
• TypeScript 7 desteği — capacitor.config.ts yüklenirken CLI artık TypeScript 7'yi destekliyor ("cli: support TypeScript 7 when loading capacitor.config.ts (#8534)"), resmi changelog'da bir özellik değil bug fix olarak listeleniyor.

TypeScript 7 desteği pratikte şunu sağlıyor: capacitor.config.ts dosyanı artık daha yeni TS derleyici sürümüyle sorunsuz yükleyebiliyorsun, tip tanımlarını elden geçirmene gerek kalmıyor.

1// capacitor.config.ts — TypeScript 7 ile sorunsuz yüklenen tipik yapı
2import type { CapacitorConfig } from "@capacitor/cli";
3 
4const config: CapacitorConfig = {
5  appId: "com.ornek.webapp",
6  appName: "Örnek Web App",
7  webDir: "dist",
8  server: {
9    androidScheme: "https",
10  },
11};
12 
13export default config;

Kritik nokta: Capacitor'ın çekirdek kütüphanesi hâlâ eski AppDelegate yolunu destekliyor. Resmi 8.5 yükseltme rehberi bunu açıkça söylüyor: "The core library still supports the AppDelegate path, so updating the dependency alone won't break your app. To build with Xcode 27, though, your app project needs to adopt the scene lifecycle." Yani bağımlılığı güncellemek tek başına uygulamanı kırmıyor; ama Xcode 27 ile derlemek istediğinde scene lifecycle'ı benimsemen gerekiyor.

1{
2  "dependencies": {
3    "@capacitor/core": "^8.5.0",
4    "@capacitor/cli": "^8.5.0",
5    "@capacitor/ios": "^8.5.0",
6    "@capacitor/android": "^8.5.0"
7  }
8}

Gerçek maliyet: wrap etmek mi, yeniden yazmak mı

8.5 yükseltme rehberine göre UIScene benimseme somut olarak üç parçadan oluşuyor: "one new file, one Info.plist entry, and one method in your AppDelegate" — yani bir yeni dosya (SceneDelegate.swift), bir Info.plist girişi ve AppDelegate'te bir metod. Bu, mevcut bir web uygulamasını Capacitor ile "wrap" etmenin teknik entegrasyon maliyetinin ne kadar düşük olduğunun somut kanıtı; kesin bir "N gün" rakamı resmi kaynaklarda yok, bu yüzden süre tahminini kendi ekibinin deneyimine göre kalibre etmen gerekiyor.

1<key>UIApplicationSceneManifest</key>
2<dict>
3    <key>UIApplicationSupportsMultipleScenes</key>
4    <false/>
5    <key>UISceneConfigurations</key>
6    <dict>
7        <key>UIWindowSceneSessionRoleApplication</key>
8        <array>
9            <dict>
10                <key>UISceneConfigurationName</key>
11                <string>Default Configuration</string>
12                <key>UISceneDelegateClassName</key>
13                <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string>
14                <key>UISceneStoryboardFile</key>
15                <string>Main</string>
16            </dict>
17        </array>
18    </dict>
19</dict>

Bu adımı tamamlayan AppDelegate metodu (resmi rehberden):

1func application(_ application: UIApplication,
2                  configurationForConnecting connectingSceneSession: UISceneSession,
3                  options: UIScene.ConnectionOptions) -> UISceneConfiguration {
4    let config = UISceneConfiguration(name: "Default Configuration",
5                                       sessionRole: connectingSceneSession.role)
6    config.delegateClass = SceneDelegate.self
7    return config
8}

Karşı tarafta, sıfırdan native yeniden yazım şu maliyetleri beraberinde getiriyor: iki ayrı kod tabanı (iOS + Android) bakımı, mevcut web iş mantığının native'e taşınması, ve yeni bir ekip yetkinliği (Swift + Kotlin). Bu üç kalem, "wrap" seçeneğinin göreli olarak neden daha az riskli bir başlangıç noktası olduğunu açıklıyor — ama nihai performans tavanını da belirliyor (bir sonraki bölüm).

1# Mevcut web projesine Capacitor ekleme (gerçek CLI komutları)
2npm install @capacitor/core@^8.5.0 @capacitor/cli@^8.5.0
3npx cap init
4npm install @capacitor/ios@^8.5.0 @capacitor/android@^8.5.0
5npx cap add ios
6npx cap add android
7npx cap sync ios

Android tarafında ek bir "scene lifecycle" adımı yok — bu değişiklik yalnızca iOS'a özgü. Android build'ini senkronize etmek için ayrı bir komut yeterli:

1# Android tarafında senkronizasyon (UIScene adımı gerektirmez)
2npx cap sync android
3npx cap open android

Performans tavanı nerede başlıyor

Capacitor'ın WebView tabanlı mimarisi, native UI kit'lerin (UIKit/SwiftUI, Jetpack Compose) render hattından farklı bir katmanda çalışıyor. Bu, günlük kullanım senaryolarının (form doldurma, liste kaydırma, sayfa geçişi) çoğunda fark edilmeyecek kadar küçük bir maliyet olabilir; ama 60fps'in kritik olduğu sürekli animasyon, kompleks canvas render'ı veya kamera-üstü gerçek zamanlı işleme gibi senaryolarda WebView'ın render katmanı native motorların gerisinde kalabilir.

Resmi kaynaklarda bu tavanı sayısal olarak tanımlayan bir benchmark bulunmuyor — bu nedenle kesin bir "şu FPS'in altında Capacitor kullanma" eşiği vermek yanıltıcı olur. Pratik yaklaşım: kritik ekranları (ör. ana akış, onboarding animasyonu) erken bir prototipte gerçek cihazda test etmek ve tavanı kendi ürünün gereksinimlerine göre ölçmek. Eğer ürünün ağırlık merkezi bu tür yoğun görsel etkileşimse, Flutter'ın Impeller render motoru gibi kendi GPU katmanına sahip çözümler karşılaştırmaya değer.

Bu değerlendirmeyi yaparken tek bir cihazla yetinme: WebView davranışı iOS ve Android arasında, hatta aynı platformun eski/yeni sürümleri arasında farklılık gösterebilir. Kritik ekranı hem düşük-orta segment bir Android cihazda hem de birkaç yıllık bir iPhone'da test etmek, "performans tavanı" sorusuna ürününe özgü, gerçekçi bir cevap verir — resmi bir genel eşik olmadığı için bu ölçüm sorumluluğu ekibe düşüyor.

Native özelliklere erişim (plugin ekosistemi)

Capacitor'ın native erişim modeli üç dile dayanıyor: resmi dokümantasyon "a Plugin API for Swift on iOS, Java on Android, and JavaScript for the web" diyor. Yani bir native özellik eksikse (örneğin özel bir sensör API'si), kendi Swift/Java plugin'ini yazıp JavaScript tarafından çağırabiliyorsun — bu, "wrap" yaklaşımının native erişim tavanını pratikte kaldırıyor, ama plugin yazımı için native bilgi gerektiriyor.

8.5 sürümü bu ekosistemin hâlâ evrildiğinin de kanıtı: scene lifecycle'a özel yeni bildirimler eklendi (.capacitorSceneWillConnect, .capacitorSceneOpenURL, .capacitorSceneOpenUniversalLink), ama resmi rehber şu uyarıyı yapıyor: "Note they're only posted on 8.5 and later, so plugins that also support earlier Capacitor 8 versions should stay on the legacy notifications." Yani birden fazla Capacitor 8 sürümünü destekleyen bir plugin geliştiriyorsan, eski bildirimlerde kalman gerekiyor.

Aynı sürümde bazı eski API'ler de kaldırıldı: "Removed: TmpViewController and the long-deprecated CapacitorBridge.tmpWindow property and tmpViewControllerAppeared notification." Bu, plugin bakımının sürüm takibi gerektiren sürekli bir iş olduğunu gösteriyor — "bir kere wrap et, unut" değil.

Pratikte bu şu anlama geliyor: eğer projende topluluk plugin'leri (kamera, push notification, biyometrik kimlik doğrulama gibi) kullanıyorsan, her Capacitor major/minor yükseltmesi öncesi o plugin'lerin changelog'unu kontrol etmen gerekiyor. Resmi çekirdek plugin'ler (@capacitor/core altında gelenler) genelde ana sürümle senkron güncelleniyor, ama üçüncü parti plugin'lerin güncelleme hızı değişken olabilir — bu da "wrap" yaklaşımının gizli bakım maliyetlerinden biri.

1// Resmi 8.5 yükseltme rehberindeki SceneDelegate.swift — SPM ve
2// CocoaPods projelerinde aynı dosya çalışıyor, Capacitor'ın
3// migrator'ı bunu otomatik oluşturuyor
4import UIKit
5import Capacitor
6 
7class SceneDelegate: UIResponder, UIWindowSceneDelegate {
8    var window: UIWindow?
9 
10    func scene(_ scene: UIScene, willConnectTo session: UISceneSession,
11               options connectionOptions: UIScene.ConnectionOptions) {
12        guard let windowScene = scene as? UIWindowScene else { return }
13        window = UIWindow(windowScene: windowScene)
14        window?.rootViewController = CAPBridgeViewController()
15        window?.makeKeyAndVisible()
16        SceneDelegateProxy.shared.scene(scene, willConnectTo: session, options: connectionOptions)
17    }
18 
19    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
20        SceneDelegateProxy.shared.scene(scene, openURLContexts: URLContexts)
21    }
22 
23    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
24        SceneDelegateProxy.shared.scene(scene, continue: userActivity)
25    }
26}

App Store / Play kabul riski

Apple ve Google'dan Capacitor veya hibrit uygulamalara özgü, sayısal bir red-oranı yayınlayan resmi bir kaynak bulunmuyor — bu nedenle burada bir yüzde vermek uydurma olur. Bilinen gerçek şu: Capacitor'ın kendi konumlandırması "eğer tarayıcıda çalışıyorsa muhtemelen mobilde de çalışır" ilkesine dayanıyor, yani uygulama mağaza incelemesinden native bir uygulama gibi geçiyor — ayrı bir "hibrit" kategorisi veya özel bir onay süreci yok.

Pratik risk, mağazaların genel prensibinden geliyor: bir uygulamanın yalnızca bir web sitesini gösteren, native değer katmayan bir "WebView sarmalayıcısı" olarak algılanmaması gerekiyor. Bunun somut karşılığı, Capacitor'ın plugin ekosistemini (push notification, biyometrik kimlik doğrulama, native paylaşım gibi) kullanarak uygulamaya gerçek native etkileşim eklemek — sadece bir web sayfasını <iframe> gibi göstermek değil.

Çıkış stratejisi: sonra native'e nasıl geçilir

Resmi bir "Capacitor'dan native'e çıkış" dokümanı yok, ama mimarinin kendisi bu geçişi kolaylaştıracak şekilde tasarlanmış: Capacitor'ın plugin API'si zaten Swift/Java tarafında native kod yazmanı gerektiriyor. Pratikte kademeli bir geçiş şöyle işliyor: önce performans-kritik tek bir ekranı (ör. ana akış animasyonu) native bir plugin veya native bir alt-görünüm olarak yeniden yaz, geri kalanı WebView'da bırak. Zamanla native ekranların oranı arttıkça, tam bir native yeniden yazıma daha az riskli, parça parça geçmiş olursun. Bu strateji resmi bir kaynağa dayanmıyor — editoryal bir öneri olarak oku, ekibinin risk toleransına göre uyarlanmalı.

Bu kademeli geçişin en büyük avantajı, "hep ya da hiç" kararını ortadan kaldırması. Bir ekip, Capacitor ile başlayıp belirli bir ekranı native'e taşıdığında, geri kalan uygulamanın WebView tabanlı kalması bir sorun teşkil etmiyor — Capacitor'ın plugin mimarisi zaten web ve native kodun aynı uygulama içinde bir arada yaşamasına izin veriyor. Bu da "önce hızlı çık, sonra kritik ekranları native'e taşı" stratejisini teknik olarak uygulanabilir kılıyor.

Karar tablosu

SSS

Web uygulamamı Capacitor ile mobile nasıl taşırım?

Mevcut web projene @capacitor/core ve @capacitor/cli paketlerini kurup npx cap init ile başlatıyorsun, ardından npx cap add ios / npx cap add android ile platform projelerini oluşturup npx cap sync ile web build'ini native projeye kopyalıyorsun. iOS 26 sonrası derlemeler için UIScene benimsemesi (bir SceneDelegate dosyası + Info.plist girişi + AppDelegate metodu) gerekiyor.

Capacitor 8'de neler değişti?

Capacitor 8.5.0 (31 Temmuz 2026), iOS için UIScene desteğini ve buna geçişi kolaylaştıran bir CLI migrator'ı getirdi; ayrıca capacitor.config.ts yüklenirken TypeScript 7 desteği eklendi.

Capacitor uygulaması App Store'a kabul edilir mi?

Apple veya Google'dan Capacitor'a özgü ayrı bir onay kategorisi veya yayınlanmış bir red-oranı istatistiği yok. Capacitor'ın kendi konumlandırması, tarayıcıda çalışan bir uygulamanın mobilde de çalışacağı ilkesine dayanıyor; uygulamanın gerçek native etkileşim (push, biyometrik, native paylaşım gibi) içermesi, salt bir web sayfası sarmalayıcısı olarak algılanma riskini azaltır.

Capacitor mı yoksa sıfırdan native mi daha ucuz?

Kesin bir maliyet rakamı resmi kaynaklarda yok. Ama teknik kanıt şunu gösteriyor: Capacitor'a geçiş (UIScene dahil) mevcut koda küçük, noktasal eklemeler gerektirirken, sıfırdan native yazım iki ayrı kod tabanının baştan inşasını gerektiriyor — bu asimetri, mevcut bir web kod tabanı olan ekipler için Capacitor'ı genellikle daha düşük başlangıç maliyetli bir seçenek yapıyor.

Güncelleme (Eylül 2026)

Bu yazının yayınlandığı 6 Ağustos 2026'dan bu yana Capacitor iki patch sürümü daha aldı: 8.5.1 ve 8.5.2 (11 Eylül 2026). 8.5.2'deki değişikliklerden biri doğrudan UIScene desteğiyle ilgili: "ios: do not forward scene lifecycle events to the page before it has loaded (#8595)" — yani scene lifecycle olayları artık sayfa tam yüklenmeden JavaScript tarafına iletilmiyor. Bu, 8.5.0'daki UIScene desteğinin olgunlaşmaya devam ettiğinin somut bir göstergesi. Ayrıca 18 Eylül 2026'da 9.0.0-alpha.7 yayınlandı, ama bu hâlâ alpha aşamasında ve production kararı için henüz referans alınmamalı. Bu yazıyı güncel tutmak istiyorsan production'a geçmeden önce güncel latest etiketini (npm'de sorgulanabilir) kontrol etmeni öneririz.

Sonuç

Web uygulamasını Capacitor 8 ile mobile taşımak, mevcut bir web kod tabanın varsa teknik olarak düşük-sürtünmeli bir başlangıç noktası. Capacitor 8.5'in UIScene desteği ve migrator'ı, Apple'ın WWDC25'te duyurduğu zorunluluğa hazırlanmayı kolaylaştırıyor; ama nihai karar ürününün performans profiline bağlı. Yoğun animasyon veya oyun-benzeri etkileşim gerektiren ürünlerde Flutter vs SwiftUI karşılaştırmasını veya React Native vs Flutter karşılaştırmasını da incelemen faydalı olur. Kotlin/Compose ekosisteminden geliyorsan Compose Multiplatform production örneğine ve Kotlin Multiplatform 1.1 vaka çalışmasına bakabilirsin. Mobile tarafta abonelik altyapısı kurman gerekiyorsa RevenueCat cross-platform subscription rehberi ve CI/CD kurulumu için Mobile DevOps best practices yazılarımız bu geçişin sonraki adımlarını kapsıyor.

Kaynaklar

• Capacitor 8.5.0 Release Notes — UIScene desteği, CLI migrator ve TypeScript 7 desteğinin resmi changelog kaydı.
• Capacitor 8.5 Upgrade Guide — SceneDelegate, Info.plist girişi, kaldırılan API'ler ve scene-scoped notification'ların resmi geçiş rehberi.
• Capacitor Documentation — Overview — "Web Native apps" konumlandırması ve Plugin API tanımı.
• Flutter Breaking Changes — Genel Liste — UIScene adoption'ın "Released in Flutter 3.38" başlığı altında listelendiği resmi kayıt.
• Flutter UISceneDelegate Adoption Rehberi — Flutter 3.41'de varsayılan hale gelen otomatik migrasyon ve Apple'ın WWDC25 zorunluluk açıklamasının aktarıldığı sayfa.