PrestaShop Mobile App: 4 Options, Costs and a Test Plan

A PrestaShop mobile app for customers is an iOS and Android app under your shop's name that shoppers install to browse, reorder and pay. PrestaShop doesn't ship one, so you get it in one of four ways: a mobile app builder module, a website to app converter, a managed app service, or a custom build. The right choice depends mostly on your checkout, because a PrestaShop checkout is built from modules.

This guide helps you pick a route and prove it on your own shop before you spend money. For the short version, see the PrestaShop to app page.

Should a PrestaShop shop have an app at all?

An app earns its place when the same people buy from you repeatedly. Check your shop against four questions first.

• Do customers reorder? Wine, coffee, pet food, cosmetics, printer supplies, spare parts and trade consumables are bought on a cycle.
• Do customers sign in to do something? Trade accounts with group prices, order history, invoices, returns and loyalty vouchers bring people back to their account.
• Do you have news worth a notification? Sales, restocks and new ranges suit push.
• Is the mobile shop already good? If phone shoppers abandon your checkout today, an app built on that checkout inherits the problem.

If most orders come from first-time visitors, spend the effort on the mobile theme instead.

What makes PrestaShop different when you add an app?

PrestaShop is open source and usually self-hosted, and it is widely used in Europe and Latin America, where the way people pay and receive parcels changes from country to country. A typical shop is fitted to its country one module at a time: a payment module for the bank method customers trust, a carrier module with a pickup-point map, translations, tax rules, and customer groups with their own prices.

That makes the checkout the hard part. Products and categories are easy to copy into an app. A payment that redirects to a bank, asks for approval in a banking app and then returns to your order confirmation page is not.

Versions vary too. PrestaShop 1.7, 8 and 9 are all in use, and PrestaShop 9.1, released in March 2026, made Hummingbird the default theme for new installs while many shops stay on Classic or a customized theme. Any route that puts code inside your shop has to match your version and your modules.

So ask one question of every route: does the app show what my modules add, or only what core PrestaShop knows about?

What are the four ways to get a PrestaShop mobile app?

Route 1: A mobile app builder module

Several vendors sell mobile app builder modules on the PrestaShop Addons Marketplace and on their own sites. You install a connector module in your back office, it exposes your catalog, customers and orders to the vendor's app, and the app draws them as native screens. Some build on the PrestaShop webservice, a CRUD API over resources such as products, combinations, carts, customers and orders.

Good at: native product lists and pages, and a home screen laid out differently from your website.

Check carefully:

• Payment and carrier support. The API describes orders and carriers as data. It doesn't describe what a payment module or a pickup-point module renders in the checkout, so each one needs explicit support from the app vendor. Ask for the list of supported modules and compare it with yours. A common fallback for an unsupported one is your website checkout shown in a WebView.
• Version and licence. The connector is a module like any other, so confirm it supports your PrestaShop version and is still updated. Licences vary between a one-time price, a subscription and paid extras, so confirm you receive store-ready builds under your own developer accounts.
• Design. Your web theme customizations don't carry over. The app has its own look.

Route 2: A website to app converter

A converter builds a native shell around your live website. The shell supplies the app icon, launch screen, a native header, menus and bottom tabs, and optional push notifications. Your front office loads inside it in a WebView, the same browser engine that Safari and Chrome use.

Good at: fidelity. The app shows whatever your theme and modules render on a phone, because it's the same page from the same server. You install nothing in PrestaShop, so its version doesn't matter.

Check carefully: you don't get natively redrawn product screens. The app is as fast and as tidy as your mobile theme and no better. Payments that leave your shop can behave differently in an embedded browser than in Safari or Chrome, which is what the test plan below is for.

SiteTo.App takes this route. You paste your shop URL, set the name, icon and tabs, and preview the app on your own phone for free. A build costs $29 for Android, $79 for iOS or $99 for both, paid once.

Route 3: A managed app service

A managed service uses the same WebView approach for your pages and adds a team. They configure the app, build custom native screens, submit to the stores and maintain it for a monthly fee. Our SiteTo.App vs MobiLoud comparison looks at one such service in detail.

Route 4: A custom app

An agency or developer builds an app against your shop's APIs. This is the route for things a website can't do, such as working fully offline. It's priced as a project and needs rework when you upgrade PrestaShop or replace a module it depends on.

