PWA ve Web'den Mobil Mağazalara: Tek Kod Tabanıyla Çoklu Platform Yönetimi
Tek kod tabanı, tek davranış anlamına gelmez. Sağlıklı multi-platform mimaride ürün çekirdeği ortaktır; platform capability'leri, dağıtım süreçleri ve release riskleri kontrollü adapter katmanlarında ayrılır.
Web'de çalışan bir ürünün Android paketi üretmesi multi-platform olduğu anlamına gelmiyor. Klavye davranışı, safe area, deep link, push notification, file system, ödeme, auth callback, offline açılış ve mağaza versioning'i devreye girdiğinde platform gerçekliği kendini gösteriyor.
Tek codebase hedef; platform farklarını yok saymak değil, onları sınırlandırmaktır.
1. Çekirdek ürün ile platform capability'sini ayırmak
Domain logic, validation, veri modeli ve çoğu UI ortak kalabilir. Kamera, dosya sistemi, haptic, native share, store billing veya deep link gibi capability'ler ise adapter arkasında yaşamalı. Böylece component 'Android miyim?' diye branch üretmek yerine ihtiyaç duyduğu capability'yi çağırır.
export interface PlatformBridge { share(input: SharePayload): Promise<void>; openExternal(url: string): Promise<void>; getInsets(): Promise<SafeAreaInsets>; billing: BillingAdapter;}
export const platform = createPlatformBridge();2. Platform condition'larını component'lere dağıtmamak
isAndroid veya isNative kontrolü onlarca component'e yayılırsa codebase teknik olarak tek, davranış olarak parçalı hale gelir. Platform farklarını mümkün olduğunca bridge, hook veya feature capability seviyesinde toplarım.
3. Release matrix oluşturmak
| Yüzey | Artifact | Version | Kritik doğrulama |
|---|---|---|---|
| Web | Static bundle | commit/release | route, cache, rollback |
| PWA | bundle + service worker | cache schema | update ve stale asset |
| Android | AAB/APK | versionCode/versionName | signing, deep link, billing |
| iOS | IPA/archive | build/marketing version | entitlements, universal links |
Her platform için artifact, version kaynağı, signing sahibi ve rollback yöntemi açık değilse release süreci hafızaya bağımlı kalır. Solo ekipte bile küçük bir release matrix ciddi hata oranını düşürür.
4. Versioning'i tek kaynaktan üretmek
package.json, Capacitor config, Gradle ve mağaza ekranlarında farklı version bilgileri elle tutulursa bir noktada drift oluşur. İnsan tarafından seçilen semantic version'ı tek kaynak yapıp platform build number'larını otomatik türetmek daha güvenilir.
{ "release": { "version": "1.4.0", "androidVersionCode": 10400, "iosBuild": 10400 }}5. Web deploy ile store release'i aynı şey sanmamak
Web deploy dakikalar içinde rollback edilebilir. Store release review, staged rollout ve kullanıcı cihazındaki eski binary nedeniyle daha yavaş bir sistemdir. API ve database değişikliklerini yalnızca son web sürümüne göre tasarlarsanız mağazada bir önceki native sürüm hâlâ aktifken uyumluluk problemi yaşarsınız.
6. N-1 client uyumluluğu
Backend contract'larını en azından aktif N-1 mobil sürümünü hesaba katarak değiştiririm. Yeni zorunlu alan eklemek, enum değerini kaldırmak veya auth response formatını değiştirmek webde görünmeyen ama mağazada ciddi sorun üreten değişikliklerdir.
7. Gerçek cihaz gate'i
- Klavye açıldığında modal ve CTA görünür kalıyor mu?
- Safe area ve status bar doğru mu?
- Cold start ve expired session davranışı doğru mu?
- Deep/universal link uygulamayı doğru route'ta açıyor mu?
- Offline açılışta sonsuz loading oluşuyor mu?
- Store billing entitlement ile backend erişimi tutarlı mı?
- Yeni web bundle eski native shell içinde çalışıyor mu?
8. CI/CD'yi build makinesi değil release gate yapmak
Her commit için pahalı native build almak gerekmeyebilir. Web typecheck/build her değişiklikte çalışırken signed store artifact'i manuel veya release tag ile tetiklenebilir. Otomasyonun amacı daha çok build üretmek değil, yanlış artifact'in yanlış kanala gitmesini engellemektir.
Sonuç: ortak çekirdek, ayrık operasyon
Tek codebase en çok ürün mantığını paylaşırken değerli. Platform operasyonunu da tekmiş gibi davranmaya zorlamak kırılganlık yaratır. Ortak domain ve UI çekirdeği; küçük platform adapter'ları, açık release matrix ve geriye dönük contract disiplini ile birleştiğinde solo ekip için sürdürülebilir hale gelir.