Every quarter, at least one client asks whether they should build a mobile app. The answer is almost always no. Not because mobile apps are bad, but because the question usually starts from the wrong place. They've seen a consumer app they like and want the same thing for their enterprise tool. The user contexts are fundamentally different, and the decision framework needs to start there.
What You Need to Know
- Most enterprise software is better served by responsive web applications than native mobile apps
- The decision should start with user context: where, when, and how people use the software
- Native mobile makes sense for field workers, offline requirements, and device-specific features
- Building both web and native doubles your maintenance cost permanently
The Default Should Be Web
Enterprise software is primarily used at a desk. Even when people access it on a phone, they're usually checking something quickly, not doing deep work. A well-built responsive web application handles both scenarios without maintaining two codebases.
78%
of enterprise software usage occurs on desktop or laptop devices
Source: Forrester, The State of Digital Business Report, 2020
The web platform has caught up dramatically in the past few years. Service workers enable offline capability. The Web Share API handles native sharing. Push notifications work in most browsers. Progressive Web Apps bridge most of the gap between web and native without the cost of a separate build pipeline.
When Native Mobile Makes Sense
There are legitimate reasons to build native. They're more specific than most teams expect.
Field Workers
If your users are in a field, on a factory floor, or visiting client sites, native mobile is often the right choice. These users need the app to work offline, to access the camera for documentation, to use GPS for location tagging. The device is their primary computer, not a secondary screen.
We built a field inspection tool last year where the user photographs a site, annotates the image, and submits a report. That workflow needs camera integration, offline storage, and background sync. A web app would have been a compromise.
Offline-First Requirements
If the application must work without any network connectivity for extended periods - hours or days, not minutes - native provides more reliable offline storage and sync patterns. IndexedDB and service workers can handle simple offline scenarios, but complex data synchronisation with conflict resolution is still easier to implement natively.
Device-Specific Features
Bluetooth, NFC, specific sensor access, background processing - if the core workflow depends on device capabilities that the web doesn't expose, native is necessary. But verify this requirement carefully. I've seen teams build native apps for "push notifications" that the web platform handles perfectly well.
The Decision Framework
When a client asks about mobile, I walk through four questions.
1. Where are your users when they use this software?
At a desk? Web. In the field? Probably native. Split between both? Web first, native for the field-specific workflow only.
2. What happens without network connectivity?
Need to view cached data for a few minutes? Web handles this. Need to collect data offline for hours and sync later? Native is more reliable.
3. What device capabilities do you need?
Camera for photo capture? Both platforms handle this now. Bluetooth integration? Native. Background GPS tracking? Native. Everything else? Probably web.
4. What's your maintenance budget?
This is the question that changes the most minds. A native mobile app needs its own build pipeline, its own deployment process, app store management, version compatibility testing across devices, and a developer who knows Swift or Kotlin. That's not a one-time cost. It's a permanent line item.
The question isn't whether you can build a mobile app. Most enterprise teams underestimate the ongoing cost by a factor of two or three.
John Li
Chief Technology Officer
The Hybrid Trap
React Native, Flutter, Xamarin - cross-platform frameworks promise the best of both worlds. In practice, they deliver the middle of both worlds. You get native-like performance with web-like development speed, but you also get native platform bugs with web-like debugging tools.
For enterprise applications, the trade-offs of hybrid frameworks are usually acceptable. The UI doesn't need to be pixel-perfect native. Performance requirements are moderate. The developer pool for React Native is larger than for Swift.
But hybrid isn't free. You still need to test on both platforms. You still need to manage app store deployments. You still need to handle platform-specific edge cases. The savings are real, in the range of 30-40% compared to building two native apps, but they're not as dramatic as the marketing suggests.
Our Recommendation
For most enterprise applications, build a responsive web app first. Use progressive web app capabilities for offline and push notifications. If you discover through actual usage data that a native app would serve a specific user segment better, build it for that segment.
The worst outcome is building a native app that 90% of your users access through the web anyway, while the app slowly falls behind because the maintenance budget doesn't stretch to keep both platforms current.
Start with the platform that serves the broadest set of users at the lowest ongoing cost. For enterprise, that's almost always the web.