App Store Reddi Vakası: 'Dark Hours' ve Çıkan Dersler

Ağustos 2026'da bir App Store reddi, birkaç gün içinde gazetecilik camiasında kendi kendini düzelten nadir bir vakaya dönüştü: önce "Apple haksız yere reddetti" başlıklı bir yazı yayıldı, ardından yazının kendisi geri çekildi. Bu makale "Dark Hours" adıyla anılan olayın gerçek kronolojisini, hangi App Store Review Guideline maddesinin tartışmanın merkezinde olduğunu ve geliştiricilerin kendi başvurularında tekrarlamaması gereken dersleri, yalnızca birincil kaynaklara dayanarak anlatıyor.

💡 Pro Tip: Bir red haberini paylaşmadan önce tek soru sor: "Bu iddiayı doğrudan Apple'ın red mesajından mı, yoksa geliştiricinin ikinci elden anlatımından mı okuyorum?"

İçindekiler

• Vakanın kronolojisi: iddia, tepki, geri çekme
• Red gerekçesi ve 4.3(b)'nin vakadaki gerçek yeri
• "Haksız red" hissinin en sık üç kaynağı
• İnceleme notları ve demo hesabı: reddi önleyen hazırlık
• İtiraz (App Review Board): vakada doğrulanan tek sonuç
• Yayın takviminizi redde karşı nasıl tasarlarsınız
• Vakadan çıkan 5 kalıcı ders
• SSS
• App Store reddi nasıl doğru okunur?
• Red gerekçesine itiraz süreci nasıl işler?
• İnceleme notlarını nasıl yazmalıyım?
• "Fal/astroloji uygulamaları App Store'da tamamen yasak mı?"
• Bir gazetecilik/blog kaynağındaki "haksız red" iddiasına ne kadar güvenmeliyim?
• Sonuç
• Kaynaklar

Vakanın kronolojisi: iddia, tepki, geri çekme

Zincir üç ayrı yayında ilerledi ve her adımda anlatı biraz daha değişti.

7 Ağustos 2026'da geliştirici Terry Godier kendi blogunda bir uygulamasının Apple tarafından reddedildiğini yazdı. Yazının orijinal metninde, reddin astroloji gerekçesiyle geldiğini ama uygulamanın "tarot fonksiyonu yok, burç yorumu yok" olduğunu iddia ediyordu.

John Gruber, Daring Fireball'da bu iddiayı aynı gün "App Store Rejection of the Week: Dark Hours" başlığıyla işledi. Ertesi gün Godier kendi yazısındaki iddialı paragrafları silip yerlerine şu notu koydu (Gruber retraksiyonunda aktarıyor): "App store review reached out to me and let me know that they had apparently never been given the updated build."

8 Ağustos 2026'da Gruber kendi yazısını tamamen geri çekti. Retraksiyon metninde gerçek tabloyu netleştirdi: "The grounds of Apple's original App Store rejection of the app, and the rejection's upholding by the App Review Board, were correct." Reddedilen uygulamanın adı "Dark Hours" değil, Asterly idi; uygulama gerçekten "bir günün tarot kartı" özelliği dahil astrolojiye adanmıştı. Aynı gün Godier, astronomi sürümü olarak web'e taşıdığı Dark Hours sitesini darkhours.io adresinden kaldırıp bağımsız geliştirici Miguel Beher'in açık kaynak "DarkHours" adlı astrofotoğrafçılık projesine (darkhours.app) yönlendirdi — iki proje aynı konum hatasını (kullanıcıları rastgele koordinatlara yönlendirme) paylaşıyordu. Gruber yazısını bir özürle kapattı: "I apologize to all who read and believed my now-retracted post, and to the reviewers at the App Store whose competence... I besmirched."

Vaka Hacker News'e de taşındı ve tartışma orada büyüdü; Gruber'in ilk (sonradan geri çekilen) yazısı topluluk gündeminde öne çıktı, bu da anlatının doğrulanmadan hızla yayılmasının somut bir örneği oldu.

