The post is about Dark Hours, a polished astronomy app for iPhone that Apple rejected under rules aimed at spammy astrology or fortune-telling apps. The absurd part is not just a category mixup between astronomy and astrology. After escalations, Apple’s review board reportedly stood by the rejection by claiming the app had a live tarot reading feature, which the developer says simply is not in the app. That turned the story from "review mistake" into "institutional inability to correct a clear mistake."
People who ship mobile apps said this felt completely normal. The recurring picture was a review pipeline that is non-deterministic, slow, and often disconnected from prior context. Developers described rejections based on old videos, screenshots from the wrong app, privacy policies that failed to render in Apple’s embedded browser, metadata nitpicks discovered one at a time, and approval times that range from hours to weeks with no obvious logic. Several pointed out that Google is not much better. It has its own arbitrary gates, including testing hurdles for personal accounts and inconsistent content ratings.
The conversation landed on a harsher conclusion than "Apple made a dumb mistake." The complaint is that Apple claims a tightly controlled store is necessary for quality and safety, yet still lets scammy subscription traps, gambling clones, and outright malware through while blocking legitimate apps for nonsense reasons. That makes the review process look less like careful curation and more like expensive, opaque bureaucracy. From there it quickly widened into the familiar fight over sideloading and alternate app stores. The strongest practical view was not that every phone should be a free-for-all. It was that users should be able to choose a locked-down default or a more open model, because the current system combines the downsides of gatekeeping with none of the promised consistency.
If mobile distribution is strategic for your company, treat store review as a product risk, not an admin step. Budget time for arbitrary delays, build fallback distribution paths where you can, and avoid assuming appeals will correct obvious mistakes quickly.
Strongly negative. Most commenters saw the rejection as proof that Apple’s review process is arbitrary, opaque, and hard to correct even when the reviewer is plainly wrong. Frustration broadened into anger at mobile app store gatekeeping in general, especially because the stores still admit scams and low-quality spam while legitimate apps get stuck.
Key insights
01
Review delay is now a release risk
Mobile teams described store review as an operational dependency you cannot make reliable. Approval can take hours or weeks, issues are often revealed one by one instead of all at once, and even account setup can drag on for months. That means release planning for mobile has to absorb queue time and random reviewer behavior the same way you would plan around a flaky third-party vendor.
Do not promise mobile launch dates or incident response windows that assume same-day review. Keep app store lead time in your roadmap, and separate fixes that need store approval from functionality you can ship through server-side changes.
The immediate rejection sounds ridiculous, but commenters pulled out the actual App Store guideline behind it. Apple explicitly calls out fortune telling, dating, timers, wallpaper, and similar categories as too crowded unless a new app offers a meaningfully different experience. The problem is not that the rule exists. It is that the standard is subjective enough that reviewers can stretch it to fit almost anything, then hide behind policy language when challenged.
If your app sits anywhere near an overfished category, prepare a clear written case for what is distinct before first submission. Put that differentiation into the review notes and product copy so a rushed reviewer has less room to map you onto a banned bucket.
What sharpened the backlash was the mismatch between Apple’s justification and observed outcomes. People pointed to scammy subscription apps, gambling clones, and documented malware that still make it into the store, while legitimate apps get blocked for invented violations. That undercuts the usual defense that strict control is the price of safety. If the store is both restrictive and porous, then developers are paying for friction without getting dependable quality control in return.
When assessing platform risk, do not count on app store review as a meaningful trust signal for users. If you sell through mobile, invest in your own trust mechanisms like reputation, support, transparent billing, and clear onboarding because the store badge is not enough.
The most concrete alternative to the current system was not unrestricted sideloading for everyone. It was a layered model where curated stores remain the default, but users can deliberately enable other sources, perhaps with granular allowlists like F-Droid. That framing matters because it shifts the debate away from the false choice between total lock-down and chaos. It treats security controls, runtime permissions, and app distribution as separate levers.
If you work on platform or policy questions, focus on designs that preserve a safe default while allowing informed opt-out. That is easier to defend publicly than abstract arguments about freedom, and it maps better to how real users vary in technical comfort.
One commenter argued the app’s presentation may have invited a fast false positive. Constellation imagery can look like zodiac symbols at a glance, and reviewers under time pressure may stop the moment they think they have a policy hit. The useful part of this argument is not excusing Apple. It is recognizing that once a bad label lands in internal notes, later reviewers may simply inherit it.
Design your first-review path as defensively as possible. Make screenshots, onboarding, and reviewer notes over-explain what the app is so a rushed pass cannot easily misclassify it.
Locked-down stores still reduce harm for nontechnical users
A minority pushed back on the easy pro-sideloading consensus by arguing that most users are highly vulnerable to social engineering. In that view, any escape hatch sophisticated users can navigate is also one scammers can coach ordinary users through. The point is not that Apple’s current process is good. It is that distribution freedom creates real consumer-protection tradeoffs that technologists often wave away too casually.
If you argue for more open distribution, pair it with a credible abuse model. You will need answers for scam coaching, deceptive prompts, and support burdens, not just principled objections to gatekeepers.
Some commenters noted that astronomy apps with “Astro” in the name still get approved, timer apps can still slip through despite policy language, and Apple’s treatment of astrology apps has changed over time. That makes the Dark Hours case look less like a coherent ban on a category and more like inconsistent enforcement by individual reviewers. The bad news is that randomness is often harder to work around than a strict rule.
Do not overfit your submission strategy to a single policy interpretation. Track reviewer outcomes over time and be ready to resubmit or reframe, because enforcement may be inconsistent even when the written rule stays the same.
daringfireball.net