How do the routes compare?

What does each route cost?

• App builder module: set by the vendor. Check whether the listing price is a one-time licence or a subscription, and whether store-ready builds, push and updates for new PrestaShop versions are included or sold as extras.
• Website to app converter: a build fee. SiteTo.App charges $29 for Android, $79 for iOS or $99 for both, paid once, and later rebuilds are quoted separately.
• Managed service: a monthly fee for as long as the app is live. The comparison linked under Route 3 works through one service's current figures.
• Custom app: a project quote, then developer time whenever the shop changes underneath it.

Every route also needs Apple's developer membership ($99 a year) and Google Play's registration ($25 once), paid to them directly. The website app cost guide covers the full budget.

Which route fits which PrestaShop shop?

Choose an app builder module if your shop is close to stock PrestaShop, your payment and carrier modules are on the vendor's supported list, and a native browsing feel matters more to you than keeping your web design.

Choose a converter if your mobile shop already works well and a real part of it comes from modules. That covers local bank payments, pickup-point delivery, B2B group prices, several languages and a customized checkout.

Choose a managed service if you want a team to own the launch and upkeep, and the monthly fee makes sense against your app revenue.

Choose a custom build if the app has to do something a browser can't, such as working properly offline.

When is SiteTo.App the wrong choice?

• Your mobile theme is the problem. A slow theme or an awkward phone checkout will be just as slow and awkward in the app. Fix the shop first.
• You need lifecycle push. SiteTo.App sends a title, text, image and link to everyone who opted in, through your own Firebase project. It doesn't send abandoned-cart or order-status notifications, and it has no segments or scheduling yet. A multi-country shop can't send one message to French customers and another to Spanish ones.
• Your main payment method can't return to the app. If the test plan shows that your most-used bank method ends in the phone's browser and your payment provider has no fix, don't launch on it.
• You want someone else to submit and maintain the app. You publish from your own Apple and Google accounts, and a managed service is the better fit if you'd rather hand that over.

It also isn't a fit for Bluetooth, AR, heavy offline use or background processing.

How do you test a PrestaShop shop as an app?

Use a real iPhone and a real Android phone if you plan to ship both. Work through the steps in order. Run any failed step again in the phone's normal browser: if it fails there too, the fix belongs in the shop.

Step 1: Prepare the shop

Put each payment module in its test mode, or create a low-priced hidden product you can refund. Create a test customer account. Take the shop out of maintenance mode, because a preview of a closed shop shows only the maintenance page.

Step 2: Browse and build a cart

Open a category, use the filters and the search, then open a product with combinations. Choose a size or colour and add it to the cart. Watch the cart count in your theme header. Then apply a voucher in the cart.

Step 3: Check delivery and totals

Enter a real delivery address and compare carrier costs and tax with the same cart on your website.

If you use a pickup-point or locker carrier, open its map in the delivery step. Some of these widgets offer a "use my location" button. Don't depend on it. Type a postcode, choose a point, and confirm later that it appears on the order confirmation page and in the back office order.

Step 4: Pay with every payment module

This step decides whether you can launch.

• On-page card forms normally behave as they do on the mobile web. Use a test card that triggers 3-D Secure and confirm the challenge completes.
• Redirect methods send the customer to a bank page or a PayPal window. Follow the whole path and confirm you land on your order confirmation page inside the app.
• Banking-app methods such as iDEAL, Bancontact, BLIK, Bizum or MB WAY ask the customer to approve the payment in another app. The risk is the way back. A bank app may return the customer to the phone's default browser, where your shop has no session, while the app is left showing the payment step. The order may still be recorded through the provider's server notification, but the customer sees a confusing screen.
• Apple Pay and Google Pay buttons show only when the payment module's script decides the environment supports them, and an in-app WebView isn't the same environment as Safari or Chrome. Treat them as a bonus and keep card payment available beside them.

If you return from a payment to an empty cart or a login page, look at cookies first. PrestaShop stores the session in a cookie, and a return that arrives without it loses the session, so the cart can look empty. At least one payment provider documents this for PrestaShop and points to the Cookie SameSite setting under Advanced Parameters → Administration, with HTTPS enabled on the whole shop. Ask your own payment module's support which setting they require.

