iOS ve Android tasarım farkları

Kısaca

Bir uygulamayı iki platforma yaparken iki ayrı kural kitabıyla çalışırsınız. iOS için Apple'ın Human Interface Guidelines'ı (HIG), Android için Google'ın Material Design 3'ü (M3) var.

Okunur yazı ve rahat dokunma hedefi gibi temel konularda ikisi aynı yere varır. Asıl ayrılık, kullanıcının elinin alıştığı yerlerde çıkar. Geri nerede durur, ana eylem nereye konur?

İki kaynağın güncel sayfalarını açıp karşılaştırdım. Tarihleri kaynaktaki gibi verdim, çünkü iki rehber de sık değişiyor.

Aynı ekran, iki platform

Aşağıda kurgusal bir harcama uygulamasının aynı ekranı var. Solda iOS hali, sağda Android hali duruyor. Telefonda ikisi alt alta dizilir.

"Farkları göster" düğmesine basın. İki ekranda aynı öğeye aynı numara konur ve altta her farkın açıklaması açılır.

Gezinme: sekme çubuğu ve gezinme çubuğu

İki platformda da ana bölümler ekranın altında durur. Adları ve kuralları farklıdır.

Apple sekme çubuğunu gezinme için kullanmanızı, eylem için kullanmamanızı ister. Ekrandaki içeriğe bir işlem yapacaksanız HIG araç çubuğunu önerir. HIG'e göre iOS'ta sekme çubuğu ekranın altında, içeriğin üstünde yüzer.

Apple iPhone için kesin bir sekme sayısı vermiyor. Yalnızca az sekmede gezinmenin genelde daha kolay olduğunu yazıyor. Taşan sekmeleri toplayan "Daha fazla" (More) sekmesinden de kaçınmanızı söylüyor.

Material 3'te karşılığı gezinme çubuğudur (navigation bar). M3 bu çubuğun üç ila beş hedefe erişim verdiğini yazar.

Üçten az hedef varsa M3 sekmeleri (tabs) önerir. Beşten fazla hedef varsa gezinme çubuğunu hiç kullanmamanızı söyler.

İki rehber de kısa etiket ister. HIG mümkünse tek kelime, M3 bir ya da iki kelime der. M3'e göre etiket kaldırılmaz, kırpılmaz, sığsın diye küçültülmez de.

Türkçe etiketiniz uzun çıkıyorsa bu kural sizi daha kısa bir kelime aramaya iter.

Hamburger menü ve çekmece

Android uygulamalarında soldan açılan gezinme çekmecesine (navigation drawer) sık rastlarsınız. M3'ün güncel çekmece sayfası, M3 Expressive güncellemesiyle çekmecenin artık önerilmediğini yazıyor. Yerine genişletilmiş gezinme rayı (expanded navigation rail) öneriliyor.

M3'ün gezinme çubuğu sayfası bu güncellemeyi Mayıs 2025 olarak tarihliyor. Aynı sayfaya göre temel gezinme çubuğu da yerini daha kısa, esnek bir çubuğa bıraktı.

Bu çubuğun Material 2'deki adı "bottom navigation" idi. M3'te navigation bar diye geçiyor, eski bir Android tasarımına bakarken bunu aklınızda tutun.

Gezinmenin genel kalıplarını mobil uygulama tasarımı rehberinde anlattım. Burada yalnızca iki platformun ayrıldığı yerleri topluyorum.

Geri davranışı: sistem geri ve kenardan kaydırma

Bence iki platform arasındaki en önemli fark burada. Kullanıcı geri dönmek için düşünmez, eli alıştığı hareketi yapar.

iOS'ta geri bir düğmedir. HIG'in araç çubuğu sayfası standart geri düğmesini kullanmanızı ve üstüne "Geri" yazmamanızı söyler. Bu düğme kullanıcıyı bilgi hiyerarşisinde bir adım geri götürür.

Kenardan kaydırma bunun kısayoludur. HIG'in hareketler sayfasına göre birçok uygulama ekranın kenarından kaydırma gibi bir kısayol hareketi sunar ve geri düğmesini de korur. Yani hareket düğmenin yerini almaz.

