Guideline 4.2 Minimum Functionality: uygulama reddi

Guideline 4.2, yani "Minimum Functionality", bir web sitesinden fazlasını sunmayan ya da insanların tutmak isteyeceği kadar değer vermeyen uygulamayı reddeder. Çözüm native özellikleri üst üste yığmak değil: birini kullanımın merkezine koymak, sonra reviewer'a nerede bulacağını söylemek. Düzeltme neredeyse her zaman yeni bir build gerektirir.

Kendi iOS uygulamalarımı yayınlıyorum: Solys, TradaZen ve Nolera App Store'da. Bu rehber, Apple'ın 15 Ekim 2026'da okuduğum resmi metnine ve geliştiricilerin Apple forumlarında paylaştığı 4.2 retlerine dayanıyor. Aşağıda geçen reddedilmiş uygulamalar örnek. Tüm ret nedenlerine genel bakış için Apple bir uygulamayı neden reddeder yazısını oku.

Guideline 4.2 ne diyor?

4.2, App Review Guidelines içindeki 4. bölümde, "Design" başlığı altında yer alıyor. İlk cümlesi kriteri koyuyor: "Your app should include features, content, and UI that elevate it beyond a repackaged website." Yani uygulaman, onu kutuya konmuş bir web sitesinin üstüne çıkaran özellikler, içerik ve arayüz sunmalı.

Metin iki fikir daha ekliyor. Gerçekten faydalı, özgün ya da "app-like" olmayan bir uygulamanın App Store'da yeri yok. Ve kalıcı eğlence ya da yeterli fayda sunmayan bir uygulama reddedilebilir. Yani 4.2 iki şeye bakıyor: web'den farkına ve değerin miktarına.

Mesajın atıf yapabileceği alt kurallar

Alt kural	Apple'ın istediği	Tipik ret
4.2	Bir web sitesinin ötesine geçmek	WebView içinde gösterilen site
4.2.1	Gerçek bir artırılmış gerçeklik deneyimi	AR görünümüne konmuş tek bir 3D model
4.2.2	Sadece pazarlama ya da linkler değil	Vitrin uygulaması, toplayıcı, linkler
4.2.3	Bağımsız bir uygulama, net indirmeler	Başka bir uygulama gerektiren uygulama
4.2.6	Ticari şablondan üretilmiş uygulama değil	Bir ajansın gönderdiği şablon

Üç not. 4.2.2 kataloglar için bir istisna tanıyor: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Yani bir ürün kataloğu geçebilir. Bir reklam broşürü geçemez.

4.2.3'ün iki maddesi var. (i), uygulamanın başka bir uygulama kurmadan tek başına çalışmasını istiyor. (ii), uygulama ilk açılışta kaynak indirmesi gerekiyorsa indirme boyutunu belirtmeni ve önceden onay istemeni istiyor.

Ticari şablonlar ve uygulama üretme hizmetleriyle ilgili 4.2.6, spam karşıtı kuralla birlikte ele alındığı için guideline 4.3 rehberinde ayrıntılı anlatılıyor.

En sık görülen iki 4.2 mesajı

Apple'ın mesajı "Guideline 4.2 - Design - Minimum Functionality" başlığıyla açılır. Devamı, reviewer'ın iki sorundan hangisini gördüğünü söyler. İşte geliştiricilerin Apple forumlarında paylaştığı iki ifade. Birkaç yıllıklar: tam metin değişmiş olabilir, ama bu iki aile değişmedi.

Uygulama bir siteye benziyor. "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." Apple forumlarında paylaşılan bu mesaj belirleyici bir cümle içeriyor: "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

Uygulama fazla zayıf. "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." Bu ikinci mesaj konsepti yeniden düşünmeni istiyor ve neyin faydalı ya da eğlenceli olduğunu tanımlayan sayısal bir kural olmadığını kabul ediyor.

Paketlenmiş bir siteye bildirim, konum ve paylaş butonu eklemek yetmez: Apple bunu kendi ret mesajlarında yazdı.

Dört tipik 4.2 ret vakası

Aşağıdaki dört vaka, kuralı açıklamak için kurgulanmış örnekler, gerçek uygulamalar değil.

Paketlenmiş web sitesi

Örnek: bir spor kulübü mobil sitesini bir WebView'da gösteriyor, üstüne de native bir sekme çubuğu koyuyor. Program, rezervasyon ve hesap birer web sayfası. Reviewer, Safari'nin ona göstereceği şeyin aynısını görüyor. Apple bunu App Review sayfasında söylüyor: bir iOS uygulaması içinde sunulan site, iOS'a uyarlanmamış web içeriği ya da sınırlı web etkileşimleri kaliteli bir uygulama yapmaz.

Ben olsam şunu yapardım: ana eylemin ekranlarını, burada program ve rezervasyonu, native olarak yeniden yazardım. Sonra sitenin yapamadığını eklerdim: seanstan önce hatırlatma, internetsiz görüntülenebilen program, bir widget'ta bir sonraki seans.

