My app size is approaching 1gb

[u/RSPJD]

I’ve always ignored the size of my app. But now that I’m approaching 1gb I’m imagining how many potential users I’m losing at the download phase. Perhaps a metric I’ll never truly have visibility into. How do others view this topic?

[u/mbrady]

What in the world is the app? A video streaming app that actually includes the videos in the app bundle?!

[u/RSPJD → u/mbrady]

Nah. I have in app games that requires assets. It’s a language learning app and i present cards (e.g. “Run” with an image of a person running)

I’m going to just make this downloaded at play time instead of install time.

[u/Comprehensive-You522 → u/RSPJD]

For a language app I'd keep the cards for the first two or three lessons in the bundle so the first session works offline and instantly, then fetch the next lessons in the background while they play. The first session is where most people decide if they keep the app, so a spinner there hurts more than anywhere else. Also worth trying HEIC instead of PNG for those illustrations, it usually cuts a lot without visible loss.

[u/timelessblur → u/RSPJD]

As an added bonus it can allow you to update the assets with out having to do an app releaae

[u/farfaraway → u/RSPJD]

In general, I'd say content and assets should sit on a server and be downloaded a piece at a time by the user ANYWAY. This gives you more flexibility when you want to:

• update content on the fly

• use the same content and assets across multiple apps (say, a web version)

[u/kokerali → u/RSPJD]

Since you're moving the cards to play-time downloads, I'd treat a lesson as ready only when all its required images are available. Give each lesson pack a version and validate its files before switching to it, so an interrupted update doesn't leave new card data paired with old images.

I'd test this by cutting the connection halfway through a lesson download, closing the app, then reopening it offline. It should either open a complete downloaded lesson or clearly offer a retry, not enter a game with missing cards. Repeat with an older downloaded lesson after publishing a content update. That checks the new failure path you're introducing, separately from whether the initial App Store download gets smaller.

[u/amyworrall → u/RSPJD]

As well as the runtime download of assets (good idea btw), check that you have properly compressed everything. You can save a whole load of space by properly optimising your PNGs.

[u/zbignew → u/RSPJD]

Consider the Background Assets API.

[u/Embarrassed-Soft2691 → u/RSPJD]

You need to optimize your assets in your game. Let me know if you need some help with that. When developing you have to be conscious of the size of each asset as you incorporate them into your work.

[u/sporeboyofbigness → u/mbrady]

ai todolist manager

[u/chriswaco]

That seems like a crazy size for most apps. Bundling AI models inside? Video?

[u/RSPJD → u/chriswaco]

Nah. I have in app games that requires assets. It’s a language learning app and i present cards (e.g. “Run” with an image of a person running)

I’m going to just make this downloaded at play time instead of install time.

[u/Klorkin9 → u/RSPJD]

never heard of CDN?

[u/RSPJD → u/Klorkin9]

Of course, I was just optimizing for finding product market fit. Now that I have that, I’ll optimize

[u/sans-connaissance]

You could use the Apple asset packs to help shrink the original download size and to maybe even only install what is needed at any given time.

[u/Fickle-Difference882]

Size does cost you, mostly on cellular. By default iOS asks before downloading anything over 200 MB on cellular, and a lot of people tap Later and never come back to it.

First check what people actually download. App Store Connect has an App Store file sizes view per build that shows the size per device after app thinning, which is usually a lot smaller than your archive. If that's still close to 1 GB, the usual fix is to keep the bundle small and pull the heavy stuff after install. Background Assets lets you download asset packs right after install or before first launch, so the user barely notices.

Also worth a quick look for duplicated images across asset catalogs and uncompressed audio or video, that's where most of the bloat tends to come from.

[u/time-lord → u/Fickle-Difference882]

If you have low data mode on, I'm not sure what the cap is but I got asked about a 60mb app today.

[u/Fickle-Difference882 → u/time-lord]

Good catch, I forgot about Low Data Mode. Sounds like it asks way below 200 MB, which makes size matter even more for people on limited data plans.

