Special Character Checker

Apple’s guideline 2.3.7 covers metadata accuracy and explicitly calls out app names: they must be limited to 30 characters and must not include prices, terms, or descriptions that are not the name — and in practice reviewers apply it to emoji-decorated names, symbol borders (★彡), and trademark or claim characters used as ornaments. The rejection is rarely permanent, but it costs a full review round-trip, which is an expensive price for a sparkle emoji.

The riskiest single category is stylized unicode letters — the 𝓯𝓪𝓷𝓬𝔂 and 𝗯𝗼𝗹𝗱 alphabets from the mathematical symbol blocks that some developers use to fake formatting in names and subtitles. They violate metadata policy on both stores, they break search entirely (a name written in 𝗯𝗼𝗹𝗱 letters does not match a search typed in normal ones), and they are mangled by screen readers, making the listing inaccessible.

Text assembled from web pages, Word documents, and translation tools accumulates invisible unicode: zero-width spaces and joiners, left-to-right and right-to-left marks, non-breaking spaces, and BOM characters. In a keyword field, a zero-width space inside “fitness” means Apple indexes a string that no user will ever type — the keyword silently earns nothing while occupying its characters.

These characters are undetectable by eye and survive most copy-paste chains, which is why a codepoint-level scan belongs in your pre-submission routine, especially for localized metadata that has passed through translators and spreadsheet round-trips. Where do special characters remain fine? Description bodies: unicode bullets, arrows, checkmarks, and emoji section markers are conventional there on both stores — the policy pressure is on names, titles, and subtitles.