Build a mobile app landing page that the app stores will accept
An app's website does two jobs at once. For people, it shows what the app does and sends them to the right store. For Apple and Google, it supplies the privacy policy and support addresses their submission forms ask for. Anticode builds the page, writes a starting privacy policy for it and gives you a contact form for support.
What's different about an app's site
Most launch pages end in a sign-up or a purchase. A mobile app landing page ends in a hand-off: the visitor leaves for the App Store or Google Play, and the install happens there. So the page doesn't need to close the sale on its own. It needs to make the store visit worthwhile, and to carry the pages that the stores and your users will come back for long after launch day.
Those back-office pages are easy to forget. Apple's App Review Guidelines expect apps to link a privacy policy, and App Store Connect asks for a support URL with every app. Google Play's user data policy also requires a privacy policy for apps that handle personal or sensitive data. If the addresses you submit go nowhere, or point at a document that doesn't describe the app, review can stall.
Sections that earn their place
- Headline and store badges
- Say what the app does in one line, then the official App Store and Google Play badges side by side. Use the artwork each company provides and follow their rules on size and spacing; don't redraw or recolour them.
- Real screenshots
- Three to five phone screens, in the order someone would meet them: the first screen, the main task, the result. Mock-ups of an unreleased screen set expectations you'll then have to meet.
- What it does, briefly
- Three short points tied to screens, such as "log a ride in two taps" beside the logging screen. Skip the generic icon grid.
- Who it's for and what it costs
- Free, free with in-app purchases, or paid. People decide whether to tap the badge based on this, so say it on the page.
- Support
- A contact form or email address, the expected reply time, and answers to the two or three questions you already get.
- Privacy policy
- Its own page, linked from the footer, describing what the app collects, not only what the website collects.
Screenshots and media
Upload your screenshots to the build. Anticode checks each file by its first bytes and stores it under your account; the model looks at the screenshots when it arranges the page, so it can put the right screen beside the right point. A screen recording can't play on a design-engine page, so host it on YouTube or Vimeo and link to it. Export screenshots at the same device size so they line up, and crop out the status bar clutter if it distracts.
Write alt text that says what each screen shows ("the weekly summary screen, showing distance and time per ride"). The design gate won't let the page publish with images that have none.
The privacy policy and support pages
Every published Anticode site gets its own Privacy Policy and Terms, written from what that site actually does: which forms it has, what they collect and where submissions go. That covers the website side well. Your app almost certainly collects things the website doesn't (device identifiers, location, crash reports, analytics from an SDK), so edit the policy to describe the app too, or the URL you give the store will describe the wrong product. The generated pages are a starting point, not legal advice.
For support, add the contact form must-have. Messages are saved to your project, sealed at rest and can be emailed to you; you can also route them to a Slack channel or a help-desk webhook. A support page with a real form gives reviewers and users somewhere to go, which is the point of the support URL. The guide to writing a privacy policy for a small website covers what the policy should say.
Building it with Anticode
- Describe the app: what it does, who uses it, which stores it's on. "A landing page for Spoke, an iPhone and Android app for logging bike commutes" is enough to start.
- Answer the Architect's questions, such as whether there's a paid tier and which design direction fits. The Technical or Swiss systems suit utility apps; Playful suits games and apps for children's parents.
- Add your screenshots, the badge artwork and the store links.
- Ask for a separate FAQ or Contact page if support needs more room than a footer section.
- Publish to an anticode.dev address or, on a paid plan, your own domain, then paste the privacy and support URLs into App Store Connect and the Play Console.
If the app itself was built in Anticode, its app-store packaging includes a checklist of what the stores ask for and a Capacitor project to download. Submitting is still up to you.
Limits worth knowing
- No device detection. Published pages run no scripts, so the page can't detect iPhone or Android and show only one badge. Show both; people know which is theirs.
- No smart banners or deep links. Anything that opens the installed app from the website is set up in the app and the stores, not by Anticode.
- No install attribution. Anticode counts page views by source, without cookies, but can't tell you which visitors went on to install. Use the stores' own analytics for that.
- English pages only. If your app is localised into several languages, the landing page won't be.
Questions people ask
Does a mobile app need a website at all?
In practice, yes. The stores ask for a support URL and, for most apps, a privacy policy URL. A small site also gives press, reviewers and search engines somewhere to land.
Can I use the App Store and Google Play badges?
Both companies publish official badges for this, with rules on how to display them. Download them from Apple's and Google's marketing pages and use them unaltered.
Will the generated privacy policy cover my app?
It covers what the website does. Add what the app collects and which SDKs it uses before you submit the URL to a store.