"Do I really need a native app, or will a PWA work?" — It's one of the first questions that comes up when you're deciding how to build with Rork, and the answer shapes your entire development approach.
Both options have genuine strengths, and I've seen developers choose the wrong one simply because they didn't know where the real line was. The good news is that the decision comes down to a handful of concrete capabilities, not abstract architectural debates. This article lays out the differences that actually matter, based on building several apps with Rork over the past couple of years.
The Short Answer: Build Native If Any of These Apply
Before diving into details, here's the decision framework up front:
- You need to send push notifications to users
- You want serious access to camera, microphone, GPS, or other hardware
- You want to publish on the App Store or Google Play
If any one of these fits your use case, go with a native app. Rork generates React Native / Expo apps, which means all three are handled naturally and reliably. If none of them apply, a PWA might genuinely be the simpler path.
I learned this line the slow way. As an indie developer, I shipped more than one product as a lightweight web app first, only to rebuild it natively once people started using it and I wanted to pull them back with a gentle notification or have them open it from a home-screen icon. Each time, the web version hit a wall the native version wouldn't have. Knowing the boundary up front would have saved me those detours, which is exactly why it's worth confronting this question at design time rather than after launch.
What "Native App" Means When You Use Rork
Rork generates apps using React Native and Expo — a framework that compiles to actual native iOS and Android components, not a web view. When users tap a button in your app, they're interacting with a real UIButton on iOS or a native View on Android, not an HTML element styled to look like one.
This matters because it's what gives Rork-built apps access to the full operating system. The gap between "wraps a website" and "runs as a real native process" is where push notifications, hardware sensors, and background tasks live.
A PWA (Progressive Web App) stays on the browser side of that gap. It can be added to a home screen, it can cache content for offline use, and it can look polished — but it can't cross the OS boundary to do things the native layer handles.
What's Actually Different: The Feature Breakdown
Here's a practical breakdown of capabilities that differ between PWA and native:
Push notifications: PWA support on iOS Safari is limited and historically unreliable. Users need to add the app to their home screen first, and even then background delivery isn't guaranteed. React Native handles push notifications consistently across both platforms.
Camera and media: PWA camera access works for basic photo capture, but real-time video processing, custom camera UI, and frame-by-frame analysis are significantly faster and more capable in native. If your app does anything interesting with the camera, native wins clearly.
Bluetooth and NFC: Not available in PWA at all in most practical scenarios. React Native supports both with well-maintained libraries.
App Store and Google Play listing: Exclusive to native apps. This isn't just about distribution — store presence brings search discoverability, user reviews, and a level of trust that a web URL doesn't carry.
Home screen widgets: Native only. WidgetKit on iOS and App Widgets on Android let your app surface information on the home screen without the user opening it.
Background processing: Native apps can run scheduled tasks, process data, and sync in the background reliably. PWA background capabilities are narrow and inconsistently supported across devices.
Performance ceiling: For most content-driven apps, PWA performance is perfectly fine. For anything involving real-time data processing, animations at 60fps, or heavy computation, native has a higher ceiling.
Push Notifications: The Feature That Shows the Gap Most Clearly
Of everything listed above, push notifications cause the most confusion because "they kind of work in PWA." Let me be specific about why native makes more sense for anything that relies on notifications.
In a Rork-generated React Native app, you implement push notification registration like this:
// Push notification setup in a Rork-generated React Native app
import * as Notifications from 'expo-notifications';
import { Platform } from 'react-native';
// Configure how notifications appear while the app is in the foreground
Notifications.setNotificationHandler({
handleNotification: async () => ({
shouldShowAlert: true,
shouldPlaySound: true,
shouldSetBadge: false,
}),
});
async function registerForPushNotifications(): Promise<string | null> {
// Request permission
const { status } = await Notifications.requestPermissionsAsync();
if (status !== 'granted') {
console.log('Notification permission not granted');
return null;
}
// Get the device push token — send this to your backend
const token = await Notifications.getExpoPushTokenAsync({
projectId: 'your-expo-project-id',
});
// Android requires an explicit notification channel
if (Platform.OS === 'android') {
await Notifications.setNotificationChannelAsync('default', {
name: 'Default',
importance: Notifications.AndroidImportance.MAX,
vibrationPattern: [0, 250, 250, 250],
});
}
return token.data;
// → Store this token on your server to target this device
}You can ask Rork to generate this by saying something like "add push notification registration and store the token." The output is a production-ready implementation that works on both platforms and reaches users whether the app is open, backgrounded, or completely closed.
Replicating this with a PWA on iOS means dealing with Safari's Web Push API limitations — users must have added your app to their home screen, you're dependent on Safari version support, and even when it works, it doesn't match the reliability of the native path. If notifications are meaningful to how your app creates value, native removes that uncertainty.
When a PWA Is the Right Choice
I want to give this a fair treatment, because there are real cases where a PWA makes more sense and I'd rather help you make the right call than oversell native.
PWA makes sense when:
- Your app is primarily informational — articles, catalogs, dashboards — and doesn't need notifications or hardware features
- You want to ship and iterate without going through App Store review (important for fast-moving teams)
- You have existing web development skills and want to ship something quickly
- You're building an internal tool for employees or a specific group, where store distribution doesn't matter
- The installation friction of going through the App Store is actually a barrier for your use case
"Task manager for our team" or "offline-capable reference guide" are solid PWA use cases. Building a full native app for those would be over-engineering, and Rork's strengths would go mostly unused.
What Rork Changes About the Native App Calculation
Historically, the main argument for choosing PWA over native was avoiding complexity — Swift, Kotlin, Xcode, provisioning profiles, Android Studio build configurations. Rork shifts that calculus significantly.
With Rork, the implementation complexity of native features becomes much more manageable:
Push notifications — describe what you want in plain language, Rork generates the Expo setup, permission request, and token management.
Camera and GPS — ask for a camera feature, Rork handles the permission flow and the platform-specific API differences.
App Store submission — Rork Max includes a cloud build and two-tap publish flow that replaces most of the manual Xcode and Fastlane setup.
Dark mode, haptics, and platform UI conventions — Rork handles these as part of how it generates components, so your app feels native by default.
The "native is too hard" argument held water when you had to write everything yourself. When Rork is handling the implementation, the gap in effort between PWA and native narrows enough that the capability difference tips the decision toward native for most non-trivial apps.
For a practical walkthrough of getting started, what Rork actually is covers the basics. For a hands-on first project, building your first app in 30 minutes is a good place to start. For a deeper dive into the push notification setup, local notifications in Expo goes further into the backend integration.
Three Questions to Find Your Answer
If you're still uncertain after reading this far, these three questions should make the decision clear:
1. Will you want push notifications six months from now? Even if notifications aren't in your first version, adding them later to a PWA is significantly harder than adding them to an app that already has the native permission infrastructure in place. If there's a real chance you'll want them, starting native saves you a rebuild.
2. Is camera or location a core part of the experience, not just a bonus? For supplementary use — "let users attach a photo" — PWA camera works fine. For apps where the camera or GPS is the point — fitness trackers, delivery apps, AR features — native quality and reliability make a meaningful difference to users.
3. Does being on the App Store create value for your users or your business? Store presence brings search discoverability, social proof through reviews, and a distribution channel your users already trust. For consumer-facing products, this is often worth more than the effort to get there.
One "yes" is usually enough to make native the right call. If all three are "no," a PWA is a perfectly reasonable approach.
The best way to validate is to build something. Start with Rork's free plan, get a prototype running, and notice what you reach for. In my experience, the first time you want a feature that a PWA can't support cleanly is the clearest signal you made the right choice by going native.