◇ App Dev/2026-06-16Advanced

Staging Wallpaper Packs Before the First Launch: Where Rork Max and Background Assets Fit

Content-heavy apps tend to greet new users with an empty grid. Background Assets downloads content out-of-band, ahead of the first launch. Here is how I implement it in Rork Max's native Swift, a domain Rork (Expo) cannot reach easily, plus how I decide when it is worth it.

Rork Max¹⁶⁶ Background Assets iOS⁸¹ Swift²⁵ Content Delivery

✦ Premium Article

There is one moment in running wallpaper apps that bothered me for a long time: the instant a user finishes downloading the app and opens it for the very first time.

I do not want to bundle heavy content like images directly into the app binary. It bloats review and distribution, and every update reships tens of megabytes to every user. But if I move to a "fetch from the server after launch" design, the first launch now shows the user an empty grid and a spinner. Giving the impression of "an app with nothing in it" in those first few seconds is, as someone running many content-driven apps as an indie developer, a quiet but real loss.

iOS has a dedicated mechanism for exactly this requirement: download content out-of-band from the app binary, and do it without waiting for the first launch. It is called Background Assets. And this is precisely a domain where Rork (Expo / React Native) cannot reach cleanly, which makes the case for Rork Max's native Swift generation concrete.

Why pre-launch prefetching is hard within Expo

When people hear "download content ahead of time" in Expo, most reach for expo-background-task or an expo-file-system download. I started there too. The problem is that both are scheduled only after the app process has launched at least once. They cannot intervene before the user first opens the app, right after install or update. The window just before the first launch, exactly where I most want content ready, stays blank.

What makes Background Assets special is that it steps into that window. After an install or update completes, the system launches a download extension that is separate from the app, and fetches content even while the user has not opened the app. Because that process is independent of the app itself, you can have content staged before the first launch.

This "runs as a separate bundle from the app" structure is the wall in Expo. Background Assets lives in an App Extension tied to the Background Assets framework, and you need a separate Swift target conforming to the BADownloaderExtension protocol. In theory you could inject the extension at prebuild with an Expo config plugin, but once you include launching, communicating with, and testing the extension, you end up writing roughly as much Swift as a native implementation. I see this as a clear example of the boundary between "ship fast with Rork (Expo)" and "go deep with Rork Max (native Swift)."

Rork Max is the product that leans toward generating native Swift on top of Claude Code and Opus 4.6. Like WidgetKit or Live Activities, Background Assets is a textbook case of "out of reach for the React Native common denominator, but with a proper path natively," so adding an extension target onto Rork Max's output was the realistic route.

Background Assets comes in two generations

Before the implementation, let me clear up a point that is easy to confuse. Background Assets has two broad modes, with different OS support and different operations.

The first is the long-standing unmanaged (self-hosted) mode. You place content on your own server or CDN, build the download URLs inside BADownloaderExtension, and handle completion yourself. You own distribution and versioning entirely. This API has been usable for a while and suits teams that already have their own delivery infrastructure.

