The rejection that wasn't about the name you can see

A Mac app rejected for its name, when its name was already right. Diagnosed, fixed and approved within two days.

CapLoc is my own app, sold on iPhone and Mac under one purchase. On 25 August 2026 Apple rejected the Mac version under guideline 5.2.5: the app name shown on the device must not contain "Mac".

The name users see (the display name) already read "CapLoc". Changing it would have done nothing. The usual instinct, renaming the app or the bundle, would have been wrong too: changing the bundle identifier breaks the shared purchase across iPhone and Mac and makes Apple treat it as a new app.

The Mac target had no product name set, so Xcode fell back to the target’s own name. The app was being built as "CapLocMac.app", and that is the name a reviewer sees in Finder. The visible label was right; the file underneath it wasn’t.

I set the product name on the Mac target only and left the bundle identifier alone. Checking the rebuilt project turned up two more problems: regenerating it had silently removed the export-compliance setting and rolled the build number back below what Apple had already received. Both had been hand-edited into generated files, so I moved them into the project definition, where a regeneration can’t erase them. Then I rebuilt through Xcode Cloud and resubmitted the same day.

Approved about 26 hours after resubmission and live on the Mac App Store. The iPhone version was approved later under the same purchase, as planned, because the bundle identifier was never touched.

A rejection message names a guideline, not a cause. Most of the work is finding the real cause and avoiding a fix that creates a new problem. Send me your rejection and I’ll tell you, free, within 24 hours what’s behind it and what it will take.