Synth Anatomy reported on November 12, 2026, that two iOS music-app developers had encountered repeated App Store rejections involving allegedly nonexistent licensing requirements, hardware demands and template-app classifications. The accounts name Michael Hetrick of Unfiltered Audio and CRUX Synth developer Marek Dendes, giving developers specific cases to examine beyond general complaints about slow reviews.
The central allegation remains unconfirmed: Apple has not confirmed that AI or automation generated the challenged decisions. The available reporting relays the developers’ accounts, without establishing how Apple produced the responses. Two cases also cannot establish how App Review behaves across the store. An incorrect rejection and an AI-generated rejection are different claims, and the evidence so far supports only the former.
Apple’s own documentation nevertheless provides a useful comparison, including a consequential warning for anyone appealing: submitting again can close an existing appeal.
What the Synth Developers Reported
Sinusoidal Run Rhythm: Four Rejections and a Reduced Release
According to Synth Anatomy’s report, Hetrick described four rejections of Unfiltered Audio’s Sinusoidal Run Rhythm in a Loopy Pro forum post. He opened with a qualified allegation:
“Apple seems to be using AI for automated App Store reviews.”
His account describes a sequence of increasingly disputed requirements:
- First rejection: App Review requested a demonstration video, something Hetrick said commonly happens with the company’s plugins.
- Second rejection: The reviewer allegedly treated the term “Polyharmonic” as licensed audio technology and requested documentation authorizing its use.
- Third rejection: Another video request allegedly required the app to be connected to “required proprietary hardware,” which Hetrick disputed.
- Fourth rejection: The MIDI variant, SRR MIDI, was reportedly classified as spam because of its similarity to the audio version.
Hetrick said the exchanges lasted more than a month. He ultimately released the audio-only version and described a plan to bundle the MIDI build into the same app binary so both AUv3 plugins would install together. At the time of Synth Anatomy’s report, the separate MIDI version remained unavailable.
That is a concrete product consequence: the reported review dispute affected which functionality reached customers. The proposed packaging change also shows how a rejection can influence software distribution, even when the developer disputes its premise. It was a plan, however, not evidence that Apple had accepted that configuration.
CRUX Synth: Repeated Template and Spam Findings
Synth Anatomy also attributed four consecutive rejections to Marek Dendes, the developer of CRUX Synth. His account described design-spam and template-generation objections, near-instant rejection responses and appeals that had gone unanswered.
These allegations concern classification as much as speed. A developer arguing that an original synthesizer has been mistaken for a template-generated app needs to resolve the basis of that classification. Simply submitting the same build again may leave the disputed finding untouched.
My view is that the strongest part of these accounts is the specificity of the alleged mistakes. A demand for a particular license or piece of hardware can be checked against an app’s actual requirements. The speed or wording of a rejection, by itself, offers much less evidence about whether AI was involved.
Apple’s Review Goals Are Not Release Deadlines
Apple’s published App Review documentation says the service works around the clock, with a goal of reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. Apple also says some submissions require longer verification.
Those figures provide context, but they need to be compared with the developers’ timelines carefully.
| Published Apple guidance | What it means for these cases |
|---|---|
| At least 50% of submissions should be reviewed in under 24 hours, and 90% in under 48 hours. | These are submission-review goals, not a promise that an app will be approved and released within two days. |
| Apps with little or no review history may need additional verification. | Apple documents a reason some submissions take longer, but that does not explain any particular rejection here. |
| Licenses, authorizations and other documentation may need verification. | Documentation requests are part of the published process. The dispute in Hetrick’s account is whether the requested license was relevant or existed. |
| Complex or novel issues can extend review. | A longer review can fit Apple’s published process; its duration alone cannot identify an internal cause. |
Hetrick’s reported month of back-and-forth is an end-to-end release delay, potentially spanning several review cycles. Apple’s percentages concern submissions. Treating those measurements as identical would exaggerate what the comparison shows.
The same distinction applies to rapid rejections. A response arriving almost immediately can satisfy a speed target while leaving the developer with an unresolved objection. Review speed and review accuracy are separate questions.
For release planning, I would treat Apple’s published percentages as a useful expectation, not a dependable launch commitment. A review cycle can end in a request for information or a rejection, leaving further work before publication.
Warning Signs Worth Documenting
The two accounts suggest several useful things to record when a review appears mistaken. None is a reliable AI detector; their value is in making a dispute specific enough to investigate.
- Repeated, near-instant rejections: Save submission times, status changes and the exact rejection text. Timing can establish a pattern without proving what produced it.
- A disputed licensing requirement: Identify the precise term or feature involved, explain its role in the app and ask which authorization Apple believes is required.
- A hardware demand that does not match the product: State whether external hardware is necessary and provide a clear demonstration of the supported setup.
- A spam or template finding involving related builds: Explain the functional differences between the submissions, including why users would need each one.
Apple recommends providing complete information and required documentation in the App Review Information section before submission. A concise setup description is particularly useful when a reviewer needs to understand how a music app or plugin is intended to operate.
I’d focus a response on the disputed premise: what hardware the app needs, what the term means, or what makes the builds functionally different. That gives Apple something concrete to reassess. Arguing first about whether the response sounds AI-generated leaves the underlying rejection unresolved.
A Resubmission Can Close Your Appeal
Apple’s documentation contains a detail that deserves more attention than the headline review-time percentages: resubmission changes the process.
When App Review requests more information and there are no other issues to resolve, Apple says developers should reply directly in App Store Connect. A fresh submission starts a new review, after which App Review can no longer reply to the previous message.
Frequently Asked Questions
3 questions
1Has Apple Confirmed That AI Caused These Rejections?
No. The reported AI involvement is an allegation from developers. Apple has not confirmed that AI generated the challenged decisions.
