Unity Android vs iOS Publishing: What Every Game Developer Needs to Know Before Launch
Shipping a Unity game to app stores looks simple on paper. You build a project, press a button, and upload the result. In practice, publishing on Android and publishing on iOS are two almost entirely separate journeys, each with its own tooling, review culture, monetization rules, and performance headaches.
If you’re a solo developer, a small indie studio, or someone who has picked up a Unity template and wants to get it live quickly, understanding these platform differences up front will save you weeks of rejected builds, confused testers, and lost revenue. This article walks through the technical, procedural, and business-side differences between Android and iOS publishing in Unity — and where the real friction points tend to show up.
Two Ecosystems, One Engine
Unity’s biggest selling point is “write once, deploy everywhere.” That promise holds up reasonably well at the code level — your gameplay logic, UI, and core systems can largely stay platform-agnostic. But the moment you move from writing code to actually shipping a product, the illusion of “one build for everywhere” falls apart.
Android and iOS are built on different operating systems, different hardware philosophies, different app review processes, and different monetization frameworks. Unity abstracts a lot of the low-level engine work, but it cannot abstract away Apple’s manual human review, Google’s fragmented device ecosystem, or the very different compliance expectations each store enforces. Treating an Android build and an iOS build as identical projects with a different icon is one of the most common mistakes new developers make, and it’s usually the first thing that trips up a first-time submission.
1. What You Need on Your Machine to Build
The starting point for these two platforms couldn’t be more different.
For Android, Unity Hub can install everything you need — the Android SDK, the NDK, and OpenJDK — directly from the editor. You can build and test an APK on Windows, macOS, or Linux without owning any specialized hardware. This flexibility is part of why so many developers start with Android: the barrier to your first working build is low.
Inside Player Settings for Android, a handful of configuration choices matter more than the rest:
- Minimum API Level, which decides how far back your game supports older devices
- Target API Level, which Google raises periodically and strictly enforces for new submissions
- Scripting Backend, where IL2CPP has effectively become mandatory for most Play Store submissions due to 64-bit requirements
- Target Architecture, where ARM64 is required and ARMv7 remains useful for supporting older hardware
iOS removes that flexibility entirely. You cannot compile, sign, or submit an iOS build without a Mac running Xcode — not because Unity chooses to restrict you, but because Apple’s toolchain simply doesn’t run anywhere else. Unity generates an Xcode project from your build, and from that point forward, the actual compiling, code signing, and archiving all happen inside Xcode on macOS before the build ever reaches App Store Connect.
The iOS-specific settings you’ll be dealing with include your target minimum iOS version, signing and provisioning profile configuration (which requires an active paid Apple Developer Program membership), and architecture settings, which on modern devices means ARM64 exclusively.
The practical upshot: if you don’t already own a Mac, you’ll need to either borrow one, rent time on a cloud-based Mac build service, or budget for buying one before you can finish an iOS release. This single requirement changes the shape of many developers’ entire release timeline.
2. Getting Through App Review
This is where the two platforms diverge most sharply in day-to-day experience.
Google Play’s review process is largely automated. Google is primarily scanning for policy violations — malware, deceptive functionality, disallowed content, and privacy issues, particularly around how accurately your Data Safety disclosures reflect what your app actually collects. Approval typically lands somewhere between a few hours and a couple of days, and outcomes are fairly predictable if you’ve followed policy correctly.
That predictability has narrowed somewhat in recent years. Newer developer accounts are often required to run a closed test with a minimum number of testers before they’re allowed to publish publicly. Target API level requirements are enforced strictly at submission time, and the Data Safety section needs to genuinely reflect your data practices, not just a generic template answer.
Apple’s process could not be more different. Every submission goes through a manual, human review, typically completed within 24 to 48 hours — but rejections are common, especially for first-time or first-few submissions. The usual culprits include incomplete or misleading store metadata, crashes or obvious bugs found during review, violations of Apple’s Human Interface Guidelines, a missing or incomplete privacy “nutrition label,” and problems with in-app purchase implementation, an area where Apple is notoriously particular.
If your game has any login system, Apple will also expect a working demo account for reviewers to test with. And if your app uses ads or in-app purchases, you’ll need to correctly implement the App Tracking Transparency prompt.
The practical lesson here is simple: give yourself buffer time on iOS, especially for your first couple of submissions, and don’t schedule a marketing push around your very first App Store submission date. A rejection on a minor technicality is common enough that it shouldn’t derail your plans — but it will delay them if you haven’t accounted for it.
3. Monetization: Two Billing Systems, Two Sets of Rules
Monetization is one of the more technically fiddly differences between the platforms, and it’s where a lot of developers lose time debugging SDK quirks that have nothing to do with their actual game logic.
On Android, any in-app purchase has to go through Google Play Billing. Unity IAP integrates with it, but you’ll need to create matching in-app products inside the Google Play Console, make sure product IDs line up exactly between your Unity project and the console, and stay on top of billing library version updates — Google periodically deprecates older versions and forces a migration.
On iOS, purchases run through Apple’s StoreKit. The setup in App Store Connect follows a similar product-ID-driven approach, but with its own quirks: your tax and banking information has to be fully completed before IAP products can go live, and subscription-based products come with stricter rules than one-time purchases.
Ad monetization has its own platform-specific wrinkles too. iOS requires the App Tracking Transparency flow to be implemented correctly, and how users respond to that prompt directly affects your ad fill rates and eCPM. Android is more lenient about tracking permissions, though Google enforces its own strict policies around content ratings and ad placement.
Get Unitysourcecode’s stories in your inbox
Join Medium for free to get updates from this writer.
If you’re setting up Unity IAP for the first time — particularly inside a pre-built template — getting product IDs, store-side configuration, and receipt validation correct across both platforms tends to be the single biggest source of early monetization bugs. It’s worth testing purchase flows in sandbox mode on both stores before you ever consider going live.
4. Performance: Fragmentation vs. Consistency
If there’s one technical difference that separates Android and iOS publishing more than any other, it’s hardware fragmentation.
Android spans an enormous range of devices, from high-end flagships with powerful GPUs down to budget phones with limited RAM and aging graphics hardware, many of which are still in active daily use across large markets. A build that runs at a silky 60 frames per second on a flagship device can drop to a crawl on a low-end one if you haven’t optimized for it.
Addressing that fragmentation usually means reducing texture sizes and using appropriate compression formats such as ASTC or ETC2, batching aggressively to cut down draw calls, scaling particle effects and shadow quality based on a detected device tier, and — critically — testing on real physical devices rather than relying solely on emulators, which don’t always reflect real-world thermal and performance behavior.
iOS is a different world. Apple controls both the hardware and the software, and at any given time there’s a relatively small, well-defined set of device models still in active use. That makes performance testing dramatically simpler: if your game runs well on a couple of representative iPhone models, you can be reasonably confident about the rest of your iOS install base.
That said, iOS isn’t free of performance concerns. Apple’s devices tend to have less thermal headroom for sustained heavy workloads, so long play sessions with demanding shader work can trigger thermal throttling — something worth explicitly testing for if your game leans on visually intensive effects.
5. Signing and Certificates
Android apps are signed using a keystore file. Since 2021, Google Play has required Play App Signing, where Google holds and manages your app’s actual signing key while you upload builds signed with a separate upload key. This setup has mostly solved the old nightmare scenario where losing your keystore meant losing the ability to ever update your app again — but backing up your credentials is still non-negotiable best practice.
iOS signing involves more moving parts: developer certificates, App IDs, and provisioning profiles for development, ad hoc, and distribution builds. Xcode’s Automatic Signing feature handles most of this for solo developers without much friction, but larger teams or anyone running a CI/CD pipeline often end up managing these pieces manually, which adds a layer of complexity that simply doesn’t exist on the Android side.
6. Testing Before You Launch
Google Play offers Internal, Closed, and Open testing tracks, which let you roll builds out to specific groups of testers before a full public release. As mentioned earlier, many newer developer accounts are now required to run a closed test with a minimum number of opted-in testers for a set period before production publishing is unlocked.
Apple’s equivalent is TestFlight, which supports up to 10,000 external testers per app. TestFlight builds still go through a lighter version of Apple’s review before external testers can install them, but that review is generally faster than a full App Store submission.
Whichever platform you’re targeting, it’s worth running both testing pipelines seriously — not only to catch bugs, but to get early feedback on your store listing itself. Icon choice, screenshots, and description copy have an outsized effect on conversion rates, and it’s much cheaper to fix that before launch than after.
7. Store Listings, Pricing, and Revenue Share
Both Google Play and the App Store take a standard 30 percent commission on paid apps and in-app purchases, reduced to 15 percent for developers under certain annual revenue thresholds through Google’s Play Media Experience Program and Apple’s Small Business Program respectively — though eligibility criteria are worth double-checking since they can shift over time.
Store listing requirements diverge in smaller but meaningful ways. Google Play gives you more flexibility with feature graphics, promotional videos, and both short and long descriptions, and it supports staged rollouts for updates. Apple enforces stricter screenshot dimensions per device type and tighter rules around what your app preview video can contain.
Pricing structure differs too. Apple uses fixed pricing tiers applied consistently across countries, while Google Play allows much more granular, country-by-country pricing control.
8. Updating a Live Game
Once your game is live, the review pipeline doesn’t go away — it just repeats for every update. Android updates are usually reviewed within hours, and Google’s staged rollout feature lets you release to a small percentage of users first to catch problems before a full rollout. iOS updates go through the same full manual review as your original submission, typically 24 to 48 hours, though Apple does offer an expedited review request for critical fixes. It’s not guaranteed, though, and shouldn’t be treated as a dependable part of your regular release process.
This difference matters a lot if you’re running a live-ops style game with frequent balance tweaks or event content — Android simply lets you iterate faster.
Common Mistakes Worth Avoiding
A few patterns show up again and again with first-time publishers on both platforms: treating the store listing as an afterthought instead of a serious conversion tool, skipping testing on real low-end Android hardware and getting hit with poor reviews as a result, overlooking Apple’s privacy nutrition label requirements and triggering avoidable review delays, mishandling platform-specific code instead of cleanly separating logic with Unity’s #if UNITY_ANDROID and #if UNITY_IOS preprocessor directives, and skipping proper IAP sandbox testing on both stores before launch, which tends to surface as broken purchase flows right after release.
Building From Scratch vs. Starting From a Ready-Made Project
Here’s the honest truth: building a genuinely polished, store-ready Unity game from the ground up — and then correctly configuring it for both Android and iOS — is a serious time investment, even for developers who’ve done it before. That’s exactly why a lot of solo developers and small studios choose to start from an already-built Unity project rather than assembling every system from zero.
Starting from a proven, previously published template means the core mechanics, UI, monetization hooks, and platform-specific build settings are already in place and tested. Your time goes into reskinning, tuning gameplay, and marketing, rather than debugging low-level engine or store configuration issues.
If you’d like a closer look at how a hybrid puzzle mechanic gets structured for a cross-platform release, this breakdown of a Solitaire 2048 Unity game template is a good example of how a lightweight, casual mechanic can be packaged for fast Android and iOS deployment. And if you’re more interested in a heavier, style-driven genre, this cyberpunk car racing game project shows how a more visually demanding title handles the performance and optimization considerations discussed earlier in this article — particularly relevant if you’re weighing how far to push visual fidelity against Android’s hardware fragmentation.
Final Thoughts
Publishing a Unity game successfully on both Android and iOS isn’t really a technical checklist — it’s about understanding two genuinely different ecosystems, each with its own review culture, hardware realities, and player expectations. Android rewards developers who can handle device fragmentation and want fast iteration cycles. iOS rewards polish, consistency, and strict adherence to Apple’s guidelines.
If you’re just starting out, the fastest way to internalize these differences is to work with a project that’s already been correctly configured for both platforms, rather than debugging every platform quirk on a brand-new game built entirely from scratch. Studying how an already-optimized, cross-platform-ready Unity project is structured — from build settings to monetization hooks — gives you a real, working reference you can learn from while also having something you can actually launch and monetize.
