Lock distribution and capability bounds before shell and store
Mobile decisions for B2B tools get hijacked by “do we need the store?” Some default to native for credibility; others assume PWA halves the budget. Ask first: how users install and update, offline needs, push and background limits, device APIs (camera/Bluetooth/files), MDM and data residency, and two-to-three-year TCO. At KSX Studio, across mobile and web work, common paths are web core plus optional native shell, or internal tools as installable PWA/desktop. China adds store review, OEM push, and WebView variance. Below: comparison dimensions and traps so an MVP choice does not freeze the next three years of architecture.
Users and context: field, desk, or occasional phone
Field inventory, inspections, and shift handoffs stress offline, scan, and continuous location—native or mature cross-platform is often safer. Sales dashboards, approvals, and light CRM on a phone may be fine as PWA or responsive web if desktop remains primary. Map weekly active time × one-handed use × offline—not only “do we need an app.” For internal tools, ask whether access is portal-only and whether personal store installs are banned. When context is fuzzy, validate flows with a clickable web prototype before spending store capital.
Distribution and updates: store, link, MDM
Native ships via stores or enterprise signing/MDM; updates depend on review and user taps. PWAs ship via URL and “add to home screen”; updates can follow deploy, but install education is hard and iOS capability/discovery remain limited. If customer IT distributes via MDM, a native package can be more compliant. If users are suppliers and external partners, app install friction is high—PWA/web login is shorter. Put on the decision sheet: target install conversion, forced-update need, whether store search presence is mandatory.
Capability bounds: push, offline, hardware APIs
Label capabilities must / nice / not needed. Reliable background push, Bluetooth peripherals, complex background sync, and advanced biometrics favor native or cross-platform with native modules. PWA service-worker caches suit assets and read-mostly data; conflict-prone offline writes need careful design. Camera scan works in modern browsers but needs real-device tests for fragmentation and permission UX. Do not mark everything must for a hypothetical future—that defaults to native and eats budget.
Security, compliance, and enterprise policy
B2B often needs SSO, cert pinning, screenshot limits, remote wipe, data residency. Native + MDM is more mature for device policy; PWAs rely on browser security and server sessions—design token lifetime, device binding, and anomaly login. Sensitive manufacturing or finance fields may force store distribution and app hardening by legal. Transport, storage, and log redaction apply regardless of shell; shell choice is not a threat model. In China, assess domain, ICP, and third-party SDK inventory.
Performance and WebView traps
Wrapping WebView and calling it native is not native UX. Long lists, heavy charts, and chatty bridges expose WebView performance and memory issues. A browser PWA can be more predictable than dual-OS WebView shells—one less fragmentation layer. If hybrid, set budgets (startup, input delay, list FPS) and a real-device matrix; follow hybrid performance practice. React Native vs native in 2026 is a separate decision; here the question is whether the B2B tool must leave a web core.
TCO: more than the phase-one quote
Price 24 months of dual native, cross-platform, and PWA/web: eng headcount, design adaptation, test matrix, store ops, push/certs, hotfix and review failure rework, customer IT tickets. PWAs often cut install and review cost but raise customer-success cost for “how do I install.” Native may raise win credibility yet stretch delivery when every feature is dual-OS. Put cost next to revenue (enterprise wins unlocked, procurement blockers) so eng preference does not capture the business case.
Default path and upgrade triggers
For most B2B tools, KSX defaults to: responsive web as source of truth → add PWA install and read-mostly offline when needed → go native/cross-platform only on hard capability or distribution constraints. Upgrade triggers: offline write conflicts become primary, MDM mandates an app package, push delivery is an SLA, peripherals need stable links. Downgrade triggers: repeated store rejection, dual-OS staffing so thin that features fork. Keep domain logic and APIs decoupled from the shell so the first choice does not trap the model inside one client.
How to run the decision workshop in discovery
Ninety-minute agenda: context map 20m; must-have capability vote 15m; distribution/IT constraints 15m; rough TCO 15m; risks and upgrade triggers 15m; written conclusion 10m. Output a one-pager: choice, assumptions, 12-month review date. Schedule spikes (push delivery, offline conflict, scan devices) early in design/build—not launch week. When using an external team, put the decision in scope and acceptance so “let’s also ship an app” mid-project is a priced change.
Checklist
- 1Primary user contexts mapped for offline, one-handed, and long-session use
- 2Distribution path (store/MDM/URL) and forced-update need documented
- 3Device capabilities labeled must/nice/no with a real-device validation plan
- 424-month TCO and commercial upside on the same decision sheet
- 5Upgrade/downgrade triggers and a 12-month review date recorded
Key takeaways
- B2B mobile choice is distribution and capability first—tech preference second
- Web core plus explicit upgrade triggers usually beats dual native on day one
- A WebView shell is not native; budgets and device matrices belong in acceptance
FAQ
- Is PWA on iOS enough for a B2B tool?
- It depends on push, background, install UX, and enterprise policy. Many approvals and read-only dashboards work; hard offline writes and strict MDM often do not. Spike install and push on target devices—do not trust generic blog conclusions.
- We already have a responsive site—do we still need a PWA?
- Add a PWA layer if you need home-screen install, limited offline, standalone display, or stronger cache control. If users stay on desktop or in managed browser sessions, invest in web UX and performance first—usually higher ROI.
- Where does cross-platform native (e.g. React Native) sit?
- It sits in the middle: app package and more native APIs, with shared UI logic. You still pay store and dual-OS test cost—just less than two native teams. Score it on the same distribution/capability sheet as PWA; do not decide only on “can we use JavaScript.”