Skip to content
Back to Blog
·Updated ·2 min read

App Review rejections for other people's brands in your metadata (4.1(c), 5.2.5)

Two rejections that point at the store listing, not the code. A competitor's name in a subtitle (4.1(c)) and third-party IP in metadata and screenshots (5.2.5). What to check and what to rewrite.

Some rejections are not about the build at all. Your store listing is part of the product, review reads it by its own rules, and your build and tests never read it. We have had three in this family, from our own submissions.

  • Guideline 4.1(c) (Copycats), on a utility app update. The trigger was the store subtitle, which carried a reference to someone else's icon or brand.
  • Guideline 5.2.5 (Legal, Intellectual Property), on the first version of a new app. The metadata contained third-party intellectual property: name, subtitle, keywords, description.
  • Also 5.2.5, on a Mac screen recorder, among four findings at once. A recorder's demo material is by definition recorded other people's things: wallpaper, Dock icons, a browser, video frames. The tool's code was fine; the screenshots were the problem.

Why it survives until submission

Subtitle, keywords, description and screenshots are metadata. Compilation, tests and screenshot size checks never touch them, so "all green locally" says nothing about this surface. These fields are often filled once at creation and never reread as the product changes, so a defect can sit there until someone rereads them line by line.

What to do, in order

  1. Find the surface the message names. If it names the subtitle, do not touch code. Fix metadata findings with metadata; changing things that were not named only lengthens the next review.
  2. Audit every proper noun, screenshot and icon: "who owns this?" Only what you made yourself can be your identity. A third-party brand as part of your identity, or content closely resembling someone else's, is the exposure.
  3. Describe, do not borrow. Remove every token you do not own and say in your own words what the app does. Where you must mention another technology, state compatibility ("works with X"), not identity ("an X client"), and read that brand's usage policy first; many draw the line exactly there.
  4. Regenerate demo material from a controlled source. A clean desktop, your own sample files, generic file names. Patching old pictures leaves the same mine in the next update.
  5. If unsure, ask in the Resolution Center about the specific item, instead of guessing at a new build and resubmitting.

One-minute check

Copy out your app name, subtitle, keywords and the first line of the description, and ask for each noun: is this someone else's brand? Then open every screenshot full size and ask: do we have the right to publish everything in this frame? One third-party trademark that is also core to your identity is the same mine we stepped on.

These notes are from Obelisk Club's own submissions. Apple's wording changes; check the current App Review Guidelines and your own message for the exact terms.

Written by

Building local-first Mac & iOS productivity apps at Obelisk Club. About the author →