Once a business has decided that a cross-platform app is appropriate, it still needs to choose the shared app layer. Flutter and React Native can both support Android and iOS products, but neither removes the need for native code, device testing, store operations or a dependable backend.
Choose Flutter when a controlled custom interface is central to the product and the delivery team is comfortable with Dart. Choose React Native when the business has strong React and JavaScript or TypeScript capability, or when the difficult native integration has been proven in that stack. In either case, test the most uncertain device and backend behaviour before committing to a full build.
This is a more specific decision than the native versus cross-platform choice. It is relevant to South African businesses commissioning a customer app, staff tool, booking product or portal. The framework should follow the product constraint, not a supplier’s default preference.
What differs between Flutter and React Native
Flutter documents a layered framework that includes its own widgets, rendering and platform embedding. It also documents platform channels for calling platform-specific code when an app needs an API or capability outside the framework layer.
React Native renders through native platform components. Its platform-specific-code documentation explains how Android and iOS code can diverge where a visual treatment or behaviour must differ. That is an important purchasing detail. A shared codebase does not mean every screen, test case or integration is shared.
Both approaches can be right for the same type of product. The decision becomes clearer when the business identifies the work that could change the estimate: hardware access, offline sync, existing front-end skills, complex animations, distinct platform behaviour or a high-risk backend integration.
A practical Flutter versus React Native matrix
| Project condition | What to prove | Decision signal |
|---|---|---|
| The app needs a tightly controlled visual system across iOS and Android. | Build one representative screen with typography, form errors, accessibility labels, loading states and any dark-mode rules. | Flutter can suit a product where the team wants one widget system to drive the interface. Confirm platform-specific behaviour rather than assuming identical output. |
| The business already has a React web product or a JavaScript or TypeScript team. | Review who will maintain the mobile app, API client, types and build pipeline after launch. | React Native may reduce the learning and hiring burden. Familiar language is not enough if the difficult integration has no tested route. |
| The first release relies on Bluetooth, NFC, background processing, wearables, camera scanning or specialised hardware. | Create a small technical spike for the hardest capability on real target devices, including denied permissions and interrupted connectivity. | Choose the option with a demonstrated native-module or platform-code plan. A package listing is a starting point, not proof that the product requirement works. |
| The app is an API client for accounts, bookings, field work or ecommerce. | Define authentication, error handling, offline behaviour, retries and the system of record for important data. | The backend contract and test plan may matter more than the framework. Use the stack the delivery team can support with clear ownership. |
| iOS and Android must behave differently in places. | List every difference, such as navigation, permission handling, payments, notifications or sharing. | Both stacks permit platform-specific code. Make it visible in scope and test it separately. |
The proof-plan checklist before a fixed build quote
A technical spike is a short, time-boxed investigation that answers a question capable of changing the architecture or estimate. It costs less than discovering a blocked integration after most screens exist. Ask for a written result, a demonstration on devices and a recommendation that records what remains uncertain.
- Name the risky journey. Describe a user action and outcome. For example: a field employee captures a photo without signal, sees that it is pending, and the record synchronises when connectivity returns without producing a duplicate.
- Set the device boundary. State the lowest supported iPhone and Android device class, OS versions, permissions, hardware accessory and network condition that matter. A proof that only works on a developer’s current handset is incomplete.
- Test the real backend contract. Use the intended authentication method, API limits and failure responses where possible. A mocked happy path cannot reveal an expired token or failed service.
- Check the operating model. Confirm who owns the source repository, cloud project, Apple Developer account, Google Play Console account, signing keys, crash reporting and release approval. The business should own production accounts and grant a supplier the access it needs.
- Record the decision. Keep the tested devices, result, limitations, follow-up work and the person who accepted the trade-off with the technical brief.
The mobile app development brief checklist helps turn this information into comparable supplier proposals. Where several vendors or systems are involved, technical project management can establish the delivery plan before development begins.
Store obligations belong in the scope
Framework choice cannot remove store requirements. Apple publishes its App Review Guidelines, including requirements that apply when an app supports account creation. Google Play requires developers to set up a store listing and meet current target API-level requirements when uploading an app bundle. Account deletion, privacy disclosures, store assets, support contact details and release access need owners and acceptance tests.
For an app that collects personal information, map each data field, permission, SDK and external recipient before implementation. The Information Regulator of South Africa describes POPIA as a framework for responsible and lawful processing of personal information. Obtain appropriate legal advice for the product’s obligations, particularly where special personal information or cross-border processing is involved. The development work still needs practical answers: what is collected, why it is needed, where it goes, how long it remains available and how a user can request deletion.
Questions to put to a development partner
- Which user journey or device capability is most likely to force native platform code, and how will you prove it?
- What code, configuration and accounts remain platform specific after the shared app layer is built?
- Which devices, OS versions and network conditions are included in acceptance testing?
- How will the app handle expired sessions, permission refusal, slow APIs, offline changes and conflicting updates?
- Which party owns the store accounts, signing credentials, source repository, cloud services and incident response after launch?
- What discovery finding would change the framework recommendation?
A credible proposal names its unknowns. Be cautious of one that promises a single codebase, a fixed estimate and no platform-specific work before it has seen the integration contracts or tested the difficult device behaviour.
Where Galactic Digital fits
Galactic Digital builds Flutter and React Native applications for businesses across South Africa from Cape Town. Start with a technical scope that names the user journey, systems to integrate, data handling and device features that cannot fail. Review the mobile app development service or start a project conversation with the proof-plan questions above.
Sources and further reading
- Flutter architectural overview, Google, accessed 26 October 2026. Supports the description of Flutter’s framework layers, widgets, rendering and platform embedding.
- Writing custom platform-specific code, Google, accessed 26 October 2026. Supports the description of Flutter platform channels.
- Native Components and Platform-Specific Code, Meta, accessed 26 October 2026. Support the description of native components and separate iOS or Android code paths.
- App Review Guidelines, Apple, accessed 26 October 2026. Supports the release-planning guidance.
- Create and set up your app, Google Play Console Help, accessed 26 October 2026. Supports the store listing and target API-level guidance.
- POPIA, Information Regulator South Africa, accessed 26 October 2026. Supports the description of POPIA.
Featured image: Firebase-flutter Arch by Jhonardz Abdulkadil licensed under CC BY 4.0.