Shipping a Mobile App When Your Team Only Knows the Web

Every SaaS founder eventually gets the question. "Where's your mobile app?" It comes from a customer, an investor, or the sales team. The team is a web team. Nobody has opened Xcode. The instinct is to hire native engineers or panic. Both are usually wrong.

This is what we recommend when clients ask how to ship a mobile app without rebuilding their team.

The first question — do you need a mobile app at all

Half the time, the honest answer is no. A well-built responsive web app on a modern phone is close to indistinguishable from a native experience for a lot of B2B tools. Before spending three to six months building a mobile app, be sure the mobile app is what the customer actually wants.

What they usually want is one of these:

• Push notifications on their phone.
• Faster access than opening a browser and logging in.
• Offline access to a specific subset of data.
• Camera or biometrics for a specific workflow.

Each of those has a different answer. Push notifications alone can often be delivered without a mobile app at all. Faster access can be solved with a PWA. Offline is where things get harder. Camera-heavy workflows usually need real native APIs.

The four realistic paths

PWA (Progressive Web App)

Your existing web app, made installable. Adds a home screen icon, offline shell, and push notifications on Android and iOS 16.4+.

Cheapest path. If your product is mostly forms, dashboards, and text — a huge chunk of B2B SaaS — a PWA covers the mobile need at a fraction of the cost. No app store review, no separate build, no separate team.

Limitations: iOS support has historically lagged Android, though it's improving. Push notifications work on iOS 16.4+ but only for installed PWAs. Deep OS integrations (background sync, some biometrics, some camera features) still favor native.

Capacitor (Ionic)

Wraps your web app in a native shell so it can ship in the app stores. From the user's perspective it's an app. From the codebase's perspective it's still your web app plus a thin JavaScript-to-native bridge.

Good fit when the app stores matter — sales cares that you're "in the App Store" — but the product is fundamentally web. You keep your web team, one codebase, and you get real native APIs when you need them. Performance is usually indistinguishable from React Native for CRUD apps.

React Native (with Expo)

Actual native app, JavaScript codebase, shared knowledge with web but a distinct implementation. Expo makes it approachable for a web team — no Xcode required for most of the flow, over-the-air updates, managed native modules.

The right pick when the mobile app is going to grow into a first-class surface. Real native UI. Full access to platform capabilities. React knowledge transfers, but iOS and Android idioms don't — and that's the learning curve.

Fully native (Swift and Kotlin)

Two teams, two codebases, two release pipelines. Only makes sense when the product is mobile-first and the mobile experience is a competitive differentiator. Rarely the right call for a web-first SaaS shipping its first mobile app.

Which one to pick

Pick PWA if

• Your app is content, forms, and dashboards.
• You don't need to be in the App Store for sales or brand reasons.
• Push notifications and installability are the main asks.
• You have zero mobile engineering budget.

Pick Capacitor if

• You need App Store presence for credibility or discoverability.
• You want one codebase and don't want to maintain two products.
• The mobile app is essentially your web app with a few native touches.

Pick React Native / Expo if

• The mobile experience is important enough to invest in real native UI.
• You expect the mobile app to diverge meaningfully from the web app over time.
• You have or plan to hire engineers who can own it.

Pick native if

• Your product is mobile-first.
• You have specific platform features that don't work well through bridges (advanced camera, ARKit, deep OS integrations).
• You can afford two teams.

The costs nobody warns you about

App Store review

Apple's review adds 1-3 days of latency to every release. Sometimes more if you touch anything sensitive. Rejections happen for reasons that feel arbitrary. Budget for this — a "hotfix" isn't hotfix speed once Apple is in the loop.

Google Play is faster and more permissive, but still not instant.

Certificates and provisioning

iOS certificates expire. Provisioning profiles need to be renewed. Push notification certificates are a specific type. Someone has to own this, and it's neither fun nor documented well.

Push notification infrastructure

iOS goes through APNs. Android goes through FCM. Managing tokens, delivery status, and preferences is a project on its own. Services like OneSignal or Expo Notifications solve most of it for a fee.

Store metadata and screenshots

Every store listing needs screenshots at multiple device sizes, a description, keywords, a privacy policy URL. Not hard, but a real chunk of first-launch work.

Analytics and crash reporting

Sentry, Firebase Crashlytics, or similar. Mobile crashes are harder to debug than web errors — no console to open on the user's device. Instrument early.

Common mistakes

Rebuilding the whole product for mobile. The mobile app doesn't need every feature. Ship the top 3-5 workflows customers actually do on their phones. Save the rest for later.

Native because it's "more professional." Users don't care what you built with. They care whether it works. Native has a niche where it wins; for most B2B SaaS, it doesn't.

Skipping PWA as an intermediate step. A PWA can carry your product for 6-12 months while you decide whether native is worth the investment. Cheap way to test demand.

Assuming React Native means "half the effort of two native apps." Closer to 70%. The savings are real but smaller than the marketing suggests, especially once you factor in platform-specific bugs.

Not shipping to the app stores for the wrong reason. If your buyer is IT-controlled, an app store listing is credibility. If your buyer is a consumer, discoverability matters. Both are real reasons to endure Apple's review even if a PWA would technically work.

The team question

A web team can ship all four of the above, with varying pain. PWA and Capacitor are the smallest lift — no new language, minor tooling changes. React Native / Expo requires learning platform idioms and dealing with occasional native code, but doesn't require hiring.

Native (Swift/Kotlin) does require hiring or contracting. If you go there without a native engineer, you'll waste months.

Our post on first engineer vs agency covers the general shape of that decision.

Trade-offs

Any hybrid approach makes some things harder. Deep OS integrations are always cleaner in native. Some third-party SDKs (payment, authentication, mapping) have wildly better native support than JavaScript bridges. If your app depends on those, the "hybrid tax" adds up.

On the other side, maintaining two codebases doubles the surface area for bugs, feature drift, and design inconsistency. Every hybrid path is a tradeoff between platform-specific quality and shared-codebase efficiency.

Common misconceptions

"PWAs don't work on iOS." They do, and have for years. Push notifications and some other features arrived later than Android, but the platform is real. iOS 16.4+ supports installable PWAs with notifications.

"React Native has bad performance." True for old versions. Current versions with the new architecture are close to native for typical CRUD workloads. Games and heavy animation are still native's territory.

"Users prefer native apps." Users prefer apps that work well. They don't check the framework in the About screen. The preference is for polish and speed, which any of the above can deliver with effort.

Frequently asked questions

Final take

A web team shipping a mobile app has more good options in 2027 than ever. Start by questioning whether you need one at all. If you do, PWA is the cheapest test. Capacitor is the fastest path to the App Store. React Native / Expo is the right investment when the mobile app is going to grow into a real product surface. Native is rarely the answer for a web-first SaaS unless the product itself is mobile-first.

If you're weighing this decision, book a call. We've shipped all four kinds and can save you the discovery time.