Web ve yerel uygulamalar için platformlar arası UI paritesi kontrol listesi

UI paritesi ne demek (ve neden kolayca bozulur)\n\nUI paritesi, web uygulamanız ile yerel mobil uygulamanızın aynı ürün gibi hissettirmesidir. Piksel piksele aynı olması gerekmez; önemli olan aynı anlam, aynı beklentiler ve birisi dokunduğunda, yazdığında ya da beklediğinde aynı sonucu elde etmesidir.\n\nBasit bir test: bir kullanıcı bir ekranda bir şeyi öğrendiyse, bu öğrenme diğer platformdaki eşdeğer ekrana aktarılabilmelidir.\n\nİnsanları sıklıkla küçük farklar taktırır. Webde bir butonda “Kaydet” yazıp mobilde “Tamam” yazıyorsa kullanıcı duraklar. Bir platformda boşluklar daha sıkışıksa, ekran daha stresli hissedilir; özellikler aynı olsa bile. Mobilde bir liste satırına dokunmak detayları açarken webde bir onay kutusu gösteriyorsa kullanıcılar tahmin etmeye başlar, UI’ya güvenmezler.\n\nNe tam olarak eşleşmeli? Anlama ve güveni etkileyen her şey. Çoğu ürün için bu şunları kapsar:\n\n- Aynı eylemler için adlar ve etiketler, ayrıca bunların nerede göründüğü\n- Temel düzenler: gezinme, ana eylemler, kritik bilgiler\n- Yükleme, hata, devre dışı, boş sonuçlar gibi durumlar\n- Bileşen davranışı (dokunma, kaydırma, uzun basma, klavye, odak)\n- Mesajların tonu ve yapısı (ne oldu, sonraki adım nedir)\n\nNe adapte olabilir? Her platformda rahatlıkla ilgili olan şeyler. Yazı tipi render’ı, safe area’lar ve iOS geri jestleri veya Android sistem düğmeleri gibi native desenler farklı olabilir; önemli olan kullanıcıların yine aynı yere ulaşması ve neyin değiştiğini anlamasıdır.\n\nPratik bir hedef “tahmin edilebilir kalıplar”dır. Birisi webde bir profili güncellediğinde aynı alanları, aynı doğrulama kurallarını ve aynı başarı mesajını mobilde de tanıyabilmelidir. AppMaster gibi bir araçla hızlıca web UI ve yerel iOS/Android UI oluştursanız bile paritenin korunması için açık kurallar gerekir; aksi halde uygulamalar iki benzer ama farklı ürün olarak evrilir.\n\n## Ekranları karşılaştırmadan önce ortak bir temel belirleyin\n\nParite incelemeleri, her platform farklı bir “doğru” fikriyle ölçüldüğünde başarısız olur. Web ve yerel ekranları karşılaştırmadan önce “aynı” sayılanın ne olduğunu kararlaştırın ve yazın. Eğlenceli değildir ama saatler süren yeniden çalışmayı önler.\n\nBüyük bir spesifikasyona ihtiyacınız yok. Sizi en sık sürüklenen hatalardan alıkoyacak birkaç kural yeterlidir:\n\n- Tipografi: boyutlar, satır yüksekliği, metnin nasıl sarıldığı veya kısaltıldığı\n- Boşluk: padding, margin, grid adımları ve ne zaman kompakt vs konforlu düzen kullanılacağı\n- Renk rolleri: birincil, uyarı, sönük, kontrast minimumları ve koyu mod beklentileri\n- Bileşenler: hangi butonlar, inputlar, kartlar ve gezinme kalıplarının “onaylı” olduğu\n- Durumlar: yükleme, hata, boş, devre dışı ve başarı geri bildirimi\n\nArdından tek bir doğruluk kaynağı seçin. Bazı ekipler bir tasarım dosyası kullanır; bazıları tokenlar artı kısa bir yazılı rehber tercih eder. Önemli olan kuralların tek bir yerde yaşaması ve değişikliklerin kaydedilmesidir. AppMaster ile geliştiriyorsanız, web ve mobil UI oluşturucularda tokenları ve yeniden kullanılabilir bileşenleri hizalamak aynı seçimlerin her yerde görünmesini sağlar.\n\nSon olarak ritim ve sahipliği belirleyin. Pariteyi son dakika cilası gibi değil, test gibi değerlendirin. İncelemelerin ne zaman yapılacağını (sürümler öncesi ve paylaşılan bileşenlerde değişiklik sonrası), kimin onaylayacağını (tasarım görsellik için, ürün niyet için, QA köşe durumları ve cihaz kapsaması için) ve “tamam”ın ne demek olduğunu kararlaştırın (uyumsuzluklar düzeltilir veya nedenle kabul edilir).\n\nÖrnek: müşteri portalınız yeni bir “Faturalar” sayfası ekliyorsa, önceden tabloların mobilde nasıl daralacağını, boş durumların eksik faturaları nasıl açıklayacağını ve cihaz çevrimdışıyken “Şimdi öde” butonunun ne yapacağını karar verin. Bu temel ile inceleme hızlı bir sapma kontrolü olur; zevk tartışması değil.\n\n## Platformlar arasında tutarlı kalan tipografi kuralları\n\nTipografi, “neredeyse aynı” ifadesinin hızla “farklı bir ürün” hissine dönüştüğü yerdir. Stil adlarını basit tokenlarla (H1, H2, Body, Caption) adlandırın ve hem web hem native’de aynı şekilde uygulayın.\n\nPlatforma duyarlı font aileleri seçin. Her platform için karakter ve yoğunluk açısından benzer kişiliği karşılayan bir birincil aile kullanın, sonra geri dönüşler tanımlayın. Örneğin: iOS’te sistem fontu (SF), Android’de sistem fontu (Roboto) ve webde benzer görünen bir web fontu, güvenli bir fallback ile system-ui. Ama amaç harflerin birebir aynı olması değil; aynı ton ve okunabilirliktir.\n\nBir tip ölçeğini bir kez tanımlayın, sonra kimsenin yeni boyut icat etmeyeceği kadar küçük tutun. Örnek olarak:\n\n- H1: 28-32px, satır yüksekliği 1.2-1.3\n- H2: 20-24px, satır yüksekliği 1.25-1.35\n- Body: 16px, satır yüksekliği 1.4-1.6\n- Secondary: 14px, satır yüksekliği 1.4-1.6\n- Caption: 12-13px, satır yüksekliği 1.3-1.5\n\nMetin davranışı boyuttan en az onun kadar önemlidir. Uzun başlıklar ve öngörülemeyen veriler (isimler, adresler, bilet konuları) için nasıl davranılacağını kararlaştırın ki web ve mobil farklılaşmasın:\n\n- Başlıklar: maksimum 2 satır, sonra üç nokta ile kısalt\n- Tablo hücreleri: tek satır, kısalt, tam değeri dokununca/göstergeyle göster\n- Paragraflar: doğal olarak sarılsın, kelime ortasında kırılma olmasın\n- Sayılar: mümkünse tabüler numeraller kullanın, ondalıkları hizalayın\n\nHizalama sık görülen bir uyumsuzluktur. Çoğu metin için varsayılanı sola hizalama yapın; özellikle formlar ve listeler için. Ortalamayı sadece kısa, tek amaçlı anlar için (başarı mesajı veya boş durum başlığı gibi) kullanın.\n\nErişilebilirlik minimumlarını müzakere konusu yapmayın. Mobilde ana gövde metni için en az 16px hedefleyin, küçük boyutlarda çok ince font ağırlıklarından kaçının ve parlak ışıkta okunacak kadar yüksek kontrast tutun. AppMaster kullanıyorsanız bu paylaşılan design tokenları haline getirin ki aynı ekran hem webde hem native’de tutarlı okunur.\n\n## Boşluk ve düzen kuralları (mobil safe area dahil)\n\nBoşluk, “neredeyse aynı”ın “farklı hissetme”ye dönüştüğü yerdir. Web ekranınız ferah iken mobil ekran sıkışık geliyorsa kullanıcılar bunu fark eder; renkler ve fontlar aynı olsa bile.\n\nHer iki platformun da kullandığı tek bir boşluk ölçeği ile başlayın. Basit bir 4 tabanlı ölçek hem CSS hem native düzen ızgaralarına temiz uyar. Kuralları basit tutun: ilişkili öğeler daha küçük boşluk alır, ayrı bölümler daha büyük; bir varsayılan ekran dolgu alanı sabittir; istisnalar nadirdir ve dokümante edilir.\n\nTipik bir temel şöyle görünür:\n\n- Paylaşılan adımlar: 4, 8, 12, 16, 24\n- İlişkili boşluklar: 8-12\n- Bölüm boşlukları: 16-24\n- Varsayılan ekran dolgu alanı: 16\n\nSonra mobilde safe area’ları standardize edin. İçerik çentik, home göstergesi veya sistem çubuklarının altında olmamalı. Bir kural işe yarar: “Tüm birincil içerik safe area + temel dolguya uyar.” Alt bir bar varsa, içeriğin son satırının erişilebilir kalması için bar yüksekliğini içerik iç boşluğuna dahil edin.\n\nListe yoğunluğu da açıkça seçilmelidir. İki seçenek belirleyin ve adlandırın (kompakt ve konforlu). Satır yüksekliğini, dikey paddingi ve ayırıcı kullanımını tanımlayın. Aynı ekran türü için web ve mobilde aynı seçeneği uygulayın ki “Faturalar listesi” iki farklı tasarım gibi görünmesin.\n\nDokunma hedefleri boşluğun bir parçasıdır. Mobilde, düzen sıkışık olsa bile kontrollerin rahatça dokunulabilmesi gerekir. Sağlam bir minimum 44x44 hedef, eylemler arasında yeterli mesafe ile yanlış dokunuşu önler.\n\nWeb için, ana kırılma noktalarında duyarlı davranışı yazın: sütun sayısı, kenar çubuğu davranışı ve listelerin ne zaman kartlara dönüştüğü. Parite incelemesinde niyeti karşılaştırın, pikselleri değil. Web daha fazlasını aynı anda gösterebilir ama hiyerarşiyi değiştirmemeli veya ana eylemleri saklamamalı.\n\nAppMaster içinde geliştiriyorsanız, web ve mobil UI oluşturucularınızda aynı boşluk tokenlarını tutmak ekranların varsayılan olarak tutarlı başlamasına yardımcı olur.\n\n## Durumlar: yükleme, hata, devre dışı ve boş ekranlar\n\nTutarlılık genellikle mutlu yol yerine durumlarda bozulur. Durum UI’sını birinci sınıf tasarım olarak ele alın; aynı yapı, ton ve eylemler web ve native’de korunmalı.\n\nÖnce eylemlerle başlayın. Birincil eylemler belirgin ve tutarlı yerde olmalı (örneğin web dialoglarında sağ alt ve mobilde yapışkan alt buton). İkincil eylemler birincille rekabet etmemeli. Yıkıcı eylemler ekstra sürtünme gerektirir: açık bir etiket (“Projeyi sil”), onay adımı ve çıkış için güvenli bir yol (“İptal”).\n\nDevre dışı bırakılmış kontroller hata gibi hissettirmemeli. Bir eylem gerçekten çalışamıyorsa disabled kullanın ve kontrolün yanında nedenini açıklayın. Yardımcı metin, mobil kullanıcıların nadiren gördüğü tooltip’lerden daha iyidir. Kullanıcı düzeltebiliyorsa nasıl düzelteceğini söyleyin (“Ödeme yöntemi ekleyin ki Ödeme etkinleşsin”). Eğer aktifleştirilemiyorsa, ne zaman açılacağını belirtin (“Onaydan sonra kullanılabilir”).\n\n### Yükleme kuralları\n\nBağlam başına bir yükleme desenini seçin ve her iki platformda da tutarlı kalın:\n\n- Sayfa içeriği için yerinde gözüken iskeletler (skeleton) kullanın (tablolar, kartlar, listeler).\n- Kısa, engelleyici beklemeler için sadece spinner kullanın (giriş, form gönderimi).\n- Göstergiyi kullanıcının zaten baktığı yere koyun: dokundukları butonun içine veya değişen içerik alanına.\n- Ana öğeler için yer ayırarak layout sıçramalarını önleyin (başlık, birincil buton).\n\n### Hata ve boş durum kuralları\n\nHatalar spesifik, sakin ve kurtarılabilir olmalı. Mümkünse mesajı problemi takip eden alana yerleştirin (alan düzeyinde). Diğer durumda, bir banner veya dialog kullanın ve tek bir net kurtarma eylemi verin: “Tekrar deneyin”, “Bilgileri düzenle” veya “Destekle iletişime geçin.” Kullanıcıyı suçlamaktan kaçının.\n\nBoş durumlar tekrar edilebilir bir şablonla en iyi çalışır: kısa başlık, bir cümle rehberlik ve kullanıcının bir sonraki beklenen adımıyla eşleşen tek bir birincil eylem. Örnek: AppMaster ile oluşturulmuş bir müşteri portalında boş “Faturalar” sekmesi “Henüz fatura yok” diyebilir ve CTA olarak “Fatura oluştur” sunabilir; web ve mobilde aynı sözcükleri ve davranışı koruyun.\n\n## Bileşen davranışı kuralları (sadece görünüş değil)\n\nİki ekran benzer görünebilir ancak yine de farklı hissedebilir. Davranış kullanıcıların ilk fark ettiği şeydir: iki kere dokununca ne olur, hatalar nasıl görünür, “geri” beklendiği yere mi götürür? Parite kontrol listeniz sadece renk ve font değil, etkileşim kurallarını da kapsamalı.\n\n### Çekirdek bileşenler için etkileşim kurallarını tanımlayın\n\nHer bileşen için bir gerçek yazın, sonra sonucu değiştirmeden her platformun desenine eşleyin:\n\n- Butonlar: basılıp bırakma geri bildirimi (ripple, highlight, haptic), uzun basmanın bir etkisi olup olmadığı ve çift gönderimleri nasıl engellediğiniz (kısa süreli devre dışı bırakma veya isteğin dönmesini bekleme).\n- Formlar: doğrulamanın ne zaman gerçekleşeceğini kararlaştırın. Birçok ekip e-posta için blur’da doğrulama yapar, isteğe bağlı alanlar için hataları sadece gönderimde gösterir. Inline hata yerleşimini tutarlı tutun ve ilk hatalı alana odaklayın.\n- Listeler: birincil yenileme desenini seçin. Mobilde pull-to-refresh, webde yenileme butonu olabilir; ama ikisi de aynı veriyi güncellemeli ve kaydırma pozisyonunu tahmin edilebilir tutmalı. Ayrıca bir sayfalama yaklaşımı seçin: numaralandırılmış sayfalar, “Daha yükle” veya sonsuz kaydırma.\n- Gezinme: geri davranışı niyete göre eşleştirin, platform tuhaflıklarına göre değil. Derin linklerin nasıl davrandığını, modaların nasıl kapandığını ve hangi akışların tam ekran vs modal olduğunu tanımlayın.\n- Arama: temizleme butonunun ne yaptığı (sadece metni mi temizliyor yoksa sonuçları da mı), boş sonuç kopyasını tutarlı tutun ve filtre chiplerinin tek dokunuşla kaldırılabilir olmasını sağlayın.\n\n### Test edebileceğiniz küçük bir örnek\n\nFatura arayıp detaylara girip ödeme yapan bir müşteri portalını düşünün. Mobilde “Öde”ye hızlı çift dokunuş, spinner gösterip eylemi kilitlemezseniz iki ücret yaratabilir. Webde Enter tuşuna basmak bir alan hatalıyken bile formu gönderebilir.\n\nAppMaster ile inşa ediyorsanız, aynı kuralları Business Process mantığında belirleyin (tek bir uçuşta olan ödeme isteği) ve web ile mobil oluşturucularda UI davranışlarını eşleştirin.\n\nBir kez karar verin, sonra her sürümde doğrulayın: iki kere dokunma, hatalarla gönderim, yenileme, geri çıkma, aramayı temizleme testi yapın.\n\n## Adım adım: bir parite incelemesi nasıl yapılır\n\nParite incelemeleri tekrarlanabilir bir ritüel olarak en iyi sonucu verir. Amaç, kullanıcılar yapmadan önce “aynı özellik, farklı deneyim”i yakalamaktır.\n\nÖnce yan yana karşılaştırma seti seçin: oturum açma, arama, bir detay görünümü, form gönderimi ve ayarlar. Aynı test verilerini hem web hem mobilde kullanın ki davranışı değil içeriği karşılaştırıyor olun.\n\nİncelemeyi tutarlı bir sırayla yürütün:\n\n- Etiketlerin, eylemlerin ve çıktıların eşleştiğini doğrulayın.\n- Durumları kontrol edin: yükleme, hata, boş, devre dışı, başarı.\n- Davranışı kontrol edin: dokunuşlar, odak, klavye, kaydırma, onaylar.\n- Sonra boşluk, tipografi ve görsel cilayı kontrol edin.\n- Düzeltmelerden sonra en az bir “altın yol” akışını tekrar test edin.\n\nBir skor kartı kararları hızlandırır. Her ekran veya bileşen için: eşleşme (niyet ve davranış aynı, sadece platform-native farklar), kabul edilebilir fark (farklı UI, aynı sonuç, dokümante edilmiş) veya uyumsuzluk (anlam değişiyor, ek adımlar ekleniyor veya kural bozuluyor) olarak işaretleyin.\n\nUyumsuzluk kaydettiğinizde iki ekran görüntüsü, hangi kuralın bozulduğunu (ör: “birincil eylem yerleşimi” veya “boş durum tonu”) ve bir cümleyle kullanıcı etkisini ekleyin. AppMaster kullanıyorsanız, sorunun UI oluşturucu ayarı mı, paylaşılan bileşen kuralı mı yoksa süreç mi olduğunu not edin.\n\nKuralları düzeltmeye istekli olun. Aynı “uyumsuzluk” tekrar ediyorsa rehber muhtemelen belirsiz veya gerçekçi değildir. Ekranları tek tek yamamak yerine sistemi güncelleyin.\n\n## Tutarsızlığa yol açan yaygın tuzaklar\n\nÇoğu parite sorunu büyük kararlar değil; uygulama, hata düzeltmeleri ve son dakika değişiklikleri sırasında kaydırılan küçük değişikliklerdir. Bir kontrol listesi yardımcı olur ama sürüklenmenin nereden başladığını bilmeniz gerekir.\n\nMetin sürüklenmesi klasik bir örnek. Web “Değişiklikleri kaydet” derken mobil “Güncelle” diyebilir, ama işlev aynıysa kullanıcılar bunu sürtünme olarak algılar; özellikle şifre sıfırlama, profil düzenleme ve ödeme onaylarında.\n\nBoşluk sürüklenmesi daha sessizdir. Birisi bir ekranı düzeltmek için 6px padding ekler ve bu tekil değişiklik yayılır. Birkaç sprint sonra web düzen ferahken mobil sıkışık hissedebilir, halbuki her ikisi de aynı tasarımı kullanıyor olması gerekir.\n\nDurum boşlukları en fazla kafa karışıklığına yol açar. Web temiz boş durumlar ve hata mesajları gösterirken mobilde boş bir liste, sonsuz spinner veya sessiz bir hata görülebilir. Bu genellikle durumların farklı yerlerde ele alınmasından kaynaklanır (webde frontend, mobilde native view mantığı).\n\nİncelemelerde şunlara dikkat edin:\n\n- Aynı eylem için farklı etiketler veya aynı mesaj için farklı ton\n- Boşluk ölçeği dışında rastgele eklenen padding veya marginler\n- Bir platformda eksik yükleme, hata, boş veya devre dışı durumlar\n- Platform varsayıllarının kurallar olmadan sızması (togglelar, tarih seçiciler, uyarılar)\n- Erişilebilirlik gerilemeleri: kafa karıştırıcı web odak sırası veya mobilde çok küçük hedefler\n\nBasit bir örnek: müşteri portalında web “Henüz fatura yok” diye bir ipucu ve ödeme yöntemi ekleme butonu gösterirken mobil sadece boş bir liste gösteriyorsa kullanıcı uygulamanın bozuk olduğunu düşünebilir. Düzeltme görsel ciladan ziyade tam olarak hangi boş durum içeriğinin ve beklenen buton davranışının ortak olduğu konusunda anlaşmaktır ve sonra bunu her yerde uygulamaktır.\n\nAppMaster ile hem web hem native inşa etseniz bile parite yine de metin, boşluk tokenları ve durum işleme için kurallar gerektirir ki her ekran kendi istisnası haline gelmesin.\n\n## Hızlı parite kontrolü (sürüm öncesi 5 dakikalık geçiş)\n\nHızlı bir parite kontrolü kullanıcıların ilk fark edeceği şeyleri yakalar: yanlış görünen metin, farklı davranan butonlar ve bitmemiş hissi veren ekranlar.\n\nBir referans ekranı webde ve telefonda açık tutun. En çok kullanılan akışı seçin (giriş, arama, ödeme, istek formu) ve hızlıca tarayın:\n\n- Tipografi ölçeği: Başlıklar, gövde metni ve altyazılar aynı boyut adımlarını ve ağırlık kurallarını takip ediyor mu? Satır yüksekliğini özellikle küçük telefonlarda kontrol edin.\n- Boşluk ve dokunma konforu: Kartlar, formlar ve dialoglar çevresindeki padding tutarlı mı? Mobilde içerik çentik veya home göstergesine yakın sıkışmış mı?\n- Ekran durumları: Ana ekranlar yükleme, hata, boş ve devre dışı durumları net gösteriyor mu? Kullanıcı her zaman ne olduğunu ve ne yapacağını bilmeli.\n- Bileşen davranışı: Birincil eylemler aynı şekilde gönderiyor mu, aynı geri bildirimi gösteriyor mu ve çift tıklama/dokunmayı engelliyor mu? Geri davranışı girilmiş verileri beklenmedik şekilde kaybetmemeli.\n- Metin anlamı: Etiketler ve hata mesajları anlam olarak eşleşmeli, sadece kelime olarak aynı olmamalı. Web “Fatura adresi” derken mobil “Ödeme bilgisi” dememeli, eğer gerçekten farklı değillerse.\n\nBir şey başarısız olursa şu soruyu sorun: “Kullanıcı farklı bir ürüne geçtiğini hisseder mi?” En büyük uyumsuzluğu önce düzeltin.\n\nÖrnek: AppMaster ile oluşturulmuş bir müşteri portalında aynı form webde ve mobilde olsa da mobil yavaş ağda “Gönder”e iki kere dokunmaya izin veriyor olabilir. Açık bir yükleme durumu ekleyip butonu isteğin bitimine kadar devre dışı bırakarak davranışı eşleştirin ve yinelemeleri önleyin.\n\n## Örnek: müşteri portalını web ve mobilde tutarlı hâle getirmek\n\nBasit bir müşteri portalı düşünün: Giriş, Profil ve Siparişler listesi. Web uygulaması dizüstü bilgisayarda destek personeli tarafından kullanılıyor. Mobil uygulama ise müşteriler tarafından hareket halindeyken kullanılıyor. Aynı akışı ve anlamı her yerde istiyorsunuz, UI detayları farklı olsa bile.\n\nSıklıkla ortaya çıkan bir uyumsuzluk: müşteri henüz siparişe sahip değilse webde Siparişler sayfası bir ikon, kısa bir mesaj ve “Ürünleri keşfet” gibi bir birincil buton içeren dostça bir boş durum gösterebilir. Mobilde aynı ekran bazen rehbersiz boş bir liste olarak kalır ve kullanıcı uygulamanın bozuk olduğunu düşünür.\n\nDüzeltme: pariteyi görsel tahmin değil, kurallar olarak ele almak. Kurallar şöyle uygulanır:\n\n- Boş durum şablonu: Her iki platformda da aynı yapı ve kopya: başlık (“Henüz sipariş yok”), bir yardımcı cümle ve tek bir net eylem. İkincil eylemler bağlantı olarak bırakılmalı, buton değil.\n- Buton hiyerarşisi: Her ekranda bir birincil eylem. Hem web hem mobilde “Ürünleri keşfet” birincil. “Destekle iletişime geç” ikincil ve daha hafif görünür.\n- Boşluk ölçeği: Aynı boşluk adımlarını kullanın (ör: 8, 16, 24) ki düzen ilişkili gelsin. Mobil dokunma hedefleri etrafında biraz daha dikey padding ekleyebilir ama yine de aynı ölçeği kullanır.\n\nDavranış paritenin en çok bozulduğu yerdir; bu yüzden açıkça tanımlayın:\n\n- Yenileme: Mobil pull-to-refresh destekler; web yenileme ikonu veya “Yenile” butonu kullanır. Her ikisi de aynı yükleme durumunu tetikler ve mümkünse kaydırma pozisyonunu korur.\n- Sayfalandırma: Web “Daha yükle” ve sayfa boyutu kontrolleri gösterebilir; mobil sonsuz kaydırma veya “Daha yükle” kullanır. Yeni öğeler yerine eklenmeli, değiştirilmemeli.\n- Hatalar: Siparişler yüklenemiyorsa her iki platform da aynı mesajı ve yeniden dene eylemini göstermeli. Bir platformda toast ile, diğerinde tam ekran ile gizlemeyin.\n\nSonuç önemlidir: kullanıcı ne olduğunu ve bir sonraki adımı anlar. UI her platformun gereksinimlerine (safe area, klavye davranışı, hover vs dokunma) saygı duyar ama portal tek bir tutarlı ürün gibi hissedilir.\n\n## Sonraki adımlar: ürün büyüdükçe pariteyi korumak\n\nParite bir kez doğru yapmak kolaydır; ürün hareket etmeye başladıktan sonra kaybetmek kolaydır. Yeni özellikler, hızlı düzeltmeler ve platforma özel istekler hızla toplanır. Amaç "tutarlı kalmak"ı varsayılan hâle getirmektir.\n\nKontrol listenizi yaşayan bir belge olarak ele alın. Her sürümden sonra ne değiştiğini ve sizi neyin şaşırttığını kaydedin. Eğer bir ekran mobilde farklı bir boş durumla yayınlandıysa bunu kural veya örnek hâline getirin ki tekrar olmasın.\n\n### Tutarlılığı varsayılan yol hâline getirin\n\nNe kadar çok şeyi yeniden kullanabilirseniz, o kadar az yeniden karar vermeniz gerekir. Liste ekranları, detay ekranları, formlar ve “sonuç yok” görünümleri gibi ortak kalıplar için küçük bir yeniden kullanılabilir bileşen ve sayfa şablonu seti oluşturun. Ortak kopya (buton etiketleri, boş durum mesajları) için tek bir doğruluk kaynağı tutarak web ve native’nin yavaşça farklı tonlar geliştirmesini önleyin.\n\nBasit bir rutin ekipleri dürüst tutmaya yardımcı olur:\n\n- Değişiklik notlarında parite kurallarını güncelleyin, haftalar sonra değil.\n- Özellik kabul kriterlerine parite maddeleri ekleyin (durumlar, boşluk, davranış).\n- PR veya QA onayında her iki platformdan ekran görüntüleri veya kısa kayıtlar isteyin.\n- “Onaylı farkları” takip edin ki istisnalar kasıtlı ve dokümante edilmiş olsun.\n\n### Pariteyi inşa etme sürecine entegre edin\n\nHangi araçları kullanırsanız kullanın, paylaşılan tokenlar, paylaşılan şablonlar ve paylaşılan davranış kuralları hedefleyin. AppMaster kullanıyorsanız tokenlarınızı ve yeniden kullanılabilir UI kalıplarınızı web ve mobil oluşturucular arasında ortak varlıklar olarak tutmak ve kritik davranışı Business Process Editor’da merkezi hale getirmek faydalıdır. Böylece parite, son dakika incelemelerle zorlanmak yerine ürünün nasıl inşa edildiğiyle desteklenir.\n\nBunu sürdürebilir kılmak için yaklaşan bir özelliği seçin ve tanımına parite kontrollerini kabul kriteri olarak ekleyin. "Tutarlı tut"mayı doğrulanabilir işlere dönüştürmenin kolay bir yoludur.