Olayı daha da karmaşık hale getiren ayrı bir gelişme, isim çakışmasıydı. Godier'in astronomi sürümünü taşıdığı web uygulamasına verdiği "Dark Hours" (boşluklu) adı, bağımsız geliştirici Miguel Beher'in önceden var olan açık kaynak "DarkHours" (boşluksuz) adlı astrofotoğrafçılık projesiyle (GitHub: mbeher2200/DarkHours, darkhours.app) çakıştı. Gruber'in aktardığına göre Beher, Bluesky üzerindeki bir yazışmada Godier'in Dark Hours'ının kendi projesiyle aynı konum hatasını — kullanıcıları "random fields in Mexico" adresine yönlendiren hatayı — taşıdığını belirtti. Godier 9 Ağustos 2026'da yayımladığı özür yazısında web uygulamasını Claude ile ürettiğini ve Beher'in açık kaynak projesine "çarpıcı biçimde benzediğini, hatta onun sonradan düzelttiği bir hatayı yeniden ürettiğini" yazdı. İsim çakışması, zaten karışmış olan anlatıyı bir kat daha bulanıklaştırdı.

Burada önemli bir ayrım netleştirilmeli: geri çekme işlemini yapan Gruber'in kendisiydi, Godier değil. Godier'in yaptığı, kendi blog yazısındaki iddialı paragrafları silip bir düzeltme notuyla değiştirmek ve ardından web uygulamasını kapatmaktı. Gruber ise kendi yazısını resmi olarak retrakte etti ve okuyucularından özür diledi. Bu ayrımı gözden kaçırmak, vakayı "geliştirici itiraf etti" gibi yanlış bir çerçeveye sokabiliyor; oysa red iddiasıyla ilgili düzeltmeyi yayımlayan, kendi haberini geri çekmek zorunda kalan gazeteciydi. Godier'in 9 Ağustos'ta yayımladığı özür yazısı ise reddi değil, web uygulamasının isim çakışmasını ve AI ile üretilmiş olmasını konu alıyordu.

Aşağıdaki tablo olayın zaman çizelgesini özetliyor.

Red gerekçesi ve 4.3(b)'nin vakadaki gerçek yeri

Birincil kaynaklarda reddin bildirilen gerekçesi açık: Godier'in kendi ifadesiyle "It was rejected on the grounds that it was astrology." Apple'ın bu kategoriye neden mesafeli durduğunu açıklayan madde ise App Store Review Guideline 4.3(b); Gruber bu maddeyi yalnızca retraksiyonunun dipnotunda, Apple'ın genel duruşunu ("Apple's stance is basically that the App Store has enough of these apps") anlatmak için anıyor. Guideline'ın metni şöyle diyor: "Certain kinds of apps, such as dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling, are well established on the App Store and we will not accept new submissions unless they offer a meaningfully different or improved experience." Yani fal/kehanet (fortune telling), App Store'da zaten doygun kabul edilen bir kategoridir ve yeni bir başvurunun kabul görmesi için mevcut uygulamalardan "anlamlı ölçüde farklı veya geliştirilmiş" olması gerekir.

Bu, astroloji temalı uygulamaların kategorik olarak yasak olduğu anlamına gelmiyor. Apple'ın kendisi App Store'da "Best Astrology Apps" başlıklı bir editoryal liste yayımlamış durumda. Asterly'ye bildirilen gerekçe yine de astrolojiydi; Gruber retraksiyonunda durumu şöyle özetliyor: "an astrology app was rejected for being an astrology app." 4.3(b) ise reddin dayanağı değil, Apple'ın bu kategoriyi neden doygun saydığını açıklayan arka plan. Gruber'in asıl tespit ettiği kırılma noktası başka bir yerdeydi: geliştiricinin kamuya anlattığı ürün tanımı (astronomi) ile Apple'ın incelediği gerçek build'in içeriği (astroloji + tarot) örtüşmüyordu.

