How to Publish Games on All Platforms Simultaneously

Publishing a game on all platforms simultaneously means shipping the same project to PC, mobile, web, and console on a single release date. The surprising part is that the build is usually not the bottleneck — modern engines export one project to every target. The real difficulty is coordination: every store has its own account, its own submission process, and, critically, its own review window, and the longest of those dictates your launch date.

The strategy that actually works is to start from one codebase, open developer accounts on every store you intend to ship to, and work backward from your target launch date through the longest review window — usually console certification, sometimes a first App Store submission. This guide covers what "all platforms" means, the fees and timelines for every major store, and a realistic launch calendar, with every figure grounded in each store's published terms.

What "all platforms" actually means#

"All platforms" is not one thing. It is four tiers, each with different requirements, audiences, and revenue models.

Tier	Platforms	What you need to ship
PC	Steam, Epic Games Store, itch.io, GOG	A Windows (and often macOS/Linux) build, store pages, trailers, age ratings
Mobile	Apple App Store (iOS), Google Play (Android)	An IPA and an Android App Bundle, plus device screenshots and privacy disclosures
Web	Browser (HTML5), itch.io	An HTML5 build; lowest friction, lowest revenue per user
Console	Xbox, PlayStation, Nintendo Switch	Approved developer status, a devkit or partner kit, and platform certification

Each tier multiplies your testing surface. The realistic question for an indie is not "all of them, day one" but "which tier is my game built for, and which can I add next?"

Start from one codebase#

Simultaneous publishing is only feasible if you build the game once and export it to each target. Maintaining a separate codebase per platform is how ports turn into separate projects that drift apart. The good news: every serious 2D engine already does cross-platform export.

Engine	Desktop	Mobile	Web	Console
Unity	Yes	Yes	Yes	Yes (with approved devkits)
Godot	Yes	Yes	Yes (HTML5)	Yes (via publishers/porting)
MonoGame	Yes	Yes	Limited	Yes (used in shipped console titles)
Defold	Yes	Yes	Yes	Yes
Egmatic	Yes	Yes	Yes	Roadmap

The rule: one project, one content source, per-target packaging. The logic, levels, and assets are shared; only the final package (IPA, AAB, Steam depot, HTML5 bundle) and a thin layer of platform-specific code differ. If your engine cannot export to a target you care about, that target is not on your launch list — switch engines before you switch platforms. Our guide to multiplatform export goes deeper on this prerequisite.

The stores: accounts, fees, and review windows#

Here is the practical landscape, with figures from each store's published terms as of 2026.

Store	Account fee	Revenue share	Typical review
Apple App Store	$99 / year	30% standard; 15% under $1M/year (Small Business Program); 15% on subscriptions after year one	24–48 hours, human review
Google Play	$25, one-time	15% on first $1M/year, then 30%; 15% on subscriptions from day one	A few hours to 2 days
Steam	$100 per app (Steam Direct, recoupable)	30% under $10M; 25% from $10M–$50M; 20% above $50M	A few days for store page and build review
Epic Games Store	$0 to publish	12%; 0% on the first $1M/year per app (since 2025)	Approval-based, days
itch.io	$0	You choose the cut, 0–100%; default 10%	Near-instant; no approval gate
Consoles	$0 per app, but approved developer status required	Typically 30% (varies by agreement)	Weeks — full platform certification

A few details that catch people out:

• Apple requires a Mac. Building and uploading an iOS app goes through Xcode on macOS. There is no first-party way around this for App Store builds.
• Google Play now requires closed testing. New personal developer accounts must run a closed test with at least 12 testers before they can submit to production — plan for that lead time on your first Android release.
• Consoles are gated. You cannot simply upload to Xbox, PlayStation, or Switch. You apply to a partner program — ID@Xbox for self-publishing on Xbox, the PlayStation Partners program for Sony, and the Nintendo Developer Portal for Switch — sign an NDA, and get access to devkits and certification requirements. Certification is thorough and runs to several weeks.

In account fees alone, launching on Apple, Google, and Steam in your first year costs about $224 ($99 + $25 + $100). Adding Epic and itch.io costs nothing extra. Consoles cost no listing fee but require approved status and a devkit.

The coordination problem: work backward from launch#

The reason true simultaneous launches are hard is that review windows do not line up. Work backward from your target date:

