- Apps & Mobile
eCommerce App Development That Earns Its Place on a Phone
Native and cross-platform shopping apps, progressive web apps and custom platform apps, built by the team that then has to get people to install and reopen them. Most brands do not need an app. The ones that do need it for one specific reason, and the honest first conversation is about whether yours is one of them.
- We will tell you if a faster mobile site would beat an app for less money
- Built against a retention target, not a launch date, because an uninstalled app earns nothing
- Your repository, your developer accounts, your store listings — documented and handed over
iOS + Android
One shared codebase
Your repo
Code and accounts in your name
Day 30
Retention reviewed, not just launch
Scoped
Quoted from requirements
- The Problem
Why most eCommerce apps get built and then abandoned
Twelve reasons app projects fail, and almost none of them is a development problem. We raise these before quoting, because the cheapest app project is the one you decide not to do.
It duplicates the mobile site
An app that does exactly what your website already does on a phone gives a shopper no reason to install it, and no reason to keep it.
Nobody owns installs
The build gets budget and the acquisition does not. An app with no install channel is a product with no distribution.
Retention was never a target
Apps are judged on day-30 retention, not downloads. If nobody agreed a number before the build, nobody can tell afterwards whether it worked.
The catalogue does not suit it
Apps reward frequent, habitual purchase. A catalogue bought once every two years will not generate the reopen rate an app needs to justify itself.
Two codebases, two release trains
Separate native iOS and Android builds double the maintenance and guarantee the two drift apart. Most brands cannot resource that honestly.
Checkout was rebuilt from scratch
A hand-built app checkout rarely matches the hosted one it replaced, and wallet support is where it usually falls short.
No plan for store review
App Store and Play review can add a week to any release and can reject one outright. Teams that have not budgeted for it miss launch dates.
Deep links were an afterthought
Without universal links and app indexing, every campaign, email and search result sends app users back to the website.
Push became spam
Notification permission is granted once and revoked permanently. Overused in month one, the channel is gone by month three.
Nobody budgeted for upkeep
Two operating systems ship breaking changes every year. An app without a maintenance retainer stops working, and the first sign is usually a one-star review.
Analytics never matched the website
App and web analytics use different identity models. Without deliberate work the app looks either far better or far worse than it is.
It was built on a template
App-builder templates launch quickly and hit a ceiling almost immediately, and the code is rarely portable when you outgrow it.
- What We Do
Our eCommerce app development services
Eight services covering build, release and upkeep. Scope the eCommerce app development services you need from the audit rather than from a package list — most brands need two or three of these, not all eight.
01
Cross-Platform App Development
One React Native codebase shipping to both iOS and Android, which is the right default for most brands.
02
Native iOS & Android Development
Separate native builds where device features, performance or an existing team genuinely justify two codebases.
03
Progressive Web Apps
An installable, offline-capable storefront with no app store dependency — often the honest alternative to an app.
04
Custom Platform Apps
Shopify, BigCommerce and WooCommerce apps built for your own store where no off-the-shelf app does the job properly.
05
Headless Storefront Builds
A React or Next.js front end on your existing commerce backend, where template control is the actual requirement.
06
App Integrations & APIs
Commerce, loyalty, search, reviews and support joined to the app through your platform APIs, with error handling.
07
Release & Store Submission
Signing, provisioning, store listings, review submissions and the staged rollouts that limit the damage of a bad build.
08
App Maintenance & Support
OS version upgrades, SDK deprecations, crash monitoring and the release cadence that keeps the app from quietly breaking.
App work sits on top of the store rather than beside it — it depends on eCommerce development, feeds off retention for installs and reopens, and is only worth doing once conversion on the mobile site is sound.
- Stack
Platforms & technologies we build apps on
We recommend the approach that fits the business and the team that will maintain it, not the one we would rather build on.
Commerce Backends
- Shopify & Shopify Plus
- WooCommerce
- BigCommerce
- Adobe Commerce / Magento
App & Front-End
- React Native
- Swift (iOS)
- Kotlin (Android)
- React & Next.js / PWA
App Infrastructure
- Push notifications
- Deep & universal links
- App analytics & attribution
- Crash & performance monitoring
- Wallet & in-app payments
- CI, signing & staged rollout
- Scope
What our eCommerce app development covers
Ten things we build regularly. If what you need is not on this list it is worth a conversation rather than an assumption — most eCommerce app development work turns out to be three of these ten, not all of them.
Shopping apps
Progressive web apps
Product & browse experiences
In-app checkout & wallets
Subscription & reorder flows
B2B ordering apps
Loyalty & rewards
Push & in-app messaging
Account & order tracking
Custom platform apps
- Ecosystem
What the app has to connect to
An app is a second front end on the same business. Everything below already exists for the website, and every one of these connections is a place where the app and the site can silently stop agreeing.
Your App
Connected to the nine systems below
Payments
Apple Pay, Google Pay, saved cards and in-app purchase rules.
Catalogue & Stock
Live availability, so the app never sells what the website knows is gone.
Identity & CRM
One customer record across app and web, including social and passkey sign-in.
Orders & ERP
App orders in the same queue as web orders, not a separate pile to reconcile.
Push, Email & SMS
One messaging plan across channels, so a customer is not told the same thing three times.
Analytics & Attribution
App events mapped to the same definitions as the website, or the two will never reconcile.
Shipping & Tracking
Live tracking in the app, which is the single most-used feature on most shopping apps.
Search & Merchandising
The same search engine and ranking rules as the site, not a second set of results.
Support & Returns
Helpdesk, chat and returns inside the app, with order context already attached.
- The Process
Our eCommerce app development process
Seven stages. The first one is the one that saves most of the money, because it is where we establish whether you need an app at all.
01
Qualify
Purchase frequency, repeat rate, mobile revenue share and the install channel you actually have. If the numbers say a faster mobile site would beat an app, we say so and the project stops here.
02
Plan
Native or cross-platform, a feature scope tied to a day-30 retention target, store accounts in your name, and a release calendar that assumes review delays rather than hoping against them.
03
Design
Native patterns rather than a website in a frame — platform navigation, gestures, system fonts and dark mode, designed on the handset sizes your own analytics show.
04
Build
Shipped to a test track in reviewable increments, with deep links, push, analytics and crash reporting wired in from the first build rather than retrofitted before launch.
05
Test
Real devices across both operating systems and several OS versions, offline and poor-connection behaviour, and the failure paths — declined cards, expired sessions, an API that times out mid-checkout.
06
Submit & Release
Signing, provisioning, store listings and privacy declarations, then a staged rollout to a small percentage first so a crash reaches dozens of customers rather than thousands.
07
Retain & Maintain
Day-7 and day-30 retention reviewed against the target set at planning, alongside OS upgrades, SDK deprecations and crash triage. This is the stage that decides whether the build was worth it.
- By Need
App development by business need
Eight needs and the approach each one calls for. Two of them are answered by not building an app.
Customers Buy Monthly or More
Cross-platform shopping app
The one case where an app reliably pays: habitual reorder, saved payment, one-tap repeat and push that is actually useful.
Mobile Site Is the Real Problem
Performance work, not an app
If mobile converts at half of desktop, fix that first. It costs a fraction of an app and benefits every visitor rather than the few who install.
You Want App-Like Without Stores
Progressive web app
Installable, offline-capable and push-capable, with no review queue and no 30% store cut on anything sold inside it.
Trade Buyers Reorder Constantly
B2B ordering app
Contract pricing, order pads, approval flows and reorder from history, for buyers who place the same order every week.
The Platform Cannot Do It
Custom platform app
A private Shopify or BigCommerce app built for your store, which survives platform updates in a way a theme hack does not.
An Existing App Is Failing
App audit & rebuild decision
A code and analytics audit to establish what is salvageable. Sometimes the honest answer is that a rebuild costs less than continuing to patch.
You Need Template Control
Headless storefront
If the requirement is control over rendering and URLs rather than a phone icon, headless is the cheaper and more durable answer.
The App Already Shipped
Maintenance & release retainer
OS upgrades, SDK deprecations, crash triage and a named developer who already knows the codebase.
- Foundations
Performance, privacy & release discipline
Four non-negotiables, all in scope by default. On an app these are harder to retrofit than on a website, because a bad release reaches a store listing and a review score before it reaches you.
Performance
- Cold start time
- Scroll and image performance
- Poor-connection behaviour
Reliability
- Crash-free session rate
- Staged rollouts
- Rollback and forced-update paths
Privacy & Security
- Store privacy declarations
- Tracking consent and ATT
- Token storage and session handling
Maintainability
- One codebase where possible
- OS and SDK upgrade cadence
- Documented build and release
- Accounts and signing keys in your name
- Why Us
Why choose our eCommerce app development company
Eight things that separate a commerce app from a general mobile project, and what to ask any eCommerce app development company before the statement of work is signed.
We Will Talk You Out of It
If your purchase frequency and install channel do not support an app, we will say so before quoting. That costs us the project and saves you the budget.
Built Against a Retention Target
Day-7 and day-30 retention agreed at planning and reviewed after launch. Downloads are a vanity number and we do not report them alone.
The Team That Markets It
The people building the app also have to drive installs and reopens afterwards, which changes what gets prioritised in the scope.
Commerce, Not Generic Mobile
Variant logic, wallet checkout, live stock and returns are our daily work rather than something looked up when a ticket mentions them.
One Codebase by Default
Cross-platform unless there is a specific reason not to be, because two native codebases double the maintenance and drift apart within a year.
Store Submission Owned
Signing, provisioning, privacy declarations and review responses handled by us, with the accounts and keys in your name throughout.
Deep Links From Day One
Universal links and app indexing built in, so email, search and paid campaigns open the app rather than bouncing users to the website.
You Own Everything
Your repository, your developer accounts, your signing keys, your store listings, documented at handover. There is no version of this where leaving us breaks your app.
- Build types
Three ways this gets built, and what each one commits you to
Three approaches, with when each one fits, what it involves and the scope it commits you to. These are build types rather than client case studies — the figures below are scope, not results.
Browse and buy
One-tap reorder
BUILD TYPE
Cross-platform shopping app
React Native, one codebase, both app stores
WHEN IT FITS
Customers who buy monthly or more often, a meaningful share of revenue already on mobile, and an owned channel — email, SMS or packaging — capable of driving installs without paid spend.
TECHNOLOGY
React Native, your existing commerce backend via API, wallet checkout, push, universal links, crash and analytics SDKs
WHAT IT INVOLVES
Native navigation and gestures rather than a wrapped website, saved payment and one-tap reorder, live order tracking, and a push plan with a frequency ceiling agreed before launch.
TYPICAL SCOPE
1
Shared codebase
2
App stores
Monthly
Release cadence
Day 30
Retention reviewed
Installed from the browser
Works offline
BUILD TYPE
Progressive web app
Installable storefront, no app store in the loop
WHEN IT FITS
You want app-like behaviour — a home-screen icon, offline browsing, push — without two codebases, a review queue or a store commission. For most brands asking for an app, this is the honest answer.
TECHNOLOGY
React or Next.js, service worker, web app manifest, web push, your existing commerce backend and checkout
WHAT IT INVOLVES
One front end serving both the website and the installed experience, cached catalogue for offline browsing, an install prompt placed where intent is highest, and the same checkout the website already uses.
TYPICAL SCOPE
0
Store reviews to pass
1
Codebase, shared with web
Same day
Release, no queue
0%
Store commission
Order pad
Contract pricing
BUILD TYPE
Private platform app
Built for one store, distributed to nobody else
WHEN IT FITS
The platform cannot do something your business needs and the available public app does most of it badly — trade ordering, contract pricing, approval workflows, or an integration nobody has written.
TECHNOLOGY
A private Shopify, BigCommerce or WooCommerce app against the platform APIs, with its own admin surface and webhooks
WHAT IT INVOLVES
Built against documented platform APIs rather than patched into a theme, so it survives platform updates. Scoped narrowly on purpose: a private app that tries to do five things is five things to maintain.
TYPICAL SCOPE
Private
Distribution
1
Store it serves
API
Not theme code
Yours
Code and repository
- FAQs
eCommerce app development FAQs
Eight questions that come up before most app projects. More on our full FAQ page.
Do we actually need an app?
Probably not, and we would rather establish that before you spend anything. Apps earn their place when customers buy frequently and you have an owned channel capable of driving installs without paid spend. If purchases are occasional, or if the mobile site converts at half the desktop rate, the money goes further on fixing the mobile experience. We run that qualification first and we have talked brands out of app projects on the strength of it.
How long does eCommerce app development take?
A private platform app scoped to one job is the quickest. A progressive web app is next, because it shares a codebase with the website. A cross-platform shopping app with wallet checkout, push, deep links and analytics is the longest, and the store review queue adds time at the end that is outside anyone’s control. The variable that moves app timelines most is not development speed — it is how quickly product data, content and decisions come back from your side, which we scope explicitly at planning.
What does an eCommerce app cost?
It depends on which of the three build types fits and how much of the commerce layer already exists as a usable API. A private platform app is the smallest piece of work here; a progressive web app sits in the middle because it shares code with the website; a full cross-platform shopping app is several times either. We scope from requirements rather than quoting a package, and our pricing page explains the approach. Budget for the maintenance retainer as well as the build — an app without one stops working within about a year.
Native or cross-platform?
Cross-platform, unless there is a specific reason not to be. One React Native codebase shipping to both stores halves the maintenance and keeps the two platforms from drifting apart, which they always do when they are separate projects. Go native when you need device capabilities React Native does not reach well, when performance in a specific interaction genuinely matters, or when you already employ native engineers. Two native codebases is a standing commitment most brands underestimate.
What about a progressive web app instead?
Seriously consider it. A progressive web app gives you a home-screen icon, offline browsing, push notifications and no store review queue, from one codebase shared with your website, and nothing sold through it carries a store commission. The trade-offs are real: push on iOS is more limited, you get no app store listing as a discovery channel, and some device features are out of reach. For most brands who ask us for an app, this is the honest recommendation.
Who owns the code and the store listings?
You do, throughout. The repository, the Apple and Google developer accounts, the signing keys and the store listings are all in your name from the first day rather than transferred at the end. We document the build and the release process, so if you take it in-house or move to another agency the app keeps shipping. There is no version of this where leaving us breaks your app, and we would not ask you to sign one.
How do we get people to install it?
Installs are a marketing problem, not a build problem, and it is the half that usually goes unfunded. The channels that work are the ones you already own: email and SMS to existing customers, a prompt on the mobile site at the point of highest intent, packaging inserts, and post-purchase order tracking as the reason to install. Paid install campaigns are expensive and the installs are rarely worth what they cost. We scope the install plan alongside the build, because an app nobody installs is the most expensive thing on this page.
Can you take over an app somebody else built?
Yes. The first step is an audit of the codebase and the analytics together, because the two questions are whether the app is technically salvageable and whether anybody is using it. Sometimes the honest answer is that a rebuild costs less than continuing to patch, and sometimes it is that the app should be retired and the budget moved to the mobile site. We will tell you which before you commit anything.
Find out whether an app is the right spend
Book a technical audit. We will review your purchase frequency, mobile revenue share, install channels and current mobile experience, and tell you whether an app is the right next investment or whether the same budget does more elsewhere — whether or not you hire us.