Kotlin vs SwiftUI: iOS ve Android'de Tek Bir Ürünü Tutarlı Tutma

İki yığında tek bir ürünü uyumlu tutmak neden zor\n\nÖzellik listesi eşleşse bile iOS ve Android'de deneyim farklı hissedilebilir. Her platformun kendi varsayılanları vardır. iOS sekme çubuklarına, kaydırma hareketlerine ve modal sayfalara eğilimlidir. Android kullanıcıları görünür bir Geri düğmesi, güvenilir sistem geri davranışı ve farklı menü/diğer diyalog kalıpları bekler. Aynı ürünü iki kez inşa ettiğinizde, bu küçük varsayılanlar birikir.\n\nKotlin vs SwiftUI sadece bir dil veya çerçeve seçimi değildir. Ekranların nasıl göründüğü, verinin nasıl güncellendiği ve kullanıcı girişinin nasıl davranması gerektiği konusunda iki ayrı varsayım kümesidir. Gereksinimler “iOS gibi yap” veya “Android’i kopyala” şeklinde yazılırsa, bir taraf her zaman tavizkar hissedecektir.\n\nEkipler genellikle tutarlılığı mutlu yol ekranları arasındaki boşluklarda kaybeder. Bir akış tasarım incelemesinde uyumlu görünebilir, sonra yükleme durumları, izin istemleri, ağ hataları ve “kullanıcı ayrılıp geri dönerse ne olur” gibi durumlar eklendiğinde sapma başlar.\n\nParite genellikle tahmin edilebilir yerlerde bozulur: ekran sırası ekiplerden biri akışı “basitleştirdikçe” değişir, Geri ve İptal farklı davranır, boş/yükleme/hata durumları farklı metinlere sahip olur, form girişleri farklı karakterleri kabul eder ve doğrulama zamanlaması kayar (yazarken vs odak kaybolduğunda vs gönderimde).\n\nPratik hedef özdeş UI değildir. Hedef, iki yığının da aynı noktaya ulaşmasını sağlayacak kadar net davranışı tanımlayan tek bir gereksinimler kümesidir: aynı adımlar, aynı kararlar, aynı kenar durumlar ve aynı sonuçlar.\n\n## Paylaşılan gereksinimler için pratik yaklaşım\n\nZor olan widgetlar değil. Zor olan, UI biraz farklı göründüğünde bile her iki uygulamanın da aynı şekilde davranmasını sağlayacak tek bir ürün tanımını korumaktır.\n\nBaşlarken gereksinimleri iki kovaya ayırın:\n\n- Eşleşmeli: akış sırası, ana durumlar (yükleniyor/boş/hata), alan kuralları ve kullanıcıya görünen metin.\n- Platforma özgü olabilir: geçişler, kontrol stilleri ve küçük düzen seçimleri.\n\nHerkes kod yazmadan önce ortak kavramları düz bir dille tanımlayın. “Ekran”ın ne anlama geldiğinde, bir “route”un ne olduğunu (parametreler dahil, örn. userId), “form alanı”nın ne sayıldığını (tip, placeholder, zorunlu, klavye) ve bir “hata durumu”nun neleri içerdiğini (mesaj, vurgulama, ne zaman temizlenir) kararlaştırın. Bu tanımlar tartışmaları azaltır çünkü her iki ekip aynı hedefe yönelir.\n\nKabul kriterlerini outcome (sonuç) odaklı yazın, framework belirtmeyin. Örnek: “Kullanıcı Continue’a dokunduğunda butonu devre dışı bırakın, bir spinner gösterin ve istek bitene kadar çift gönderimi engelleyin.” Bu, her iki yığın için de nasıl uygulanacağına dair talimat vermeden nettir.\n\nKullanıcıların fark edeceği detaylar için tek bir doğruluk kaynağı tutun: metin (başlıklar, buton metinleri, yardımcı metin, hata mesajları), durum davranışı (yükleniyor/başarılı/boş/çevrimdışı/izin reddedildi), alan kuralları (zorunlu, minimum uzunluk, izin verilen karakterler, formatlama), ana olaylar (gönder/iptal/geri/yeniden dene/zaman aşımı) ve eğer izliyorsanız analiz isimleri.\n\nBasit bir örnek: bir kayıt formu için “Parola en az 8 karakter olmalı, kural ipucunu ilk blur’dan sonra gösterin ve kullanıcı yazarken hatayı temizleyin.” UI farklı görünebilir; davranış aynı olmalıdır.\n\n## Navigasyon: Aynı akışları zorlamadan eşleştirmek\n\nEkranları değil, kullanıcı yolculuğunu haritalayın. Akışı, bir görevi bitirmek için kullanıcının izlediği adımlar olarak yazın: “Gözat - Detayları aç - Düzenle - Onayla - Tamam.” Yol netleşince, ürünün gerektirdiklerini değiştirmeden her platform için en iyi gezinme stilini seçebilirsiniz.\n\