Afterwards, check that the order reached the back office with the right status.

Step 5: Test accounts and sessions

Sign in, open your order history, and use Reorder on a past order if your theme offers it. Then close the app completely and reopen it: you should still be signed in with the cart intact. PrestaShop's Administration settings set the front office cookie lifetime to 480 hours (20 days) by default.

The same page has an option called "Check the cookie's IP address", which compares the visitor's address with the one stored in the cookie. Phones change address as they move between Wi-Fi and mobile data, so review that option if testers get signed out for no clear reason.

If you use a social login module, try each button. Google blocks its sign-in screen in embedded WebViews, so a "Continue with Google" button may show an error there. Make sure email and password login is offered.

Step 6: Languages, currencies and B2B

PrestaShop puts the language in the address, such as /fr/ or /es/, so decide which language the app should open on. Then switch language and currency with your theme's selectors and check that prices and the cart follow.

For a trade shop, sign in with an account in a customer group that has its own prices. Compare a product price and a cart total with the same account on the website.

Step 7: Tidy the frame

Deal with the cookie banner and any newsletter pop-up, and check that your theme's sticky header doesn't double up with the native header and tabs. SiteTo.App can run scripts that hide your site's own header and pop-ups, so note what you'd like removed.

What should the results tell you?

What should you set up in the app itself?

• Bottom tabs: PrestaShop already has good destinations. Home, a top category or the Prices drop page, Cart, and My account work for most shops, and a trade shop can point a tab straight at order history. Turn on friendly URLs under Shop Parameters → Traffic & SEO first, and copy each address from your live shop.
• Cart badge: with a developer's help, the SiteTo.App JS SDK can show a count on the Cart tab. PrestaShop themes since 1.7 keep the current cart in a prestashop.cart JavaScript object and fire an updateCart event when it changes, which gives the developer the number to pass on.
• Push: connect your own Firebase project with the Firebase guide, then send a title, text, image and link from the dashboard.

Product, price and stock changes in the back office show up in the app without a new build. Changing the icon or app name needs a rebuild, and later rebuilds are quoted separately.

What do PrestaShop shops need to know before publishing?

You submit the app from your own Apple and Google accounts. SiteTo.App signs the iOS build and uploads it to TestFlight in your Apple account, so you don't need a Mac or Xcode, and gives you an AAB for Google Play. The create and publish guide walks through each step. Apple and Google decide what gets approved, and nobody can promise the outcome. These points come up for PrestaShop shops in particular.

Physical goods use your own checkout. Apple's App Review Guidelines say that goods and services consumed outside the app are paid for with methods other than in-app purchase (section 3.1.3(e)). That covers a shop that ships products.

Virtual products are different. Downloadable content used inside the app falls under Apple's in-app purchase rules in section 3.1, and Google Play has its own payments policy. Read both first if downloads are a real part of your sales.

Offer account deletion. Apple expects any app that supports account creation to let people start deleting their account from inside the app. PrestaShop's official GDPR module handles erasure requests that the merchant validates in the back office. Add a clearly labelled "Delete my account" link or request form to the account area.

Give reviewers a way in. If prices or the catalog sit behind a login, as in many B2B shops, supply a working test account in the review notes.

Show more than a website. Apple's Guideline 4.2 asks apps to offer more than a repackaged site. Native tabs, a native header and push notifications help. See the Guideline 4.2 guide and the publishing guide.

Common questions

Do I need to install a module or enable the webservice?

Not with a converter. SiteTo.App works from your public shop URL. App builder modules need a connector in your back office because they read your catalog directly.

Can one app cover a multistore?

One app starts on one URL. Shops in a multistore have their own addresses, so choose the shop the app should open. Separate brands usually deserve separate apps.

What happens to the app when I upgrade PrestaShop or change theme?

With a converter, the app shows the upgraded shop the next time it's opened, with no new build. If your page addresses change, the tab links in the app need updating to match. A module update that breaks your mobile checkout breaks it in the app too, so place a test order on a phone after significant upgrades.

Next step

Place a test order on your phone with your most-used payment method. If that goes well, preview your PrestaShop shop as an app for free, run the seven steps above, and check pricing once you know it works.

Running another platform too? See the guides for Magento and WooCommerce.