Bu ayrım pratikte önemli, çünkü iki farklı red senaryosunu birbirinden ayırıyor. Birincisi, bir kategorinin tamamen yasaklandığı senaryo — bu vakada geçerli değil. İkincisi, bir kategorinin "izin verilen ama doygun" olduğu ve yeni girişlerin ekstra bir farklılaşma yükü taşıdığı senaryo — fal/kehanet kategorisinin 4.3(b)'deki konumu bu. Bir geliştirici red mesajını "Apple bu kategoriyi sevmiyor" diye okursa yanlış sonuca varır; doğru okuma "bu kategoride zaten var olan uygulamalardan somut olarak ne farklı sunuyorum" sorusuna cevap aramaktır.

Değerlendirme notu: bu, App Review Board'un öznel bir yargı kullandığı anlamına geliyor, ama bu öznellik Apple'ın kendi rehberinde açıkça kabul edilen bir tasarım tercihi — geliştiricinin niyetine dair bir suçlama değil, sürecin doğasına dair bir gözlem.

"Haksız red" hissinin en sık üç kaynağı

Bu vaka ve Apple'ın kendi dokümantasyonu, "haksız red" hissinin arkasında tekrar eden üç örüntü olduğunu gösteriyor.

• İnceleme notları ile gönderilen build'in senkron olmaması. Godier'in kendi ifadesiyle inceleme ekibi güncellenmiş build'i "hiç almamış" görünüyordu. Geliştirici güncellemeyi gönderdiğini sanıyor, inceleme eski sürümü değerlendiriyor. Bu tür bir kopukluk özellikle sık build gönderen ekiplerde kolayca oluşabiliyor: her yeni sürüm, App Store Connect'teki "hangi build inceleniyor" alanıyla eşleşmediğinde, geliştiricinin zihnindeki uygulama ile Apple'ın önündeki uygulama iki farklı ürüne dönüşebiliyor.
• Guideline 2.1 (App Completeness) tek başına dominant. Apple'ın resmi App Review sayfasına göre "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness." Yani çözülmemiş inceleme sorunlarının %40'ından fazlası içerik tartışması değil, eksik veya çöken bir build'den kaynaklanıyor — bir ekran açılmıyor, bir test hesabı çalışmıyor, bir metadata alanı boş kalmış. Bunlar medyada "Apple keyfi davrandı" başlığıyla anlatılacak kadar çarpıcı değil, ama istatistiksel olarak en büyük pay bunlara ait.
• Sınırda kategori öznelliği. Guideline 1.1.6 (sahte/şaka işlevi) ve 4.3(b) (doygun kategoriler) gibi maddeler öznel yargı içeriyor. Apple bunu rehberin giriş bölümünde açıkça yazıyor: "We will reject apps for any content or behavior that we believe is over the line... 'I'll know it when I see it'." Bu ifade, App Review'un kural-tabanlı değil, ölçüt-tabanlı çalıştığı alanların var olduğunu açıkça kabul ediyor — ve bu tür alanlarda iki farklı inceleme turunun farklı sonuçlara varması, sistemin bir arızası değil, tasarımının bir parçası.

Aşağıdaki tablo vakada ve Apple'ın rehberinde geçen üç maddeyi özetliyor.

İnceleme notları ve demo hesabı: reddi önleyen hazırlık

Apple'ın resmi rehberi hesap tabanlı özellikler için net bir gereklilik tanımlıyor: "provide either an active demo account or fully-featured demo mode, plus any other hardware or resources that might be needed to review your app." Dark Hours/Asterly vakası, gönderim-inceleme hattındaki bir iletişim kopukluğunun klasik bir örneği oldu — geliştirici güncel build'i gönderdiğini varsaydı, inceleme ekibi farklı bir sürümü değerlendirdi.

