Drupal Mobile App: 4 Ways to Get One, Compared

A Drupal site can become a mobile app in four ways: make it installable as a progressive web app, load the live site inside a native shell with a website to app converter, build a separate decoupled app on JSON:API, or hire a managed service or agency to do one of those for you. The deciding question for most Drupal teams is whether the organization can afford to run a second front end next to the one it already governs.

This guide compares the four routes, including the cases where SiteTo.App is the wrong choice, then gives a phone test plan for single sign-on, private files and languages. For the short version, see the Drupal to app page.

Does your Drupal site need an app at all?

Drupal runs university and council websites, association and member portals, nonprofit resource libraries, intranets, news sites and Drupal Commerce stores. What these have in common is an audience that returns, often signed in, to do a specific job.

Ask three questions before comparing products:

1. What will someone do in the app every week? Check a timetable, read member news, book a facility, report a problem, renew something, reorder. If you cannot name the task, a good responsive theme is enough.
2. Does that task already work on a phone? If a member needs seven taps through a mega menu to reach their dashboard, an app built from the site inherits most of that journey. Fix it in the theme first.
3. Is the store listing itself worth something? Residents and students search the App Store and Google Play by name, and a home-screen icon is easier to return to than a bookmark.

An information-only site with no repeat task is a poor candidate. Apple can reject apps that add little beyond a website under Guideline 4.2.

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

Every route with its own store listing also needs developer accounts: the Apple Developer Program at $99 a year and Google Play at $25 once, paid to Apple and Google directly.

Route 1: a progressive web app

A PWA adds a web app manifest and a service worker to the site so that people can install it from the browser. The contributed Progressive Web App module handles the basics for Drupal. Since iOS 16.4, web apps added to the iPhone home screen can also receive web push.

There is no store review, and no store listing either. On an iPhone the user has to know to use Share, then Add to Home Screen. For a staff intranet that can be enough. Our comparison of PWA, native and WebView goes deeper.

Route 2: a website to app converter

With SiteTo.App the app is a native shell around your live website: your icon and launch screen, a native header with your logo, a side menu, bottom tabs, swipe-back, pull-to-refresh and optional push notifications through your own Firebase project. The pages inside are your Drupal pages, loaded in a WebView, which is the same browser engine as Safari or Chrome.

Drupal still renders every page and makes every access decision, and a node published at 9:00 is in the app at 9:00 with no new build. The limit follows from the same design: the app is only as good as your mobile theme. Our guide to converting a website to a mobile app covers the general process.

A Drupal team with mobile developers can build this kind of shell in-house with a framework such as Capacitor, in exchange for owning the build pipeline, signing certificates and yearly SDK updates.

Route 3: a decoupled app on JSON:API

JSON:API is part of Drupal core, the decoupled Drupal guide covers the wider approach, and contributed modules such as Simple OAuth handle authenticated requests. Developers write the app in Swift and Kotlin, or in React Native or Flutter, with Drupal as the content back end.

A decoupled app can do things a website cannot: store content for offline use, use Bluetooth or background location, and present screens designed for the phone. The price is a second front end. Each content type needs a screen, and roles and access rules have to be respected through the API. Webforms, translations, search and Commerce checkout are each a piece of work to build and then keep in step with the site.

Route 4: a managed service or agency

Managed services build and submit the app for you and charge a recurring fee for the team behind it. Some use the same WebView approach as a converter, and our comparison with MobiLoud shows what that fee buys. A Drupal agency can also deliver route 3 as a project. Either suits an organization where nobody can own store submission, or where procurement requires a contracted supplier.

Which route fits which Drupal site?

When is SiteTo.App the wrong choice for a Drupal site?