Target launch date:               Day 0
Console certification submit:     Day -28 to Day -42   (longest pole)
Steam build + store page submit:  Day -14 to Day -21
App Store first submit:           Day -14              (leave room for rejections)
Google Play production submit:    Day -7 to Day -10
Final build freeze:               Day -10 to Day -14

The store with the longest review window governs your whole timeline. If you want console in the day-one launch, you submit to console certification a month or more ahead. If you cannot, you ship PC and mobile on day one and let console follow — this is the most common indie pattern, and it is not a failure of "simultaneous"; it is a deliberate staged launch.

A realistic launch sequence#

1. Pick your day-one platforms based on what your engine exports to and where your audience is. A 2D casual game leans mobile-first; a deeper indie title leans PC-first.
2. Open every developer account early. Apple, Google, Steam, Epic, itch.io can all be set up before your game is done. Console partner-program applications can take weeks to approve, so apply first.
3. Build one project, export per target. Generate the IPA, AAB, PC build, and HTML5 bundle from the same source.
4. Prepare store assets once. Screenshots, trailers, descriptions, age-rating questionnaires, and privacy policies — reuse them across stores with platform-specific sizing.
5. Submit in reverse order of review length. Console first (if applicable), then Steam, then Apple, then Google. Each store should clear review before day zero.
6. Set release dates to match. Each store lets you choose a release date. Align them. Use "limited release" or phased rollout on Google Play to control the first hours.
7. Test on real devices per platform. A build that runs on your dev machine can still fail a touch-device certification check or a console TRC/TCR.
8. Have a rejection plan. First submissions get rejected — often for metadata, privacy, or age ratings rather than the build. Budget time for one re-submission per store.

"Simultaneous" versus "staged": pick the right strategy#

Strategy	What it is	When it fits
True simultaneous	Every store goes live on one date	You have console certification cleared and enough QA to support every platform at once
PC first, then mobile	Ship Steam/itch on day one, mobile weeks later	Deep gameplay that benefits from a PC audience and early feedback before a mobile port
Mobile first, then PC	Ship App Store/Play first, PC later	Casual game whose audience is on phones; PC version as a premium later
Early Access on PC, full launch everywhere	Sell an unfinished PC version, then 1.0 across all platforms	Game that benefits from real-player iteration; common for simulation and strategy

Do not treat "simultaneous" as a virtue in itself. A staged launch where each platform gets the attention it needs usually ships a better game than a stressed day-one-everywhere push.

The mistakes that derail a multiplatform launch#

• Chasing true simultaneity when staging is smarter. Holding a finished PC build for six weeks to wait for console certification costs momentum and revenue.
• Underestimating console certification. It is weeks, not days, and it is strict. Plan for it or leave console for a later phase.
• Ignoring packaging differences. iOS needs an IPA from Xcode on a Mac; Google Play needs an Android App Bundle; Steam needs its depot format. These are not interchangeable.
• Forgetting privacy and age ratings. The single most common reason for App Store and Google Play rejection is an incomplete privacy policy or missing data-disclosure form, not the build itself.
• Skipping per-platform device testing. Touch controls behave differently from keyboard and mouse. A PC build does not prove the mobile port works.
• Leaving tax and payout setup to the end. Each store requires tax forms and bank details before you can be paid. Setting these up at launch is too late.
• Not budgeting review rejections. Plan for at least one re-submission per store on a first launch.

Where Egmatic fits#

Egmatic is built around the "one project, every target" model that simultaneous publishing depends on. You build the game once — scenes, logic, and assets authored in the editor and serialized to JSON — and export that same project to desktop, mobile, and web. Because the open engine consumes the same JSON data on every target, you are not maintaining per-platform forks; the content you tested is the content you ship.

That removes the worst part of multiplatform work, which is divergence between platforms. You still submit to each store individually and clear each review window, but you are submitting the same game in different packages rather than parallel codebases. If you want the foundation first, our guide to publishing games without coding and the complete iOS and Android strategy cover the submission side in detail.

Conclusion#

Publishing on all platforms simultaneously is a coordination problem more than a technical one. Build from one codebase, open accounts on every store you intend to ship to, and work backward from your launch date through the longest review window — usually console certification. Know the fees ($99/year Apple, $25 Google, $100 Steam Direct, free on Epic and itch.io) and the revenue shares (Steam's 30/25/20% tiers, 12% on Epic, your chosen cut on itch.io), and respect that review windows of hours, days, and weeks do not align. Pick true simultaneity only when you can clear every window; otherwise stage deliberately. Do that, and "everywhere on day one" stops being a scramble and becomes a schedule.