Flutter lets one codebase reach Android and iOS—if your backend is ready

A polished shop app only works when orders, auth, and notifications already live in one API—not in a spreadsheet beside the website

HARTBEESPOORT — For a South African shopkeeper weighing a branded phone app, the sales pitch is seductive: one build, two app stores, customers who never forget you because your icon sits on their home screen. Flutter, Google's open-source UI toolkit, is the framework most agencies now cite for that promise. Its documentation states that developers can maintain one codebase and deploy to mobile, web, desktop, and embedded targets from the same project (Flutter multi-platform). The May 2026 Flutter 3.44 release further tightened iOS dependency handling by making Swift Package Manager the default for Apple builds, reducing the tooling friction that once slowed cross-platform delivery (Flutter 3.44 release notes).

The catch, repeated in planning rooms from Gauteng to the Cape, is simpler than any framework debate: a pretty mobile wrapper around a broken website is still broken. If product stock, checkout, and order status do not already flow through a disciplined backend, wrapping the storefront in native chrome will not fix fulfilment gaps—it will only make them harder to ignore.

One API, two screens

The architecture that works in production looks like a straight line. A Django REST backend holds products, customers, carts, and orders in one database. A React web storefront reads those endpoints today. A Flutter client reads the same endpoints tomorrow—account login, order history, saved addresses, and catalogue search—without duplicating business rules in a second codebase.

That pattern is visible on past-and-present.co.za, the Hartbeespoort-based shop trading as Past and Present under the banner "Vintage & Modern Treasures." The public site lists hardware, consumables, bundles, and vintage stock with cart and registration flows; product imagery is served through an API media route rather than static page assets, signalling that the browser shop is a client of a shared backend rather than a standalone brochure (Past and Present). Card payments via Yoco, tracked domestic delivery windows, and fourteen-day returns are documented on the shop's FAQ—the operational promises a mobile app would inherit, not reinvent (Past and Present FAQ).

For developers, Django REST framework supplies serializers, authentication policies, and browsable endpoints—the standard toolkit for exposing that backend to any client (Django REST framework). Mobile apps typically authenticate with JSON Web Tokens through libraries such as djangorestframework-simplejwt, which issue short-lived access tokens and longer-lived refresh tokens so sessions can persist without storing passwords on the device (Simple JWT documentation). Production deployments should keep access lifetimes short, rotate refresh tokens, and serve all traffic over HTTPS so bearer tokens cannot be intercepted in transit—a baseline requirement when the same login must work on a phone and in a desktop browser under one account.

What the app actually delivers

Agency briefs for independent retailers usually cluster around a handful of features that justify store listings beyond a responsive website.

Push notifications for order updates. When a parcel ships or a message arrives, Firebase Cloud Messaging (FCM) can deliver a visible alert to the customer's device. Google's Flutter documentation walks through installing the firebase_messaging plugin, retrieving a device registration token, and handling taps that reopen the app to the relevant order screen (FCM in Flutter — get started). On the server side, the Django backend registers each device token and triggers notifications when order status changes—"Your order has shipped" on the lock screen is the textbook use case described in integration guides for this stack. Setting up FCM requires Firebase project credentials and Apple push capability; those are operational steps for the merchant and developer, not something shoppers ever see.

Offline-friendly catalogue browsing. South African mobile networks remain uneven outside major metros; an app that blanks out when signal drops loses browsing sessions. Flutter's offline-first guidance recommends a repository pattern that reads cached catalogue data immediately from local storage, then refreshes from the API when connectivity returns (Offline-first support — Flutter docs). Product search and window-shopping can work from cache; payment and checkout still require a live connection—a honest split most SME shoppers accept if the app labels cached content clearly.

Consistent branding across devices. The editorial image brief for this story—a phone showing order history beside a desktop browser logged into the same account—captures the product goal: one identity, one order record, two form factors. Flutter's custom rendering engine draws its own pixels rather than delegating entirely to native widgets, which helps visual parity between Android and iOS (Flutter multi-platform).

