Native, Web, and Cross-Platform Apps: Choosing a Mobile Delivery Model
📑 On this page
- A concrete example: augmented reality versus an internal form
- Native applications
- Mobile web applications
- Progressive web apps
- Cross-platform frameworks
- Shared code is not the only goal
- Performance
- Device capabilities
- Offline behavior
- Distribution
- Update control
- Accessibility
- Security
- Team and ecosystem
- Product consistency and platform fit
- Hybrid strategies
- Decision questions
- Knowledge check
- The one idea to remember
Building for phones does not require one universal approach.
Native apps target a specific operating system, web apps run through browsers, and cross-platform frameworks share substantial application code while producing apps for several platforms.
Each model trades device integration, performance, distribution, update control, code sharing, and team specialization.
A concrete example: augmented reality versus an internal form
An augmented-reality measuring app needs:
- Camera
- Motion sensors
- Low-latency rendering
- Platform-specific AR frameworks
- Careful battery and thermal behavior
Native development may offer the strongest fit.
An internal expense form needs:
- Text input
- Photo upload
- Authentication
- Approval status
A responsive web app may reach every employee quickly without app-store distribution.
Choose from product needs, not fashion.
Native applications
Native apps use platform languages, frameworks, and tooling.
Examples:
- Swift and SwiftUI on Apple platforms
- Kotlin and Jetpack Compose on Android
Benefits:
- Direct access to platform APIs
- Latest platform features
- Native interaction conventions
- Strong performance control
- Mature profiling and accessibility tools
Costs:
- Separate platform expertise
- More implementation divergence
- Coordinated feature delivery
- App-store operations
Shared backend and design principles still reduce duplication.
Mobile web applications
A mobile web app runs in a browser.
Benefits:
- Link-based access
- No installation requirement
- Immediate server deployment
- Broad platform reach
- Search and sharing
- One web skill set
Limits can include:
- Restricted background execution
- Inconsistent device API support
- Browser UI constraints
- Platform-specific behavior
- Less app-store presence
Modern browsers support many capabilities, but availability and permission behavior differ.
Test the actual target devices and browsers.
Progressive web apps
A progressive web app, or PWA, enhances a web app with features such as:
- Installability
- Offline caching
- App-like display
- Push notifications where supported
- Background synchronization
It remains built on web technologies.
PWA capability varies by platform and browser.
Installation and notification support may differ, and users may not understand how to install.
Use progressive enhancement so the core web experience remains useful without every advanced feature.
Cross-platform frameworks
Cross-platform frameworks allow substantial shared code.
Approaches include:
- JavaScript or TypeScript runtime with native components
- Compiled shared UI toolkit
- Shared business logic with platform-native UI
- Web content inside a native shell
Benefits:
- Shared features
- One product team
- Faster parity
- Reused tests and domain logic
Costs:
- Framework dependency
- Native integration layers
- Platform mismatch
- Upgrade complexity
- Debugging across abstraction layers
"Write once" does not mean test once.
Shared code is not the only goal
Code reuse can reduce duplication, but user experience may need platform-specific behavior.
Examples:
- Navigation conventions
- Back gestures
- Share sheets
- Keyboard behavior
- Notification settings
- Accessibility APIs
Forcing identical UI everywhere can make the app feel foreign on every platform.
Share business rules and common components where valuable, while allowing platform adaptation.
Measure maintenance and outcome, not percentage of shared lines.
Performance
Performance includes:
- Startup
- Scrolling
- Animation
- Memory
- Battery
- Network
- Binary size
- Background work
Native access offers fine control, but poorly written native code can still be slow.
Cross-platform frameworks can meet demanding applications when used well.
Web apps can perform strongly for forms and content while struggling with specialized graphics or long background tasks.
Profile the critical workflow on real lower-end devices.
Device capabilities
Consider needs for:
- Camera
- Bluetooth
- NFC
- Sensors
- Secure hardware
- Health data
- Files
- Background location
- Widgets
- Live activities
- AR
Native frameworks usually expose new capabilities first.
Cross-platform frameworks rely on plugins or native modules.
Web APIs may be unavailable or restricted.
One missing critical capability can outweigh broad code-sharing benefits.
Offline behavior
All models can support offline work, but through different storage and lifecycle tools.
Requirements include:
- Local database
- Cached assets
- Synchronization
- Conflict resolution
- Encryption
- Migration
- Backup expectations
A native app is not automatically offline-first.
A web app with a service worker is not automatically useful offline.
Offline behavior must be designed around specific tasks.
Distribution
Web:
- Open a URL
- Deploy server changes quickly
- No store review for ordinary updates
Native and packaged cross-platform:
- App stores or enterprise distribution
- Review and signing
- Installation
- Version adoption delay
Stores provide discovery, trust signals, payments, and device management.
They also impose policies, fees, review time, and account risk.
Distribution can be more important than implementation language.
Update control
Web applications can update when the user reloads or receives new assets.
Installed apps may remain old for months.
Backend APIs must support version lag.
Some frameworks support over-the-air updates for permitted code and assets, but platform policies limit what can change outside store review.
Updates need:
- Rollback
- Compatibility
- Migration
- User-state protection
Fast update capability should not bypass quality and security review.
Accessibility
Native, web, and cross-platform stacks all have accessibility APIs.
Quality depends on:
- Semantic components
- Focus
- Screen-reader names
- Dynamic text
- Keyboard and switch support
- Contrast
- Motion
Cross-platform abstractions may map imperfectly to platform semantics.
Custom drawing and canvas-heavy interfaces need extra accessibility work.
Test each target platform with its assistive technologies.
Shared code does not guarantee shared accessible behavior.
Security
Mobile clients are untrusted and can be inspected.
Do not embed:
- Server API secrets
- Master encryption keys
- Privileged credentials
Use platform secure storage for tokens, certificate validation, server-side authorization, dependency review, and secure update signing.
Native binaries are harder to inspect than web source but not secret.
The backend remains the authority for shared business rules.
Team and ecosystem
Consider:
- Existing skills
- Hiring
- Library maturity
- Vendor longevity
- Upgrade path
- Debugging tools
- Native expertise
- Release operations
A framework that promises speed may create dependency on a small plugin ecosystem.
Native development may require two teams but give clearer platform ownership.
Web may fit an organization with strong browser skills and modest device integration.
Choose a stack the team can maintain for the product's expected lifetime.
Product consistency and platform fit
Products need consistent:
- Brand
- Information architecture
- Business rules
- Account behavior
They also need platform fit:
- Back navigation
- System controls
- Permission patterns
- Input conventions
Design systems can define shared tokens and behavior while using platform-appropriate components.
Consistency means predictable product meaning, not pixel identity across all devices.
Hybrid strategies
A product can combine approaches:
- Native shell with web content
- Shared core logic with native screens
- Web onboarding plus native main app
- Native app for field staff and web dashboard for managers
Hybrid design can place each workflow in the delivery model that fits it.
It also introduces:
- Authentication handoff
- Navigation boundaries
- Duplicate analytics
- Accessibility consistency
- Release coordination
Use hybrid boundaries deliberately.
Decision questions
Ask:
- Which device capabilities are essential?
- What performance is required?
- Must it work offline?
- How will users discover and install it?
- How quickly must updates reach everyone?
- Which platforms matter?
- What skills and operations can the team sustain?
- How much platform-specific experience is valuable?
Prototype the highest-risk capability before committing.
Do not choose based only on an impressive demo or claimed code-reuse percentage.
Knowledge check
- Which benefits commonly favor native development?
- How does a PWA differ from an ordinary web app?
- Why does shared code not eliminate platform-specific design?
- How can distribution requirements decide the architecture?
- Why must mobile clients never contain privileged server secrets?
The one idea to remember
Native, web, and cross-platform approaches are delivery models with different strengths. Choose from device access, performance, distribution, offline needs, accessibility, update behavior, and the team's ability to operate the product over time.