Mobile apps are the only software product where a stranger's opinion of your writing is published permanently underneath it. App store copy is read in a scrolling feed against six competitors, permission prompts are answered in a second by someone who has been trained to refuse, and every unclear onboarding screen shows up as a one-star review that will still be visible in three years. The constraints are unusually brutal too: thirty characters for a title, a screenshot caption read in half a second, and a review process that can reject a release over the wording of a privacy label.

We edit what mobile teams produce — app store listings, titles, subtitles and descriptions, screenshot captions and preview video scripts, keyword and localisation copy for multiple stores, onboarding and first-run experience text, permission request prompts and pre-permission explanations, paywall and subscription copy including renewal terms, in-app messaging and push notification text, error and offline state messages, privacy labels and data disclosure declarations, release notes, review responses and support replies, and internal design documentation and specifications. Our editors check that store descriptions match what the app actually does at first launch, and that subscription terms are stated where store policy requires them rather than only in the terms of service.

The permission prompt sequence is where mobile writing produces its most measurable effect, because a refused permission is usually permanent and often disables the feature the user installed the app for. The system dialogue itself gives you one short line, which is why the priming screen before it matters so much. We rewrite these so the app asks only at the moment the permission is needed rather than in a block at launch, so the priming screen states the benefit to the user in their terms — "so we can show you journeys from where you are standing" rather than "to enable location-based features" — and so it names what the app does not do with the data, since the reason people refuse is usually a fear the prompt never addresses. We also write the refusal path properly, because the user who said no must still be able to use the app and must be told plainly how to change their mind later.

Everything you send is treated confidentially, including unreleased apps, store listings under embargo and internal specifications. Whether you are an independent developer writing your own listing, a studio preparing a launch across several markets, or a team whose onboarding is losing users before the first screen, we can make every constrained piece of text do more work.