Unity Android vs iOS Publishing: A Developer's Technical Breakdown

Cross-platform is one of Unity's biggest promises: write your gameplay once, deploy it to Android and iOS from the same project. That promise holds up reasonably well at the code layer. Where it breaks down is everywhere else — build tooling, signing, store review, monetization APIs, and performance behavior across wildly different hardware.

If you're a developer preparing your first dual-platform release, this is the technical rundown you need before you hit "Build." We'll go through the environment setup, store submission mechanics, IAP wiring, performance planning, and signing workflow for both platforms, along with the mistakes that trip up most first-time submissions.

Why "One Build, Two Platforms" Isn't Really True

Unity abstracts a huge amount of platform complexity for you. Input handling, rendering, physics, and most gameplay systems can stay platform-agnostic if you write them that way. But the moment you move past gameplay code into "how does this thing actually get onto a phone," Android and iOS stop looking like variations of the same process and start looking like two separate pipelines that happen to share a game engine.

Treating them identically — same build flags, same assumptions about testing, same submission timeline — is the single most common reason first submissions get delayed or rejected. Let's break down where the real divergence happens.

1. Build Environment and Tooling

Android

Unity Hub can install everything required for Android builds directly: the Android SDK, NDK, and OpenJDK. You can build and test an APK on Windows, macOS, or Linux without any special hardware, which makes Android the lower-friction platform to get your first build running on.

The Player Settings you'll actually care about:

• Minimum API Level — the floor for how old a device can be and still install your app
• Target API Level — Google raises the required minimum yearly, and enforces it strictly at submission
• Scripting Backend — IL2CPP is effectively mandatory now for Play Store submissions due to 64-bit requirements
• Target Architectures — ARM64 is required; ARMv7 is optional but still useful for older device coverage

A common pattern for separating Android-specific code from shared logic:

#if UNITY_ANDROID && !UNITY_EDITOR
    // Android-specific initialization, e.g. Play Billing setup
    InitializeAndroidBilling();
#endif

iOS

There's no way around this one: you need a Mac running Xcode to finish an iOS build. Unity generates an Xcode project as its iOS build output, and compiling, signing, and archiving all happen inside Xcode before anything reaches App Store Connect. Windows and Linux can get you 90% of the way there, but the final 10% requires macOS.

Key settings on the iOS side:

• Target minimum iOS version
• Signing & Provisioning Profiles, which require a paid Apple Developer Program membership
• Architecture, which on current devices means ARM64 only

If you don't own a Mac, this becomes a real planning constraint — you're looking at either borrowing one, renting time on a cloud Mac build service, or budgeting to buy one before your iOS release date is realistic.

2. Store Review: Automated vs. Manual

This is where the day-to-day developer experience diverges most.

Google Play review is largely automated. Google is mainly checking for policy violations: malware, deceptive functionality, disallowed content, and privacy issues — particularly whether your Data Safety form actually matches what your app collects. Turnaround is typically a few hours to a couple of days, and results are fairly predictable if you've followed policy.

A few things have tightened recently: new developer accounts frequently need to run a closed test with a minimum tester count before they're allowed to go public, target API level requirements are enforced hard at submission, and the Data Safety section needs to be accurate, not just filled in generically.

Apple's App Store review is manual and human-reviewed, typically completed in 24–48 hours, but rejections on first submissions are common. Frequent causes include:

• Incomplete or misleading metadata and screenshots
• Crashes or obvious bugs found during the reviewer's pass
• Violations of the Human Interface Guidelines
• Missing or incomplete privacy "nutrition label"
• In-app purchase implementation issues — Apple is particularly strict here

If your game has login functionality, expect to provide a working demo account. If you use ads or IAP, App Tracking Transparency has to be implemented correctly or you risk rejection.

Practical takeaway: build extra time into your schedule for iOS, especially for your first submission. Don't plan a launch marketing push around your very first App Store submission date — plan it around your first approved build instead.

3. In-App Purchases and Billing APIs

Monetization is one of the more technically fiddly parts of dual-platform publishing, mostly because Android and iOS use completely separate billing systems under the hood.

Android requires Google Play Billing for any in-app purchase. Unity IAP wraps this, but you still need to:

• Create matching in-app products inside the Google Play Console
• Keep product IDs identical between your Unity project and the Play Console
• Track Billing Library version deprecations — Google periodically forces migrations

iOS uses Apple's StoreKit. App Store Connect follows a similar product-ID model, but with its own requirements: tax and banking details must be fully completed before IAP products can go live, and subscription products carry stricter rules than one-time purchases.

A typical Unity IAP initialization pattern that works across both stores:

void InitializePurchasing()
{
    if (IsInitialized()) return;

    var builder = ConfigurationBuilder.Instance(StandardPurchasingModule.Instance());
    builder.AddProduct("coins_pack_small", ProductType.Consumable);
    builder.AddProduct("remove_ads", ProductType.NonConsumable);

    UnityPurchasing.Initialize(this, builder);
}

The product IDs (coins_pack_small, remove_ads) have to match exactly on both the Play Console and App Store Connect side — a mismatch here is one of the most common causes of "purchases silently failing" bug reports.

Ad SDKs add another layer of platform difference. iOS requires the App Tracking Transparency prompt, and how users respond to it directly affects ad fill rate and eCPM. Android is more lenient on tracking permissions but strictly enforces its own content rating and ad placement policies.

4. Performance: Fragmentation vs. Consistency

