Services / Mobile / Website-to-app

Your website, on the home screen, without rebuilding it

If your site already does the job, you do not need a second version of it. We wrap what you have in a real app, add the things a browser cannot do (notifications, offline access, the camera, biometric sign-in) and get it onto both stores.

Start the conversation →See the technology

Why it matters

The cost is the wait

Plenty of businesses ask for an app and are quoted for a rebuild: the same catalogue, the same checkout, the same account pages, written a second time in a different language and then maintained forever alongside the original. Sometimes that is the right answer. Very often it is not, because the parts that make an app feel like an app (the icon, the notifications, the offline behaviour, the biometric sign-in, the payment sheet) are a thin layer, and the thing underneath already exists.

There are two honest routes. An installable web app puts your site on the home screen with no store involved at all: it updates the moment you publish, costs the least, and works on both platforms, but it depends on customers knowing to install it, and iPhone requires them to add it to the home screen before notifications work at all, which most people never do. A native shell gives you a real store listing, proper native notifications, offline caching and hardware access, at the price of store review and a second thing to release. We recommend one, explain why, and are happy to be argued out of it.

The line that decides the project is Apple's: a repackaged website with nothing added is rejected, and rightly so. So the work is not the wrapper. It is the native layer we add around your site, and the mobile problems on the site itself that a phone will punish. We audit both before quoting, and if we think your case does not clear that bar we will say so rather than take the money and lose you three months in review.

What you actually get

Built to be trusted

The wrapper is the easy part. These are the things that turn a website in a frame into something a store will accept and a customer will keep.

We audit the site before promising anything

How it performs on a mid-range phone on a slow connection, whether the sign-in survives inside an app, how the checkout behaves, whether touch targets and forms are usable one-handed. The audit produces a fix list and an honest verdict on whether wrapping is the right route at all.

A real app, not a browser bookmark

Native navigation, a proper splash screen, native transitions and gestures, and no browser chrome anywhere. Links to other sites open outside the app, deep links from an email or a message land on the right screen, and the back gesture does what each platform's users expect.

Notifications that actually arrive

Native push on both platforms, segmented by topic with per-topic opt-outs, deep-linked to the relevant page, and triggered from your existing systems (an order status change, a new article, a booking reminder) rather than from a separate marketing tool nobody has time to run.

It opens with no signal

Shell, assets and recently viewed pages cached on the device, so the app opens instantly and shows something useful rather than a dinosaur. Actions taken offline queue and replay when the connection returns, with clear feedback about what is waiting.

The native pieces your site cannot reach

Face ID or fingerprint unlock, Apple Pay and Google Pay in the checkout, camera and barcode scanning, the share sheet, wallet passes, home-screen badges, and the file picker, added around your existing pages rather than by rewriting them.

One place to update, most of the time

Content, prices and pages keep coming from your site, so a change is live in the app the moment you publish it, with no store release. Changes to the native shell itself still need a submission. We are explicit about which side of that line each change falls on.

Where it earns its keep

Same pattern, different desks

The candidates for this are businesses whose website already works well and whose customers already come back. The app is a shorter route in, not a new product.

01 · Publishers & membership media

A reading app without a second newsroom

The problem: Readers arrive from search and social, read one piece, and leave. Subscribers want an app; building a separate reading experience means a second content pipeline and a second set of bugs, which the newsroom will not staff.
What we build: An app around the existing site with articles cached for offline reading on a commute, breaking-news notifications by section rather than all-or-nothing, saved articles, and subscriber sign-in that persists so nobody meets a paywall they have already paid for.
What changes: Subscribers get the app they asked for, publishing stays a single workflow, and you gain a direct channel to your most loyal readers that does not depend on a platform's algorithm.

02 · Retail & e-commerce

Store presence without a second storefront

The problem: Your store runs well on the web and your team knows how to manage it. Rebuilding the whole catalogue and checkout natively means maintaining two storefronts, and every promotion becoming two jobs instead of one.
What we build: A shell around your existing store adding wallet payment, biometric sign-in, order-status and back-in-stock notifications, offline browsing of recently viewed products, and in-store barcode scanning, while catalogue, pricing and checkout stay exactly where your team already manages them.
What changes: A listing on both stores and a faster checkout for repeat buyers, without splitting your merchandising work in two or freezing your web roadmap while an app is built.

03 · SaaS & customer portals

The app your enterprise customers keep asking for

The problem: Your product is a web application that works well on a phone, but procurement conversations keep stalling on whether there is a mobile app, and customers want alerts on a lock screen rather than in an inbox.
What we build: A shell around the portal with company single sign-on carried through, biometric unlock, native notifications wired to the events that matter, offline access to recent records, and document capture from the camera, listed on both stores under your brand.
What changes: The checkbox is ticked with a defensible app rather than a token one, alerts reach people who do not live in email, and your product roadmap is not diverted into rebuilding what already works.

The technology

The tools behind it, named

Two routes, chosen against your site and your goals, and a set of native additions that are the same either way.

6 layers · 34 technologies

The site you already have

