When an institution decides to build a mobile app, the first question is rarely about the app itself. It's about where the content will come from. Course catalogs, announcements, faculty profiles, event listings, news — this content already lives in a content management system, and the app needs a reliable way to reach it. This is exactly where an API-first approach to Drupal comes in: instead of treating the mobile app as a separate project with its own content store, Drupal becomes the single backend that serves the website, the app, and any future channel through one consistent set of APIs.
This article explains how to build a mobile app on top of Drupal using an API-first architecture. We'll clear up the difference between "API-first" and "headless," look at why this model suits mobile so well, walk through the API and authentication layers, cover the mobile-specific concerns most guides skip, and set out a clear framework for deciding how far to decouple.
API-First vs Headless: Clearing Up the Confusion
These two terms are often used interchangeably, but they describe different things, and understanding the distinction shapes how you plan the project.
Headless describes an architecture: the front end (what the user sees) is separated from the back end (where the content lives), and the two communicate over an API. In a headless setup, Drupal stops rendering the pages itself and instead hands raw content to a separate front-end application.
API-first describes a design philosophy: the content is modeled and exposed as APIs from the very beginning, so it's ready to feed any number of channels at once — a website, an iOS app, an Android app, a smartwatch, a kiosk, a voice assistant. Headless is about separating one front end; API-first is about being ready for all of them. A mobile app is often the trigger for going API-first, but the real payoff is that the same backend can serve every channel the institution adds later, without rebuilding the content layer each time.
Drupal is well suited to both because its API capabilities are part of core rather than an add-on. Since Drupal 8, and matured through Drupal 9, 10, and 11, the platform ships with a web services layer that turns structured content into API responses with no custom code. That's the foundation everything else in this article builds on.
Why API-First Is the Right Foundation for a Mobile App
Choosing an API-first Drupal backend for a mobile app brings advantages that show up across the whole lifespan of the project, not just at launch.
- One content source, many channels: The same announcement, course, or profile is entered once in Drupal and delivered to the website, the mobile app, and any other channel simultaneously. Editors don't maintain content twice, and the app never falls out of sync with the site.
- Structured content, ready for any interface: Because Drupal stores content as structured data rather than rendered pages, that content maps cleanly onto a mobile interface. A course isn't a block of HTML — it's a set of fields (title, credits, instructor, schedule) the app can arrange however it needs.
- Independent front-end and back-end evolution: The app team can ship a new version without touching the backend, and the content team can restructure the backend without breaking the app, as long as the API contract holds. Upgrades on one side don't force a rebuild on the other.
- A future-proof investment: When the next channel appears — a new app, a campus display system, an integration with another platform — the content is already exposed and waiting. The institution builds a new front end, not a new backend.
- Enterprise-grade content management behind the app: The app inherits Drupal's editorial workflows, granular permissions, multilingual support, and media handling — capabilities that a purpose-built mobile backend would have to reinvent from scratch.
The API Layer: JSON:API, REST, and GraphQL
Drupal can expose content through three main specifications. They aren't competitors so much as different tools, and the right choice depends on the app's needs.
| Specification | What it is | Best fit |
|---|---|---|
| JSON:API | A standardized spec, enabled in Drupal core with zero configuration. Exposes every content entity as a well-structured endpoint automatically. | The default choice for most mobile apps — consistent, predictable, no setup. |
| REST (RESTful Web Services) | The classic approach, also in core. Endpoints are configured per resource with more manual control. | Simple integrations or when a specific custom endpoint shape is needed. |
| GraphQL | A query language (via a contributed module) that lets the client request exactly the fields it wants in a single call. | Complex apps that need to minimize requests and fetch precise data sets. |
For most mobile projects, JSON:API is the natural starting point. It's part of core, it requires no configuration to switch on, and it follows a strict specification, which means the mobile developer knows exactly what the responses will look like. Its structure also handles the relationships between content — a course and its instructor, an event and its venue — in a predictable way, which is a frequent need in institutional apps. GraphQL becomes attractive when an app screen needs to pull many different pieces of data at once and you want to avoid multiple round trips; the trade-off is added setup and complexity. As a general rule, start with JSON:API and move to GraphQL only when a concrete performance need justifies it.
Authentication: Why Mobile Apps Can't Rely on Cookies
Authentication is the first real technical hurdle in a decoupled mobile build, and it catches many teams off guard. A traditional Drupal site authenticates users with session cookies handled by the browser. A native mobile app has no browser and no cookie jar, so that mechanism simply doesn't apply. The app has to authenticate a different way.
The standard solution is token-based authentication. The user enters their credentials once; the app sends them to Drupal; Drupal verifies them and returns a token; and the app stores that token and attaches it to every subsequent request. Two approaches dominate:
- OAuth 2.0 (Simple OAuth module): The recommended approach for most decoupled apps. It issues access and refresh tokens, supports modern flows including PKCE for public clients like mobile apps, and integrates cleanly with central identity systems. This is the path most institutional builds take.
- JWT (JSON Web Token): A lightweight alternative where the token itself carries the user's identity. It's simple and stateless, and a good fit for straightforward apps without complex authorization needs.
For institutions that already run single sign-on, the OAuth layer can connect the app to the same central identity provider used everywhere else, so students and staff sign in to the app with the credentials they already have. Getting authentication right early matters — it's far harder to retrofit a secure token flow onto an app built around a simpler assumption than to design for it from the start.
The Mobile-Specific Layer: Offline, Push, and Media
Most guides on decoupled Drupal stop at the API and authentication. But a mobile app lives on a device with intermittent connectivity, limited bandwidth, and its own notification system, and these realities need planning that a website never demands.
- Offline access and caching: A mobile user expects the app to work on a train or in a lecture hall with poor signal. The app should cache content locally and sync with Drupal when a connection returns. The API layer supports this by serving cacheable, structured responses the app can store and refresh — but the caching and sync logic lives on the app side and has to be designed deliberately.
- Push notifications: Notifications are one of the main reasons institutions want a native app in the first place — a new grade, a schedule change, an emergency alert. Drupal acts as the trigger source: when content is published or an event fires, Drupal calls out to a push service (such as Firebase Cloud Messaging) that delivers the notification to devices. The content and the trigger live in Drupal; the delivery is handled by the platform's notification infrastructure.
- Media and image optimization: Mobile screens and mobile data plans make image handling critical. Drupal's media system and image styles can generate appropriately sized versions of each image, so the app requests a mobile-optimized rendition rather than downloading a full-resolution file meant for desktop. This directly affects load times and data usage.
- Progressive Web Apps as a middle path: Not every institution needs a full native app. A Progressive Web App (PWA) delivers much of the native experience — home-screen installation, offline support, push notifications — from a single web codebase, and Drupal supports this through a dedicated PWA module. For many campuses, a PWA is a lower-cost route to an app-like experience before committing to native development.
Decoupled, Progressively Decoupled, or Coupled?
Going fully decoupled is a real commitment, and it isn't automatically the right answer. Being honest about when not to decouple is as important as knowing when to. There are three broad models:
- Coupled (traditional Drupal): Drupal handles both content and presentation. This remains the right choice for a standard website with no separate app or front-end framework. If there's no mobile app and no second channel, decoupling adds cost without benefit.
- Progressively decoupled: Drupal renders most of the page but hands specific interactive components to a JavaScript framework. This keeps Drupal's editorial and layout tools intact while adding rich interactivity where it's needed — a useful middle ground for a website that wants some app-like behavior without a full rebuild.
- Fully decoupled: Drupal is purely a backend, and one or more independent front ends (a mobile app, a separate web app) consume its APIs. This is the model a native mobile app requires, and it's the right choice when you're genuinely serving multiple channels — but it means the front-end team takes on responsibilities Drupal used to handle, from routing to SEO to accessibility.
The deciding factor is how many front ends the content needs to serve. A single website is best kept coupled. A website plus a native mobile app points toward a decoupled or hybrid architecture. The mistake is decoupling for its own sake — a fully decoupled build for a project that only ever needed one website adds complexity and cost the institution will maintain for years. We looked at the broader platform trade-offs in our comparison of Drupal, WordPress, and Joomla.
Front-End Choices: React Native, Flutter, and Native
Because an API-first Drupal backend is front-end agnostic, it works with whatever mobile technology the team prefers. The API doesn't care what consumes it, which frees the decision to rest on the app's requirements and the team's skills.
- React Native: A popular cross-platform choice that builds iOS and Android apps from a single JavaScript codebase. It pairs naturally with Drupal's JSON:API, and there's a large ecosystem and talent pool behind it.
- Flutter: Google's cross-platform framework, using the Dart language, known for smooth performance and a consistent look across platforms. It consumes Drupal's APIs as readily as any other client.
- Native (Swift / Kotlin): Building separately for iOS (Swift) and Android (Kotlin) gives the deepest platform integration and best performance, at higher development cost. The Drupal backend serves all of them identically.
The key point is that this is a genuinely open choice. Because the backend exposes standard APIs, the institution isn't locked into any one front-end technology and can even change it later without touching the content layer.
Common Pitfalls in an API-First Mobile Build
- Decoupling when you didn't need to: The most common mistake. If there's no second channel, a coupled Drupal site is simpler, cheaper, and easier to maintain. Decouple because you have a mobile app, not because it sounds modern.
- Leaving authentication until late: Token-based auth shapes the whole app architecture. Design the OAuth or JWT flow at the start, not after the app is already built around session assumptions.
- Forgetting what the front end now owns: In a decoupled build, the front-end team inherits routing, SEO, accessibility, and metadata — things Drupal handled automatically before. These have to be planned for explicitly, or they simply won't happen.
- Ignoring the mobile-specific layer: Offline behavior, push, and image optimization aren't afterthoughts. An app that doesn't handle poor connectivity or serves desktop-sized images will feel broken regardless of how clean the API is.
- Over-fetching data: Requesting more than a screen needs wastes bandwidth and battery. Use JSON:API's field filtering, or GraphQL where it fits, to fetch only what's required.
- Treating the API as an afterthought: The whole point of API-first is to design the content model and its API deliberately, up front. Bolting an API onto a content structure that was never meant to be consumed externally leads to awkward, inefficient endpoints.
Done thoughtfully, an API-first Drupal backend gives an institution a single, well-structured content source that can power a website, a mobile app, and whatever comes next — without duplicating content or rebuilding the foundation each time. It's a natural fit for organizations that already rely on Drupal's structured content and want to extend it to new channels. To see the wider range of what the platform supports, our overview of what you can do with Drupal maps the surrounding scenarios, and the what is Drupal guide covers the fundamentals of its structured content model.
Frequently Asked Questions About Drupal and Mobile Apps
Is Drupal a good backend for a mobile app?
Yes, particularly when the app needs to share content with a website or other channels. Drupal's API-first capabilities are built into core, so it can serve structured content to iOS, Android, or any front end through standard APIs without custom infrastructure. It's an especially strong fit when the app benefits from enterprise-grade content management behind it — editorial workflows, granular permissions, multilingual content, and robust media handling. For a standalone app with no shared content and no content-management needs, a lighter backend may be enough; the case for Drupal grows with content complexity.
Do I need to know PHP to build a mobile app on Drupal?
Not for the app itself. In a decoupled architecture, the mobile app is built with mobile technologies — React Native, Flutter, Swift, or Kotlin — and communicates with Drupal purely through APIs. The mobile developers work in their own language and never touch PHP. PHP knowledge is only relevant on the Drupal side, for configuring the backend, modeling content, and customizing the API layer, which is typically handled by the Drupal team rather than the app team.
JSON:API or GraphQL for a mobile app?
Start with JSON:API. It's enabled in Drupal core with no configuration, follows a strict and predictable specification, and covers the needs of most mobile apps out of the box. GraphQL is worth considering when app screens need to fetch many different pieces of data in a single request and you want to minimize round trips — but it adds setup and complexity through a contributed module. The practical path is JSON:API by default, GraphQL when a concrete performance requirement justifies the extra effort.
Can one Drupal backend power both a website and a mobile app?
Yes, and that's one of the strongest reasons to choose an API-first approach. A single Drupal backend can serve the website and the mobile app at the same time, from the same content. An announcement or course entered once appears on both, always in sync, with no duplicated effort. This is exactly what "one content source, many channels" means in practice, and it's the core advantage of building API-first from the start.