How the Moodle mobile app works with your own site
Learners expect to open their courses on a phone, but the official Moodle app does not host any content. It connects to the Moodle site your organization runs, so phone access depends on how that site is configured, which services the app can call, and how users sign in. Enabling the app is therefore a configuration and security decision for the learning team and the people who run the server, not only a download from the app stores. Treat it as a change to your platform that needs an owner, a test plan and a review before learners rely on it.
The app gives learners access to the courses they are enrolled in, course content, activities and their own grades and messages, and it can show notifications. Offline use is limited to what the Moodle documentation describes for your version, so confirm which activity types and content can be used without a connection before you promise offline access to learners or to course authors. Notifications also depend on site settings and on push delivery, which may involve a connection from your site to an external service. Ask for that data flow to be written down so your security reviewers can assess it.
A team needs this setup when a meaningful share of learners study on phones, when courses include activities that people complete on the move, or when staff need timely alerts about deadlines and messages. If most learning happens at desks through a browser, the app may add little, and the team should decide that on purpose. The team also needs to choose between the official app as published and a branded app built for the organization. A branded app is a separate build and release process with its own owner, so decide it before the rollout plan is written.
Mobile access widens the surface your site exposes, because the app relies on web services and token-based sessions. Before enabling it, inventory which web services and mobile services are switched on, which roles can use them, and whether any service accounts carry more rights than they need. Confirm that the site is served only over HTTPS with a valid certificate, that session lengths and any multi-factor or single sign-on flow work correctly in the app, and that the organization has a way to revoke tokens when a device is lost or an account leaves. Confirm the exact settings names and their effect against the documentation for your Moodle version.
Plan the rollout as a test project. Test the app on the iOS and Android versions your learners actually use, with accounts from each authentication method you run, and record which features behave differently on each. Expect one-time work for configuration, security review, test devices and the first rollout, and recurring work for app updates, site upgrades and regression testing after each Moodle release, which ships in April and October. When you request a quote, ask for the services and roles in scope, the platforms covered, who signs off the security review and how updates to the app and the site will be tested.
Mobile configuration options and when each fits
This table compares the mobile access decisions a Moodle team makes for its own site: the official app, mobile web services, offline access, push notifications, sign-in and a branded app. Read each row for when the option fits, what it depends on in your environment and what to confirm for your release. Check feature behavior in the release notes for your version before you commit to a design.
| Option | When it fits | What it depends on | What to confirm in release notes |
|---|---|---|---|
| Official Moodle app against your site | Most sites that want learners and staff on phones with the standard feature set. | A reachable HTTPS site, a supported Moodle version and site URL settings that match the app. | Supported app versions for your Moodle release and any site settings the notes require. |
| Mobile web services enabled | Any site the official or branded app will connect to. Enable and scope it deliberately. | Authentication method, the service account's permissions and which web service functions are exposed. | Which mobile service functions your version provides and how to configure them. |
| Offline access | Learners on unreliable connections, field staff or courses with large media. Test with your own content first. | Device storage, the activity types your courses use and how much data users may cache. | Which activities support offline use in your version and how cached content is protected. |
| Push notifications | Time-sensitive alerts such as deadlines or messages, where users accept app notifications. | Outbound connectivity to the push service used by your app build and the site's notification settings. | Push setup steps, whether messages pass through an external relay and what content leaves your network. |
| Sign-in through SSO or MFA | Sites where web sign-in runs through SSO or multi-factor authentication and mobile sign-in must follow the same path. | Identity provider support for the mobile login flow and session lengths on devices. | Authentication methods the app supports in your version and how SSO sign-in is handled. |
| Official app or branded app | Official app when standard branding is enough. Branded app when the app name, store listing and distribution must be yours. | Store accounts, signing keys, app review and who rebuilds the app at each Moodle release. | Build and distribution terms, license conditions for your app name and the rebuild steps for your target version. |
What the app needs from the site underneath
The Moodle mobile app does not talk to your site through a special channel. It calls the same web services layer that other API clients use, and it signs learners in through whichever authentication method your site has enabled. Before anything else, the team should confirm two things on the self-hosted site: that the mobile web services are turned on and exposed to the app, and that the login method learners actually use is one the app can complete. Both checks belong in the design phase, because a site that works well in a browser can still fail at sign-in on a phone. Moodle core ships several authentication plugins, including manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services. Each one changes what the app has to do at login. A manual account is the simplest path. LDAP and external database authentication check credentials against a directory or table outside Moodle, and OAuth 2 sends the learner through an identity provider. In each case, the team should list which plugins are enabled in Site administration, which one applies to which group of users, and what the app expects at the point where the learner is handed off. SAML 2.0 single sign-on adds another layer. The SAML2 Single sign on plugin (auth_saml2), maintained by Catalyst IT, creates Moodle accounts from the identity provider's assertion and uses field mapping configured in Moodle to fill in profile fields such as username, email and names. With SSO in place, the login path becomes a redirect to the identity provider, an assertion back to Moodle, and account matching or creation based on the mapped fields. If a mapped attribute is missing or differs in format, the learner may get an account that does not match an existing one, or no account at all. Check the plugin's listed Moodle version support against the release you run before you commit to it. The team must test this path on a phone, not only in a browser. Install the app against a test copy of the site, sign in with a representative set of accounts (new learners, returning learners, staff with elevated roles, and a user whose attributes are incomplete), and confirm that the redirect, the return to the app and the session all behave correctly on both iOS and Android. Browser tests do not exercise the app's embedded login behavior, so they can pass while the app fails. Record which identity provider versions, plugin versions and Moodle release you tested, because a change to any of them can break this path again.
Setup sequence for the mobile app on a self-hosted site
This sequence takes a self-hosted Moodle site from version checks to a documented mobile setup that learners can sign in to and use on their own devices. Each step ends with a check you can run, so the site owner knows when to move on.
Confirm the Moodle version and requirements
The platform team confirms the Moodle version the site will run and reads its release notes for the PHP, database and upgrade requirements. For Moodle 5.1, the notes call for 64-bit PHP 8.2 or later, and a supported database such as PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Sites upgrading to 5.1 must already run Moodle 4.2.3 or later. Check the running version under site administration, then compare the PHP version, database version and extensions on the servers against the notes. The step is complete when every requirement is marked as met in a written record, with any gap assigned to an owner.
Point the web server document root at public
On Moodle 5.1 or later, the web server must serve the new /public directory rather than the main Moodle folder. The server administrator updates the virtual host or equivalent configuration, reloads the web server, and confirms that the site loads from the new root. If the document root is wrong, the site may show directory listings or errors, so this change should be tested before the mobile app is connected. Check it by requesting the site's front page and a login page from outside the internal network, then confirming that no file listings appear and that core pages return normally.
Enable mobile web services and required functions
A Moodle administrator turns on web services and the mobile web service that the official app uses, then reviews which web service functions are available to it. Only the functions needed for the features the organization plans to offer should be added to the service. Each added function extends what the app token can do, so the list should be reviewed with the security team. Confirm the setup by checking that the mobile service is enabled and that a test user with a permitted role can see the features in a browser session. Record the function list and the role that owns the service in the configuration document.
Configure the login method learners will use
The administrator selects the authentication method learners will use with the app, such as manual accounts, email self-registration, or an external method. If the organization uses SAML 2.0 single sign-on, the team confirms that the SAML2 Single sign on plugin (auth_saml2), maintained by Catalyst IT, supports the target Moodle version. The plugin's listed support covers Moodle 2.7 through 5.1, so newer versions need separate confirmation. Test sign-in in a browser first, then confirm that the app's sign-in flow reaches the same account. The step is complete when a test user signs in through the chosen method and the user record matches the field mapping.
Test on real devices with a test account
The QA lead runs the app on physical iOS and Android devices with a dedicated test account enrolled in representative courses. Testers cover sign-in, course navigation, activity submission, file upload, and notifications, using both the network the site is reached through and a mobile network. Results are logged per device and per app version, including any login redirect, certificate warning or missing activity type. The step is complete when the test script passes on the agreed device list, and every failure has a ticket or an accepted-risk note. Do not reuse production accounts for these tests.
Set offline and notification options, then document
The site owner decides which content learners can download for offline use and which notifications the app should send, then sets those options in Moodle. Offline access and push notifications each depend on the server settings and on the app's own configuration, so both should be confirmed in a test run with a device set to offline mode. The team then writes a configuration record covering the Moodle version, document root, enabled services and functions, login method, test results and offline and notification choices. The step is complete when the record is signed off by the platform owner and the security reviewer.
Security settings to review before learners install the app
Each setting below changes what the app can reach, how long a login stays valid and what leaves your network. Review them with your security team before learners receive the app, and confirm exact option names and defaults in the documentation for your Moodle version, since these settings change between releases.
Which web service functions are exposed
Check which web service functions the mobile service makes available to the app. Each function is an API call that a logged-in user can make, so a broad list widens what a stolen token can read or change. Ask whether the set matches the features learners actually use, and confirm in your version's documentation how the mobile service is defined and which functions it includes by default.
Token lifetime and lost device sessions
Ask how long a mobile token stays valid and how a session ends when a learner reports a lost or replaced phone. A long lifetime keeps a copied token usable for longer, while a short one forces frequent re-authentication. Confirm whether a password change or an administrator action invalidates existing app sessions, and whether your identity provider's sign-out reaches the app.
Offline content and device scope
Decide whether learners can download course content for offline use and, if so, on which devices. Downloaded files and cached data stay on the phone after a course ends or an account is suspended, so the questions are what is stored, how long it stays and whether it can be cleared remotely. Confirm which offline and cache options your version provides and whether site policy can restrict them.
Push notification content and relay
Review what a push notification shows on the lock screen and which external service carries it. Notifications about messages or grades can reveal course names or personal details to anyone who sees the phone, so decide how much wording to include. Confirm with the documentation which relay the official app uses, what data it receives, and whether your privacy notice and data transfer records need to name it.
TLS on every endpoint
Confirm that every address the app contacts uses HTTPS with a valid certificate chain, including the Moodle site, any file or media hosts and any SSO endpoints the login flow passes through. Check that redirects never fall back to plain HTTP and that each certificate covers the exact hostname learners use. Test with the certificate and TLS configuration used in production, not a staging host.
Service account access
List the accounts that the mobile service and any integrations use, and what each account can do. Service accounts with broad roles create a path around normal learner controls, so give each one the narrowest role that works, keep its credentials out of shared documents and exclude it from interactive login where your identity setup allows. Confirm how your version assigns capabilities to the mobile service role.
When a branded app is worth its own build
The first decision is whether learners use the official Moodle app connected to your site, or an app that you build, brand and publish under your organization's name. The official app connects to your site through the mobile services you enable, and learners enter your site address inside it. A branded build adds your identity: app name, icon, splash screen, colors, store listing and a navigation structure you can shape around your course catalog and your learner groups. Organizations usually choose a branded build when learners are expected to find the app in a store under the institution's name, or when the default navigation does not match how their courses are organized.
A branded build also adds work that the official app spares you. Your organization needs its own developer accounts with the Apple and Google app stores, and it must manage signing certificates and keys for every release. A lapsed account or a lost signing key can block updates for every learner until it is resolved. Each Moodle upgrade changes what the site offers, so your app build must be rebuilt and tested against it. Moodle ships major releases in April and October and minor point releases every two months, so the build calendar has to follow that cadence, with time set aside for store review.
Publishing a binary also makes you responsible for the code inside it. The Moodle app is open source under its own license, separate from the GPL-3.0 license that covers the Moodle site code, so you must confirm the app license terms for your situation before choosing this path. Confirm as well what the store policies require for publishing an app built from open-source code, and whether your use of the Moodle name in the app title, icon or listing is permitted. Once the terms are clear, plan for a review of the app source you build from, tracking of upstream changes, and a documented method for carrying your own changes forward.
Before committing, answer four questions in writing. Who will hold the store accounts and the signing keys, and who can approve a release? Does your audience need the institution's name on the app, or is the official app enough? How often will you rebuild after Moodle upgrades and app updates, and who tests each build on the devices your learners use? What happens to learners if a release is delayed? A quote from an implementation partner should separate the one-time setup of the build pipeline and store listings from the recurring work of reviewing upstream changes, rebuilding and submitting releases. Illustrative example: a single institution with an internal learner base may find the official app sufficient, while a provider that sells courses to the public may need the branded path.
Limits to confirm in your environment
Each item below is a check to run in your own environment before you commit to a rollout, because the app's behavior depends on your Moodle version, network, courses and devices. Use the Moodle release notes and the Moodle app documentation as the reference for each check, and record the answers with the owner who will run them.
Feature support by Moodle version
The Moodle app does not expose every feature of every Moodle version, so the first check is which capabilities your installed release makes available to the app. Start with the release notes for your version and the Moodle app documentation, then list the features your teachers and learners depend on, such as grading, messaging and calendar views. Record each one against your version so that gaps surface during planning and testing.
Push notification relay dependency
Push notifications to the app can depend on a relay service that sits between your Moodle site and the devices, and whether your deployment uses one changes what must be open and who operates it. Check the app documentation for how notifications are delivered, then confirm whether your site can reach that service from its network and whether any personal data passes through it. Ask the Moodle administrators to document the answer before notifications are enabled for learners.
Offline access by course format
Offline access depends on the course formats, activity types and quiz settings your courses use, and each combination can behave differently. Build a test course that covers every format in use, along with quizzes that use the question types and settings your assessors rely on. Check the app documentation for what downloads and syncs, then record which activities need a live connection and tell course designers before term starts.
Device and operating system support
The app publishes the mobile operating system versions it supports, and those minimums can change with each app release. Learners on older phones or tablets may be unable to install the current app, which raises the load on your help desk. Confirm the minimum versions in the app documentation and release notes, then compare them with the devices your learners actually use, including managed institutional devices.
Behavior during major upgrades
Major Moodle releases arrive every April and October, and each one can change the server setup and web services that the app calls. Moodle 5.1 moved the web server document root to the new public directory, and a site that still points at the main folder may show directory listings or errors. Test the app against a staging copy of each target release, review its release notes for changes, and plan the app version alongside the Moodle upgrade.
Questions buyers ask before hiring help with the Moodle app
How much effort does a Moodle mobile app setup take?
Effort depends mostly on four factors: your Moodle version, how learners sign in, how many course formats you use, and whether you publish a branded app. A standard setup on a current site with username and password sign-in mostly involves enabling mobile web services, checking which features the app exposes, and testing on a sample of devices. Each added factor adds configuration and testing. Single sign-on adds identity configuration and login tests. Custom course formats may not display as expected in the app, so each one needs a review. A branded build adds app store accounts, signing, design assets and a release process you maintain for every update. Ask any provider to split the estimate by these components so you can see which ones you can reduce.
How long does a Moodle app rollout take?
The timeline depends on scope, so no single duration applies to every site. A rollout with mobile services on an existing site, one login method and a short device test list is much smaller than a branded app with single sign-on, custom course formats and a staged learner pilot. Your change process also sets the pace: security review, internal approvals, app store review for a branded build, and scheduling the pilot around term dates. Ask for a plan broken into phases, with the dependencies for each phase and the items that sit with your team. Delays most often come from waiting on access, approvals or test learners rather than from the configuration itself.
What does a Moodle app project need from our team?
At minimum you need a Moodle site administrator who can change mobile and web service settings and review the results. A security reviewer should approve which web services and login methods are exposed before go-live. For single sign-on, an identity administrator must provide the identity provider settings, attribute mappings and test accounts. A branded build also needs someone who owns the app store developer accounts and can approve store listings. Course formats and content need a named owner who can check how courses look in the app. Finally, a test group of learners and instructors on the devices you support is needed to confirm offline access, notifications and navigation before a wider release.
Can our own staff set up the Moodle app without a partner?
Yes, many teams can enable mobile services and run a basic test themselves, because the core settings live in the Moodle administration area. The harder work tends to be in the parts that touch other systems or release processes: single sign-on with your identity provider, push notifications, a branded build with its own signing and store submissions, and testing across the device and operating system versions your learners use. Those tasks also recur, since each Moodle upgrade and each app release needs a fresh check. Assess your team's experience with identity protocols, mobile release tooling and Moodle upgrades. If gaps exist, a fixed-scope project can cover the build and hand over documented procedures your staff run afterwards.
Does our Moodle version change how the mobile app is set up?
Yes. The version determines the server requirements, the upgrade path and the features you can rely on. For example, Moodle 5.1 requires 64-bit PHP 8.2 or later and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later, according to the Moodle 5.1 release notes. From 5.1, the web server document root must point to the new public directory, or the site may show directory listings or errors. Moodle 5.3 raises the PHP minimum to 8.3 and requires sites to run Moodle 4.4 or later to upgrade. Confirm which Moodle app release supports your exact site version before you configure anything, and plan the server changes before the app work begins.
How does single sign-on work with the Moodle app?
The app signs learners in through the same authentication method your site uses, so the login choice affects both the web and mobile experience. Moodle core includes authentication plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services. For SAML 2.0, many sites use the SAML2 Single sign on plugin (auth_saml2) maintained by Catalyst IT, which lists support for Moodle 2.7 through 5.1 in the Moodle plugins directory. Check that the plugin version matches your Moodle version before you rely on it. Then test the browser-based sign-in flow inside the app on each platform you support, including session expiry, multi-factor prompts and account provisioning for new learners.
What should a written quote for the Moodle app include?
A useful quote states the scope in specific terms, so you can compare providers on the same basis. Ask for the Moodle version and server environment, the login methods, the number and type of course formats, the list of devices and operating system versions to be tested, and whether a branded build is included. Also ask what the provider needs from your team, which deliverables you will receive, how testing and acceptance work, and what support follows go-live. Separate one-time work from recurring items such as upgrades, app releases and plugin maintenance. Because DeployOpen works to fixed scope agreed in writing before work starts, a quote should map directly to those written scope items.
Which security settings should we review before enabling mobile services?
Start with the web services and functions that the app will call, and enable only those your learners need. Review who may use mobile services, how access tokens are issued and how long they remain valid, and whether all connections use HTTPS. Check that the login method for the app matches your standard policy, including multi-factor authentication and account lockout behavior. Confirm the server settings for the document root, file access and directory listings, especially after an upgrade to Moodle 5.1 or later. Record the configuration, confirm logging captures mobile access, and have a security reviewer sign off. Verify each setting against the Moodle documentation for your exact version, since defaults and option names change between releases.
How DeployOpen works on this
DeployOpen treats the Moodle mobile app as a project inside your own Moodle site, not a separate product. We start from your Moodle version, hosting, authentication and the mobile features your learners need, then write the scope before any configuration changes. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Confirm your current Moodle version and its security support end date before choosing mobile settings.
- Inventory the mobile features your courses need, such as offline access, notifications and file downloads.
- Record your authentication method, including any SAML 2.0 or LDAP sign-in the app must pass through.
- Agree in writing which mobile service settings, web server changes and test devices are in scope.
How we build
- Enable and configure the mobile web services and the features selected in the written scope.
- Check web server document root and PHP and database requirements against your target Moodle release.
- Test sign-in, course access, offline content and push notification paths on agreed iOS and Android devices.
- Review site security settings for mobile access, including token lifetime and exposed web services.
How we hand over
- Deliver a written configuration record listing enabled services, settings changed and accounts used.
- Document the mobile login flow, troubleshooting steps and known limits for your support staff.
- Provide a test checklist your administrators can repeat after each Moodle minor release.
- Walk your administrators through the settings and agree who owns each item after handover.
How we support
- Review mobile settings and test results whenever you move to a new Moodle minor release.
- Plan Moodle major upgrades so mobile configuration is retested against the new version.
- Available as a retainer for ongoing monitoring, fixes and retesting of the mobile path.
- Agree response expectations and service levels in writing before the retainer starts.