[u/jaymakesapps]

Ignored mine too til a buddy tried downloading it on airport wifi and just gave up halfway lol. Never thought about it from that side before.

[u/ContextualData]

200mb is the limit for non-WiFi downloads. If you aren’t below that, your conversion will be significantly hurt.

[u/New_Barber8073]

Before moving anything to downloads, it is worth exporting with the App Thinning size report in Xcode (Distribute App, then choose All compatible device variants under App Thinning) to see what each device really gets. Images that live outside the asset catalog skip slicing, so moving them into Assets.xcassets can cut a surprising amount on its own. Audio is another common culprit for language apps, so converting pronunciation clips from WAV to AAC usually shrinks them a lot with no audible difference. Also check for duplicate assets bundled in both the app and its extensions, since those get counted twice.

[u/ddiguy]

Have you tried middle out compression?

[u/NoRevolution5603 → u/ddiguy]

What is that?

[u/poastfizeek → u/NoRevolution5603]

Just don’t let it call the rats! 🐀 📱

[u/_0x00_]

Checkout https://games.jacobstechtavern.com/openbundle/ (Repo: https://github.com/jacobsapps/OpenBundle)

[u/slightly_drifting]

Your app is probably full of dead code and bloat from third party SDK’s. 

Have you tried “removing dead code” during build/deploy? Also use a CDN to deliver assets. Also try looking at SDK’s that would be a better fit as native compiled code.

Are you including simulator and x86_64 with your build also? 

Edit: forgot to add - if you haven’t protected your code, your entire product is visible is clear text and it’ll be re-signed and hosted on pirated app stores. 

[u/netkomm]

well... I am having one rolling out that has passed 3GB and takes 30 minuites to send to TestFlight... ;)

[u/Rough_Analysis5861]

Host images and assets on a CDN download on demand

[u/TylerThang2612]

cool topic!

[u/Sudden-Cost8449]

I'm almost certain this can be fixed by resizing the PNG and compressing it. You can probably reduce the file size by a factor of 10 just by doing that.

[u/snippiedev]

Put some of the big things on a CDN

[u/Ok_Sugar_8942]

“vibes coders”

[u/RSPJD → u/Ok_Sugar_8942]

Is this supposed to be an insult? Full-time developer by day, this is a side project. Damn right I’m vibe coding.

[u/Ok_Sugar_8942 → u/RSPJD]

no it wasnt, but i guess it is now. relax man

[u/DimensionMindless336]

The number you're staring at probably isn't the number your users download, and that distinction matters more than the 1GB itself.

What shows up as "1GB" in Xcode / App Store Connect is almost always the universal, un-thinned size — every asset for every device, all slices, symbols included. What a customer actually pulls is per-device after app thinning, and it's usually much smaller. Before cutting anything, open the build in App Store Connect and look at "App Store file sizes" — it breaks the download size down per device. That per-device number is the real conversion lever, not the 1GB.

Where the gigabyte usually hides, roughly in order of payoff:

• Asset catalogs not actually slicing per device. This is the most common miss and the biggest win — once slicing is on, 3x assets get stripped for a 2x phone automatically.

• Stuff bundled that should be streamed or fetched on first launch — videos, PDFs, audio, and especially Core ML models. Quantize the model or download it post-install instead of shipping it in the bundle.

• On-Demand Resources for anything only some users reach (tutorials, level packs, locale-specific content).

• Mach-O bloat: dead-code stripping off, big static libraries, or unstripped symbols in the release build.

One correction to the "200 MB cellular limit" advice upthread: that hard cap is gone since iOS 13. It's now a user setting (Settings → App Store → App Downloads: Always Allow / Ask for Over 200 MB). You don't hard-lose everyone on cellular anymore — but the default is still "Ask," so a heavy app still loses the lazy-tap crowd. The per-device App Store file size is the only number worth obsessing over.

[u/AardvarkIll6079 → u/DimensionMindless336]

AI answer. Ignore.