Mobile Game Technical Limits: Frame Budgets, Build Size and Store Rules for Unity Projects

Mobile Game Technical Limits: Frame Budgets, Build Size and Store Rules for Unity Projects

> Quick Summary: A mobile game has 16.7 milliseconds per frame at 60 frames per second and 33.3 at 30. On Google Play the base download is capped at 200 MB, with up to 4 GB in asset packs; on iOS, users are asked to confirm downloads over 200 MB on mobile data. Android builds must be 64-bit, which in Unity means IL2CPP with ARM64. Store limits are as of November 2026.

These are the limits I design against when building games such as Tilting Jar, SUNTHREAD and BEEing in Unity. They are facts of the platform, not preferences.

Frame time budget

• 60 frames per second: 16.7 ms per frame for everything: game logic, physics, rendering, UI.
• 30 frames per second: 33.3 ms per frame.
• 120 frames per second (high refresh displays): 8.3 ms per frame.
• A frame that takes longer than its budget is dropped; players see it as a stutter.
• Phones slow themselves down when they get hot. A game that holds 60 for two minutes and 40 after ten has a thermal problem, not a rendering problem. Test for at least 15 minutes on a real mid-range device.
• Garbage collection pauses are the most common cause of single dropped frames in Unity. Avoid allocating memory every frame.

Build size

• Google Play, base module: up to 200 MB compressed download in an Android App Bundle.
• Google Play, asset packs: up to 1.5 GB each and 4 GB in total, delivered at install time or later through Play Asset Delivery.
• iOS: above 200 MB, users on mobile data are asked to confirm the download. Fewer of them finish it.
• In Unity, textures and audio are almost always the bulk of the build. Compression format and maximum texture size change the build far more than code does.
• Casual and hyper-casual games convert best when the first download is well under 150 MB.

Rules the stores enforce

• 64-bit only on Android. Google Play has required 64-bit code since August 2019. In Unity: scripting backend IL2CPP, target architecture ARM64.
• Target API level. Google Play requires new apps and updates to target a recent Android version, and raises the bar every year. An old Unity version can leave you unable to ship an update.
• Android App Bundle. New apps on Google Play must be uploaded as an AAB, not an APK.
• Privacy forms. Ad and analytics SDKs collect data. Both the App Store privacy details and the Google Play Data safety form must list what those SDKs collect, not only what your own code collects.
• Games aimed at children fall under stricter advertising and data rules on both stores.

Memory

• The operating system closes a game that uses too much memory, without an error message. On phones with 3 to 4 GB of RAM, staying under roughly 1 GB of use is a safe working target.
• Texture memory is the usual culprit. One uncompressed 2048 by 2048 texture uses 16 MB; with modern compression (ASTC) it uses a fraction of that.

Pre-release checklist

1. Holds target frame rate for 15 minutes on a mid-range Android phone and on the oldest iPhone you support
2. First download under 200 MB on both stores
3. IL2CPP and ARM64 enabled for Android
4. Target API level meets the current Google Play requirement
5. No memory allocation in per-frame code paths
6. Privacy forms list every SDK that collects data
7. Game pauses and resumes correctly after a phone call or app switch
8. Ads and purchases tested with real store test accounts

Frequently Asked Questions (FAQ)

I build mobile games in Unity and C#, from playable prototype to store release. The games are listed on the home page.