---
title: "App Clips vs Instant Apps vs PWAs: Lightweight App Delivery"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2029-07-17"
category: "Technology"
tags:
  - App Clips vs Instant Apps comparison
  - progressive web apps
  - lightweight app delivery
  - mobile user acquisition
  - Google Play Instant
excerpt: "68% of mobile app installs get abandoned within 30 days. App Clips, Instant Apps, and PWAs let users skip the install entirely. Here is how to pick the right one."
reading_time: "14 min read"
canonical_url: "https://kanopylabs.com/blog/app-clips-vs-instant-apps-vs-pwas"
---

# App Clips vs Instant Apps vs PWAs: Lightweight App Delivery

## Why Lightweight App Delivery Matters More Than Ever

Here is a stat that should change how you think about mobile distribution: 68% of mobile app installs are abandoned within 30 days. That means roughly two out of every three users who go through the effort of finding your app in a store, waiting for it to download, opening it, and creating an account will stop using it within a month. Your cost-per-install just tripled in effective terms.

The traditional app install funnel is brutal. A user sees an ad or scans a QR code, gets redirected to the App Store or Google Play, waits for a download that averages 40 to 80 MB, opens the app, sits through onboarding, and then maybe completes the action they originally intended. Every step bleeds users. Industry data from AppsFlyer shows that the click-to-install conversion rate for paid campaigns hovers around 25 to 35%. That means you lose the majority of interested users before they even get your app on their device.

Lightweight app delivery solves this by removing the install step entirely, or at least making it invisible. Apple App Clips, Android Instant Apps (Google Play Instant), and Progressive Web Apps each take a different approach to the same problem: getting users into your experience in seconds instead of minutes. But they have very different constraints, platform requirements, and long-term implications for your product.