If there's one technical factor that separates Android and iOS optimization work, it's hardware fragmentation.

Android spans everything from high-end flagship GPUs down to budget devices with limited RAM and older graphics hardware still in heavy use across many regions. A build running a smooth 60 FPS on a flagship can drop into single digits on a low-end device if you haven't planned for it.

Practical mitigation steps:

• Use appropriate texture compression (ASTC, ETC2) and keep texture sizes sane
• Batch aggressively and watch draw call counts
• Scale particle effects and shadow quality based on a detected device tier
• Test on real physical devices — emulators don't reliably reflect thermal and GPU behavior

iOS hardware, by contrast, is far more consistent. Apple controls both hardware and software, and at any given time there's a relatively small set of active device models. If your build runs well on a couple of representative iPhone models, you can be reasonably confident about the broader install base.

That doesn't mean iOS is performance-worry-free, though. iOS devices tend to have less thermal headroom for sustained heavy workloads, so long sessions with demanding shaders can trigger thermal throttling — worth explicit testing if your game leans on visual effects.

5. Signing and Certificates

Android apps are signed with a keystore file. Since 2021, Google Play requires Play App Signing, where Google holds your actual signing key and you upload builds signed with a separate upload key. This mostly eliminated the old failure mode where losing your keystore meant permanently losing the ability to update your app — but backing up your credentials is still essential 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 handles most of this for solo developers, but CI/CD pipelines and larger teams often end up managing profiles manually, adding complexity that simply doesn't exist on Android.

6. Testing Pipelines

Google Play offers Internal, Closed, and Open testing tracks, letting you roll builds out to specific tester groups before a public release. As mentioned, many newer developer accounts are required to run a closed test with a minimum number of testers for a set period before production publishing unlocks.

Apple's equivalent is TestFlight, supporting up to 10,000 external testers per app. TestFlight builds go through a lighter version of Apple's review before external testers can install them, generally faster than a full App Store submission.

Use both pipelines seriously — not just to catch crashes, but to get early signal on your store listing itself (icon, screenshots, description), since first impressions have an outsized effect on install conversion on both stores.

7. Store Economics and Listing Requirements

Both stores take a standard 30% commission on paid apps and IAP, reduced to 15% for developers under certain annual revenue thresholds via Google's Play Media Experience Program and Apple's Small Business Program — eligibility criteria are worth verifying since they can change.

Listing requirements differ too: Google Play gives more flexibility around feature graphics, promotional video, and short/long descriptions, and supports staged update rollouts. Apple enforces stricter per-device screenshot sizing and tighter rules on app preview video content.

Pricing structure also differs — Apple uses fixed pricing tiers applied globally, while Google Play allows granular per-country pricing.

8. Post-Launch Updates

Android updates are typically reviewed within hours, and Google's staged rollout feature lets you release to a percentage of users first to catch issues before a full rollout. iOS updates go through the same full manual review as your original submission — typically 24–48 hours — though Apple offers an expedited review request for critical fixes (not guaranteed, and not something to rely on as standard process).

This matters most if you're running a live-ops style game with frequent balance or event changes — Android lets you iterate meaningfully faster.

Common Mistakes to Avoid

• Treating the store listing as an afterthought instead of a conversion-critical asset
• Skipping tests on real low-end Android hardware and getting hit with bad reviews post-launch
• Overlooking Apple's privacy nutrition label, causing avoidable review delays
• Scattering platform-specific logic instead of cleanly isolating it with #if UNITY_ANDROID / #if UNITY_IOS
• Skipping IAP sandbox testing on both platforms before going live

Starting From a Working Project Instead of Zero

Configuring build settings, signing, IAP, and performance scaling correctly across both platforms is a real time investment, even for experienced developers. This is a big part of why many solo developers and small studios start from an already-built Unity project rather than assembling every system from scratch — the core mechanics, UI, and platform build configuration are already in place and tested, so your time goes into reskinning, tuning, and marketing.

For a concrete example of a casual, low-complexity game already structured for a dual-platform release, this House Cleaning Unity game source code is a useful reference point — a simulation-style casual title with the kind of lightweight performance profile that maps well to the fragmentation concerns covered above.

If you'd rather look at a more technically involved genre, this technical guide to building a crowd runner combat game in Unity walks through the architecture decisions behind a more systems-heavy project, which is worth reading if you're weighing how much gameplay complexity to take on before you start thinking about platform-specific build configuration.

Quick Reference Table

Factor	Android (Google Play)	iOS (App Store)
Build machine required	Windows, macOS, or Linux	macOS with Xcode only
Review process	Mostly automated, hours to ~2 days	Manual human review, ~1–2 days
Hardware fragmentation	High	Low
Signing	Keystore + Play App Signing	Certificates + provisioning profiles
IAP system	Google Play Billing	Apple StoreKit
Testing	Internal/Closed/Open tracks	TestFlight (up to 10,000 testers)
Update rollout	Staged rollout supported	Full re-review each time
Commission	30% (15% under threshold)	30% (15% under threshold)

Wrapping Up

Publishing a Unity game across Android and iOS isn't a single checklist — it's two separate operational pipelines that happen to share a codebase. Android rewards developers who can handle hardware fragmentation and want fast iteration cycles. iOS rewards polish, consistency, and strict adherence to review guidelines.

If you're new to dual-platform publishing, the fastest way to internalize these differences is to study a project that's already correctly configured for both — build settings, signing, and IAP hooks included — rather than debugging every platform quirk on a brand-new game built entirely from scratch.