WhatsApp when chat is enough; an app when loyalty is the product

South Africa's default digital shop counter is not an app store listing—it is WhatsApp. Industry commentary notes that many local businesses already take bookings, share menus, and confirm deliveries inside chat threads that customers open dozens of times a day (Business Day — WhatsApp commerce). Separate market analysis puts WhatsApp penetration among South African consumers at roughly ninety-six percent, making messaging channels attractive for businesses whose customers arrive by referral rather than search (SO Websites — WhatsApp automation in SA).

For a sole trader fielding under a hundred conversations a month, the free WhatsApp Business app or a lightweight API integration may suffice. The WhatsApp Business API—the programmatic tier that powers automation, multi-agent inboxes, and ecommerce hooks—carries per-message fees and platform charges that scale with volume; guides aimed at South African operators suggest it fits businesses sending hundreds of messages monthly or running structured support teams, not every corner shop (WhatsApp Business API guide — Growth Pulse Media).

A branded Flutter app earns its keep when repeat purchase behaviour matters: saved addresses, order history, stock alerts, and push notifications that do not depend on a customer staying inside a chat thread. Vintage-and-hardware retailers like Past and Present, where buyers compare bundles over weeks and return for consumables, sit closer to that repeat-buyer profile than a one-off takeaway order. WhatsApp remains the right front door for discovery and quick questions; the app is the drawer where loyal customers keep the keys.

Timeline and budget—after the web launch

Agency roadmaps for South African SMEs typically treat mobile as a defined phase after web launch, not a parallel bet. The sequence is deliberate: stabilise product data, auth, payments, and fulfilment on the website; expose those flows through documented REST endpoints; only then commission iOS and Android builds that consume the same API. Skipping the middle step is how projects ship on time in the project plan and late in the warehouse.

Cost framing is equally blunt. Industry surveys of South African development rates cite roughly ZAR 30,000 to ZAR 350,000 depending on complexity, with cross-platform builds in major metros such as Cape Town often landing in the ZAR 130,000–ZAR 170,000 band for UI-heavy consumer apps (Mobile app development cost in South Africa — Helpful Insight Solution). Flutter's single-codebase model can reduce duplicate Android and iOS engineering relative to two native projects—an economic argument the framework's own marketing emphasises when it claims ninety percent of code can be shared across platforms in mature deployments (Flutter multi-platform). That saving evaporates if the backend must be rebuilt simultaneously.

Calendar expectations from delivery teams familiar with this stack often run twelve to twenty weeks for a first consumer release after APIs are stable: design and navigation, catalogue and cart screens, JWT login, push notification wiring, store listing assets, and review cycles on both Google Play and Apple's App Store. Backend hardening—token refresh, order webhooks, device registration—runs in parallel but should finish first.

Preconditions worth checking before you sign

Before approving a mobile phase, an owner can ask five questions that separate a channel extension from an expensive duplicate:

Do web customers already have accounts with order history? If not, the app has nothing to sync.
Are product, price, and stock changes made once in admin and reflected on the site? If staff still maintain a parallel spreadsheet, mobile will inherit the same drift.
Can the API authenticate mobile clients with JWT and return paginated catalogue JSON? DRF's authentication and serialization layers exist precisely for this contract (Django REST framework).
Is there a plan for push notifications when orders change state? FCM requires Firebase project setup and Apple push entitlements—budget time, not just budget rand (FCM in Flutter — receive messages).
Is repeat purchase common enough to overcome install friction? If every sale is a once-off WhatsApp enquiry, chat may remain the better investment (Business Day — WhatsApp commerce).

Past and Present's live .co.za storefront demonstrates the web-first half of that checklist: searchable catalogue, cart, accounts, and FAQ-backed delivery promises on one domain (Past and Present). A Flutter client would extend the same rails—not replace them.

For independent retailers comparing build paths, Flutter is not a shortcut around backend discipline. It is the reward for getting the boring parts right first: one order row, one login, one notification that tells the truth when the courier finally moves.