App Clips and Instant Apps for Instant First Use | Mironsoft

1. What App Clips and Instant Apps do, and where React Native hits limits

App Clips on iOS and Instant Apps on Android follow the same core idea: users should be able to try a small, tightly scoped part of an app without installing the full app from the store first. Typical triggers are a scanned QR code at a physical location, an NFC tag, a link in a message, or a Safari App Banner. Instead of the full app, only a heavily reduced feature set launches, built for exactly one use case, such as paying at a parking meter or viewing a single product.

For React Native apps this is not a trivial feature you simply flip on. Both App Clips and Instant Apps operate under strict size limits that sit well below what a typical React Native bundle brings along, including the Hermes engine, native dependencies, and JavaScript payload. Teams serious about these formats need to plan the main app's architecture from the start so a lean, self-contained slice can be carved out, rather than trying to squeeze the entire app into a tight size budget after the fact.

2. iOS App Clips: size limit, architecture, triggers

An App Clip is technically a standalone Xcode target with its own bundle ID, appended to the main app's bundle ID with the .Clip suffix, and is built as a separate, self-contained binary. Apple caps the uncompressed size of this target: for a long time the limit sat at 10 MB, and since iOS 16 it was raised to 15 MB for App Clips using extended capabilities such as ARKit or certain frameworks, while simple clips remain more tightly bounded. If the binary exceeds the limit, App Store Connect rejects the upload outright.

An App Clip is triggered through an App Clip Code, a visual marker that can optionally integrate NFC, through a regular QR code carrying an invocation URL, through a Safari Smart App Banner on a verified domain, or through a link in Messages or Maps. The invocation URL has to be verified via Associated Domains and an apple-app-site-association file on the server, so iOS reliably routes the link to the correct App Clip instead of just opening it in the browser.

// AppClip/QuickShopClipApp.swift
import SwiftUI

@main
struct QuickShopClipApp: App {
  @State private var productId: String?

  var body: some Scene {
    WindowGroup {
      ProductQuickViewView(productId: productId)
        .onContinueUserActivity(NSUserActivityTypeBrowsingWeb) { activity in
          guard let url = activity.webpageURL,
                let components = URLComponents(url: url, resolvingAgainstBaseURL: false) else {
            return
          }
          productId = components.queryItems?.first(where: { $0.name == "product" })?.value
        }
    }
  }
}

3. Android Instant Apps: feature modules and Play Instant

Google Play Instant follows a conceptually different model than App Clips: instead of a separate binary, the regular app itself is split into feature modules, some of which are explicitly marked as instant-enabled. Through the Android App Bundle, the Play Store selects exactly the modules needed for the current entry point at runtime and delivers only that subset, without developers having to maintain a fully separate second project.

A strict size limit applies here too: the compressed download size of all modules required for an instant entry point must not exceed 15 MB, measured across every involved feature module including the base module combined. An Instant App is triggered through a Try Now button in Play Store search results, through a link in Google search results, or through a regular QR code pointing at an address registered as instant-capable.

4. React Native inside an App Clip: is it actually feasible

Whether React Native can realistically fit inside a 15 MB App Clip budget is a fair question. The statically linked Hermes engine and React Native runtime libraries alone consume several megabytes before a single line of business logic or a single UI asset is added. In practice, a minimal React Native clip only works if you aggressively trim dependencies, compress assets, and drop every native module that is not strictly required.

The more pragmatic recommendation for most teams: build the App Clip in native SwiftUI or UIKit and share only the business logic, such as API calls or business rules, with the main app through a shared Swift package. A fully self-contained, very lean React Native clip with its own Metro entry point remains technically possible, but demands continuous size monitoring in the CI pipeline so a future dependency update does not silently blow the size budget.

5. Practical example: QR-code-based quick access to a product catalog

A realistic use case: a QR code posted at a retail display opens an App Clip on scan that shows exactly one product with price, description, and a buy button, with no login and no app installation required. Technically, the product ID is encoded as a query parameter in the invocation URL, for example https://shop.example.com/clip?product=4821, and iOS forwards that parameter to the App Clip scene via NSUserActivity as soon as it launches.

On Android, the comparable flow runs through a deep link that, on scanning the QR code, directly launches the matching instant module with the same product parameter, without the user ever seeing the Play Store, provided the app is configured as instant-capable. In both cases, the actual payment flow is deliberately kept minimal, usually through Apple Pay or Google Pay, because a full checkout form with address entry would defeat the point of a fast first experience.

6. Code-sharing strategy between the main app and the clip or instant module

To keep the main app and the clip or instant module from becoming completely separate codebases, a clear split between the UI layer and the business logic layer pays off from day one. The API client, validation rules, and data models move into a native shared package consumed by both the main app and the clip, while the UI layer deliberately exists twice: once as the full React Native surface, once as a lean native surface for the clip.

This UI duplication looks like extra work at first glance, but it prevents size optimizations for the clip from forcing compromises on the main app's UI. An alternative approach, rarely viable in practice, is a separate Metro bundle entry point with a curated, heavily trimmed dependency list, which then has to be manually re-checked against the size budget every time the main app's dependencies change.

// app/build.gradle.kts
android {
    dynamicFeatures += setOf(":quickview")
}

// quickview/build.gradle.kts
plugins {
    id("com.android.dynamic-feature")
}

dependencies {
    implementation(project(":app"))
}

7. Technical limitations: size, session duration, and feature scope

Beyond the raw size limit, further technical constraints apply. An App Clip only stays active for about eight hours after being backgrounded before iOS terminates it for good, push notifications are only allowed within a narrow window after use and with explicit consent, and access to certain sensitive permissions, such as full contacts access, is blocked outright.

Instant Apps on Android carry similar restrictions: access to dangerous permissions under the Android permission model, such as background location or camera without explicit runtime grant, is limited or fully blocked, and persistent local storage is not guaranteed by the system to carry over into a later full install once the instant session ends, unless explicit migration logic exists through a shared cloud account.

8. Converting from clip or instant app to the full install

The transition from an App Clip to the full app runs through a native StoreKit overlay, SKOverlay, which Apple deliberately renders as a consistent UI element on top of the clip surface, inviting the user to install the full version. So the user does not start from zero after installing, the App Clip and full app share an App Group container through which, for example, an already filled cart or a started booking carries over seamlessly.

On Android Instant Apps, the transition is less noticeable because the same app bundle base is used technically anyway: the Play Store offers an install button directly inside the instant app surface, and because the instant app and full version share the same package ID, local state can continue through shared databases or a server-side user account without any additional migration code.

9. Testing and the App Store or Play Store review process

App Clips can be launched in Xcode through a dedicated scheme with a stored test invocation URL, directly in the simulator or on real devices, without ever having to scan an actual QR code. For beta testing through TestFlight, a dedicated App Clip release process exists, running independently from the main app's release process, because Apple reviews App Clips more strictly on feature scope and explicitly rejects apps whose clip covers more than the advertised fast single use case.

Android Instant Apps are tested locally by extracting them from the app bundle with bundletool, or distributed via an internal app sharing link in the Play Console before the instant-capable modules go live officially. Google also reviews instant-capable modules separately for size, startup time, and permission scope before they become visible to users through Try Now links.

10. Summary

11. FAQ: App Clips and Instant Apps: The Essentials at a Glance