Pratikte bunu önlemek için kullanılabilecek basit bir ön-kontrol listesi şu şekilde kurulabilir:

1#!/usr/bin/env bash
2# submission-checklist.sh — gönderim öncesi manuel doğrulama listesi
3set -euo pipefail
4 
5echo "1) Demo hesabı/mod App Store Connect > App Review Information alanında güncel mi?"
6echo "2) Son yüklenen build numarası, test edilen build ile birebir aynı mı?"
7echo "3) Review Notes, kaldırılan/değiştirilen her özelliği açıkça listeliyor mu?"
8echo "4) Uygulama açıklaması ile gerçek uygulama içeriği (özellik listesi) örtüşüyor mu?"
9 
10read -p "Tüm maddeler onaylandı mı? (y/n) " confirm
11if [[ "$confirm" != "y" ]]; then
12  echo "Gönderimi durdur, önce eksik maddeyi tamamla." >&2
13  exit 1
14fi
15echo "Gönderime hazır."

Review notes alanına yazılacak metnin yapısını netleştirmek için basit bir şablon da faydalı olur:

1{
2  "buildNumber": "42",
3  "removedFeatures": ["tarot-card-of-day widget"],
4  "addressedGuideline": "4.3(b)",
5  "demoAccount": {
6    "email": "reviewer@example.com",
7    "note": "Önceden doldurulmuş test verisiyle geliyor"
8  },
9  "screenshots": ["onboarding.png", "core-flow.png"]
10}

Bu şablonun kendisi Apple'ın resmi bir formatı değildir; amacı, ekip içinde her gönderimden önce aynı bilgilerin eksiksiz doldurulmasını garanti altına almaktır.

Demo hesabı gereksinimini kod tarafında da görünür kılmak faydalı olabiliyor. Örneğin bir "review mode" flag'i uygulama içinde tek bir yerden yönetilirse, hangi build'in hangi demo veriyle gönderildiği daha kolay izlenebilir:

1import Foundation
2 
3enum ReviewMode {
4    /// App Store Connect'teki demo hesabıyla giriş yapıldığında true olur.
5    /// Amaç: inceleme ekibinin gördüğü veri ile gerçek kullanıcı verisini
6    /// birbirinden ayırmak, review notes'ta tarif edilen akışla build'i eşlemek.
7    static var isActive: Bool {
8        UserDefaults.standard.bool(forKey: "com.example.reviewModeActive")
9    }
10}

Bu örnek, Apple'ın resmi bir API'si değil; yalnızca ekiplerin kendi projelerinde "inceleme ekibi hangi build'i, hangi veriyle görüyor" sorusunu net tutmak için kurabileceği bir iç kontrol deseni.

İtiraz (App Review Board): vakada doğrulanan tek sonuç

Asterly, Ocak 2026'da gönderilip reddedildikten sonra bir itiraz sürecinden geçti ve App Review Board, Nisan 2026'da orijinal reddi onadı. Board'un Gruber tarafından aktarılan birebir gerekçesi şuydu: "We understand that the app includes a live tarot reading feature." Yani itiraz mekanizması işledi, ama sonucu değiştirmedi; Board, gönderilen build'de hâlâ duran içeriğe bakarak ilk reddi geçerli saydı.

Buradan çıkarılabilecek tek somut ders şu: bir itirazın var olması, sonucun geliştirici lehine değişeceği anlamına gelmiyor. Board, uygulamada bulduğu canlı tarot okuma özelliğine dayanarak reddi sürdürdü.

Yayın takviminizi redde karşı nasıl tasarlarsınız

Apple'ın resmi App Review sayfasına göre "On average, 90% of submissions are reviewed in less than 24 hours." Bu hızlı geri bildirim döngüsü, aslında geliştiriciler lehine bir tampon imkânı sunuyor: büyük bir lansman tarihini tek bir inceleme turuna bağlamak yerine, olası bir red/düzeltme turu için birkaç günlük pay bırakmak mümkün.

