Developer-first Mobile App Assets

Mobile apps ship a thin binary and pull the rest at runtime: remote config images, localized asset packs, level or content bundles, promotional artwork, and downloadable resource updates that don't warrant a full App Store / Play Store release. Every one of those downloads happens on a phone, frequently over a flaky cellular link, so the dominant performance factor is edge proximity. files.link hosts these assets on permanent URLs served from a global CDN, so a user in São Paulo and a user in Berlin each fetch from a nearby point of presence rather than your origin region.

The upload side is a simple REST flow you can run from a build script or your backend's admin tooling — POST /v1/files/{folderId} returns a presigned URL and id, you PUT the asset bytes, then POST /v1/files/confirm-upload with {ids:[...]} — using your raw API key as the auth header. Versioning is best handled with explicit paths rather than mutation: upload icon assets under a v2.3 folder or with a versioned filename, so /v2.3/pack.zip and /v2.4/pack.zip each have their own permanent, aggressively-cacheable URL.

That avoids the cache-busting headaches you get when you overwrite a single 'latest' URL, and lets older app versions keep pulling the assets they were built against. From the client side, files.link is just HTTP, which means it works identically from native iOS (URLSession), native Android (OkHttp/Retrofit), React Native (fetch), and Flutter (dio/http) — there is no platform SDK to add to your binary, no extra dependency to keep updated, and no per-platform configuration.

For assets that should only reach entitled users — paid content packs, account-scoped downloads, pre-release builds for testers — store them as private files and have your backend mint expiring signed URLs after it checks the user's entitlement, so the download link can't be shared past its window. A clarification on scope: this is asset and resource delivery, not a managed code-push framework — files.link won't orchestrate JS bundle rollouts the way an OTA-update product does, but it is an excellent, cheap origin-plus-CDN for the bundles such a system downloads, and for any image or data file your app fetches at runtime.

Billing is prepaid credits against real storage and egress, which scales naturally with install base instead of forcing you onto a fixed tier before you have the users to fill it.