• Your SSO provider blocks embedded browsers and there is no other way to sign in. The app cannot get past the login screen. The test plan below finds this quickly.
• You need content offline. The app needs a connection to load your pages.
• You want push sent automatically when a node is published, or targeted by role or language. Notifications are sent by hand from the dashboard to everyone who opted in, with no segments or scheduling yet.
• You want screens that do not exist on the website. SiteTo.App adds native navigation around your pages and leaves their design alone.
• You need a supplier to submit the app and answer reviewers. You submit from your own Apple and Google accounts and read every reviewer message yourself.
• The site is still on Drupal 7 with a fixed-width theme. Drupal 7 reached end of life in January 2025. Migrate before you put the site in front of more people.

How do Drupal features behave inside a WebView app?

Most of a Drupal theme renders exactly as it does in a phone browser. These are the exceptions.

Single sign-on. Many Drupal sites authenticate through an identity provider using modules such as OpenID Connect, SAML Authentication or CAS. The user leaves your site, signs in elsewhere and is sent back, and whether that works inside an app depends on the provider. Google's OAuth policy does not allow its sign-in screen in embedded web views. An enterprise policy that requires a managed device or an approved browser can block a web view in the same way. The standard Drupal form at /user/login has no such dependency.

Session length. Drupal's default session cookie lasts about 23 days, but the default server-side settings can clear a session left unused for a little over two days, and public-sector and university sites may tighten session handling further. A short session is sound on a shared desktop. On a personal phone it means signing in again far more often than people expect from an app. The Persistent Login module adds an explicit "remember me" option if you want one.

Private files. Documents stored in Drupal's private file system are served through Drupal so that access can be checked for each request. If a PDF link is handed to another app or browser that does not hold the session cookie, Drupal sees an anonymous visitor and refuses.

Languages and domains. Drupal's Language module can pick a language from a URL prefix, a domain, the user's account or the browser. The app opens one start URL, and its tabs point to fixed paths. A site with /en and /fr prefixes needs a decision about which one the tabs use, and a visible language switcher for everyone else.

Forms. Plain Webform fields are no trouble. File and photo uploads, multi-step forms with saved drafts and CAPTCHA challenges are the ones to test.

Overlays and the admin toolbar. Consent banners, newsletter modals and sticky headers compete for the space where the app's native header and tabs sit. SiteTo.App can hide your site's own header and pop-ups with scripts that run inside the app, so the theme is untouched and cached pages are served as usual. Editors who sign in to the app will still see Drupal's admin toolbar.

Drupal Commerce. Commerce checkout with card fields on your own pages is the simple case. Gateways that redirect to a hosted payment page need a test order each.

Accessibility. Public bodies and universities usually have legal accessibility duties. The pages inside the app are the same HTML your theme produces, so work already done there carries over. The native header, menu and tabs are new interface, so include them when you test with VoiceOver and TalkBack.

How do you test a Drupal site as an app, step by step?

Use a real phone, the production site and test accounts for two or three roles. The preview is free and needs no card, so run the whole plan before paying for anything.

Step 1: Check the mobile theme

Open your five most visited pages in a phone browser. Look for sideways scrolling in tables and Views, a mega menu that covers the screen and a consent banner that cannot be dismissed. Fix what you find in the theme.

Step 2: Create the preview

Paste the public URL into SiteTo.App, using the language prefix or domain your mobile visitors should land on. Set the app name, icon and launch screen, then choose tabs for the tasks people repeat. A membership body might use Home, News, Events and My Account. Copy each link from the live site's path alias, then scan the code to open the app on your phone.

A staging site behind HTTP authentication or an IP allowlist cannot be loaded on a phone, so the plan uses production.

Step 3: Prove sign-in first

This test decides the project, so run it before anything else.

1. Sign in the way real users do. If that is SSO, complete the full round trip, including the MFA prompt.
2. Open a page that only your role can see.
3. Close the app completely and reopen it. Check again the next morning.
4. If your site uses Drupal passwords, request a reset. The one-time link in the email normally opens in the phone's browser, so confirm the new password then works in the app.
5. Sign out and confirm the restricted page is refused.

If SSO fails, ask your identity team whether a policy is blocking embedded browsers and whether a Drupal-password login can be offered alongside it. If neither is possible, stop here and look at another route.