Fazla basit uygulama

Örnek: günde bir alıntı gösteren ve başka hiçbir şey yapmayan bir uygulama. On saniyede her şeyini görmüş olursun. 4.2 "lasting entertainment value or adequate utility" diyor: kalıcı bir değer ya da yeterli bir fayda. Düzeltmek için etrafına ekran ekleme, ana eyleme derinlik kat. Burada: bir geçmiş, favoriler, seçilen saatte bir hatırlatma, ana ekranda bir widget.

Yapay zekâyla üretilmiş, hiçbir şeyi native olmayan uygulama

Örnek: bir metin alanı, bir buton, düz metin olarak gösterilen bir yapay zekâ yanıtı. Apple aracı değil, reviewer'ın ekranına geleni değerlendirir. Deneyim bir web sayfasına sığıyorsa, 4.2 gelme ihtimali yüksek.

Yapay zekânın neyi iyi yaptığını, neyi kaçırdığını yapay zekâyla uygulama yapmak yazısında anlatıyorum. Her üreticinin çıkardığı format, web uygulaması mı mobil proje mi, Lovable, Rork mu FlutterFlow mu yazısında karşılaştırılıyor.

İçerik bekleyen boş kabuk

Örnek: ilanı olmayan bir pazar yeri, boş bir rehber, "Yakında" yazan bir akış. Reviewer, gösterecek hiçbir şeyi olmayan bir uygulama açıyor. Bu vaka, geçici içeriği reddeden 2.1'e de dokunuyor: guideline 2.1 rehberine bak. Uygulamayı gerçek içeriği olduğunda gönder ya da önceden doldurulmuş bir demo hesap ver.

Yaptığım test: "Peki Safari'de?"

Göndermeden önce kendime şunu soruyorum: bir web sitesi aynı ana işlevi sunabilir mi? Cevap evetse, uygulama 4.2'ye açık. Bir native özelliği değerlendirmek için kullandığım tablo bu. Bir özellik süs olduğunda değil, ana eyleme hizmet ettiğinde sayılır.

Özellik	Şu durumda sayılır...	Şu durumda yetmez...
Bildirimler	Beklenen bir bilgi getiriyorsa	Sadece yazılarını duyuruyorsa
Çevrimdışı	Ana içerik kullanılabilir kalıyorsa	Sadece bir hata ekranı çıkıyorsa
Widget	Kişiye özel bir veri gösteriyorsa	Logonu gösteriyorsa
Paylaşım	Uygulamana içerik gönderilebiliyorsa	Sadece bir link paylaşıyorsa
Kamera, sensörler	Ana eylemin parçasıysa	Siteni açıyorsa
Yerel veriler	Uygulama hesaplıyor, düzenliyor, hatırlıyorsa	Her şey bir web sayfasında yaşıyorsa

Apple'ın önerileri de aynı yönde. Bir widget güncel, bir bakışta okunabilen bir içerik gösterir. Bir bildirim az sözle faydalı bir bilgi getirir ve kullanıcıyı uygulamadaki bir göreve itmek için kullanılmaz.

Uygulamalarımın yapıp bir sitenin yapamadığı şeyler

Her uygulamayı, tarayıcıda olmayan bir ana işlev ya da insanı geri getiren bir değer etrafında tasarlıyorum.

• Solys bir alarm. Alarm sesi, iOS 26'nın alarm servisi AlarmKit üzerinden çalıyor: Apple'ın alarmı gibi sessiz modu aşıyor. Kapatmak için bir mini oyunu kazanman gerekiyor, seçtiğin uygulamalar da uyandıktan sonra duraklatılmış kalıyor. Hiçbir web sayfası sessizdeki bir iPhone'u çaldıramaz.
• TradaZen bir trading simülatörü: gerçek bir tarihte gerçek bir grafik, bir karar, açılan mumlar, sıralamalı düellolar ve yükselen bir rütbe. Burada uygulamayı taşıyan native bir özellik değil. 4.2'nin bahsettiği kalıcı eğlence değeri.
• Nolera bir gardırop: kıyafetlerinin fotoğrafını çekiyorsun, uygulama arka planlarını kaldırıp düzenliyor, sonra her sabah bir kombin öneriyor. Kamera ana eylemin parçası. Bir bonus değil.

4.2 bir native özellik listesi istemez: bir site açmak yerine uygulamayı kurmak için bir sebep ister.

Bir 4.2 reddini adım adım düzeltmek