![Multiple mobile devices displaying lightweight app experiences](https://images.unsplash.com/photo-1512941937669-90a1b58e7e9c?w=800&q=80)

If you are building a [web app vs mobile app](/blog/web-app-vs-mobile-app) and trying to figure out your distribution strategy, understanding these three options is not optional anymore. The days of relying purely on App Store discoverability and paid install campaigns are over for most startups. You need a way to let users try before they commit.

## Apple App Clips: Instant Experiences with a 10MB Ceiling

Apple launched App Clips with iOS 14 in 2020, and the concept is simple: a small, focused part of your app that loads instantly when a user taps an NFC tag, scans a QR code, opens a link in Safari, or encounters an App Clip code in the real world. No App Store visit required. The experience launches in under two seconds on a decent connection.

The hard constraint is size. Your App Clip binary must be under 10 MB uncompressed (increased from the original 10 MB limit, Apple briefly raised it to 15 MB but reverted). That 10 MB ceiling forces you to strip out everything nonessential, which is actually a design advantage. It forces you to think about what the single most important user flow is and build only that.

### Discovery Mechanisms

App Clips have the most diverse physical-world discovery options of any lightweight delivery method:

- **NFC tags:** A user taps their iPhone on an NFC-enabled sticker or tag at a physical location. Coffee shops, parking meters, scooter rentals, and restaurant tables are prime use cases. The App Clip launches instantly with location context.

- **QR codes:** Standard QR codes work, but Apple also created proprietary App Clip Codes, which are visually distinct NFC-enabled QR codes. These work better for branding but require ordering physical materials from Apple's design guidelines.

- **Safari Smart Banners:** When a user visits your website on Safari, a banner at the top can offer to launch your App Clip. This is one of the highest-converting discovery surfaces because the user already has intent.

- **Maps and Siri Suggestions:** If your App Clip is associated with a physical location registered in Apple Maps, it can appear as a suggestion when users are nearby.

- **Links in Messages:** Sharing an App Clip link in iMessage renders a rich card preview that launches the App Clip on tap.

### Feature Limitations You Will Hit

App Clips are sandboxed more aggressively than full apps. You cannot access the user's health data, fitness data, or contacts. Background execution is limited. You cannot use CallKit or CareKit. Push notification permissions are granted automatically but expire after 8 hours unless the user explicitly enables them. Most critically, App Clips are deleted by the system after 30 days of inactivity, so any local data your clip stored is gone.

Payment is where App Clips shine. Apple Pay is fully supported and strongly encouraged, meaning users can complete a transaction without entering any payment details. Sign in with Apple is also available, reducing the account creation friction to a single tap. For commerce-focused use cases like ordering food, renting equipment, or paying for parking, this combination of instant launch plus Apple Pay is extremely powerful.

One technical detail that trips up teams: your App Clip and your full app share an app group container. If a user has your App Clip and later installs the full app, the data migrates automatically. This is a critical feature for conversion. A user who ordered coffee through your App Clip and saved their favorite order should see that data when they install the full app. Build for this migration from day one.

## Android Instant Apps: Google Play Instant and the 15MB Limit

Google launched Instant Apps in 2017 and later rebranded the platform as Google Play Instant. The core idea is similar to App Clips: users can run a portion of your Android app without installing it. But the implementation, discovery model, and technical requirements are different enough that you should treat them as separate projects.

The size limit for an Instant App is 15 MB per feature module. Google uses Android App Bundles to deliver only the modules a user needs, so your total app can be much larger as long as individual instant-enabled features stay under the limit. This modular approach is more flexible than Apple's monolithic 10 MB clip, but it requires you to architect your app with feature modules from the start. Retrofitting an existing monolith into instant-compatible modules is a significant engineering effort, often taking 4 to 8 weeks depending on codebase complexity.

### How Users Find Instant Apps

The discovery model leans heavily on Google's ecosystem:

- **Google Play Store "Try Now" button:** This is the primary discovery surface. When a user finds your app in the Play Store, they see a "Try Now" button alongside the "Install" button. Conversion data from Google shows that apps offering a Try Now option see 20 to 30% higher install rates because users can verify the experience before committing.

- **Google Search:** Instant Apps can appear in search results with a "Run" button. This is particularly powerful for utility apps where a user searches for something like "tip calculator" and can run one immediately.

- **Web links:** Any URL associated with your Instant App can launch it directly. This requires Android App Links verification, similar to standard [deep linking for mobile apps](/blog/deep-linking-mobile-apps).

- **Ads:** Google Ads supports Instant App campaigns where tapping an ad launches the app experience instead of redirecting to the Play Store.

### Technical Requirements and Gotchas

Instant Apps run in a restricted sandbox. You cannot use background services, access device identifiers like IMEI, use foreground services (with some exceptions for location), or access the full file system. Notifications require explicit permission, just like full apps. The instant experience runs in a sandboxed process, so it cannot interact with other installed apps on the device.

Google Play Services is required, which means Instant Apps do not work on devices without Google Play (some Huawei devices, Amazon Fire tablets, custom ROMs). This is a real gap if your audience includes users in China or users on non-standard Android devices.

![Developer writing code for instant app feature modules](https://images.unsplash.com/photo-1555949963-ff9fe0c870eb?w=800&q=80)

The payment story is weaker than Apple's. Google Pay integration works, but the adoption rate of Google Pay is lower than Apple Pay in most Western markets. You will likely need to support multiple payment methods in your Instant App, which eats into your 15 MB budget. Some teams solve this by using Stripe's lightweight SDK, which adds roughly 2 MB to the bundle.

One advantage Android has: the "Install" prompt from within an Instant App is seamless. Google provides an API that triggers an in-context install without leaving your experience. The user taps a button, the full app downloads in the background, and the transition happens without losing state. This conversion flow is smoother than anything Apple offers from App Clips.

## PWAs: No Size Limit, No App Store, No Gatekeepers

Progressive Web Apps take a fundamentally different approach. Instead of being a slimmed-down version of a native app distributed through a platform vendor, a PWA is a web application that uses modern browser APIs to deliver an app-like experience. There is no size limit. There is no app store review. There is no platform gatekeeper deciding whether your experience is allowed to exist.

A PWA at its core requires three things: a valid HTTPS connection, a Web App Manifest file that describes metadata like name, icons, and theme color, and a service worker that handles caching and offline behavior. That is the minimum. In practice, a production PWA also needs responsive design, push notification support via the Web Push API, and careful performance optimization to hit the speed benchmarks that make the experience feel native.

### Installation and Discovery

PWAs are discovered through the web. Any URL can be a PWA. Users find them through search engines, social media links, QR codes, NFC tags, or direct URLs. When a user visits a PWA that meets Chrome's installability criteria (HTTPS, manifest, service worker, sufficient engagement), the browser offers an "Add to Home Screen" prompt. On Android, this creates a standalone experience that looks and feels like a native app, complete with its own icon and splash screen. On iOS, the experience is more limited. Safari supports Add to Home Screen, but it does not show install prompts automatically, and iOS PWAs lose some capabilities like push notifications (though Apple added Web Push support in iOS 16.4, it remains less reliable than native push).

The big advantage of PWAs is reach. A single codebase works on every platform with a modern browser. You are not paying Apple 15 to 30% commission on transactions. You are not waiting 24 to 72 hours for App Store review. You can deploy updates instantly. For businesses where speed to market and distribution flexibility matter more than accessing native device APIs, this is a massive advantage.

### Where PWAs Fall Short

PWAs cannot access Bluetooth (well, Web Bluetooth exists but is Chrome-only and buggy), NFC reading (limited Web NFC on Android Chrome), ARKit/ARCore, HealthKit, Apple Pay on the web (supported in Safari but not in standalone PWA mode on all versions), or any hardware API that Apple or Google has not exposed to the browser. If your app needs to scan a Bluetooth device, process health data, or use advanced camera controls, a PWA is not going to work.

Performance is the other gap. A well-built PWA can feel nearly native for content-heavy apps, social feeds, e-commerce storefronts, and dashboards. But for anything that requires complex animations, heavy computation, or real-time graphics, the browser layer adds enough overhead that users notice. Games, video editors, and AR experiences are still native territory.

Offline support is a double-edged sword. Service workers give you fine-grained control over caching, so you can build genuinely functional offline experiences. But you have to build it all yourself. There is no system-level offline mode like native apps get. And on iOS, Apple aggressively purges service worker caches after a period of inactivity (reportedly 7 days without use), which can break your offline experience for infrequent users.

## Head-to-Head Comparison: Size, Speed, Features, and Conversion

Choosing between these three options requires understanding how they stack up across the metrics that actually matter for your business. Here is the breakdown:

### Size and Load Speed

- **App Clips:** 10 MB max. Loads in 1 to 2 seconds. Apple caches the clip on their CDN, so delivery is consistent. The size constraint is the tightest of all three options, but the load speed is the fastest.

- **Instant Apps:** 15 MB per feature module. Load time is 2 to 4 seconds depending on the module count. Google's infrastructure handles delivery through Play Services. Slightly slower than App Clips because of the modular loading architecture.

- **PWAs:** No hard limit. Load speed depends entirely on your optimization. A well-built PWA with proper code splitting and a CDN can achieve first-meaningful-paint in under 3 seconds on a 4G connection. But you can also build a 50 MB PWA that takes 15 seconds to load. The discipline is on you.

### Conversion to Full Install

This is where the data gets interesting. Google reported that Instant App users who convert to a full install show 25% higher engagement at day 30 compared to users who installed directly from the Play Store. The "try before you buy" model self-selects for engaged users. Apple has shared less public data, but third-party reports from companies like Snipp and Bird suggest App Clip to full-app conversion rates between 15 and 25%, depending heavily on the value proposition and how frictionless the upgrade prompt is.

PWA install rates are harder to benchmark because the "install" step (Add to Home Screen) is optional and the app works without it. Starbucks reported their PWA sees 2x the number of daily active users compared to their native app, partly because the barrier to access is so much lower. But "installed" PWA users (those who added it to their home screen) show engagement patterns closer to native app users.

### Offline Capabilities

- **App Clips:** Limited. App Clips are designed for short, connected interactions. You can cache some data locally, but there is no expectation of deep offline support, and the system will delete the clip after 30 days of inactivity.

- **Instant Apps:** Minimal. The experience requires a connection to launch. Some limited caching is possible, but Google does not encourage offline-first Instant App design.

- **PWAs:** Best of the three. Service workers give you full control over what gets cached and how. You can build a fully functional offline experience, cache API responses, queue actions for sync when connectivity returns, and even use Background Sync to process queued requests.

### Platform Reach

- **App Clips:** iOS only. Requires iOS 14 or later, which covers roughly 95% of active iPhones as of mid-2029.

- **Instant Apps:** Android only. Requires Google Play Services, excluding Huawei AppGallery devices and some regional Android variants. Covers roughly 80% of the global Android install base.

- **PWAs:** Cross-platform. Works on any device with a modern browser. Full feature support on Chrome for Android. Increasingly capable on Safari for iOS, though still with notable gaps in push notifications, background sync, and home screen integration.

## Real-World Use Cases and When to Pick Each Option

Theory is fine, but here is where each option actually wins in production, based on what we have seen working with clients and what the market data shows:

### App Clips Win For: Physical-World Commerce

If your business involves a user standing in front of a physical thing and needing to interact with it immediately, App Clips are the best option. Parking meters, scooter rentals (Bird's App Clip lets you scan and ride in under 10 seconds), restaurant ordering (Toast and Square both support App Clip integrations), and event ticketing. The NFC and QR discovery mechanism is purpose-built for these scenarios. The Apple Pay integration eliminates payment friction. A user walks up, taps, pays, and walks away. No account creation, no install, no friction.

Panera Bread reported that their App Clip for in-store ordering reduced the average time-to-order from 4 minutes (for users who had to download the full app) to under 45 seconds. That is not an incremental improvement. That is a different product experience entirely.

### Instant Apps Win For: Play Store Conversion Optimization

If your primary acquisition channel is the Google Play Store and you want to reduce the friction between "browsing" and "committed user," Instant Apps are the move. The Try Now button is uniquely powerful because it catches users at the exact moment of highest intent. Gaming companies have seen particular success here. Voodoo and King have both used Instant Apps to let users play a level before installing, and the result is a user base that retains significantly better because they already know they like the game.

E-commerce apps also benefit. Letting a user browse your product catalog, add items to a cart, and even begin checkout without installing removes the biggest drop-off point in mobile commerce. Wish (the shopping app) reported a 20% increase in daily sessions after launching their Instant App experience.

### PWAs Win For: Global Reach and Low-Bandwidth Markets

If your audience is global, includes users on low-end devices, or exists in markets where data costs are high, PWAs are the clear winner. Twitter Lite (now X Lite) famously reduced data consumption by 70% compared to the native app and saw a 65% increase in pages per session. Flipkart Lite, the Indian e-commerce giant's PWA, drove a 70% increase in conversions compared to their mobile web experience. These are not marginal gains. They are transformative for businesses operating in price-sensitive markets.

PWAs also win when you need to bypass the app stores entirely. Regulatory concerns, commission avoidance (particularly relevant for subscription businesses where Apple's 15 to 30% cut is painful), or simply wanting to control your own distribution. Epic Games' battle with Apple's App Store policies is a high-profile example of why some companies want alternatives to store-based distribution.

![Analytics dashboard showing mobile conversion metrics and user retention data](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80)

For [mobile conversion rate optimization](/blog/mobile-conversion-rate-optimization), the key insight is that all three of these technologies reduce friction at the top of the funnel. The question is which type of friction matters most for your specific user journey.

## Implementation Costs, Timelines, and the Hybrid Approach

Budget and timeline are where the rubber meets the road. Here is what to expect for each option:

### App Clips

If you already have an iOS app built with SwiftUI or UIKit, adding an App Clip target takes 2 to 4 weeks for a simple single-flow experience (ordering, payment, booking). The App Clip shares code with your main app target, so you are mostly extracting and slimming down an existing flow. Budget $15,000 to $40,000 with an agency, less if your internal team handles it. The main cost driver is fitting within the 10 MB limit, which often requires replacing heavy dependencies with lighter alternatives and optimizing assets aggressively.

If you do not have an iOS app yet, building an App Clip from scratch is faster and cheaper than building a full app. A focused App Clip with Apple Pay integration can be built in 3 to 5 weeks for $20,000 to $50,000. Some teams launch the App Clip first, validate the use case, and then build the full app only after proving demand.

### Instant Apps

Instant Apps require your Android app to use Android App Bundles and be structured with feature modules. If your app is already modularized, enabling the instant experience takes 2 to 3 weeks and costs $10,000 to $25,000. If your app is a monolith, the refactoring to support feature modules is the expensive part, often 6 to 10 weeks and $30,000 to $70,000 depending on the codebase size. You will need to identify which features should be instant-enabled, extract them into separate modules, and ensure each module stays under the 15 MB limit.

### PWAs

If you have an existing responsive web application, converting it to a PWA is the most cost-effective option. Adding a service worker, web manifest, and offline caching to an existing React, Vue, or Next.js application takes 1 to 3 weeks and costs $5,000 to $20,000. Tools like Workbox (from Google) automate much of the service worker complexity. Next.js and Nuxt both have PWA plugins that handle the basics out of the box.

Building a PWA from scratch that rivals a native app experience is a bigger project. A full e-commerce PWA with offline support, push notifications, and optimized performance takes 8 to 14 weeks and costs $40,000 to $100,000. But you get a cross-platform experience that works everywhere, which often makes the per-platform cost lower than building separate native apps.

### The Hybrid Play

Smart teams do not pick just one. The most effective strategy for many businesses is a PWA as the base experience (available everywhere, no install required), App Clips for iOS users encountering your product in the physical world, and Instant Apps for Android users discovering you through the Play Store. Your full native apps remain the goal for power users who want the richest experience, but you are not gating access behind an install.

This hybrid approach costs more upfront, typically $60,000 to $120,000 to build all three lightweight experiences alongside your native apps. But the user acquisition math usually justifies it. If your cost-per-install is $3 to $5 and 68% of those installs churn within 30 days, you are effectively paying $9 to $15 per retained user. Lightweight delivery methods that improve retention by even 20% can save hundreds of thousands of dollars annually at scale.

## Choosing Your Lightweight Delivery Strategy

The decision framework is simpler than it looks. Start with three questions: Who is your user? Where do they discover your product? What is the single most important action you want them to take?

If your users are iPhone owners encountering your product at a physical location, and the key action is a payment or booking, build an App Clip. The NFC/QR discovery combined with Apple Pay is unbeatable for commerce in physical spaces.

If your users find you through the Google Play Store and the key action is trying your core experience before committing to an install, build an Instant App. The Try Now button is the highest-intent discovery mechanism on Android.

If your users come from web search, social media, or messaging apps, and the key action works well in a browser, build a PWA. You get the widest reach, the lowest distribution cost, and no app store dependencies.

If you are not sure, start with a PWA. It is the lowest-risk, widest-reach option that works as a foundation. You can always add App Clips and Instant Apps later as you identify platform-specific opportunities.

The broader trend here is undeniable: the barrier between "visiting a website" and "using an app" is dissolving. Users do not think about the technical distinction. They want to complete a task with minimum friction. The companies that win are the ones that meet users where they are, in the format that requires the least commitment.

If you are figuring out which lightweight delivery approach fits your product and want a technical team that has built all three, [book a free strategy call](/get-started) and we will map out the fastest path to reducing your acquisition costs and improving retention.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/app-clips-vs-instant-apps-vs-pwas)*