App Store ve Google Play'in Tasarıma Etkisi: 2026 Gereksinimleri

Mobil uygulama tasarımı yalnız kullanıcıya değil, iki mağazanın inceleme kurallarına da cevap verir. Apple ve Google'ın kuralları bazen bir ekranın var olmasını zorunlu kılar (hesap silme), bazen bir tasarım kalıbını yasaklar (manipülatif izin ekranları), bazen de bir SDK ya da API düzeyi şartıyla bütün arayüzün görünümünü değiştirir. Bu yazı, 2 Ekim 2026 itibarıyla geçerli olan ve tasarımı doğrudan etkileyen gereksinimleri resmi kaynaklarıyla birlikte topluyor.

2026 itibarıyla tarih çizelgesi

Hesap, giriş ve hesap silme ekranları

Girişsiz kullanım. Apple'ın yönergelerine göre hesaba dayalı önemli özellikleri olmayan uygulamalar girişsiz kullanılabilmeli; uygulamalar, temel işlevle doğrudan ilgili olmadıkça ya da yasa gerektirmedikçe çalışmak için kişisel bilgi girilmesini şart koşamaz 1. Bu, ilk açılışı bir giriş duvarıyla başlatan tasarımları doğrudan etkiler; ayrıntısı için onboarding tasarımı yazısına bakabilirsiniz.

Hesap silme. Uygulama hesap oluşturmayı destekliyorsa hesap silme de uygulama içinden sunulmalı 1. Google Play'in kuralı iki parçalı: uygulama içinde hesabı ve ilişkili verileri silme yolu ve kullanıcının silme talebinde bulunabileceği bir web bağlantısı 7. Google, uygulama içi yolun sezgisel ve belirgin olmasını, örneğin hesap ayarları ya da benzeri bir bölümde yer almasını; web bağlantısının hatasız açılmasını, silme talebini sayfada belirgin göstermesini ve uygulama ya da geliştirici adını anmasını istiyor 7. Bazı özellikler hesapsız kullanılabilse bile uygulamanın herhangi bir yerinde hesap oluşturulabiliyorsa silme seçeneği gerekiyor 7.

Tasarım karşılığı: hesap ayarlarında açıkça adlandırılmış bir "Hesabı sil" satırı, sonuçları anlatan bir onay ekranı (hangi veriler silinir, abonelik varsa ne olur, işlem ne kadar sürer), gerekiyorsa kimlik doğrulama adımı ve işlem sonrası bilgilendirme. Silmeyi bir müşteri hizmetleri formunun arkasına saklamak hem mağaza kuralları hem de karanlık örüntüler açısından risklidir.

Giriş seçenekleri. Apple'ın 4.8 maddesi, birincil hesabı kurmak ya da doğrulamak için üçüncü taraf ya da sosyal giriş hizmeti kullanan uygulamaların eşdeğer bir seçenek olarak başka bir giriş hizmeti daha sunmasını istiyor. Bu hizmet; veri toplamayı kullanıcının adı ve e-posta adresiyle sınırlamalı, kullanıcının e-postasını gizli tutmasına izin vermeli ve uygulamadaki etkileşimleri izinsiz reklam amacıyla toplamamalı 1. Uygulama yalnız şirketin kendi hesap sistemini kullanıyorsa ya da mevcut bir eğitim veya kurumsal hesapla giriş gerektiren bir eğitim, kurumsal veya iş uygulamasıysa bu şart aranmıyor 1. Giriş ekranında bu seçeneklerin eşit ağırlıkta ve platform kurallarına uygun butonlarla sunulması gerekir.

İzin ve gizlilik: ekranlar ile beyanlar tutarlı olmalı

Apple'ın gizlilik kuralları, izin akışlarını tasarlarken doğrudan sınır çizer. Yönergelere göre uygulamalar kullanıcının izin ayarlarına saygı göstermeli, gereksiz veri erişimine rıza vermesi için kullanıcıyı manipüle etmeye, kandırmaya ya da zorlamaya çalışmamalı; mümkünse izin vermeyen kullanıcıya alternatif sunmalıdır. Apple'ın örneği açık: konum paylaşmayı reddeden kullanıcıya adresi elle girme imkânı tanıyın 1. Veri en aza indirme ilkesi gereği, mümkün olduğunda Fotoğraflar ya da Kişiler'e tam erişim istemek yerine sistem seçicisi ya da paylaşım sayfası kullanılmalı 1.

Mağaza tarafında her iki platform da gizlilik beyanı istiyor. Apple, gizlilik politikasının hem App Store Connect'te hem uygulama içinde kolay erişilebilir olmasını ve gizlilik bilgileri dahil tüm meta verilerin uygulamanın gerçek deneyimini doğru yansıtmasını istiyor 1. Google Play'de geliştiricilerin Data safety formundaki veri silme sorularını da yanıtlaması gerekiyor 7.

Tasarım ekibi için anlamı şu: hangi ekranın hangi veriyi, hangi amaçla istediğini gösteren bir veri envanteri, mağaza beyanlarının da kaynağıdır. Bir form alanı eklendiğinde ya da bir analitik aracı eklendiğinde beyanların da güncellenmesi gerekir.

iOS 26 ve Liquid Glass

Apple'ın iOS 26 ile getirdiği Liquid Glass, camın optik özelliklerini akışkanlık hissiyle birleştiren dinamik bir malzeme; kontroller ve gezinme öğeleri için ayrı bir işlevsel katman oluşturuyor 3. SwiftUI, UIKit ve AppKit'in standart bileşenleri, uygulama en güncel SDK ile derlendiğinde bu görünümü otomatik alıyor 3. 28 Nisan 2026'dan beri App Store'a yüklenen uygulamaların Xcode 26 ve iOS 26 SDK ile derlenmesi gerektiği için 2, güncelleme gönderen her iOS uygulaması bu değişiklikle yüz yüze.