İkinci ders ise Guideline 2.1 istatistiğinden geliyor: çözülmemiş inceleme sorunlarının %40'ından fazlası içerik tartışması değil, eksik/çöken/güncel olmayan build. Yayın takvimini "son dakika build'i" üzerine değil, gönderimden en az birkaç gün önce tamamlanmış ve QA'dan geçmiş bir sürüm üzerine kurmak, hem ilk red riskini hem de itiraz sürecine girme ihtimalini azaltıyor.

Bu iki noktayı birleştiren basit bir zamanlama kuralı şöyle kurulabilir: hedef yayın tarihinden en az bir "red + yeniden gönderim" döngüsü kadar (ortalama inceleme süresi + düzeltme süresi) önce ilk gönderimi yapmak.

Vakadan çıkan 5 kalıcı ders

• Bir "haksız red" iddiası yayılmadan önce doğrulanmalı. Gruber'in kendi vakası, güvenilir ve deneyimli bir kaynaktan gelse bile tek taraflı bir anlatının yanlış olabileceğini gösterdi. Yazı ilk yayımlandığında geniş bir okuyucu kitlesine ulaştı; retraksiyon geldiğinde hasar zaten oluşmuştu. Bir red haberini paylaşmadan önce, iddiayı doğrudan guideline metniyle veya varsa geliştiricinin gönderim geçmişiyle karşılaştırmak, bu tür bir geri çekmeyi önlemenin tek yolu.
• Guideline 4.3(b)'nin "doygun kategori" mantığı astroloji/fal uygulamalarını otomatik yasaklamıyor. Asıl kriter mevcut uygulamalardan "anlamlı farklılaşma." Bu ayrımı gözden kaçırmak, geliştiricilerin "kategorim zaten yasak" diye yanlış bir sonuca varıp kategoriyi tamamen terk etmesine yol açabilir; oysa doğru tepki farklılaşma stratejisini güçlendirmek olurdu.
• İnceleme sorunlarının başında içerik tartışması değil, eksik veya güncel olmayan build geliyor. Guideline 2.1 maddesi tek başına çözülmemiş inceleme sorunlarının %40'ından fazlasını oluşturuyor. Bu istatistik, "içerik politikası" tartışmalarının medyada daha çok yer kaplamasına rağmen, gerçekte incelemede çözülemeyen sorunların çok daha sıradan ve önlenebilir bir sebepten (çöken ekran, eksik metadata, çalışmayan link) kaynaklandığını gösteriyor.
• İnceleme notları ve demo hesabı senkronizasyonu kritik. Geliştiricinin "gönderdim sandığı" build ile incelemenin gördüğü build arasındaki fark tek başına bir vakayı başlatabiliyor. Dark Hours/Asterly vakasında bu senkronizasyon kopukluğu, tartışmanın haftalarca sürmesinin altında yatan teknik nedenlerden biriydi.
• App Review Board'un bir reddi onaylaması, sürecin işlediğinin göstergesi. İtirazın var olması sonucu garanti etmiyor; Asterly vakasında Board, Nisan 2026'da aynı gerekçeyle reddi sürdürdü. Bu, itiraz mekanizmasının "otomatik telafi" değil, ikinci bir bağımsız değerlendirme olduğunu hatırlatıyor.

SSS

App Store reddi nasıl doğru okunur?

Red mesajındaki gerekçe maddesini (guideline numarasını) esas al ve bunu kendi ürün tanımınla değil, son gönderdiğin build'in gerçek içeriğiyle karşılaştır. Dark Hours/Asterly vakasında asıl sorun, geliştiricinin anlattığı uygulama ile Apple'ın incelediği build arasındaki farktı; red metni geliştiricinin hafızasını değil, gönderilen build'i esas alır.

