Mobil ve çoklu yüzey (Android, iOS, Web/PWA, Desktop, TV, giyilebilir, otomotiv) çağında, yayınlama tek başına bir “build yüklemesi” değil; entegrasyonlar ile örülü bir üretim–teslim–ölçüm ekosistemidir. Kaynak kodundan mağaza varlıklarına, crash toplama katmanından ödeme/abonelik doğrulamasına, pazarlama ölçümünden LiveOps’a kadar her parçanın birbirine doğru bağlanması gerekir. Yanlış seçimler teknik borcu, çapraz-platform tutarsızlıkları ve operasyonel yorgunluğu büyütürken; doğru entegrasyon seti deney hızını, geliri, görülebilirliği ve kullanıcı memnuniyetini ivmelendirir.
1) CI/CD Omurgası: Çoklu Yüzeyde Güvenli Otomasyon
Amaç: Aynı commit’ten Android AAB, iOS IPA, Web (PWA/TWA), Desktop (isteğe bağlı) artefaktlarını tutarlı sürümve imza ile üretmek.
Araç Örnekleri: GitHub Actions/GitLab CI, Bitrise, Codemagic (özellikle Flutter), CircleCI; mobil tarafında Fastlane (deliver, pilot, supply), Gradle ve Xcode Cloud (iOS odaklı).
Şablon:
-
Matris iş akışı:
platform × flavor × target
. -
Jobs: Lint–Test–Build–Sign–Upload–Notify.
-
Gizli yönetimi: Keystore/p12/Profiles/KMS/Secret Manager.
-
Artefakt: AAB/IPA + mapping/dSYM + changelog + sürüm notu.
Mini Vaka: Tek repo, üç yüzey (Android/iOS/Web). GitHub Actions matrisinde prod
job’ı yalnızca imzaları çözebilir (least privilege). Hatalı sürümde otomatik rollback job’ı tetiklenir; canary %5 → %25 → %100.
Kontrol Listesi:
-
Sürüm kodu/ismi tek kaynaktan?
-
Platforma özel imzalar ayrı kasada mı?
-
Canary/staged rollout parametreleri CI’dan yönetiliyor mu?
2) Mağaza Otomasyonu ve Varlık Yönetimi
Amaç: Mağaza görselleri, metinleri, yerelleştirmeleri ve sürüm notlarını kod gibi yönetmek.
Araç Örnekleri: Fastlane (supply/deliver), AppCenter Distribute (test), App Store Connect/Play Console API’leri, lokalizasyon için Lokalise/Crowdin.
Uygulama:
-
Repo içinde
store/
klasörü: ikon/poster/video poster, kısa/uzun açıklamalar, yerelleştirme JSON/YAML. -
CI, branche göre ilgili varyantı yükler (ör.
release/x_y_z
→ prod mağazalar).
Ölçüm: Mağaza değişiklikleri ile PPO/ASO test sonuçlarını bağlayabilmek için commit hash + variant id etiketleyin.
3) ASO/PPO Deney Platformları
Amaç: İkon, ilk görsel, video poster, başlık/kısa açıklamayı bilimsel şekilde test etmek.
Araç Örnekleri: Play Store Listing Experiments (PPO), App Store Product Page Optimization (PPO), Custom Product Pages; üçüncü taraf olarak Splitmetrics/Storemaven (iOS odaklı).
Kural: MDE %8–12, güç ≥ %80, süre ≥ 1 hafta; tek değişkenli test.
Mini Vaka: Sonuç ekranı posteri → CR +%9.5; “indirim” yerine “sonuç” cümlesi → trial start +%6.3. Karar defterine işlenir; kalıcı kurallar güncellenir.
4) Analitik ve Semantik Katman: Tek Dilde Ölçmek
Amaç: Play/App Store/Web analitik panellerini tek bir anlam katmanı ile konuşturmak.
Araç Örnekleri: Firebase/GA4, Amplitude/Mixpanel, Segment/RudderStack (event router), Snowflake/BigQuery (DWH), dbt/Transform.
Semantik Sözlük (örnek):impression, product_page_view, install, first_open/visit, onboarding_complete, core_action_done, paywall_view, purchase_start, purchase_success, refund, churn_signal
Etiketler: platform, store, device_tier, country, acquisition_proxy, ab_group, app_version
Kazanım: D1/D7 retansiyon, ARPPU, LTV kısa ufuk, mağaza CR ve PPO sonuçları karşılaştırmalı okunur.
5) Crash/ANR ve Performans İzleme
Amaç: Çoklu cihaz/OS’ta stabilite ve hız sinyallerini anında görmek.
Araç Örnekleri: Firebase Crashlytics, Sentry, Backtrace; Android Vitals/Play Console; Xcode Organizer (iOS); Web’de Sentry + Web Vitals.
Metrikler: crash_free_session ≥ %99
, p95_cold_start ≤ 2 sn
, ANR_rate ↓
, Web’de LCP < 2.5s
, TBT < 200ms
, CLS < 0.1
.
Protokol: Eşik aşımında alarm → canary daraltma → hotfix. Sürüm notunda sayısal iyileştirme yaz (örn. “soğuk açılış %35 kısaldı”).
6) Abonelik ve IAP Doğrulama
Amaç: Google Billing/StoreKit/HMS/Amazon IAP farklarını tek modelle yönetmek.
Araç Örnekleri: Sunucu tarafında ortak IAP modeli (Product, Purchase, SubscriptionState), RevenueCat (çoklu mağaza), kendi doğrulama servisleri, App Store/Play makbuz API’leri.
Şablon:
-
BillingService
arayüzü (Play/StoreKit/HMS/Amazon impl). -
Sunucuda tek tablo, farklı doğrulama uçları.
-
Durum makineleri:
trial, intro, active, grace, paused, canceled, refunded
.
Ölçüm: trial→paid
, 2. fatura oranı, refund
, grace
payı; mağaza/pazar kırılımları.
7) Ödeme Geçidi ve Vergi Uyumu (Web/PWA)
Amaç: PWA veya web satışlarında güvenli ve düşük sürtünmeli ödeme.
Araç Örnekleri: Stripe/Adyen/Braintree, Apple Pay/Google Pay entegrasyonları, vergi için Stripe Tax/Quaderno.
İlke: Misafir ödeme, tek tık kayıtlı kart, iade güvencesi metni; KDV/VAT otomasyonu.
8) Bildirim ve Mesajlaşma
Amaç: Değer-sonrası izinle etkileşim ve geri çağırma.
Araç Örnekleri: Firebase Cloud Messaging (Android/Web push), APNS (iOS), OneSignal/Braze/MoEngage (çoklu kanal), Segment ile tetikleme.
Uygulama:
-
İzin değerden sonra (onboarding mini zaferi → izin).
-
Kanal ayrımı: kritik/işlemsel/pazarlama.
-
Sessiz saatler ve kişiselleştirme.
9) Deney/A/B ve Özellik Bayrakları
Amaç: Üretimde risk almadan varyant denemek.
Araç Örnekleri: Firebase Remote Config + A/B, LaunchDarkly/Flagsmith, Statsig/Optimizely Feature.
Şablon:
-
Kaynak koddan bağımsız parametrik kontroller: paywall kopyası, izin metni, onboarding sırası.
-
Kill switch: Regresyon anında özelliği anında kapat.
10) Konfigürasyon Yönetimi (Remote Config)
Amaç: Yeni yayın gerektirmeden davranış değiştirmek.
Uygulama:
-
Pazar bazlı fiyat/deneme, metin, görsel toggle.
-
“Acil yama” için “trafiği kapat/aç”, “lite mod” gibi anahtarlar.
Ölçüm: Konfig değişikliğinin funnel ve kalite metriklerine etkisi (öncesi/sonrası).
11) In-App Review/Update ve Yorum Yönetimi
Amaç: Skoru yükseltmek, güncelleme sürtünmesini azaltmak.
Araç Örnekleri: Android In-App Review/Update, iOS için uygun an prompt stratejileri; AppFollow/Appbot/AppTweak (yorum analizi).
Sistem: Tema analizi → sprint → ölçülebilir sürüm notu → ilgili yorumlara özgün yanıt.
12) Telemetri Veri Ambarı ve BI
Amaç: Ürün, pazarlama ve finans verilerini tek yerde birleştirmek.
Araç Örnekleri: BigQuery/Snowflake + dbt, Looker/Metabase/Superset, Fivetran/Stitch (ETL).
Model: Kısa ufuk LTV (90–180 gün); mağaza–pazar–cihaz segmentleri; edinim → LTV geri beslemesi ile bütçe optimizasyonu.
13) Gizlilik, Güven ve Erişim Kontrolü
Amaç: ATT/Privacy Sandbox/OAID/çerez yönetimi gibi rejimlere uyum.
Araç Örnekleri: Consent Management Platform (OneTrust/Didomi), App Privacy/etiket yönetimi, Play Integrity.
İlke: Veri minimizasyonu, amaç açıklığı, değer-sonrası izin; hassas veri için sunucu doğrulaması.
14) Erişilebilirlik ve Kalite Güvence Araçları
Amaç: Her kullanıcı için kullanılabilirlik.
Araç Örnekleri: iOS Accessibility Inspector, Android Accessibility Scanner, Lighthouse (a11y kontrolleri), axe-core, TalkBack/VoiceOver testleri.
Kontrol Listesi:
-
Büyük metin ve yüksek kontrast modu
-
Hareket azaltma seçeneği
-
Odak (focus) hiyerarşisi
-
Sesli geri bildirim
15) İçerik Dağıtımı ve Asset Yönetimi
Amaç: İlk oturum süresini kısaltmak ve paket boyutunu düşürmek.
Araç Örnekleri: Android Play Asset Delivery (PAD), iOS/Android için CDN (CloudFront/Fastly), Unity Addressables, Remote Asset Bundles.
Strateji: install-time
(çekirdek), fast-follow
(erken), on-demand
(seviye/DLC). Skeletal UI ve “tek tık örnek” ile 60–120 saniyede küçük zafer.
16) Görsel Regresyon ve Otomatik QA
Amaç: UI kırılmalarını kod seviyesinde yakalamak.
Araç Örnekleri: Percy/Chromatic (web), Detox/XCUITest/Espresso (mobil), Appium, Playwright + emülasyon.
Şablon: Kritik ekranların “altın görüntü (golden)” seti; CI’da diffs; ürün sayfası görselleri için ayrı test paketi.
17) Dış Trafik, Deep Link ve Attribution
Amaç: Kampanyaların mağaza/PWA etkisini doğru okumak ve içerik derin bağa atlamak.
Araç Örnekleri: Firebase Dynamic Links/Branch/Adjust/Appsflyer, UTM kuralları, Deferred deep linking.
Uygulama: İlk açılışta kampanya parametrelerini event’e yansıt; CPL/eCPI yerine CR ve LTV ile optimizasyon.
18) LiveOps, İçerik Takvimi ve Oyunlaştırma
Amaç: Yayın sonrası elde tutmayı artırmak.
Araç Örnekleri: Play Game Services, GameSparks/PlayFab/Beamable (oyun), CMS/Headless (içerik), LaunchDarkly (dinamik etkinlik bayrakları).
Ölçüm: Etkinlik dönemlerinde oturum süresi, paywall ve organik yorum artışı.
19) Dokümantasyon ve Karar Defteri (Decision Log)
Amaç: Entegrasyon ve deney kararlarının kurumsal hafızası.
Araç Örnekleri: Notion/Confluence, ADR (Architecture Decision Records) şablonları.
Şablon: Problem–Alternatifler–Seçim–Gerekçe–Metrikler–Geri Dönüş. PPO/ASO/LTV sonuçlarını iliştirin.
20) Entegrasyon Denetimi (Quarterly Health Check)
Amaç: Entegrasyonların zamanla çürümemesini sağlamak.
Kontrol: SDK sürümleri, güvenlik bültenleri, kırılan API’ler, gizlilik işaretleri, performans/enerji regresyonları.
Ritüel: 90 günde bir “Health Report” + aksiyon planı; borçları sprint backlog’una yazın.
21) Çapraz-Platform SDK Seçim Kriterleri
Amaç: Flutter/React Native/Unity/Native projede doğru paket.
Kriterler:
-
Bakım sıklığı ve yıldız/issue oranı
-
Platform kapsamı (Android/iOS/Web/TV)
-
Şeffaf lisanslama ve fiyat
-
Performans etkisi (soğuk başlatma/paket boyutu)
-
Sentry/Crash ile stack izlenebilirliği
22) Mimari Soyutlama: Adapter ve Feature Flag Katmanları
Amaç: GMS/HMS/Amazon/StoreKit farklarını koda kilitlemeden yönetmek.
Şablon: AuthService
, BillingService
, PushService
, AnalyticsService
arayüzleri; mağaza bazlı implementasyonlar; feature flag ile koşullu açma/kapama.
Kazanım: Yeni platformu eklemek “plugin ekle” değil, “impl ekle” olur; test ve bakım kolaylaşır.
23) Güvenlik ve Bütünlük
Amaç: Kurulum ve satın almanın meşruiyet sinyalini artırmak.
Araç Örnekleri: Play Integrity API, DeviceCheck/Attestation, sunucu tarafı imza doğrulama, kod bütünlük kontrolü.
Pratik: Riskli skorlar için ödül/rekabet modlarını kısıtla; anomali havuzlarını izleyerek kötüye kullanımı azalt.
24) Erişilebilirlik–Performans–Enerji Üçgeni
Amaç: UX kazanımı ile teknik verimi birlikte yükseltmek.
Uygulama: Yüksek kontrast/büyük metin; skeletal UI/ilk kare hız; enerji tüketimini azaltan frame pacing. “Erişilebilirlik raporu”nu sürüm notuna iliştirin—şikâyet temaları azalır.
25) 30–60–90 Gün Entegrasyon Yol Haritası (Uygulanabilir)
Gün 0–30:
-
CI/CD matris ve gizli yönetimi; Fastlane ve mağaza API’leri.
-
Semantik analitik sözlüğü ve event yönlendirme (Segment/Rudder).
-
Crash/performans izleme; PPO’da “sonuç ekranı” posteri; değer-sonrası izin.
Gün 31–60:
-
IAP doğrulama servisleri (veya RevenueCat), Remote Config + Feature Flags.
-
Bildirim segmentasyonu (kritik/işlemsel/pazarlama); yorum tema → sprint döngüsü.
-
PAD/asset dağıtımı; görsel regresyon testleri.
Gün 61–90:
-
DWH + LTV kısa ufuk modeli; pazara göre fiyat/deneme deneyleri.
-
Health Check raporu; güvenlik/SDK sürüm güncellemeleri.
-
LiveOps/etkinlik altyapısı; karar defteri güncellemesi.
Sonuç
Çoklu platformda yayınlama, entegrasyonlar zincirinin güçlülüğü kadar sağlıklıdır. Başarı, üç eksende birleşir:
-
Operasyonel omurga: CI/CD, mağaza otomasyonu, PPO/ASO testleri, crash/performans izleme, Remote Config ve feature flags ile güvenli ve hızlı yayın ritmi.
-
Gelir ve edinim zekâsı: Çoklu mağaza IAP doğrulaması, web ödemeleri, bildirim ve deney altyapısı, telemetri–DWH–LTV kısa ufuk modeliyle ölçülebilir büyüme.
-
Kullanıcı güveni ve kalite: Değer-sonrası izin, erişilebilirlik, enerji/perf optimizasyonu, yorum–tema–sprint–ölçülebilir sürüm notu döngüsü ve gizlilik/uyum disiplini.
Doğru araç–doğru yerde–doğru kuralla kullanıldığında; yayınlama süreci bir “dosya yükleme” olmaktan çıkar, tekrarlanabilir bir ürün motoruna dönüşür. Entegrasyonları “yapıştırıcı” değil, mimari birer rol olarak ele alın. O zaman her yeni platform, yeni borç değil; kolay eklenen bir yüzey olur. İşte bu yüzden, çoklu platformda büyüyen ekiplerin sırrı entegrasyon tasarımıdır—kodu taşır, ürünü taşır, geliri taşır.