We work with whatever your site is built on. The wrap does not require you to change platform, and we will tell you plainly if yours is not a good candidate.

Next.js
WordPress
Shopify
WooCommerce
Sanity
Your own stack

Route one: the installable web app

No store, no review, and updates the moment you publish. The cheapest route, and genuinely enough for some businesses.

Progressive Web App
Workbox
Web Push
Lighthouse
Safari
Google Chrome

Route two: the native shell

A real store listing and real native capability around your existing pages, with native screens written where a web page cannot do the job.

Capacitor
Ionic
React Native
Expo
Swift
Kotlin

The native layer we add

The capabilities a browser tab cannot offer, and, not incidentally, the ones that make the submission defensible.

Firebase Cloud Messaging
Apple Push Notification service
OneSignal
Biometric sign-in
Camera & scanning
Universal & app links

Getting it onto the stores

Signing, build automation and submission on both platforms, including the appeal when a reviewer reads a rule differently than we do.

App Store
Google Play
fastlane
GitHub Actions
Xcode
TestFlight

Measuring whether it was worth it

Installs are the vanity number. What matters is whether app users come back more often and buy more than the same people did on the web.

PostHog
Mixpanel
Google Analytics
Sentry

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Typically four to eight weeks, most of which is the native layer and the mobile fixes on your site, not the wrapper.

An honest audit first

We run your site on real mid-range phones on a throttled connection, walk the sign-in and checkout, and check it against both stores' rules for what a wrapped site must add. You get a fix list, a verdict, and, where it applies, a recommendation not to do this.

We choose the route with you

Installable web app or native shell, decided against your customers, your notification plans and whether a store listing genuinely matters to your buyers. The trade-offs are written down, including the ones that argue against our recommendation.

We fix what phones punish

Slow first paint, layout shifting under a thumb, forms that fight the keyboard, sign-in that breaks inside an in-app browser, touch targets sized for a mouse. These fixes improve your website for everyone, which is a decent return before the app even exists.

We build the native layer

Notifications, offline caching, biometric unlock, wallet payment, camera, deep links, and native screens for anything the web layer cannot do well. This is the part that makes it an app rather than a frame, and it is where most of the effort goes.

Beta, then submission with the risk priced in

Your team and a pilot group test through TestFlight and Google Play's closed track. Then we submit, with the reviewer notes, demo account and justification prepared, and with at least one rejection round assumed in the plan rather than hoped away.

Two release lanes afterwards

Content and site changes go live immediately with no store involvement. Shell changes go through review on a planned cadence. We keep the boundary documented so your team always knows which lane a change is in before they promise a date.

Before you commit

The questions worth asking

Will Apple accept a wrapped website?

Not on its own. Apple's rules are explicit that an app which simply repackages a website, with nothing a browser could not already do, will be rejected, and Google has been tightening in the same direction. That is why the native layer is the project rather than an add-on: notifications, offline use, biometrics, camera, wallet, deep links. With those in place approval is the normal outcome, but it remains a reviewer's judgement, not a guarantee. We prepare the justification, and we handle the appeal if the first answer is no.

Would an installable web app be simpler?

Simpler, cheaper and instantly updatable, yes, and for some businesses it is the right call. The costs are real though: no store listing, so customers cannot find you by searching a store; installation depends on the customer following a prompt, which many will not; and on iPhone notifications only work after the site has been added to the home screen. If your customers expect to find you in a store, or notifications are central to the plan, the shell is worth its extra cost.

Do we now have two things to maintain?

Partly, and it is worth being clear about it. Content, catalogue, pricing and page changes stay in one place and appear in both. The native shell is a second, small codebase that needs occasional attention: an operating system release, a store policy change, an expiring certificate. It is far less than maintaining a second full application, but it is not nothing, and we quote a support arrangement for it rather than leaving it unowned.

Will it feel slow, like those apps that are obviously websites?

That reputation is deserved and it comes from wrapping a site that was already slow on a phone. The audit exists precisely to catch that. With caching of the shell and assets on the device, native navigation around the web content, and the performance fixes done first, the result is hard to distinguish from native for content and commerce. For heavy animation, complex gestures or real-time interfaces, it is not the right approach and we will say so.

Does having an app help our Google ranking?

No. Store listings and web search results are separate systems, and an app does nothing for your website's ranking. What it can do is give repeat customers a faster route back, and give you a channel that does not depend on someone else's algorithm. Anyone selling you an app as an SEO tactic is selling you something else.

How much cheaper is this than building natively?

Materially cheaper, because the expensive part (the catalogue, the checkout, the account system, the business logic) is not rewritten. But it is not free, and there is a point where it stops being the economical choice: heavy offline working, background location, complex hardware, or an interface that must feel unmistakably native will cost more in workarounds than building properly would have. We assess that at scoping and tell you which side of the line you are on.

Send us your site and we'll tell you if it's ready

Give us the URL. We will come back with how it behaves on a mid-range phone, what would have to be added to pass store review, and whether wrapping it is genuinely the right call for you.

Start the conversation →

Explore more

The rest of Mobile Apps

Customer apps Staff & field apps App Store launch ← All of Mobile