Mobile app development.

Cross-platform frameworks such as React Native and Flutter can share a significant portion of application code between iOS and Android. Native development, meaning separate Swift and Kotlin builds, may be preferred when a product depends heavily on platform-specific capabilities, performance requirements, or deep operating-system integration.

A progressive web app may also be appropriate when browser delivery, installation requirements, and device capabilities fit the product. The choice is made against the product's features, design, native integrations, testing requirements, and budget. A shared codebase reduces duplicated implementation, but how much that changes total project cost depends on how much of the product is platform-specific.

Where a product must remain useful with limited connectivity, offline behaviour is designed explicitly. This can include cached data, queued actions, synchronisation rules, conflict handling, and clear interface states for operations that require a connection.

Install size and data usage are decided during the build rather than adjusted afterwards. Where users are on metered mobile data and mid-range devices, both belong in the specification, and the app is tested on that class of device.

An application that stores data, has accounts, or takes payments needs a backend, and that backend is a substantial part of the scope. It covers the API, the data model, authentication and session handling, permissions, and the administrative interface the business uses to run the product.

Where the app takes payments, M-Pesa can be integrated through the Safaricom Daraja API with STK push and server-side callback confirmation, the same reconciliation a web checkout requires. Card payments and any in-app purchase requirements are assessed against the store policies that apply to the product, before the payment flow is designed.

App Store and Google Play preparation and submission support can be included in the project: developer account setup, store listings, screenshots, privacy declarations, and the submission itself. Approval decisions and review timelines are controlled by Apple and Google.

Every subsequent update goes through the same review queue, so release planning allows for it. The most common causes of rejection are administrative, a missing privacy policy, a test account the reviewer cannot use, a permission requested but never explained, and they are dealt with before submission.

iOS and Android both ship annual platform updates that can deprecate what an application relies on. Maintenance covering OS compatibility, dependency updates, security patches, crash monitoring, and small changes can be included under an ongoing arrangement.

Ongoing cost depends on backend infrastructure, operating-system changes, third-party services, monitoring, support, and the rate of new feature development. It is budgeted separately from the initial build so the running cost is visible before the project starts.