Why run an Open edX mobile app for your own platform
This page covers how to build and distribute the Open edX mobile app for a platform you run yourself, using the official openedx-app-android code and the Tutor Android plugin. It is written for organizations that already operate their own Open edX site and want learners to reach courses from a branded app in addition to the browser. The supplied research describes the platform and Tutor, but not the mobile code itself, so you must confirm the repository location, plugin status and app store requirements directly with the maintainers and against your own environment before you plan the work.
The app is another client of the same learning management system, so learners sign in, see their enrolled courses and open course content from a phone. For the operator, that means the app depends on the same decisions as the web experience: how learners authenticate, which courses appear in the catalog, and how the brand is applied. Before scoping, decide whether one app will serve one brand or several sites, whether learners need content offline, and which features the app release you target actually supports. Put each of these questions to the maintainers in writing.
The app suits organizations with a learner base that already studies on mobile, a settled brand identity and course structure, and staff who can own a mobile build pipeline, signing keys and store accounts. If identity, course design or the platform itself are still changing, a web-first rollout is often easier to manage. Cost splits into one-time work (repository setup, branding, first store submission) and recurring work (dependency updates, store policy changes, testing against each new platform release). Ask any partner or internal team for a quote that separates these items and states who holds each account.
Start by fixing the platform version, because Open edX supports only its latest named release at a time, and Verawood is the current named release, published on 30 July 2026. The app build must match a platform release that is still supported, so check which app version targets which platform release before you commit to a date. Next, confirm with your own team who will approve store submissions and who will respond when a platform upgrade breaks the app. Those answers shape the rest of the plan more than any technical choice.
Choosing between a branded app build and the responsive web LMS
This table compares three ways to reach learners: the responsive web LMS alone, a branded build of the official Android app with the Tutor Android plugin, and a fuller custom app over your own API layer. Read each column for who owns the work, what identity and LMS support it needs, and which store and upkeep duties follow. The main takeaway is that the branded and custom options add store and maintenance work that the web LMS does not carry, so confirm the verification items in each column before you commit.
| Decision area | Responsive web LMS only | Branded app from openedx-app-android | Fuller custom app with own API layer |
|---|---|---|---|
| Who owns the build | Your team configures the LMS theme, site settings and content. No separate client codebase is created. | Your team or a partner forks the official Android code and builds it with the Tutor Android plugin. | Your team owns a separate client and an API layer that sits between the app and LMS services. |
| Identity and LMS needs | Learners sign in through the identity providers already configured on the LMS. | The app's sign-in flow must work with your identity provider and the LMS endpoints of the release you run. | Token issuance, scopes, session handling and endpoint ownership must be designed across gateway, identity provider and LMS. |
| Branding work | Theme, logos and site configuration in the LMS. Changes are reviewed in browsers only. | App name, icons, colors, launch screen and strings, set through the plugin configuration for each build. | Full design system, navigation, screens and accessibility testing, built from the start. |
| Store accounts and submission | No app store accounts are needed. | Your organization holds the developer accounts and signs each build. Confirm each store's current review rules. | The same store obligations apply, and the backend services the app calls must be available during store review. |
| Maintenance burden | Follows Tutor and LMS upgrades. Re-test the theme and key learner pages after each upgrade. | Each adopted LMS release may require rebasing the app on upstream changes and publishing a new build. | Your team maintains the client, the API layer and compatibility with each upstream LMS release. |
| Verify before choosing | Confirm the mobile browser experience for your learners, including behavior on slow connections. | Confirm the app version matches your release, check the plugin license terms and test sign-in end to end. | Confirm API contracts, endpoint owners, release cadence and the support model in writing. |
| Typical fit | Learners who use desktop or mobile browsers and have modest branding needs. | Organizations that want a branded app listing and can run regular store releases. | Products where the LMS is one service among several and a team will own the API. |
How the mobile app connects to your LMS and identity
The mobile app is a client of your Open edX LMS, so its behavior depends on which LMS endpoints it calls and how the LMS is configured. Open edX is built on Django and React and is delivered through Tutor, which runs the LMS and Studio as containers in infrastructure you control. Learners' course lists, enrollments, progress and course content reach the app through the LMS's APIs, not through a separate data store. Before you build anything, ask the app team to list every endpoint the app version calls, and check each one against the LMS release you run. Open edX supports only the latest named release, so the app version and the platform release should be planned and tested together.
The app does not decide how learners sign in. The LMS does, and the app has to work with whatever the LMS offers. Open edX third-party authentication supports OAuth2 providers, with Google, Facebook, LinkedIn and Azure Active Directory available by default, plus SAML 2.0, Shibboleth and LTI. Older provisional support exists for CAS and SSL client certificates. Your identity provider may use only one of these paths, so confirm which sign-in flow the app uses: a web view that opens the LMS login page, or a token exchange against an OAuth2 provider. The common failure is a provider that works in the browser but has no redirect or callback configuration for the app. Test each provider your learners use on a real device, including first login, password reset and session expiry.
Branding in the app is separate from the LMS theme, but the two must agree. The theme that Tutor applies to the LMS sets the look of the web experience, while the app's own settings control its name, colors, logos, API base URL and the site or organization it connects to. If the app points at a different domain from the one your LMS serves, learners see errors that look like sign-in failures. Keep these values in one configuration source that is version controlled, and treat any change to the domain, the theme or the Tutor configuration as a release event that needs a fresh test of login and course loading. Tutor's plugin system is the usual place to add these integrations, so decide early which settings belong in a plugin and which belong in the app build.
Plan the work around the points where the two systems meet. Confirm the endpoint list and sign-in flows for your app version and LMS release in writing before the build starts. Set up a test identity for each provider and each role that uses the app, including staff accounts that should not reach learner content. Decide who owns the app when the platform moves to a new named release. Verawood is the current named release, and the next releases, Willow and Xylon, are listed for December 2026 and June 2027. Each upgrade can change the APIs the app depends on, so ask the app team how they will confirm compatibility before the platform moves and who signs off the result.
Setup sequence for a branded Open edX mobile app
This sequence takes a self-hosted Open edX platform from a confirmed release to a branded Android app that signs in to your own LMS and is ready for store submission. Each step closes with a check you can observe, so problems surface on test devices before learners see the app. The order matters because the app code, the Tutor Android plugin and the platform release must agree.
Confirm the platform release and Tutor version
The platform team confirms which named Open edX release the LMS runs and which Tutor release deploys it. Open edX supports only its latest named release, and the current one is Verawood, published on 30 July 2026. If the LMS runs an older release, plan the upgrade before the app work starts, because the app must match the platform you run. Ask your Tutor provider or the Tutor maintainers to confirm which Tutor version deploys your release. Done when the release and Tutor versions are recorded in the project file and the LMS admin pages report the same versions.
Match the app code and plugin versions
Select the openedx-app-android code and the Tutor Android plugin version that are documented to work with the release confirmed in the first step. Do not assume the newest branch of either project matches your platform. Confirm the pairing in the project documentation and, where the documentation is unclear, with the plugin maintainers. Record the exact commit or tag for both components so any later build can be reproduced. Done when a clean checkout of the unmodified app builds without errors and points at a placeholder LMS address.
Stand up a test LMS and sign in
Deploy a non-production Open edX instance with Tutor in infrastructure you control, reachable over HTTPS from the test devices. Create test learner accounts and enable the sign-in method the app will use, such as the platform's standard login or an identity provider you have already configured. Enroll a test learner in at least one course with sample content so the course list has something to show. Done when a build pointed at the test LMS signs in on a test device and the course list loads from that LMS. Treat this check as the gate for every later step.
Configure app identifiers and branding
Set the application identifier, display name, package name, icons, splash screen, colors, legal links and support contact in the app configuration. Choose an identifier that is unique to your organization, because stores and devices use it to recognize the app and changing it later creates a new app. Replace every default visual asset and review all user-facing text against your brand guidelines. Point the LMS base URL at your test host. Done when the build installed on a test device shows your name, icon and sign-in screen, and its network traffic reaches only your LMS hosts.
Build and test on physical devices
Produce signed debug builds and install them on the physical Android devices and OS versions your learners are likely to use. Test sign-in, the course list, course content, video playback, sign-out and any offline behavior your deployment enables. Emulators help with early work but tend to miss camera, network and battery issues, so include real hardware in the test matrix. Log each defect against the app version and platform release recorded earlier. Done when the core learner flows pass on every device in the agreed matrix and no open defect blocks a release candidate.
Prepare store listings and release process
Prepare the Google Play listing, data safety and privacy declarations, content rating answers, screenshots and descriptions. Decide who holds the signing key and upload credentials, and confirm the developer account belongs to your organization. Write the release process: version numbering, a staged rollout plan, a rollback path and the named approver for each release. Confirm the privacy policy link on the listing points to a live page on your site. Done when a release candidate is uploaded to an internal test track and the approval steps have been rehearsed once end to end.
Branding, app identifiers and app store considerations
Branding for an Open edX mobile app touches more than a logo. Before any build is submitted, decide the app name, icon set, splash screen, primary and accent colors, the application identifier (the Android application ID and the iOS bundle identifier), and the store listing text. These values are set in the app's build configuration and in store consoles, so they are hard to change later without creating a new listing. The identifier in particular should be chosen once, kept unique to your organization, and recorded alongside the signing setup. Treat the branding inputs as part of the platform's configuration in your own repository, not as one-off design files that live in someone's inbox.
Store accounts are the first ownership question. Google Play and Apple's developer program each tie an app to an account, and the account holder controls publishing, review responses, and the ability to add or remove team members. Confirm inside your organization which legal entity holds each developer account, who holds the administrative role, and who is the named backup. Avoid registering accounts under a personal email address of an engineer or contractor. If DeployOpen builds the app for you, agree in writing who creates the accounts, who receives the credentials, and how access is removed at handover.
Signing key custody needs the same care. The Android upload or app signing key and the iOS distribution certificates and provisioning profiles determine whether you can ship updates at all. Losing a signing key or letting it sit on an unmanaged laptop is a serious operational risk. Decide where keys are generated and stored, who may use them in a build pipeline, how they are backed up, and what the recovery path is if a key is compromised or a team member leaves. Confirm these arrangements with your security and platform leads before the first release, and record them in your own documentation.
Before submission, prepare the material stores ask for. Most listings require a privacy policy hosted at a public address that matches what the app actually does, a content rating questionnaire, and data safety or privacy nutrition disclosures describing what data is collected, whether it is linked to the user, and whether it is shared. Those answers depend on how your platform handles accounts, analytics and notifications, so involve the people who run those services, not only the people who design the listing. Confirm the exact fields and any age or education-related declarations with each store's current console before filling them in.
Store policies change, sometimes between a build being approved internally and the day it is submitted. Requirements for privacy disclosures, account deletion, permissions, target API levels and content categories are updated by the stores on their own schedules. Check each store's current developer guidelines at the time of submission rather than relying on notes from an earlier release, and build that check into your release checklist. Ask your implementation partner to show which policy version each submission was prepared against, and keep that record with the release.
Security and operations for a self-hosted learner app
A self-hosted Open edX mobile app puts signing, configuration and learner data under your control, along with the risks that come with them. The cards below cover six decisions to make before the first release: who holds the keys, what ships inside the package, how traffic is protected, what stays on devices, how releases are reversed, and how failures are detected.
Signing key custody
Every Android release must be signed with a key, and whoever holds that key can publish builds that learners trust. Decide who generates the upload and signing keys, where they are stored (a hardware-backed key service or HSM is a common choice), and who may run the release build. Confirm what your app store account supports for key management, and document a tested recovery path for a lost or compromised key.
Secrets kept out of the package
An Android app package can be unpacked, so any API key, client secret or service credential compiled into it should be treated as public. Decide which values the app truly needs, and keep privileged credentials on the server side of the LMS and its identity provider. Where the app must carry an identifier, confirm it is safe to expose and can be rotated without a new store release. Check build logs and artifacts for leaked values.
Transport security to the LMS
Requests between the app and your LMS, including sign-in redirects and token exchanges, should run over TLS with certificates issued for your LMS domain. Decide whether the app refuses cleartext traffic, and whether to pin certificates, which adds work each time a certificate changes. Confirm that every endpoint your identity provider uses is reached over HTTPS. Test expired, self-signed and mismatched certificates against a staging build before release.
Learner data on devices
Session tokens, cached progress and downloaded course content can all sit on a learner's device, outside your infrastructure. Decide what the app caches, how long it keeps it, and whether sign-out clears it. Confirm that tokens use the platform's secure storage facilities and that offline content is removed when a learner loses access. Record these choices for your privacy team, since you do not manage the devices.
Update and rollback practice
Learners install mobile updates on their own schedule, so a faulty build can stay in use after you fix it. Decide which app versions your LMS will support after each upgrade, since Open edX supports only its latest named release. Tie every build to a tagged source revision that you can reproduce, and define how a bad release is halted or replaced. Test the upgrade from the previous app version before each rollout.
Crash and sign-in monitoring
Crashes and failed sign-ins are often the first sign of a broken release, and learners rarely report them. Decide which crash reporting tool collects app data, and whether you host it, since crash payloads can include device or user identifiers. On the LMS side, watch failed sign-ins from each configured provider, such as OAuth2, SAML or Shibboleth, and alert on sudden changes. Confirm log retention and who may read these records.
How Open edX release cadence affects your app
Open edX states that the latest named release is the only supported release, and that it cannot support more than one release at a time. For a mobile app, that means the app and the platform it connects to must be planned against a named release, not against a general version of Open edX. Verawood is the current named release, published on 30 July 2026. The next releases, Willow and Xylon, are listed for December 2026 and June 2027. Your planning should start from which release your platform runs today and when your next platform upgrade is expected to land.
Each platform upgrade can change what the app depends on. The mobile app talks to the LMS through its API, and the platform changes behind that API between releases. Verawood, for example, added a new Studio sidebar, a redesigned instructor dashboard, an AI Extensions Framework and new frontend plugin slots. Learner-facing changes, such as course navigation, authentication behavior or content delivery, are the ones that matter most to a mobile build. Before you schedule a platform upgrade, check whether the app's current release of openedx-app-android still matches the target release, and whether any API calls, sign-in flows or course views need changes.
Confirm compatibility with the app maintainers before any platform upgrade, not after it. Ask them which Open edX release each app version is built and tested against, whether they publish a compatibility matrix, and how long they keep a version working against the previous release. Ask whether they will publish fixes for a release that has already been superseded. The answers determine whether you can upgrade the platform first and rebuild the app afterwards, or whether the two changes must be coordinated in the same window.
Plan the app release calendar around the platform calendar. The Willow and Xylon dates are listed targets from the Open edX release notes, so confirm them against the official release notes when you plan. A practical sequence is to test the current app build against a staging copy of the platform on the next release, record any broken flows, and decide whether to ship an app update before or after the production upgrade. Mobile app store review and user update adoption add time that the platform team does not control, so the gap between a platform upgrade and an app release can be longer than the upgrade itself.
Assign ownership for the release check now. A named person on the platform team should own the compatibility record, and a named person on the app side should own the test plan. Agree on who signs off a platform upgrade that affects the app and what happens if the app build is not ready. Ask your implementation partner to include the compatibility check in the upgrade scope, and to state in writing what is tested, which devices and operating system versions are covered, and what remains your team's responsibility after handover.
Limits to confirm before you commit to a native app
A native app adds a second product to run next to your Open edX platform. Each item below is a question that can change scope, cost and ownership, and each names who can answer it so you can confirm it before you sign a fixed-scope agreement.
Feature coverage in the app code
Compare the courses you plan to run against what the openedx-app-android code and the Tutor Android plugin currently support, such as video, graded content, discussions, progress tracking and certificates. Ask the repository maintainers which features are complete, which are partial and which are on the roadmap. Anything missing becomes custom work in your scope, so record each gap as a line item before you decide.
iOS availability and build path
The supplied facts do not establish an iOS build path, so do not assume one exists. Ask the Open edX mobile maintainers and the Tutor project whether an iOS app is maintained, which codebase it uses, and what signing, review and distribution steps it requires. If no maintained path exists, plan the iOS work as a separate project with its own scope.
Offline learning behavior
Confirm which course content the app caches, how long it stays available without a connection and how progress syncs back to the LMS after reconnection. Learners in low-bandwidth regions depend on this, and it affects storage, data protection and testing effort. Ask the app maintainers for the documented offline behavior, then test it with your own course types on a real device.
Push notification support
Check whether the app supports push notifications, which push service it uses and what credentials your organization must hold to send them. Push delivery depends on platform accounts that you own, so ask your platform team who will manage those credentials and renewals. Also confirm how the notification settings from your platform map to what learners see in the app.
Supported platform releases
Open edX states that the latest named release is the only supported release, so your LMS version and the app version must be matched and kept in step. Ask the Open edX release maintainers and the Tutor project which app versions work with your current release and how long each pairing is expected to hold. Plan your platform upgrades and app upgrades together.
Long-term maintenance ownership
Decide who will update the app, respond to operating system changes, renew store accounts and fix defects after launch. Options include your own developers, a retained partner or a combination, and each has a different recurring cost. Ask the vendor or partner to state in writing which tasks they cover, the response expectations and what happens when the upstream code changes.
Branding and store review rules
Confirm which branding elements the app lets you change, such as names, icons, colors and splash screens, and whether store review policies require a specific privacy policy, login method or account deletion flow. Ask your legal and compliance team to review the policy text and the data the app collects. Store acceptance is not guaranteed by the code alone, so budget time for review rounds.
Questions buyers ask before building an Open edX app
Is a branded Open edX mobile app worth building compared with the responsive web LMS?
It depends on how your learners use the platform. A responsive web LMS already runs in a phone browser, needs no store listing and is updated with each platform deployment. A branded app adds a store presence, a second client to test and a separate release cycle. Before deciding, ask your learner and product owners three things: what share of learners study on phones, whether a presence in the app stores matters to your program, and which mobile tasks the web experience handles poorly. If the answers are unclear, measure mobile web usage for a term before committing. Confirm with the vendor which app features the release you plan to use supports, so you compare the app and the web LMS on the same features.
What drives the cost of an Open edX mobile app build?
Cost follows the work each decision adds, and it splits into build work and upkeep. The main drivers are branding scope (a logo and color change is small, while custom screens, navigation and onboarding are larger), number of platforms (each store and operating system adds build, signing and test work), sign-in complexity (username and password is simpler than SSO through SAML 2.0, Shibboleth or an OAuth2 provider, which needs your identity team and test accounts), and store management (accounts, listings, review responses and releases). Build work is mostly one-time. Store upkeep, dependency updates, device testing and platform upgrades recur. Ask every quote to price these items separately so you can see which ones your scope includes.
How long does it take to build and publish an Open edX app?
The duration depends on branding scope, the number of platforms, sign-in complexity, how quickly your team returns design assets and approvals, and how long store review takes, which neither party controls. No timeline is fixed until the scope is agreed in writing. Ask the vendor for a written schedule with milestones for design sign-off, a staging build on test devices, identity testing, store submission and release. Ask which dates depend on your team and which depend on external review. Also ask how the plan changes if your platform moves to a newer named release during the build, because Open edX supports only the latest named release at a time.
What does our team need to provide for an outside mobile app build?
Most of the inputs are accounts, assets and access that only your organization can supply. You need developer accounts for the Android and iOS stores registered in your organization's name, design assets (logo, colors, icons, store screenshots and listing copy), and test devices covering the operating system versions you plan to support. For sign-in, you need test accounts and an administrator for your identity provider, plus access to a staging LMS. You also need a named approver who can sign off designs and releases quickly. Ask the vendor to list these inputs in the written scope, with an owner and a due point for each. Ask who holds the store accounts, signing keys and build credentials at handover.
Can our own engineers build an Open edX app without an outside partner?
Possibly, if you have mobile development skills in-house and the capacity to keep the app current. The app code is published as open source in the official openedx-app-android repository, and the Tutor Android plugin connects it to a Tutor-run platform. Your team would still need to handle branding, sign-in configuration, store accounts, release signing, test devices and an ongoing upgrade path. Ask whether you have at least one engineer who can own the app after launch, not only the first build. If that person is not available for the long term, the upkeep is usually the harder part to staff than the initial build.
How does the Tutor Android plugin fit into the app build?
Tutor is the official Docker-based Open edX distribution, and its plugin and hooks system is licensed under Apache 2.0. The Android plugin is the Tutor-side piece that carries your platform's settings into the mobile app build. In practice, the build flow covers pointing the app at your LMS, applying branding inputs, building the app, signing it and distributing it through the stores. Treat the exact configuration keys, build commands and supported Tutor versions as details to confirm in the plugin's own documentation for your Tutor version. Ask your engineers to check that the plugin version matches the platform release before the first build.
What breaks when the Open edX platform or the mobile app is upgraded?
The main risk is a mismatch between the app and the platform release. Open edX states that the latest named release is the only supported release, and Verawood is the current named release, published on 30 July 2026. Willow and Xylon are listed for December 2026 and June 2027. Each platform upgrade can change the interfaces the app depends on, and each new mobile operating system release or store policy change can require app updates. Plan for regression testing on test devices, a staging LMS for each upgrade, and a store release for each app change. Ask for the upgrade approach in the written quote, including who runs the tests and who approves the release.
How DeployOpen scopes and supports an Open edX mobile app
DeployOpen treats an Open edX mobile app for your own platform as a fixed-scope piece of work, with deliverables agreed in writing before the build starts. The work begins from the official openedx-app-android code and the Tutor Android plugin, inside the cloud accounts and release systems you control.
How we scope
- The written scope names your Tutor deployment, target app identifiers and the platforms you plan to ship to.
- Branding decisions are listed up front: logos, colors, app name, splash content and which screens change.
- Fixed-scope agreements list deliverables, acceptance tests and the store accounts and credentials your team provides.
How we build
- Build from the official openedx-app-android code with the Tutor Android plugin, keeping upstream changes traceable.
- Apply branding through configuration and resources where possible, and record every change to app code.
- Test sign-in, enrollment, course navigation and content playback against your platform on test builds.
How we hand over
- Hand over signed build pipeline configuration, source repository access and step-by-step build documentation for your team.
- Document which values come from your Tutor configuration and which belong to your app store accounts.
- Record the store submission checklist, owner for each credential and the steps for rotating signing keys.
How we support
- Ongoing support can be a retainer covering rebuilds when your platform or the upstream app code changes.
- Review each new Open edX named release before rebuilding, because Open edX supports only the latest release.
- Confirm store review timelines and policy changes with the stores directly, as DeployOpen does not control them.
