App Store Rejection Case: 'Dark Hours' Lessons

In August 2026, an App Store rejection became a rare case of journalism correcting itself within days: an article titled "Apple rejected it unfairly" went viral, then was retracted. Based solely on primary sources, this article covers the real chronology of the "Dark Hours" incident, which guideline clause sat at the center of the dispute, and the lessons developers should not repeat.

💡 Pro Tip: Before sharing a rejection story, ask yourself one question: "Am I reading this claim directly from Apple's rejection message, or from the developer's secondhand account?"

Table of Contents

• The chronology of the case: claim, reaction, retraction
• The rejection's real grounds, and where 4.3(b) actually fits
• The three most common sources of the "unfair rejection" feeling
• Review notes and the demo account: preparation that prevents rejection
• The App Review Board appeal: the one confirmed outcome in this case
• How to design your release calendar against rejection risk
• 5 lasting lessons from this case
• FAQ
• How should I read an App Store rejection correctly?
• How does the appeal process for a rejection work?
• How should I write review notes?
• "Are fortune-telling/astrology apps completely banned on the App Store?"
• How much should I trust an "unfair rejection" claim from a journalism/blog source?
• Conclusion
• Sources

The chronology of the case: claim, reaction, retraction

The chain played out across three separate publications, and the narrative shifted slightly at every step.

On August 7, 2026, developer Terry Godier wrote on his own blog that Apple had rejected one of his apps. The original text of the post claimed the rejection cited astrology as the grounds, but that the app had "no tarot function, no horoscope reading."