Android'de geri bir sistem hareketidir. M3'ün hareketler sayfasına göre kullanıcı bazı bileşenlerde sağa ya da sola kaydırarak önceki hedefe döner. M3 bu harekete tahmine dayalı geri (predictive back) diyor.

Kullanıcı kaydırmayı bitirmeden karar verebilir. Ya önceki görünüme geçer ya da bulunduğu ekranda kalır. M3'te üst uygulama çubuğunun soldaki düğmesi ise ya bir geri okudur ya da menü simgesidir.

Benim pratik sonucum şu: Android'de ekranın kenarlarına kendi yatay kaydırma hareketimi koymam. iOS tarafında HIG de sistem arayüzüne erişen hareketlerle çakışan özel hareketlerden kaçınmanızı söyler.

Birincil eylem: FAB ve araç çubuğu

Android'in en tanıdık öğesi yüzen eylem düğmesidir (floating action button, FAB). M3'e göre FAB ekrandaki en önemli eylem için kullanılır ve tüm içeriğin önünde durur.

M3 FAB için birkaç net kural koyar:

• Bir ekranda birden fazla FAB olmaz.
• Arşivleme, çöpe atma, uyarı ya da hata gibi küçük veya yıkıcı eylemler için kullanılmaz.
• Telefon boyutundaki ekranlarda genelde sağ alt köşede, gezinme çubuğunun üstünde durur.
• Çoğu durum için orta boy FAB önerilir. Küçük FAB artık önerilmiyor.

Açtığım HIG sayfalarında FAB'a karşılık gelen bir bileşen yok. HIG'in araç çubuğu sayfasına göre "Bitti" ya da "Gönder" gibi tek bir birincil eylem, araç çubuğunun sondaki (sağ) tarafına konur.

Android tasarımını iOS'a taşırken sağ alttaki yuvarlak düğmeyi olduğu gibi bırakmak sık gördüğüm bir hatadır. Bence o düğme iOS ekranında Android'den unutulmuş gibi durur. Ana eylemi sağ üste ya da içeriğin içine taşımak daha doğal olur.

Sağ alt köşenin başparmağa neden yakın olduğunu başparmak bölgesi sayfasında anlattım.

Uyarı ve diyalog

İki rehber de diyaloğu az kullanmanızı ister. Ayrıldıkları yer düğmelerin sayısı ve sırasıdır.

HIG'e göre bir uyarıda başlık, isteğe bağlı bir metin ve en fazla üç düğme olur. Başlık iki satırı geçmemeli, düğme adı bir ya da iki kelime olmalı.

Düğmeler yan yana dizilince Vazgeç genelde başta (solda) durur. Alt alta dizilince genelde en alta iner.

Apple ayrıca sık yapılan ve geri alınabilen işlemler için uyarı göstermemenizi söyler. Uygulama açılırken uyarı göstermek de önerilmez.

M3'te diyalogda en fazla iki eylem olur. Düğmeler diyaloğun sağ kenarına toplanır ve onay düğmesi kenara en yakın olandır. Vazgeç gibi kapatma eylemi onun soluna gelir.

M3 başlıkta "Emin misiniz?" gibi belirsiz sorulardan kaçınmanızı da söyler. Demodaki "Harcama silinsin mi?" başlığı bu yüzden ne olacağını açıkça söylüyor.

Düşük ya da orta öncelikli bir bilgi için M3 diyalog yerine snackbar önerir. Diyaloğun ne zaman gerektiğini modal ve popup kalıbı sayfasında ayrıca anlattım.

Tipografi: SF Pro ve Roboto

HIG'e göre iOS ve iPadOS'un sistem yazı tipi SF Pro'dur. Apple bu platformlarda varsayılan yazı boyutunu 17 pt, en küçük boyutu 11 pt olarak verir.

iOS'ta yazı boyutu kullanıcının elindedir. Dynamic Type adlı sistem özelliğiyle kişi cihazdaki yazıyı büyütüp küçültebilir. HIG, sistem yazı tipini metin stilleriyle kullanırsanız bu desteğin geldiğini yazar.

M3'e göre Roboto hem Android'in hem de M3 tip ölçeğinin varsayılan yazı tipidir. Roboto 3.300'den fazla glif içerir. Desteklenmeyen bir dilde Noto Sans yedek yazı tipi olarak devreye girer.

