Title, Subtitle and Description Under Regulatory Review

The asymmetry that dictates the sequence: Google Play lets you change title, short description and long description whenever you like, and test them against live store traffic. Apple does not. Title, subtitle and keyword field change only with a new version submission and review, and Apple's Product Page Optimization tests icons, screenshots and preview videos, never text. So store text is testable on one platform and a considered bet on the other. The order of work here follows from that and is not negotiable: establish the text on Play where it can be read, then port the surviving decisions into the next iOS release rather than spending a review cycle on a guess. What the title and subtitle are for: Thirty characters each, carrying ranking weight and the first conversion read simultaneously. The common failure is treating those as two jobs and letting the keyword win. A subtitle packed to rank will move you two positions and cost four points of conversion, a net loss you will not see unless you watch impression to page view and page view to install as separate rates. I write the pair together and tell you explicitly which one I traded away and by how much. The long description Apple never reads: Four thousand characters, indexed by Google, ignored entirely by Apple. On Play it is a ranking asset that also has to survive being read by somebody who scrolled past the screenshots looking for a reason to trust the app. For a medical device app that is where the device class, the CE marking, the notified body and the data handling statement belong, and they belong early rather than as compliance sludge at the bottom. For this buyer that material is the conversion argument. Consumer app copywriters bury it, which is exactly backwards in these categories. Promotional text, which most teams forget they own: One hundred and seventy characters on the App Store, editable without a release, not indexed. It is the only lever available between iOS releases, and it is where a market entry, a regulatory approval or a new integration goes. Teams that do not use it are shipping releases they did not need to ship. Regulatory review is inside the process, not after it: Metadata for an MDR-regulated app is labelling in several jurisdictions. Copy leaves here as a marked-up document showing which phrase carries which claim risk and what the alternative formulations are, so your reviewer holds a decision meeting rather than issuing a rejection. If nobody is named as the reviewer, I will ask you to appoint one before I write a word. Change control: One variable per release. If the title changes in the same release as the screenshots, the read is confounded and you will spend the following quarter arguing about which one did it. I will decline to ship both together and tell you which goes first. Not included: Keyword research, which precedes this and is scoped separately. Screenshot and icon design. Localisation into other languages. Editorial featuring submissions. Who should not buy this: Teams who want copy inside a week with regulatory kept out of it. And teams whose description problem is actually a positioning problem. If the product team cannot say in one sentence which user this is for, no title fixes that, and I will send you back to settle it rather than write elegantly around the gap.