Red gerekçesine itiraz süreci nasıl işler?

Vakada somut olarak bilinen tek adım şu: Asterly bir itiraz sürecinden geçti ve App Review Board Nisan 2026'da orijinal reddi onadı. Bu, itiraz mekanizmasının işlediğini ama sonucu garanti etmediğini gösteriyor. Sorunlu bulunan içerik kaldırılmadan yapılan bir itirazın, aynı gerekçeyle tekrar reddedilme riski taşıdığı bu vakadan çıkarılabilecek net bir sonuç.

İnceleme notlarını nasıl yazmalıyım?

Her yeni gönderimde hangi özelliğin kaldırıldığını veya değiştirildiğini açıkça belirtmek, hangi guideline maddesine yanıt verdiğini not etmek ve hesap gerektiren akışlar için güncel bir demo hesabı sağlamak temel pratiktir. Bu vaka, inceleme notları ile gönderilen build arasında bir kopukluk olduğunda sürecin ne kadar karmaşıklaşabileceğini gösteriyor.

"Fal/astroloji uygulamaları App Store'da tamamen yasak mı?"

Hayır. Guideline 4.3(b) fal/kehanet kategorisini "doygun" olarak tanımlıyor ve yeni başvurulardan mevcut uygulamalardan anlamlı ölçüde farklılaşmasını istiyor; kategorik bir yasak değil. Nitekim Apple'ın kendisi App Store'da astroloji uygulamalarını öne çıkaran editoryal bir liste yayımlamış durumda.

Bir gazetecilik/blog kaynağındaki "haksız red" iddiasına ne kadar güvenmeliyim?

Bu vaka tam olarak bunun bir uyarı örneği. Saygın bir kaynaktan gelse bile, tek taraflı ve ikinci elden bir anlatı yanlış çıkabiliyor; mümkünse iddiayı ilgili guideline metniyle ve varsa geliştiricinin gerçek gönderim geçmişiyle çapraz kontrol etmek gerekiyor.

Sonuç

Dark Hours/Asterly vakası, App Store reddi tartışmalarında sık görülen bir tuzağı gözler önüne seriyor: red gerekçesini kendi ürün tanımınla değil, gönderdiğin gerçek build'le okumak gerekiyor. App Store Optimization (ASO) rehberi ile keşfedilebilirlik tarafını, App Store Connect Subscriptions rehberi ile gönderim sonrası abonelik yönetimini, App Store Connect API Otomasyonu ile TestFlight ve submission süreçlerini otomatikleştirmeyi, StoreKit 2 Production Rehberi ile IAP tarafını derinleştirebilirsin. Gerçek rakamlarla bir App Store başarı hikâyesi için iOS App Store'da $1M Kazandım yazısına, build pipeline'ını sağlamlaştırmak için ise Xcode Cloud Pipeline Optimization rehberine bakabilirsin.

Kaynaklar

• Daring Fireball — App Store Rejection Retraction — Vakanın tam kronolojisi, Godier'in düzenlemeleri, App Review Board'un Nisan 2026 kararı ve Gruber'in özrü.
• Apple Developer — App Store Review Guidelines — 4.3(b) doygun kategoriler, 1.1.6 sahte/şaka işlevi ve demo hesabı gereklilikleri.
• Apple Developer — App Review — Guideline 2.1'in çözülmemiş inceleme sorunlarındaki payı ve ortalama inceleme süresi istatistikleri.
• Hacker News — item 49214863 — Vakanın topluluk tartışması ve App Review Board yanıtına dair alıntılar.
• Apple — Best Astrology Apps — Apple'ın astroloji uygulamalarını öne çıkaran editoryal listesi.
• Terry Godier — Mea Culpa: Dark Hours — Godier'in 9 Ağustos 2026 tarihli özür yazısı: isim çakışması ve web uygulamasının AI ile üretilmesi.