Mobile app for PrestaShop: when it pays off and how it's done
A native app puts your store on the customer's home screen and lets you notify them, but it is not for every store. We look at when it pays off, how it connects to the PrestaShop catalogue and cart, what Apple and Google require and what maintenance it needs.
Turning a PrestaShop store into an app for iPhone and Android is possible without duplicating the catalogue: the app uses the store itself, with its products, prices, stock and orders, and adds what the website lacks, such as the icon on the phone, notifications and a presence on Google Play and the App Store. It pays off above all when your customers buy repeatedly; if almost all of them buy once, a good mobile website is usually enough.
Let us look at when it makes sense, how it is set up and what has to be maintained afterwards, because an app is not something you publish and forget.
What an app offers that the website does not
People visit the mobile website when they remember you. The app is on the home screen, one tap away, and lets you talk again to whoever has it installed. In practice, what makes the most difference is:
- Push notifications. The order status, the cart left half-finished or a campaign for a group of customers reach the phone without depending on email or its spam filter.
- Your brand in view. Your own icon, colours and splash screen. The customer does not search for you in a search engine: they open you.
- A session that lasts. The customer logs in once and the app remembers their account, so the next purchase takes fewer steps.
- Phone features. For example, scanning a product's barcode to go to its page, which is very useful for spare parts, consumables or stores with technical references.
- Links that open the app. A link to your store in an email or a message opens the app directly if the customer has it installed.
When it pays off and when it does not
| Situation | Native app |
|---|---|
| Repeat customers (food, consumables, spare parts, seasonal fashion) | Usually pays off: every notification is a visit you do not pay for in advertising |
| Selling to professionals who order often | Pays off: quick access, session kept open and repeat orders |
| Community or brand with loyal followers | Pays off if there is frequent content or news to announce |
| One-off or very infrequent purchases (a mattress, a boiler) | Rarely: hardly anyone installs an app to buy once |
| Small catalogue and little mobile traffic | Improve the mobile website first; an app does not fix a slow store |
Before deciding, look at your data: what percentage of orders come from customers who had already bought, and how much traffic comes from mobile. If both are high, an app has potential.
Native app or PWA
The cheaper alternative is a progressive web app (PWA): the website itself, installable on the home screen from the browser and with web notifications. We covered this in the article on installable stores and push notifications. The main differences:
- Presence in the app stores. A PWA does not appear on Google Play or the App Store; a native app does, and many customers search there.
- Notifications on iPhone. Web notifications on iOS come with more conditions than on Android, and the customer must have installed the website first. In a native app they are the usual ones.
- Cost and maintenance. A PWA is cheaper to launch and does not go through Apple and Google review. A native app requires developer accounts and updates whenever the app stores demand them.
For many stores, a PWA is a good first step. When repeat purchasing justifies being in the app stores, the native app is the next step up.
How it connects to PrestaShop
There are two approaches, and the difference matters a great deal in the long run:
- An app that rebuilds the store by reading the catalogue through an API and building its own screens. It gives a lot of visual control, but every module that adds something to the product page or the checkout has to be reprogrammed in the app, and every change in the store can throw it out of step.
- An app that uses the store itself inside a native structure (tab bar, notifications, scanner, links) and hides what is not needed on mobile, such as the website's header and footer. Catalogue, cart, prices, stock, orders, modules and gateways are the store's own: what you change in the back office appears on the website and in the app at the same time.
The second approach avoids maintaining two stores. What does need reviewing first is the checkout, the payment gateways (those that open the bank's or a wallet's page must return to the app properly) and the cache, which is where surprises usually appear.
Publishing on Google Play and the App Store
Publishing is not uploading a file. Each app store reviews what is published and has its own requirements:
- Developer accounts in your name. Apple charges an annual fee and Google a one-off payment. Having them in your name matters: the app is yours and does not depend on whoever developed it.
- Requirements that lead to rejection if missing. For example, that the customer can delete their account from within the app, that the privacy policy is linked and, if login with other accounts is offered, Sign in with Apple on iPhone.
- An app that offers more than the website. Apple in particular rejects apps that are just a website in a frame. Native features (notifications, scanner, its own navigation) are what make it acceptable.
- Review for every new version. Changing the name, icon or splash screen means publishing another version. What is managed from the store (products, prices, texts, campaigns) does not.
The maintenance you do not see
An app is not a one-off job. Android and iOS change every year, and Apple and Google require apps to adapt to their new versions; those that do not keep up can no longer be updated and end up removed. On top of that comes the store itself: every update of PrestaShop, the theme or a checkout module also has to be checked inside the app.
What is worth measuring
- Active installs, not total downloads.
- Orders placed from the app and their value, compared with those from the mobile website.
- Notification open rate and the orders that come in after each campaign.
- Notification opt-outs: if they rise, you are notifying too often or about things that are not of interest.
How we do it at Rekire
In the service to turn PrestaShop into an app we first review the store (theme, checkout, gateways and cache), install the module that enables app mode, notifications and links, generate the Android and iOS app with your icon, colours and tabs, and publish it on Google Play and the App Store with your developer account. It works with PrestaShop 1.7.8 to 9 and with any theme, and the app uses your catalogue, prices and orders, with no second site to maintain. On that page you will find the price of the setup and of the annual maintenance.
Frequently asked questions
Do I have to maintain two stores if I build an app?
No, if the app uses your PrestaShop. What you change in the back office appears on the website and in the app at the same time.
Can I have a PrestaShop app on iPhone?
Yes. It is published on the App Store with an Apple developer account in your name, meeting its review requirements.
Which is better, an app or a PWA?
A PWA is cheaper and works as a start; a native app gives you a presence in the app stores and more reliable notifications on iPhone. It depends on how often your customers buy again.
What happens to the app when I update PrestaShop?
It has to be checked, especially the checkout and payments. That is why app maintenance includes reviewing it after updating the store or the theme.