Direct answer
A project's target platforms field accepts both App Store (iOS) and Google Play (Android) at once, so one project can generate listing copy for both stores from the same description, category, tone, and competitor inputs instead of duplicating a project per platform. This keeps the two listings consistent in positioning and claims while still letting each platform's output respect its own field-length and formatting conventions.
Why one project beats two parallel ones
Running App Store and Google Play as separate projects means every input — description, tone, competitors — has to be kept in sync by hand every time the app changes. A single project with both platforms selected reads from one shared set of inputs, so a description update or a tone change applies to both outputs at once instead of needing to be copied across two projects and inevitably drifting.
What stays shared and what doesn't
| Stays shared across platforms | Adapts per platform |
|---|---|
| App description, category, competitors, brand tone | Field lengths and store-specific copy conventions |
| Screenshot style and recipe selection | Store-specific metadata limits (title/subtitle vs. short description) |
When separate projects make sense instead
If an app genuinely has different positioning per store — a different target audience, a different feature set, or a different pricing model between iOS and Android — that's a real reason to run two projects rather than force one shared input set to cover two different products. Sharing inputs only helps when the underlying app story is the same on both platforms.
Common mistakes
- Creating two projects for the same app "to be safe," then letting the descriptions drift out of sync after the first edit.
- Selecting only one platform out of habit and then manually copying output into a second store listing instead of letting the project generate both at once.
Checklist
- Confirm both platforms are selected if the app is genuinely the same product on iOS and Android.
- Only split into two projects if positioning, audience, or pricing actually differs by store.
- After any input change, regenerate both platform outputs from the same project rather than hand-editing one to match the other.
Operating rule
One project per app story, not one project per store — split projects only when the underlying product story actually diverges.