The second is Managed Background Assets, which came into its own in iOS 26. You group content into units called asset packs, bundle them with the packaging tool that ships with Xcode, and upload them via Transporter or the App Store Connect API. The system (and, if you choose Apple hosting, Apple's side) manages distribution, updates, and compression. Apple hosting includes up to 200 GB per app within the Developer Program, and asset packs can be distributed and updated independently of the app build. In other words, you no longer have to resubmit the app just to swap content.

An app like my wallpaper apps, where images are the star, content is added regularly, but the code barely changes, pairs well with managed plus Apple hosting. On the other hand, if you already have a self-hosted delivery pipeline on something like Cloudflare and want fine-grained control over distribution logic, unmanaged keeps you in command. Let us start with the unmanaged code, since the mechanics are easier to follow.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Understand how Background Assets downloads content separately from the app binary, and why this is hard to do within Expo

✦Learn a working BADownloaderExtension implementation and how to split essential vs non-essential downloads

✦Get a decision framework, based on content volume and update cadence, for moving to iOS 26 Managed Background Assets (Apple hosting, up to 200 GB)

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Implementing BADownloaderExtension

The minimal unmanaged setup is a class conforming to BADownloaderExtension. On app install or update, the system calls this class, and you hand "what should be downloaded now" to BAManager.

import BackgroundAssets
 
@main
struct WallpaperDownloaderExtension: BADownloaderExtension {
 
    // Called by the system right after install/update.
    // Reserve the "essential content to stage before the first launch" here.
    func backgroundDownload(
        for request: BAContentRequest,
        manifestURL: URL,
        extensionInfo: BAAppExtensionInfo
    ) -> Set<BADownload> {
        guard let manifest = try? loadManifest(from: manifestURL) else {
            return []
        }
 
        var downloads: Set<BADownload> = []
        for entry in manifest.essentialPacks {
            let download = BAURLDownload(
                identifier: entry.id,
                request: URLRequest(url: entry.url),
                essential: true,                 // must be ready before first launch
                fileSize: entry.byteSize,
                applicationGroupIdentifier: "group.net.rorklab.wallpaper",
                priority: .default
            )
            downloads.insert(download)
        }
        return downloads
    }
 
    // Called each time one download finishes.
    // The standard move is to relocate the file into the App Group container.
    func backgroundDownload(
        _ download: BADownload,
        finishedWith fileURL: URL
    ) {
        guard let shared = FileManager.default.containerURL(
            forSecurityApplicationGroupIdentifier: "group.net.rorklab.wallpaper"
        ) else { return }
 
        let destination = shared
            .appendingPathComponent("packs", isDirectory: true)
            .appendingPathComponent(download.identifier)
 
        try? FileManager.default.createDirectory(
            at: destination.deletingLastPathComponent(),
            withIntermediateDirectories: true
        )
        // The extension sandbox is cleared after it exits, so always move into the shared area.
        try? FileManager.default.moveItem(at: fileURL, to: destination)
    }
 
    func backgroundDownload(
        _ download: BADownload,
        failedWithError error: Error
    ) {
        // Hand essential failures off to the app-side fallback (on-demand fetch).
        BALogger.shared.record(download.identifier, error)
    }
}

After building this, what struck me as more important than the official description is the meaning of the essential flag. A download marked essential: true is one the system tries to guarantee is complete before the first launch. The flip side is that piling a lot of content here lengthens the "time until install finishes" as the user perceives it. Marking only the bare minimum I want visible the moment they open it as essential (in my case, the dozen-odd images at the top plus a few thumbnails per category) and pushing the rest to essential: false for a relaxed moment after launch was the split that balanced perceived speed against install completion rate.

Reading staged content from the app itself

The files the extension downloaded live in the App Group container. The app reads from there first, and falls back to the server only if it is missing. A two-tier design.

enum WallpaperStore {
    static let groupID = "group.net.rorklab.wallpaper"
 
    static func localURL(for packID: String) -> URL? {
        guard let shared = FileManager.default.containerURL(
            forSecurityApplicationGroupIdentifier: groupID
        ) else { return nil }
        let url = shared
            .appendingPathComponent("packs", isDirectory: true)
            .appendingPathComponent(packID)
        return FileManager.default.fileExists(atPath: url.path) ? url : nil
    }
 
    // Show instantly if already staged; fetch on demand if not.
    static func loadPack(_ packID: String) async throws -> URL {
        if let cached = localURL(for: packID) { return cached }
        return try await OnDemandDownloader.fetch(packID) // the old fallback
    }
}

With this two-tier design, users for whom Background Assets did not finish in time (storage pressure, slow connection, essential failure, and so on) silently fall back to the old on-demand fetch. I have come to feel it is safest to treat Background Assets as "an accelerator that dramatically improves the first experience when it works," not "a foundation that breaks the app when it fails." In practice, users where Background Assets finished in time saw essentially zero wait on the first grid, and users where it did not simply dropped back to the same experience as before.

Should you move to iOS 26 Managed Asset Packs?

Once the mechanics are clear with unmanaged, the next call is whether to move to managed. Managed lets you bundle asset packs with the Xcode packaging tool, upload them, and delegate download resumption, prioritization, and eviction under storage pressure to the system. Choose Apple hosting and you do not even need your own CDN.

I use roughly three axes to decide.

First, whether content updates can be decoupled from app releases. Asset packs distribute and update independently of the app build, so you no longer queue for review just to add images. If you swap content several times a week, that alone can justify the move.

Second, how much of the distribution logic you want to own. Managed is easier, but timing and fine-grained branching are left to the system. If you have strong needs like A/B serving different packs or shipping different content per region, staying unmanaged with your own CDN keeps you nimble.

Third, total volume. Apple hosting includes up to 200 GB per app, so an image-centric app fits comfortably. If you carry large volumes of video or 3D assets and approach the ceiling, you need to estimate it at the design stage.

For myself, I am settling into a split: wallpaper-style apps, where the code is largely stable and only images keep growing, lean toward managed plus Apple hosting, while experimental apps where I want fine distribution control stay unmanaged.

Where testing tends to trip you up

Finally, let me share the testing side, which wears you down more than the implementation itself. Background Assets only fires naturally on the real install/update path, so reproducing "pre-launch download" in the simulator during development is awkward. I split the extension's download-reservation logic into pure functions covered by unit tests, and verify end-to-end on TestFlight builds.

The other place that snags people is validation on the Transporter / App Store Connect side. If an asset pack's metadata does not meet the requirements, it is rejected at upload time. Reading the validation message calmly and checking the packaging settings (identifier, supported platforms, size) one by one usually traces back to a missed setting.

If you want a first step, list just a dozen pieces of content you want on the very first screen of the first launch, and write a minimal BADownloaderExtension that downloads them as essential. Once you watch the empty grid disappear, you develop a feel for how much to push into prefetch.

Thank you for reading. I hope it helps anyone wrestling with the first-launch experience of a content-heavy app.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.