Apple'ın uyarlama rehberinden tasarıma doğrudan yansıyan noktalar 3:

1. Özel arka planları azaltın. Sekme çubuğu, araç çubuğu gibi gezinme öğelerindeki özel arka planlar Liquid Glass'ı ve kaydırma kenarı efektini bozabilir; sistemin arka planı belirlemesine izin verin.
2. Efekti az kullanın. Liquid Glass'ı birçok özel kontrole uygulamak içerikten dikkati dağıtır; yalnız en önemli işlevsel öğelerle sınırlayın.
3. Erişilebilirlik ayarlarıyla test edin. Kullanıcılar Liquid Glass görünümünü ayarlardan değiştirebiliyor, şeffaflığı ya da hareketi azaltan erişilebilirlik ayarlarını açabiliyor; özel öğeleri bu ayarların her biriyle deneyin.
4. Kontrollerde renk kullanımında ölçülü olun. Renk gerekiyorsa sistem renklerini ya da açık ve koyu varyantı olan, artırılmış kontrast seçeneği de bulunan özel renkler tanımlayın.
5. Uygulama ikonunu katmanlarla yeniden düşünün. İkonlar artık katmanlardan oluşuyor; sistem yansıma, kırılma ve gölge gibi efektleri katmanlara kendisi uyguluyor.

Geçiş için geçici bir yol var: UIDesignRequiresCompatibility anahtarı, uygulamanın önceki SDK'larla derlenmiş gibi görünmesini sağlayan bir uyumluluk modu açıyor. Ancak Apple'ın belgesine göre bu anahtar yalnız arayüzü gözden geçirme süresince geçici kullanım için ve iOS 27 ya da sonrası için derlendiğinde sistem tarafından yok sayılıyor 4. Yani eski görünümde kalmak bir strateji değil, kısa bir erteleme.

Android 16, API 36 ve Material 3 Expressive

Google Play'in hedef API kuralı, Android tarafındaki en somut tarih. 31 Ağustos 2026'dan beri yeni uygulamalar ve güncellemeler Android 16 (API 36) ya da üstünü hedeflemeli; Wear OS ve Android Automotive OS için alt sınır API 35, Android TV ve Android XR için API 34. Mevcut uygulamaların, kendi hedef sürümlerinden yeni Android sürümlerini çalıştıran cihazlarda yeni kullanıcılara görünmeye devam etmesi için en az API 35'i hedeflemesi gerekiyor. Ek süre isteyen geliştiriciler 1 Kasım 2026'ya kadar uzatma talep edebiliyor 5.

API 36'yı hedeflemek, üç tasarım değişikliğini beraberinde getiriyor 6:

• Kenardan kenara zorunlu. Android 15'te kenardan kenara görünümden çıkmak için kullanılan seçenek, API 36'yı hedefleyen uygulamalarda devre dışı. Durum çubuğu ve gezinme çubuğunun altına uzanan içerik için güvenli boşluklar her ekranda tasarlanmalı.
• Tahmine dayalı geri animasyonları varsayılan. Ana ekrana, görevler arasına ve etkinlikler arasına geri dönüş animasyonları varsayılan olarak açık. Geri hareketinin nereye götürdüğü akış tasarımında açıkça tanımlanmalı.
• Büyük ekranda yön kilidi yok. En küçük genişliği 600dp ve üstü olan ekranlarda yön, yeniden boyutlandırma ve en-boy oranı kısıtlamaları uygulanmıyor; uygulama bütün pencereyi dolduruyor. Oyunlar bu kuralın dışında. Geçici bir çıkış seçeneği var, ancak Google bunun API 37 hedeflendiğinde geçerli olmayacağını belirtiyor. Tablet ve katlanabilir cihazlar için uyarlanabilir düzen artık ertelenemez.

Görsel dil tarafında Google'ın Material 3 Expressive güncellemesi bağlamı oluşturuyor. Google, bu güncellemeyi 46 ayrı araştırma çalışması ve dünya genelinde 18.000'den fazla katılımcıyla geliştirdiğini; bir göz izleme çalışmasında katılımcıların temel arayüz öğelerini Expressive tasarımlarda dört kata kadar daha hızlı bulduğunu bildiriyor 8. Bu bir mağaza zorunluluğu değil, ama Android'in yeni bileşenleri ve hareket dili bu yönde ilerliyor; design system'inizi güncellerken dikkate almanız gereken bir referans. Bileşen ve token düzeyindeki etkisi için design system nedir yazısına bakabilirsiniz.

Takvimi tasarım planına bağlamak

Mağaza gereksinimleri her yıl değişir ve çoğu, uygulamanın bir sonraki güncellemesiyle devreye girer. Bu yüzden tasarım planına bir "platform takvimi" eklemek yararlıdır:

1. Apple'ın Upcoming Requirements sayfasını ve Google Play'in hedef API sayfasını üç ayda bir kontrol edin 2 5.
2. Her yeni SDK ya da API hedefi için davranış değişikliklerini okuyun ve etkilenen ekranları listeleyin.
3. Design system bileşenlerini önce güncelleyin; ekranlar bileşenleri miras alsın.
4. Hesap, izin ve gizlilik akışlarını her büyük güncellemeden önce mağaza kurallarına karşı gözden geçirin.
5. Yeni görünümü en büyük yazı boyutu, şeffaflığı azaltma ve koyu mod ile test edin.

Bu kontrolleri yeni bir uygulamada baştan ya da mevcut uygulamanın geçişinde ekran ekran nasıl ele aldığımızı mobil uygulama tasarımı sayfamızda bulabilirsiniz.