I fancy myself a calm and collected person. Mellow. Only very few things on this good earth rile me up enough to make me want to punch my Mac’s screen. But boy, is Apple’s App Review consistently one of them.
Prologue
I recently released ScreenFloat v2.3.8. I submitted it to the Mac App Store on July 16th, 2026, and later that day, it was reviewed and approved by App Review without any issues. I published it on July 20th.
As sometimes sadly happens though, right after the release, I noticed a crashing bug. It’s sort of obscure, but prominent enough that I would have been uneasy had I not fixed it right away. I’ll skip over the part where I panic and curse myself for missing it – that’s my own personal hell.
I fixed the bug (one line of code!) and re-submitted to Apple with an expedited review request, which was granted.
Chapter I – The Devil Is In The Details. But Where Are They!?
The update eventually entered review and was fairly soon afterwards rejected for the following reason:
This is an automated message. The review of this submission cannot proceed. See below for more information.
An automated analysis of the submission indicates the app includes placeholder or otherwise insufficient purpose strings.
Purpose strings must clearly and completely describe your use of data.
Take one of the following actions:
- If the app needs access to a protected resource that requires a purpose string, revise the purpose string to explain how the app will use the resource and provide a specific example of how the data will be used. Then resubmit for review.
- If the app does not need access to a protected resource that requires a purpose string, remove the code that’s accessing the resource and the purpose string from the binary. Then resubmit for review.
Aside from the fact that it took me a second to understand what the automated message (a first for me, by the way) meant by “purpose strings”1, I was flabbergasted.
Which purpose string does the automated process deem “insufficient” or a “placeholder”?
What does “insufficient” even mean here? Is a purpose string not clear, or too short, or not easily understandable? Is it grammatically incorrect? Is it in a localization, or the English language version?
What’s a “placeholder” considered to be in this context?
Is it objecting to my use of the protected resource, or my user-facing sentence?
Which protected resource is it objecting to in the first place?
It’s painfully ironic that they require my strings to “clearly and completely describe” my use of data, when they themselves so marvelously fail to do so.
You know what’s “insufficient”? Your freaking automated message!
They might as well have told me “Something’s preventing us from further reviewing your app. Good luck finding it, asshole!”.
Even if I only had one purpose string in my app, this would have been annoying, because that detail would help quite a bit in knowing where to look and what to change.
But I have several of them. ScreenFloat is a screen capture app, so it can record your screen, and, if you tell it to, your microphone and system audio. (And, if you enable it, your key strokes during recording, but that doesn’t need a “purpose string”.)
In addition to those, the app has a Face ID purpose string, because folders in ScreenFloat can be locked and unlocked with biometrics. It has a Pictures folder purpose string for the specific case where a v1-library-import fails for certain files, so the app can move those there.
It has an Apple Events purpose string so the app can use and interact with Shortcuts. Lastly, it has a Contacts purpose string, because ScreenFloat can Quick Look vcards encoded in QR codes, and that only works with that Contacts entitlement, otherwise no preview is shown, or worse, the app crashes. Don’t ask me why.
Long story short, ScreenFloat needs all those purpose strings, and I believe they are worded correctly. After all, they have been like this ever since they first shipped.
So I reworded two purpose strings to demonstrate goodwill, and re-submitted.
Chapter II – They’re Just Trying to Break Me Now
Another rejection. This time from an actual person. Or so I believe. It didn’t say “automated message” this time around. I’m not sure if getting escalated from an automated rejection to a human one is reason to rejoice, or to worry even harder. But I digress.
The rejection this time was much clearer, but just as infuriating.
The app uses one or more entitlements which do not appear to have matching functionality within the app.
[…]
com.apple.security.personal-information.addressbook
I see.
Apparently, App Review completely ignored – or is ignorant of – the fact that in App Store Connect2, there’s a section called “App Sandbox Information”, specifically designed for the purpose of telling App Review what entitlements your app uses, and why.
I have this. See here:
So pardon my French, but it’s freaking right there.
But I did as they did, and ignored this.
I gave them the same (paraphrased) reason via reply-to-the-rejection, and now the app is “Waiting for Review” again. What a waste of time.
Epilogue
I cannot stress enough how frustrating these inconsistent app reviews are.
If you recall from the beginning of this post, just 5 days ago, on the 16th, I submitted basically the same binary, and it went through without a hitch.
Now, a few days later, with a one-line change in the binary to fix a crash, I have two rejections for stuff that has been in the app since I can’t even remember when.
What gives, App Review?
Why waste my (and your) time with asking for info on an entitlement, when it’s already there?
Why not object to it at the very first review of that entitlement with v2.0, instead of out-of-the-blue, after goodness knows how many updates in between?
What’s with that absolutely disgusting and disrespectful automated message with no details whatsoever?
What happened between July 16th and today, five days later!?
And most importantly of all: why won’t you let me release my one-code-line-crash-fixing app update for ScreenFloat already!?
- Purpose strings are the strings that are displayed to users when requesting protected resources, like the microphone, camera, etc.
There should be a different term for this than “purpose strings”. How about “Usage Description string”, since that’s how they’re defined in code, like “NSMicrophoneUsageDescription”? That would make it way more recognizable to developers. ↩︎ - The place where developers submit their apps to App Review. ↩︎
[…] You can find the blog post here. […]