Trimming App Size for Rork Max Apps: App Thinning and On-Demand Resources

Using the asset catalog correctly

The first move is to pull the loose images out of the bundle root and into the asset catalog. Assign each image to its 1x / 2x / 3x slot inside Assets.xcassets, and Slicing will deliver just the one variant a device needs.

// ❌ Common right after generation (bundle root, not sliced)
Image(uiImage: UIImage(named: "hero_background.png")!)
 
// ✅ Through the asset catalog (no extension, Slicing applies)
Image("hero_background")

When you find an image loaded by a filename with an extension, that is the signal it points at the bundle root. Re-register it in the asset catalog and reference it by name without the extension. That alone stops the huge 3x image from shipping uselessly to 1x and 2x devices.

Apply the same scrutiny to fonts. It is common to double-bundle the same family as separate files for body and heading, or to leave a weight you stopped using. Trim down to the weights actually rendered on screen and several megabytes simply vanish.

Moving the first download off your back with ODR

Large resources that Slicing cannot cut go to On-Demand Resources (ODR): a tutorial video, extra theme packs, the high-resolution wallpaper sets you do not need on first launch.

With ODR you tag assets and fetch them when needed. After setting the tag on the resource in Xcode's asset catalog, you request it from code like this.

import Foundation
 
final class ThemePackLoader {
    private var request: NSBundleResourceRequest?
 
    func loadThemePack(tag: String) async throws {
        let req = NSBundleResourceRequest(tags: [tag])
        // Observe req.progress if you want to show a UI indicator
        self.request = req
 
        let available = await req.conditionallyBeginAccessingResources()
        if available {
            return            // Already present on the device
        }
        try await req.beginAccessingResources()
    }
 
    func release() {
        request?.endAccessingResources()
        request = nil
    }
}

There are three points worth stressing. First, conditionallyBeginAccessingResources checks whether the pack is already fetched, so you avoid a pointless re-download. Second, you must call endAccessingResources when finished or the benefit of ODR fades. Third, the fetch can fail on a weak network, so always provide a path that falls back to a low-resolution copy bundled in the app. In production, a review from someone whose fetch failed on the subway will reflect exactly whether you designed that fallback.

In my case I recommend bundling only the default theme and moving the extra wallpaper packs — about 40MB in total — to ODR. The first download gets lighter, and the extra packs are fetched only by people who want them, so average traffic drops as well.

Setting a size budget and running it

Trim once and forget, and the app grows again. So I run a per-app size budget. The table below is the target I use for my own indie wallpaper apps.

With this budget in place, every time you add a screen you can decide on the spot whether an image is bundled or ODR. The judgment stops depending on memory, and you avoid the slow creep.

Trimming while you measure

Cutting by feel is dangerous, so always read the numbers. Xcode's Organizer has an App Size Report showing per-device delivery size and what occupies it.

# Export the post-thinning size from an archive
xcodebuild -exportArchive \
  -archivePath MyApp.xcarchive \
  -exportPath ./thinned \
  -exportOptionsPlist thinning.plist
# In thinning.plist set <key>thinning</key><string>&lt;all-variants&gt;</string>

Open the resulting App Thinning Size Report.txt and you get per-device compressed and uncompressed sizes. I record these numbers on every release and track the delta from last time. If it grew, the first suspect is the assets from a screen I added recently.

Measuring also surfaces surprises. In one app, 12MB of unused localization images was still sitting in the asset catalog, referenced from nowhere in code. Without the report, I would probably never have noticed.

Knowing where to stop

A final word on where to spend effort. Size reduction has no natural floor. But the line users actually feel is fairly fixed: whether the first download crosses the cellular warning, and whether they can start using the app right after launch. Hold those two and further effort yields less and less.

I keep three things at the top: make Slicing reliably apply, move only the obviously large resources to ODR, and keep recording the size budget. The rest is polish for when there is spare time.

Start by searching your own Rork Max project for any image still loaded with a file extension. That is the first step toward reclaiming size. Thank you for reading.