İki platformda tek bir marka yazı tipi de kullanabilirsiniz. Böyle bir seçimde önce Türkçe karakterleri denerim: ğ, ı, İ, ş. Sonra en büyük yazı boyutunda ekran dağılıyor mu, ona bakarım.

Dokunma hedefi: 44 pt ve 48 dp

Burada fark küçük. HIG iOS'ta varsayılan kontrol boyutunu 44 × 44 pt, en küçüğünü 28 × 28 pt olarak verir. M3 dokunma hedefinin en az 48 × 48 dp olmasını önerir ve bunun yaklaşık 9 mm ettiğini yazar.

M3'ün aynı sayfası iOS'un 44'ü önerdiğini de not eder. Birimler farklı olsa da iki rehber aynı parmak için konuşuyor.

Ölçülerin ayrıntısını ve WCAG tarafını dokunma alanı sayfasında anlattım, burada tekrar etmiyorum.

İzin ekranları

iOS'ta konum ya da mikrofon gibi bir izni sistem penceresi ister. Tasarımcının elinde kalan, iznin ne zaman ve hangi cümleyle istendiğidir.

HIG'in gizlilik sayfası net. İzni, kullanıcı o izni gerektiren özelliği gerçekten kullandığında isteyin. Açılışta izin istemeyin, tek istisna uygulamanın o izin olmadan hiç çalışmamasıdır.

Apple, izin penceresindeki açıklama cümlesi için de örnek verir. Kısa, tam, etken bir cümle ister. "Daha iyi bir deneyim için mikrofon erişimi gerekir" gibi belirsiz bir gerekçeyi kötü örnek olarak gösterir.

Sistem penceresinden önce kendi ekranınızı gösterecekseniz HIG tek düğme ister. Düğmenin adı "Devam" ya da "İleri" gibi olmalı ve sistem penceresini açmalı.

Bu ekranda "İzin ver" yazmayın. Apple bunu bir yönlendirme (manipülasyon) biçimi sayar, çünkü kullanıcı farkında olmadan sistem penceresindeki izin düğmesine basabilir.

Açtığım Material 3 sayfalarında izin isteğine ayrılmış bir bölüm bulamadım. Android'de de aynı zamanlama kuralını uygularım: izin, ihtiyacın doğduğu anda ve neden gerektiğini söyleyen bir cümleyle istenir.

Tek tasarım mı, iki tasarım mı?

İki uygulamayı tek bir kod tabanından çıkarsanız bile tek bir tasarımı iki platformda aynen kullanmanızı önermem.

Ben ekrandaki öğeleri iki gruba ayırırım. Markanın göründüğü yerler ortak kalabilir: renkler, kartlar, illüstrasyonlar, içerik. Kullanıcının elinin alışkanlıkla hareket ettiği yerler platforma göre ayrılır: geri, ana gezinme, diyalog düğmeleri ve ana eylem.

Sebebi basit: kullanıcı başka uygulamalarda öğrendiğini sizinkinde de bekler. Bu fikrin adı Jakob yasası. iPhone kullanıcısı geri hareketini başka iOS uygulamalarında öğrendi, sizinkinde de aynısını dener.

Ekran okuyucu ve yazı büyütme gibi erişilebilirlik ayarlarını da iki telefonda ayrı ayrı denerim. Bunu mobil uygulama erişilebilirliği rehberinde ayrıca ele aldım.

Benim notum

Sık gördüğüm durum şu: ekip tasarımı kendi telefonunun alışkanlığıyla çizer, diğer platform sonradan "uyarlanır". Uyarlanan kısım çoğu zaman yalnızca renk ve ikon olur, geri ve diyalog düğmeleri yerinde kalır.

Bu yüzden iki platformlu bir uygulamada ilk baktığım şey, aynı akışın iki telefonda yan yana kaydı. Yukarıdaki demodaki beş nokta, kontrol listemin ilk satırlarıdır.

İki platformu birlikte tasarlayıp koda dökmek isterseniz Tasarla & Yayınla Sprinti tam bunun için var. 2 hafta sürüyor, tasarım ve kod birlikte reponuza geliyor.