iOS kısa görevler için modal sayfaları ve net kapatmayı tercih eder. Android ise geri yığını ve sistem Geri düğmesini kullanmaya eğilimlidir. Kuralları baştan tanımladığınız sürece her ikisi de aynı akışı destekleyebilir.\n\nÜst düzey alanlar için sekmeler, derinlemesine gezinme için stack’ler, odaklanmış görevler için modallar/sheet’ler, deep link’ler ve yüksek riskli işlemler için onay adımları gibi yapı taşlarını karıştırabilirsiniz; yeter ki akış ve sonuçlar değişmesin.\n\nGereksinimleri tutarlı tutmak için route isimlerini her iki platformda da aynı şekilde adlandırın ve girdilerini uyumlu tutun. “orderDetails(orderId)” her yerde aynı şeyi ifade etmeli; ID eksik veya geçersiz olduğunda ne olduğu dahil.\n\nGeri davranışı ve kapatma kurallarını açıkça belirtin; çünkü sapma burada olur:\n\n- Her ekrandan Geri’nin ne yaptığı (kaydet, vazgeç, sormak)\n- Bir modalin kapatılıp kapatılamayacağı (ve kapatmanın ne anlama geldiği)\n- Hangi ekranların iki kez erişilebilir olmaması gerektiği (çift push’ları önleme)\n\n- Deep link’lerin kullanıcı girişli değilse nasıl davrandığı\n\nÖrnek: bir kayıt akışında iOS “Conditions”i sheet olarak sunarken Android bunu stack’e push edebilir. Bu, her ikisi de aynı sonucu (kabul/ret) döndürüp kayıt akışına aynı adımda devam ediyorsa sorun değildir.\n\n## Durum: Davranışı tutarlı tutmak\n\nEğer ekranlar benzer görünmesine rağmen uygulamalar “farklı” hissediyorsa, sebep genellikle durum yönetimidir. Uygulama detaylarını karşılaştırmadan önce, bir ekranın hangi durumlarda olabileceği ve her durumda kullanıcının ne yapmasına izin verildiği konusunda anlaşın.\n\nDurum planını düz metinle yazın ve tekrarlanabilir tutun:\n\n- Loading: bir spinner gösterin ve temel eylemleri devre dışı bırakın\n- Empty: eksik olanı açıklayın ve sonraki en iyi eylemi gösterin\n- Error: açık bir mesaj ve yeniden dene seçeneği gösterin\n- Success: veriyi gösterin ve eylemleri aktif tutun\n- Updating: bir yenileme çalışırken eski veriyi görünür tutun\n\nSonra durumun nerede tutulacağına karar verin. Ekran seviyesinde durum yerel UI detayları (sekme seçimi, odak) için uygundur. Tüm uygulamanın güvendiği şeyler (oturum açmış kullanıcı, feature flag’ler, önbelleklenmiş profil) için uygulama seviyesi durum daha iyidir. Anahtar şey tutarlılıktır: “çıkış yapılmış” Android’de uygulama seviyesi ama iOS’ta ekran seviyesi olarak ele alınırsa, bir platform eski veriyi göstermeye devam edebilir.\n\nYan etkilere (refresh, retry, submit, delete, optimistic update) açık olun. Başarı ve hata durumunda ne olacağını, ve bunun kullanıcıya ne şekilde gösterileceğini tanımlayın.\n\nÖrnek: “Orders” listesi.\n\nPull-to-refresh yapıldığında eski listeyi görünür tutar mısınız (Updating) yoksa tam sayfa Loading ile mi değiştirirsiniz? Başarısız yenilemede son iyi listeyi tutup küçük bir hata mı gösterirsiniz yoksa tam bir Error durumuna mı geçersiniz? Eğer iki ekip farklı yanıt verirse, ürün hızla tutarsız hissedecektir.\n\nSon olarak, önbellekleme ve sıfırlama kurallarında anlaşın. Hangi verinin yeniden kullanılmasının güvenli olduğunu (ör. son yüklenen liste) ve hangi verinin taze olması gerektiğini (ör. ödeme durumu) kararlaştırın. Ayrıca durumun ne zaman sıfırlanacağını tanımlayın: ekrandan ayrılma, hesap değiştirme veya başarılı gönderim sonrası gibi.\n\n## Formlar: Sapmaması gereken alan davranışı\n\nFormlar küçük farklılıkların destek taleplerine dönüşmeye başladığı yerlerdir. Görünüşte “yakın” bir kayıt ekranı bile farklı davranabilir ve kullanıcılar bunu çabuk fark eder.\n\nÖnce herhangi bir UI çatısına bağlı olmayan tek bir kanonik form spesifikasyonu ile başlayın. Bunu bir sözleşme gibi yazın: alan adları, tipler, varsayılanlar ve her alanın ne zaman görünür olduğu. Örnek: “Şirket adı sadece Hesap türü = İşletme ise görünür. Varsayılan Hesap türü = Bireysel. Ülke cihaz yerelinden alınır. Promo kodu opsiyoneldir.”\n\nSonra insanlar her iki platformda da aynı hissetmesini bekleyecek etkileşimleri tanımlayın. Bunları “standart davranış” olarak bırakmayın, çünkü “standart” farklılık gösterir.\n\n- Alan başına klavye türü\n- Otomatik doldurma ve kaydedilmiş kimlik bilgileri davranışı\n- Odak sırası ve Next/Return etiketleri\n- Gönderme kuralları (geçerli olana kadar devre dışı mı vs hatalarla izin mi verilir)\n- Yüklenme davranışı (neyin kilitlendiği, neyinin düzenlenebilir kaldığı)\n\nHataların nasıl göründüğünü (satır içi, özet veya her ikisi) ve ne zaman göründüğünü (odak kaybında, gönderimde veya ilk düzenlemeden sonra) belirleyin. Genel olarak iyi çalışan kural: kullanıcı gönderiyi denemeden hataları göstermeyin, sonra satır içi hataları yazarken güncel tutun.\n\nAsenkron doğrulamayı baştan planlayın. “Kullanıcı adı mevcut mu” gibi bir ağ çağrısı gerekiyorsa, yavaş veya başarısız isteklerde nasıl davranılacağını tanımlayın: “Kontrol ediliyor…” göster, yazmayı debounce et, eski yanıtları görmezden gel ve “kullanıcı adı alınmış” ile “ağ hatası, tekrar deneyin” arasındaki farkı ayır. Bunu yapmazsanız, uygulamalar kolayca sapar.\n\n## Doğrulama: Bir kural seti, iki uygulama\n\nDoğrulama pariteyi sessizce bozduğu yerdir. Bir uygulama girişi engeller, diğeri izin verir ve destek talepleri gelir. Çözüm sihirli bir kütüphane değil; herkesin anlayacağı bir dille yazılmış tek bir kurallar kümesi ve sonra bunun iki kez uygulanmasıdır.\n\nHer kuralı geliştirici olmayan birinin de test edebileceği şekilde cümle olarak yazın. Örnek: “Parola en az 12 karakter olmalı ve en az bir sayı içermelidir.” “Telefon numarası ülke kodu içermelidir.” “Doğum tarihi gerçek bir tarih olmalı ve kullanıcı 18+ olmalıdır.” Bu cümleler sizin doğruluk kaynağınız olur.\n\n### Telefon tarafında mı yoksa sunucu tarafında mı çalıştığını ayırın\n\nİstemci tarafı kontroller hızlı geri bildirim ve bariz hatalar için olmalı. Sunucu tarafı kontroller nihai kapıdır ve veri/güvenliği koruduğu için daha sıkı olmalıdır. Eğer istemci bir şeyi kabul edip sunucu reddederse, aynı mesajı gösterin ve aynı alanı vurgulayın ki kullanıcı kafası karışmasın.\n\nHata metnini ve tonunu bir kez tanımlayın, sonra her iki platformda yeniden kullanın. “Enter” mı yoksa “Please enter” mi dediğiniz, cümle biçimini kullanıp kullanmadığınız veya ne kadar spesifik olacağınız gibi ayrıntılar küçük bir metin uyumsuzluğu bile iki farklı ürün hissi yaratabilir.\n\nYerel dil ve formatlama kuralları yazılmalı, tahmin edilmemeli. Telefon numaraları, tarihler (zaman dilimi varsayımları dahil), para birimi ve isim/adresler için neyi kabul edeceğinizi ve nasıl göstereceğinizi yazın.\n\nBasit bir senaryo: kayıt formunuz Android’de "+44 7700 900123" boşluklarla kabul ederken iOS boşlukları reddediyorsa; kural "boşluklara izin verilir, saklarken sadece rakamlar tutulur" şeklinde yazılırsa, her iki uygulama kullanıcıyı aynı şekilde yönlendirip aynı temiz değeri kaydedebilir.\n\n## Adım adım: İnşa sırasında pariteyi nasıl korursunuz\n\nKodla başlamayın. Tarafsız bir şartname ile başlayın; her iki ekipin de doğruluk kaynağı olarak kabul ettiği bir belge olsun.\n\n### 1) Önce tarafsız bir şartname yazın\n\nHer akış için bir sayfa kullanın ve somut tutun: bir kullanıcı hikayesi, küçük bir durum tablosu ve alan kuralları.\n\n“Sign up” için Idle, Editing, Submitting, Success, Error gibi durumları tanımlayın. Her durumda kullanıcı ne görüyor ve uygulama ne yapıyor yazın. Boşluk kırpma, hataların ne zaman gösterildiği (odak kaybında vs gönderimde) ve sunucu e-postayı reddederse ne olacağı gibi ayrıntıları ekleyin.\n\n### 2) Parite kontrol listesi ile inşa edin\n\nKimse UI uygulamaya başlamadan önce, iOS ve Android’in geçmesi gereken ekran ekran kontrol listesi oluşturun: route’lar ve geri davranışı, ana olaylar ve sonuçlar, durum geçişleri ve yükleme davranışı, alan davranışı ve hata yönetimi.\n\n### 3) Aynı senaryoları her iki platformda test edin\n\nHer seferinde aynı seti çalıştırın: bir mutlu yol, sonra kenar durumlar (yavaş ağ, sunucu hatası, geçersiz giriş ve uygulama arka plandan döndüğünde).\n\n### 4) Farkları haftalık gözden geçirin\n\nKısa bir parite günlüğü tutun ki farklar kalıcı hale gelmesin: ne değişti, neden değişti, bunun bir gereksinim mi yoksa platform konvansiyonu mu ya da hata mı olduğu ve hangi tarafın güncellenmesi gerektiği (şartname, iOS, Android veya hepsi). Sapmayı erken yakalayın, düzeltmeler küçükken.\n\n## Ekiplerin yaptığı yaygın hatalar\n\niOS ve Android arasında pariteyi kaybetmenin en kolay yolu işi “aynı görünmesini sağlamak” olarak ele almaktır. Davranış eşleşmesi piksel eşleşmesinden daha önemlidir.\n\nYaygın bir tuzak, bir platformun UI detaylarını diğerine kopyalamaktır; bunun yerine ortak niyeti tanımlayın. İki ekran farklı görünebilir ama aynı şekilde yüklenip, hata verip ve iyileşiyorsa “aynı” sayılabilir.\n\nBir diğer tuzak platform beklentilerini yok saymaktır. Android kullanıcıları sistem Geri düğmesinin güvenilir biçimde çalışmasını bekler. iOS kullanıcıları çoğu yığında kaydırarak geri almayı bekler ve sistem sheet/diğer diyalogların doğal hissetmesini ister. Bu beklentilerle savaşırsanız, kullanıcılar uygulamayı suçlar.\n\nTekrarlayan hatalar:\n\n- Davranışı tanımlamak yerine UI’yı kopyalamak (durumlar, geçişler, boş/hata yönetimi)\n- Ekranları “özdeş” tutmak için yerel gezinme alışkanlıklarını kırmak\n- Hata yönetiminin sapmasına izin vermek (bir platform modalle engellerken diğeri sessizce yeniden dener)\n- İstemci ve sunucu doğrulamasını farklı yapmak, böylece kullanıcı çelişen mesajlar alır\n- Farklı varsayılanlar kullanmak (otomatik büyük harf, klavye türü, odak sırası) böylece formlar tutarsız hisseder\n\nHızlı bir örnek: iOS yazarken “Parola çok zayıf” uyarısı gösterirken Android göndermeye kadar beklerse, kullanıcı bir uygulamanın daha katı olduğunu varsayar. Kuralı ve zamanlamayı bir kez kararlaştırın, sonra iki yerde uygulayın.\n\n## Yayına almadan önce hızlı kontrol listesi\n\nYayın öncesinde sadece pariteye odaklanan bir tur yapın: “aynı görünüyor mu?” değil, “aynı anlama mı geliyor?”.\n\n- Akışlar ve girdiler aynı niyeti taşımalı: route’lar her iki platformda da aynı parametrelerle olmalı.\n- Her ekran temel durumları yönetmeli: yükleniyor, boş, hata ve aynı isteği tekrar eden bir yeniden dene ile kullanıcıyı aynı yere döndüren bir akış.\n- Formlar kenarlarda aynı davranmalı: zorunlu vs opsiyonel alanlar, boşluk kırpma, klavye türü, otomatik düzeltme ve Next/Done davranışı.\n- Doğrulama kuralları aynı girdi için aynı olmalı: reddedilen girdiler her iki platformda da aynı sebeple reddedilmeli ve aynı tonla ifade edilmeli.\n- Analitik (kullanılıyorsa) aynı anda tetiklenmeli: anı tanımlayın, UI eylemini değil.\n\nSapmayı hızlı yakalamak için bir kritik akışı (ör. kayıt) seçin ve onu kasıtlı hatalar yaparak 10 kez çalıştırın: alanları boş bırakın, geçersiz kod girin, çevrimdışıyken işlemi deneyin, telefonu döndürün, istek ortadayken arka plana alın. Sonuç farklıysa, gereksinimleriniz henüz yeterince paylaşılmamış demektir.\n\n## Örnek senaryo: her iki yığında da inşa edilmiş bir kayıt akışı\n\nAynı kayıt akışını iki kez inşa ettiğinizi düşünün: Android’de Kotlin, iOS’ta SwiftUI. Gereksinimler basit: E-posta ve Parola, sonra Doğrulama Kod ekranı, sonra Başarı.\n\nNavigasyon farklı görünebilir ama kullanıcının yapması gereken değişmez. Android’de ekranları push/pop yaparken e-postayı düzenlemek için pop edebilirsiniz. iOS’ta NavigationStack kullanıp kod adımını bir destination olarak sunabilirsiniz. Kural aynı kalır: aynı adımlar, aynı çıkış noktaları (Geri, Kodu Yeniden Gönder, E-postayı Değiştir) ve aynı hata yönetimi.\n\nDavranışı hizada tutmak için UI kodu yazılmadan önce ortak durumları düz metinle tanımlayın:\n\n- Idle: kullanıcı henüz gönderim yapmadı\n- Editing: kullanıcı alanları değiştiriyor\n- Submitting: istek devam ediyor, girdiler devre dışı\n- NeedsVerification: hesap oluşturuldu, kod bekleniyor\n- Verified: kod kabul edildi, ilerle\n- Error: mesaj göster, girilen veriyi koru\n\nSonra doğrulama kurallarını tam olarak sabitleyin, kontroller farklı olsa bile:\n\n- Email: zorunlu, kırpılacak, e-posta formatıyla eşleşmeli\n- Password: zorunlu, 8-64 karakter arası, en az 1 rakam, en az 1 harf\n- Verification code: zorunlu, tam 6 hane, sadece sayısal\n- Hata zamanlaması: bir kural seçin (gönderimde ya da odak kaybında) ve tutarlı kalın\n\nPlatforma özgü ince ayarlar sunumu değiştirirken anlamı değiştirmemelidir. Örneğin, iOS tek seferlik kod autofill kullanabilir, Android SMS kodu yakalama sunabilir. Bunu şöyle belgeleyin: ne değişiyor (giriş yöntemi), ne aynı kalıyor (6 hane gerekli, aynı hata metni) ve ikisinde de ne test edileceği (yeniden dene, yeniden gönderme, geri navigasyon, çevrimdışı hata).\n\n## Sonraki adımlar: Uygulama büyüdükçe gereksinimleri nasıl tutarlı tutarsınız\n\nİlk sürümden sonra sapma sessizce başlar: Android’de küçük bir düzeltme, iOS’ta hızlı bir fix ve kısa sürede eşleşmeyen davranışlarla uğraşırsınız. En basit önleme yöntemi, tutarlılığı haftalık iş akışının bir parçası yapmak, temizleme projesi haline getirmemektir.\n\n### Gereksinimleri yeniden kullanılabilir bir özellik spesifikasyonuna dönüştürün\n\nHer yeni özellik için tekrar kullandığınız kısa bir şablon oluşturun. Davranışa odaklı ve UI detaylarına bağlı olmayan bir içerik tutun ki her iki yığın aynı şekilde uygulayabilsin.\n\nİçerikte olsun: kullanıcı hedefi ve başarı kriterleri, ekranlar ve navigasyon olayları (geri davranışı dahil), durum kuralları (yükleniyor/boş/hata/yeniden dene/çevrimdışı), form kuralları (alan tipleri, maskeler, klavye türü, yardımcı metin) ve doğrulama kuralları (ne zaman çalışır, mesajlar, engelleyen vs uyarı).\n\nİyi bir şartname test notları gibi okunur. Bir ayrıntı değişirse, şartname önce değişir.\n\n### İşiniz bittiğinde parite incelemesini DoD’nize ekleyin\n\nPariteyi küçük, tekrarlanabilir bir adım yapın. Bir özellik tamamlandı olarak işaretlendiğinde, birini her iki platformda aynı akışı hızlıca çalıştırıp farkları not etmeye gönderin. Kısa bir kontrol listesi onaylatın.\n\nEğer tüm uygulamalar için veri modellerini ve iş kurallarını tanımlayacak tek bir yer isterseniz, AppMaster (appmaster.io) arka uç, web ve yerel mobil çıktılar dahil eksiksiz uygulamalar oluşturmak için tasarlanmıştır. Yine de parite kontrol listesine devam edin: davranış, durumlar ve metin hâlâ kasıtlı bir inceleme gerektirir.\n\nUzun vadeli hedef basit: gereksinimler değiştiğinde, her iki uygulama da aynı hafta içinde, aynı şekilde evrimleşsin, sürpriz olmasın.