John Gruber covered this claim the same day on Daring Fireball under the headline "App Store Rejection of the Week: Dark Hours." The next day, Godier deleted the contentious paragraphs from his own post and replaced them with the following note (as quoted in Gruber's retraction): "App store review reached out to me and let me know that they had apparently never been given the updated build."

On August 8, 2026, Gruber fully retracted his own post. The retraction text clarified the real picture: "The grounds of Apple's original App Store rejection of the app, and the rejection's upholding by the App Review Board, were correct." The rejected app was not named "Dark Hours" — it was Asterly, and it was indeed dedicated to astrology, including a "tarot card of the day" feature. The same day, Godier took down the Dark Hours site at darkhours.io, which he had repurposed as an astronomy-themed web version, and redirected it to independent developer Miguel Beher's open-source astrophotography project called "DarkHours" (darkhours.app) — the two projects shared the same location bug (sending users to random coordinates). Gruber closed his post with an apology: "I apologize to all who read and believed my now-retracted post, and to the reviewers at the App Store whose competence... I besmirched."

The case also spread to Hacker News, where discussion grew further; Gruber's original (later retracted) post rose to the top of the community's agenda there, a concrete example of how a narrative can spread quickly before it is verified.

A separate development added to the confusion: a naming collision. The name Godier gave his astronomy-themed web app — "Dark Hours" (with a space) — collided with independent developer Miguel Beher's pre-existing open-source astrophotography project named "DarkHours" (no space; GitHub: mbeher2200/DarkHours, darkhours.app). According to Gruber, Beher noted in an exchange on Bluesky that Godier's Dark Hours carried the same location bug as his own project — one that sent users to "random fields in Mexico." In his apology post published on August 9, 2026, Godier wrote that he had built the web app with Claude and that it "strikingly resembled" Beher's open-source project, even reproducing a bug Beher had since fixed. The naming collision blurred an already muddled narrative one layer further.

One distinction needs to be clear here: it was Gruber himself who issued the retraction, not Godier. Godier deleted the contentious paragraphs from his own blog post, replaced them with a correction note, and later took down the web app. Gruber formally retracted his own post and apologized to his readers. Missing this distinction can frame the case as "the developer confessed" — when in fact it was the journalist who had to retract his own story. Godier's apology post, published on August 9, addressed not the rejection itself but the naming collision and the fact that the web app had been AI-generated.

The table below summarizes the timeline of events.

The rejection's real grounds, and where 4.3(b) actually fits

In the primary sources, the stated grounds for the rejection are explicit: in Godier's own words, "It was rejected on the grounds that it was astrology." The App Store Review Guideline clause that explains why Apple keeps its distance from this category is 4.3(b); Gruber cites it only in a footnote, to explain Apple's general stance ("Apple's stance is basically that the App Store has enough of these apps"). The guideline text reads: "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." Fortune telling is already a saturated category on the App Store, and a new submission must be "meaningfully different or improved" compared to existing apps to get accepted.

This doesn't mean astrology-themed apps are categorically banned. Apple itself publishes an editorial list on the App Store titled "Best Astrology Apps." The grounds given for Asterly's rejection were still astrology; Gruber sums it up: "an astrology app was rejected for being an astrology app." 4.3(b) is not the basis for the rejection itself — it's background explaining why Apple considers the category saturated. The real breaking point Gruber identified was elsewhere: the product description the developer publicly gave (astronomy) didn't match the actual content of the build Apple reviewed (astrology + tarot).

This distinction matters in practice, because it separates two rejection scenarios. The first: an entire category banned outright — not applicable here. The second: a category "allowed but saturated," where new entries carry an extra burden of differentiation — this is where fortune-telling sits under 4.3(b). A developer who reads a rejection as "Apple doesn't like this category" reaches the wrong conclusion; the correct reading is "what concretely am I offering that's different from apps that already exist in this category?"

Evaluation note: this means the App Review Board exercises subjective judgment, but that subjectivity is a design choice Apple's own guidelines openly acknowledge — not an accusation about intent, but an observation about the process.

The three most common sources of the "unfair rejection" feeling

This case, together with Apple's documentation, points to three recurring patterns behind the "unfair rejection" feeling.

• A mismatch between the review notes and the submitted build. In Godier's own words, the review team apparently "never" received the updated build. The developer thinks they submitted the update; the review evaluates the old version instead. This can easily happen on teams that ship builds frequently: whenever a new version doesn't match the "build under review" field in App Store Connect, the app in the developer's head and the app in front of Apple become two different products.
• Guideline 2.1 (App Completeness) dominates on its own. According to Apple's official App Review page, "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness." More than 40% of unresolved review issues aren't content disputes at all — they come from an incomplete or crashing build: a screen that won't open, a test account that doesn't work, an empty metadata field. These aren't dramatic enough for headlines like "Apple acted arbitrarily," but statistically they account for the largest share.
• Subjectivity at category boundaries. Clauses like Guideline 1.1.6 (fake/prank functionality) and 4.3(b) (saturated categories) involve subjective judgment. Apple states this openly in the guidelines' introduction: "We will reject apps for any content or behavior that we believe is over the line... 'I'll know it when I see it'." This openly acknowledges that some areas of App Review run on judgment rather than fixed rules — and in those areas, two review passes reaching different conclusions isn't a malfunction, it's part of the design.

The table below summarizes the three clauses that appear in the case and in Apple's guidelines.

Review notes and the demo account: preparation that prevents rejection

Apple's official guidelines define a clear requirement for account-based features: "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 became a textbook example of a communication breakdown in the submit-and-review pipeline — the developer assumed the current build was submitted, while the review team was evaluating a different version.

In practice, a simple pre-submission checklist can be set up to prevent this:

1#!/usr/bin/env bash
2# submission-checklist.sh — manual pre-submission verification checklist
3set -euo pipefail
4 
5echo "1) Is the demo account/mode in App Store Connect > App Review Information up to date?"
6echo "2) Does the last uploaded build number exactly match the build you tested?"
7echo "3) Do the Review Notes explicitly list every feature that was removed or changed?"
8echo "4) Does the app description match the actual app content (feature list)?"
9 
10read -p "Are all items confirmed? (y/n) " confirm
11if [[ "$confirm" != "y" ]]; then
12  echo "Stop the submission, finish the missing item first." >&2
13  exit 1
14fi
15echo "Ready to submit."

A simple template for structuring the review notes text is also useful:

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": "Comes pre-filled with test data"
8  },
9  "screenshots": ["onboarding.png", "core-flow.png"]
10}

This template isn't an official Apple format; its purpose is to guarantee the team fills in the same information consistently before every submission.

It also helps to make the demo account requirement visible in code. If a single "review mode" flag is managed from one place, it becomes easier to track which build was submitted with which demo data:

1import Foundation
2 
3enum ReviewMode {
4    /// Becomes true when signed in with the demo account from App Store Connect.
5    /// Purpose: keep the data the review team sees separate from real user data,
6    /// and map the build to the flow described in the review notes.
7    static var isActive: Bool {
8        UserDefaults.standard.bool(forKey: "com.example.reviewModeActive")
9    }
10}

This isn't an official Apple API either — it's an internal pattern teams can use to keep "which build is review seeing, with which data" clear.

The App Review Board appeal: the one confirmed outcome in this case

After Asterly was submitted and rejected in January 2026, it went through an appeal process, and the App Review Board upheld the original rejection in April 2026. The Board's exact reasoning, as quoted by Gruber, was: "We understand that the app includes a live tarot reading feature." The appeal mechanism worked, but didn't change the outcome — the Board upheld the rejection based on content still present in the submitted build.

The one concrete lesson: an appeal's existence doesn't mean the outcome changes in the developer's favor. The Board upheld the rejection based on the live tarot reading feature it found in the app.

How to design your release calendar against rejection risk

