Native vs Cross-Platform vs PWA in Kenya: 10 Questions Before You Build

“Should we build a mobile app?” is usually the wrong first question. A Kenyan or East African organisation first needs to define who will use the product, what they must accomplish, which devices and networks they rely on, and what must still work when connectivity becomes unreliable. Only then does native, cross-platform or progressive web app become a useful decision.

A native app is built for a specific operating system. A cross-platform app shares much of its code while producing mobile applications for more than one platform. A progressive web app, or PWA, is a web application enhanced with installable and offline-capable features where browser and platform support allow them. None is universally best; each concentrates cost, risk and flexibility in different places.

The practical difference

• Native: separate platform-specific applications can provide direct access to operating-system capabilities and platform conventions, with separate engineering and release responsibilities.
• Cross-platform: one product team shares a substantial codebase while still packaging mobile applications for supported stores and devices. Platform-specific work does not disappear.
• PWA: users access a web application through a browser, and supported devices may install it and use selected features offline. Capability and installation behaviour vary by browser and operating system.

If the product is mainly public information, discovery and enquiries, begin with the website versus web app guide. An app format is justified when a repeated workflow creates enough value to support ongoing product ownership.

Ten questions that decide the architecture

1. Who uses it, how often and on which devices?

Describe the actual user groups, their phones, operating-system versions, shared-device rules and frequency of use. An internal field team on managed Android devices presents a different decision from consumers using a broad mix of Android, iPhone and desktop browsers.

2. Which device capabilities are essential?

List required camera, location, biometrics, Bluetooth, background processing, push notifications, secure storage and file functions. Mark each as essential, useful or optional. Verify current platform support instead of assuming every browser or cross-platform library exposes identical behaviour.

3. What must work offline?

“Offline” needs acceptance cases. Can a user open previously viewed information, create a draft, capture several records, attach media or complete a transaction? Define what is stored locally, how long it remains, what happens when the same record changes elsewhere, and how the interface explains pending synchronization.

4. How will users discover and install it?

Native and cross-platform apps usually rely on store listings, review processes and update channels. A PWA can begin at a URL and may offer installation where supported. Decide whether store presence is a business requirement, whether users can follow installation guidance, and who owns listing assets, policies and release credentials.

5. What data and security risks exist?

Classify personal, financial, health, location and organisational data. Define authentication, session expiry, role access, encryption, device loss, logs and data deletion. Mobile packaging does not make insecure server logic safe; authorization and transaction rules remain server responsibilities.

6. Which integrations must survive?

Map payments, identity, notifications, maps, analytics, CRM, ERP and reporting dependencies. For payments, separate the customer prompt from server-side confirmation and reconciliation; the M-PESA integration guide explains that control boundary.

7. How much platform-specific experience is required?

A shared design system can still respect platform navigation, permissions and accessibility patterns. List where the experience must feel deeply native and where a consistent interface is more important. Prototype the high-risk interactions on real devices before committing to a complete build.

8. What is the testing matrix?

Write the supported devices, operating systems, browsers, screen sizes, network conditions and accessibility checks. Cross-platform code reduces duplication in some areas but still needs platform testing. PWAs need browser and installation-state testing. Native applications need each supported platform and release path verified.

9. Who owns releases and maintenance?

Name the owners of source code, signing keys, developer accounts, domains, hosting, analytics, monitoring and backups. Plan for operating-system releases, browser changes, third-party SDK updates, security patches and store requirements. Our support and maintenance service covers measured operating work after launch.

10. What evidence will justify the investment?

Define a baseline and outcome: completion rate, time per task, adoption by an eligible user group, failure rate, support demand or verified revenue contribution. Traffic and downloads alone do not prove that the product improved the workflow. Review full discovery, implementation and lifecycle scope in the custom software cost guide.

A decision guide

• Consider native when deep platform integration, demanding device capability or highly platform-specific experience is central and the organisation can sustain separate platform work.
• Consider cross-platform when the core journeys should remain consistent across iOS and Android and a shared codebase offers meaningful delivery value without hiding essential native work.
• Consider a PWA when reach through a URL, responsive desktop/mobile use and a single web release path matter more than universal access to native capabilities or app-store distribution.
• Consider a responsive website first when the need is primarily information, credibility, discovery and contact rather than a repeated signed-in workflow.

Red flags in a proposal

• The framework is chosen before user journeys and device capabilities are documented.
• “Works offline” has no conflict, storage or synchronization rules.
• One shared codebase is presented as eliminating all platform-specific testing.
• Store accounts, signing credentials and source ownership remain with an individual supplier.
• Security is described only as login screens rather than data, server and device controls.
• Maintenance, monitoring and operating-system updates are absent from the budget.
• Downloads, growth or revenue are guaranteed without a measurable adoption plan.

Frequently asked questions