1. Aileyi belirle. Web gezintisi: paketlenmiş site. Minimal içerik ya da özellik: fazla zayıf uygulama. 4.2.3: başka bir uygulamaya bağımlılık ya da duyurulmamış bir indirme.
2. İfadeyi değil, ürünü değiştir. Hiçbir şey değiştirmeden tartışan bir yanıtın ikna etmesi için hiçbir sebep yok. Ana eylemin ekranlarını native olarak yeniden yaz ya da eksik derinliği ekle.
3. Yeni bir build planla. Sorun uygulamanın içinde: uzaktan güncelleme yetmez. Her gönderim yeniden kuyruğa girer, App Store onay süresi yazısına bak.
4. Yol gösteren review notları yaz. Apple, eksiksiz bir review için gereken bilgiler sayfasında konsepti, özellikleri ve hedef kitleyi anlatmanı istiyor. Bir güncelleme için: neyin değiştiği ve nerede bulunacağı.
5. Sadece reviewer bir şeyi kaçırdıysa itiraz et. Native özelliğin zaten vardıysa ama görülmediyse, App Store Connect'te kısa bir videoyla yanıt ver. App Review Board'a itiraz, uygulaman yanlış anlaşıldığında anlamlıdır, zayıf olduğunda değil.

Kullanacağım not şablonu, İngilizce, kendine göre uyarla:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Sadece gönderilen build'de var olanı yaz. Duyurulup bulunamayan bir özellik sana yeni bir ret getirir, bu sefer 2.1 kapsamında.

Göndermeden önce 4.2 kontrol listesi

• Uygulamanın bir sitenin yapamadığı neyi yaptığını tek cümleyle söyleyebiliyorsun.
• Ana eylemin ekranları web sayfası değil, native.
• Her native özellik ana eyleme hizmet ediyor ve reviewer onu iki dakikadan kısa sürede görüyor.
• Uygulamada ilk açılıştan itibaren gerçek içerik ya da doldurulmuş bir demo hesap var.
• Uygulama başka bir uygulama kurmadan tek başına çalışıyor.
• İlk açılıştaki büyük bir indirme boyutunu belirtiyor ve onay istiyor.
• Review notları konsepti, hedef kitleyi ve her özelliğin yerini anlatıyor.
• Fikrin sınırdaysa, kod yazmadan önce iyi çerçevelenmiş bir iOS uygulama MVP'si ile test ettin.

Bir sonraki gönderiminde 4.2'yi geçmek

Uygulaman az önce 4.2'den reddedildiyse, Apple Review Kit atıf yapılan kuralı ve ne istediğini bulmana yardım eder, testçi için not şablonlarıyla birlikte. Hâlâ geliştiriyorsan, iOS Kit yolculuğu ilk kod satırından önce ana işlevle başlar. İnsan gözüyle bir bakış istersen, benimle bir saatlik görüşme ayarla. Tüm süreç Apple tarafından reddedilen uygulama sayfasında.

İlk yayınına hazırlanıyorsan, ücretsiz diagnostiğini yap: adımları sıraya koyar ve sana Apple retlerine karşı kontrol listemi gönderir. Ana sayfa, en baştan review düşünülerek mobil uygulama nasıl yapılır gösteriyor.

Kimse Apple'ın uygulamanı kabul edeceğini garanti edemez. Ben sana, uygulamana App Store'da var olmak için bir sebep vermende yardım edebilirim.

Sık sorulan sorular

"Guideline 4.2 - Design - Minimum Functionality" ne demek?

Minimum işlevsellik reddinin başlığı. Apple, uygulamanın bir web sitesine fazla benzediğine ya da çok az içerik veya özellik sunduğuna karar vermiştir. Aynı başlık bir alt kuralı da hedefleyebilir: vitrin uygulaması ya da link listesi için "Guideline 4.2.2", başka bir uygulamaya bağımlı uygulama için 4.2.3.

WebView kullanan bir uygulama her zaman reddedilir mi?

Hayır. Kural teknolojiyi değil, uygulamaya konmuş web sitesini hedefliyor. Reviewer ana deneyimi değerlendirir: ekranları Safari'yle aynı şeyi yapan web sayfalarıysa risk yüksek. Tarayıcıda açılan bir yardım sayfası mesele değil.

Push bildirimleri eklemek 4.2'yi geçmeye yeter mi?

Hayır. Apple, forumlarında paylaşılan bir ret mesajında bildirimlerin, konumun ve paylaşımın deneyimi yeterince zengin kılmadığını yazıyor. Bir bildirim, ana işleve hizmet ettiğinde sayılır, örneğin bir alarm ya da kişinin seçtiği bir hatırlatma.

Guideline 4.2 ile 4.3 arasındaki fark ne?

4.2 uygulamanı tek başına değerlendirir: bir web sitesine göre yeterince şey getiriyor mu? 4.3 onu diğerleriyle karşılaştırır: bir kopya mı, bir varyant mı, yoksa doymuş bir kategoride bir uygulama daha mı? Aynı uygulama ikisini birden alabilir, ama aynı şekilde düzeltilmezler.

Bir 4.2 reddinden sonra yeni build gerekir mi?

Neredeyse her zaman, çünkü sorun uygulamanın kendisinde. Tek istisna: reviewer zaten var olan bir özelliği bulamamışsa. Bu durumda build'i değiştirmeden, App Store Connect'te net notlar ve kısa bir videoyla yanıt ver.