According to Apple's official App Review page, "On average, 90% of submissions are reviewed in less than 24 hours." This fast feedback loop actually works in developers' favor as a buffer: instead of tying a launch date to a single review pass, leave a few days of margin for a potential rejection-and-fix cycle.

The second lesson comes from the Guideline 2.1 statistic: more than 40% of unresolved review issues aren't content disputes — they're incomplete, crashing, or outdated builds. Building the release calendar around a version finished and QA-tested days before submission — not around a "last-minute build" — reduces both the initial-rejection risk and the chance of an appeal process.

A simple scheduling rule that combines these two points: submit the first build at least one "rejection + resubmission" cycle (average review time plus fix time) ahead of the target release date.

5 lasting lessons from this case

• An "unfair rejection" claim needs verification before it spreads. Gruber's own case shows that even a credible, experienced source can get a one-sided narrative wrong. The post reached a wide readership when first published; by the time the retraction came, the damage was already done. Comparing the claim directly against the guideline text — or the developer's actual submission history — is the only way to prevent this kind of retraction.
• Guideline 4.3(b)'s "saturated category" logic doesn't automatically ban astrology/fortune-telling apps. The real criterion is "meaningful differentiation" from existing apps. Missing this distinction can lead developers to wrongly conclude "my category is banned entirely" and abandon it — when the correct response is to strengthen their differentiation strategy.
• Incomplete or outdated builds, not content disputes, are the top source of review issues. Guideline 2.1 alone accounts for more than 40% of unresolved review issues. Even though "content policy" disputes get more media attention, most unresolved issues come from far more mundane, preventable causes — a crashing screen, missing metadata, a broken link.
• Review notes and demo account synchronization is critical. The gap between the build the developer thinks they submitted and the build the review actually sees can, by itself, trigger a whole case. In Dark Hours/Asterly, this synchronization breakdown was one of the technical causes behind weeks of ongoing dispute.
• The App Review Board upholding a rejection is a sign the process worked. An appeal's existence doesn't guarantee an outcome; in the Asterly case, the Board upheld the rejection for the same reason in April 2026 — a reminder that appeal is not "automatic relief," but a second, independent evaluation.

FAQ

How should I read an App Store rejection correctly?

Treat the guideline number in the rejection message as the basis, and compare it against the actual content of the build you last submitted — not your own idea of the product. In Dark Hours/Asterly, the real problem was the gap between the app the developer described and the build Apple actually reviewed; the rejection text is based on the submitted build, not the developer's memory of it.

How does the appeal process for a rejection work?

The one thing concretely known from this case: Asterly went through an appeal, and the App Review Board upheld the original rejection in April 2026. This shows the appeal mechanism works, but doesn't guarantee an outcome — an appeal filed without removing the problematic content risks being rejected again for the same reason.

How should I write review notes?

State clearly which feature was removed or changed in each new submission, note which guideline clause it addresses, and provide an up-to-date demo account for flows that require one. This case shows how complicated the process gets when the review notes and the submitted build are out of sync.

"Are fortune-telling/astrology apps completely banned on the App Store?"

No. Guideline 4.3(b) defines fortune-telling as "saturated" and asks new submissions to differentiate meaningfully from existing apps — not a categorical ban. Apple itself has even published an editorial list highlighting astrology apps on the App Store.

How much should I trust an "unfair rejection" claim from a journalism/blog source?

This case is a textbook cautionary example. Even from a reputable source, a one-sided, secondhand narrative can turn out wrong; where possible, cross-check the claim against the relevant guideline text and, if available, the developer's actual submission history.

Conclusion

The Dark Hours/Asterly case lays bare a common trap in App Store rejection discussions: read the rejection reasoning against the actual build you submitted, not your own idea of the product. Go deeper on discoverability with the App Store Optimization (ASO) guide, on post-submission subscription management with the App Store Connect Subscriptions guide, on automating TestFlight and submission with App Store Connect API Automation, and on IAP with the StoreKit 2 Production Guide. For a real-numbers success story, see I Made $1M on the iOS App Store; to harden your build pipeline, see Xcode Cloud Pipeline Optimization.

Sources

• Daring Fireball — App Store Rejection Retraction — The case's full chronology, Godier's edits, the App Review Board's April 2026 decision, and Gruber's apology.
• Apple Developer — App Store Review Guidelines — 4.3(b) saturated categories, 1.1.6 fake/prank functionality, and demo account requirements.
• Apple Developer — App Review — Guideline 2.1's share of unresolved review issues and average review time statistics.
• Hacker News — item 49214863 — Community discussion of the case, with quotes referencing the App Review Board's response.
• Apple — Best Astrology Apps — Apple's editorial list highlighting astrology apps.
• Terry Godier — Mea Culpa: Dark Hours — Godier's apology post dated August 9, 2026: the naming collision and the web app's AI-generated origin.