Step 4: Open restricted content and private files

Signed in, open a role-restricted node and a private PDF. Check that the file displays and that you can get back to the page you came from. Repeat signed out and confirm Drupal refuses both.

Step 5: Work through Views, search and forms

Use an exposed filter or a facet on a long listing and page through the results. Run a site search. Then submit your busiest Webform from start to finish, including any upload field and CAPTCHA, and check that the confirmation message and notification email arrive.

Step 6: Switch language and look for overlaps

Change language with the site's switcher, then tap each tab and note any that sends you back to the default language. Then tap through as a member and as an editor, looking for a second header, a consent banner over the tabs or the admin toolbar pushing content down.

Step 7: Decide

Fix page problems in Drupal and navigation problems in the SiteTo.App settings. A failed sign-in with no fallback is a reason to choose a different route.

What does each route cost?

SiteTo.App charges once per platform: $29 for Android, $79 for iOS or $99 when you buy both together. There is no SiteTo.App subscription. Later rebuilds, for example to change the icon, are quoted separately. Publishing and editing content in Drupal never needs a rebuild. The pricing page has the details, and the cost guide compares the wider market.

A decoupled app is a development project followed by a maintenance commitment, because the app has to keep up with Drupal and with each year's iOS and Android releases. A managed service charges a recurring fee for as long as the app is live.

Apple's $99 a year and Google's $25 registration apply to any route with a store listing. Nonprofits, accredited educational institutions and government entities can ask Apple for a fee waiver if they distribute only free apps and meet Apple's other conditions.

How do you publish a Drupal-based app to the App Store and Google Play?

The create and publish guide walks through the full sequence. A few points matter more for Drupal sites than for most.

Use the organization's own developer accounts. Enroll in the institution's legal name so the listing shows the university, council or association as the publisher. Apple asks organizations for a D-U-N-S number and verification takes time, so start early.

Builds. The iOS build is signed and uploaded to TestFlight in your own Apple account, so nobody needs a Mac or Xcode (details here). Android arrives as an AAB for Google Play, or an APK. Repeat the test plan on the TestFlight build before you submit.

Give reviewers a way in. If the useful part of the app sits behind a login, create a demo account with a representative role and put its credentials in the review notes. An account that depends on your SSO and MFA will stop a reviewer at the first screen.

Plan around Drupal upgrades. Drupal 10 reaches end of life on 9 December 2026 according to the core release schedule. An upgrade to Drupal 11 that keeps the same domain and path aliases needs no new app build. If aliases change, add redirects or update the tab links.

Apple and Google make the approval decision, and nobody can promise the outcome. The publishing guide covers listings and review in more depth.

Frequently asked questions

Can I turn a Drupal website into a mobile app without a module?

Yes. A website to app converter such as SiteTo.App loads the pages your theme already renders, so there is no module to install and no API to expose. The optional JavaScript SDK for tab badges, the share sheet and haptics is a script you can attach through your theme's library.

Will our SSO work inside the app?

It depends on your identity provider. Drupal's own login form works as it does in a browser. SAML, OpenID Connect and CAS logins redirect to a provider that may restrict embedded browsers. Run a full sign-in, including MFA, in the free preview before you decide.

Does it work with Drupal 10, Drupal 11 and Drupal CMS?

Yes. SiteTo.App works from the public URL and does not depend on the Drupal version, so any public, mobile-friendly Drupal site can be previewed, including one with a decoupled front end.

Can Drupal trigger push notifications when content is published?

Not with SiteTo.App today. You send each notification from the dashboard with a title, text, optional image and a link, and it goes to everyone who opted in. If automatic or role-based notifications are essential, a decoupled build is the better fit.

Next step

Start with the sign-in test. Paste your Drupal URL into the free preview, open it on your phone and log in the way your users do. If that works, run the rest of the plan. The Drupal to app page has the short checklist to share with whoever needs to approve it.