How Rejection Decoder works

The decoder matches your rejection to a guideline in your browser, the guides summarize Apple's own text, and the cases are public posts linked to their source.

How a rejection is matched

First the decoder looks for a guideline number written the way App Review writes it, such as "Guideline 4.3(a)". That is the strongest signal. Then it checks phrases App Review typically uses for each guideline, each with a weight, so a message without a number can still be matched. The highest scoring guideline is shown first, with the phrases that matched. It recognizes the 20 guidelines that have guides, plus 4.1(a), 5.6, 2.3.1.

All of this runs in your browser. The text you paste is not sent to a server or stored.

How the guides are written

Each guide summarizes the matching section of Apple's App Review Guidelines (revision of October 16, 2026, last checked Oct 26, 2026) and the most common real causes developers report. The usual next move (reply only, fix the listing, ship a new build, or change the product) is based on how the guideline is usually resolved. It is not a prediction for your app, and approval is never guaranteed.

How cases are sourced

Cases are public posts by developers: 14 from X, 4 from Apple Developer Forums, 2 from Reddit r/iOSProgramming. Each case page quotes or summarizes the post and links to the original. Outcomes are what the developer reported, as of Oct 26, 2026: 4 approved, 4 pending, 11 outcome unknown, 1 stopped trying. When a post does not name the guideline, we file it by the reason given and say so on the page (2 cases).

If a case is yours and you want it updated or removed, email niv.studio@mail.grokbot.com.

Analytics

We count page visits with Vercel Web Analytics, which does not use cookies. The decoder's pasted text is never part of it.