Guideline 2.3.7 is one of the easier metadata rejections to walk into by accident. It covers metadata that misrepresents the app, and in our experience the most common way small teams trip it is not with a misleading screenshot or a false claim, but with a name or subtitle that has been quietly stretched to carry search terms it doesn't need to carry. The reviewer opens the listing, sees a name like Notes Pro: Notepad, Journal, Memo, Notebook, To Do, Diary, and flags it. The app itself is fine. The metadata isn't.
At Olnesta Ltd we ship small apps, and every time we've prepared a submission we've had the same short argument with ourselves about the subtitle. There is real pressure to make those thirty characters do search work, because they're visible on the product page and they influence discovery. But the name and subtitle fields are not the keyword field. They are the fields a human being reads to understand what the app is. When they stop reading like a description and start reading like a list, review notices.
What the field is actually for
App Store Connect gives every app a dedicated keyword field, up to 100 characters, comma-separated, that users never see. That is where search terms belong. It exists precisely so that you don't have to jam synonyms and category words into your public-facing name to be findable. If your app is a habit tracker and you also want to rank for routine, streak, and daily goals, those words go in the hidden field. They do not need to appear in the subtitle, and putting them there is what turns a clean submission into a 2.3.7 conversation.
The practical test we use before submitting: read the name and subtitle out loud as a single sentence. If it sounds like something a person would say when describing the app to a friend, it's probably fine. If it sounds like a search query pasted into a text box, it's probably going to be rejected, or at minimum flagged for revision. Finch: Self-Care Pet passes that test. Finch: Self Care Pet Mood Journal Habit Diary Wellness does not, and we've watched enough teams learn that the hard way to treat it as a real constraint rather than a stylistic preference.
What review is actually looking at
Our reading, based on what we've seen come back on our own submissions, is that reviewers are looking at two things when they invoke 2.3.7 on a name or subtitle. The first is redundancy: the same word or its close variants appearing more than once across the name, subtitle, and sometimes the promotional text. The second is category-word pileups, where the subtitle is a comma or bullet list of every noun a user might search for, rather than a phrase. Either pattern is enough on its own. Both together is essentially a guaranteed rejection.
What this means in practice is that the fix is almost always to shorten, not to argue. If the subtitle has been rejected for keyword stuffing, you will spend less time appealing than you will rewriting it to be an honest description in a normal English phrase and resubmitting. We've never seen an appeal on this specific issue go faster than a rewrite. And once the offending words are moved into the keyword field where they belong, the search coverage you were worried about losing is largely still there, because that field is what search was reading anyway.
A quieter listing tends to age better
The secondary reason to keep the name and subtitle clean is that they age differently from the keyword field. Keywords can be updated with each version submission without much friction. A name that has been stuffed with trending category words is harder to walk back later, because changing it feels like losing ground on search even when the current wording is what's suppressing conversion. We've found that listings which read like a product read like a product for years, and listings that read like SEO read progressively worse as the surrounding App Store evolves around them.
None of this is exotic advice. It's just that the pressure to squeeze one more term into thirty visible characters is constant, and the hidden keyword field is easy to forget about because you never see it after you fill it in. Treat the name as the app's name, the subtitle as one honest phrase about what it does, and the keyword field as the place where the search work actually happens. Submissions get simpler, and 2.3.7 stops being a category of rejection you meet by surprise.