Email:info@softosmith.com
Working Hours:Mon - Fri: 9 AM - 5 PM (PKT)
Offline access is one of the most misunderstood parts of Moodle Mobile — some things genuinely work without a connection, others only look like they do, and a few need custom development to work at all. Here's the real architecture underneath it.
A meaningful share of any Moodle Mobile user base isn't sitting on stable Wi-Fi. Offline behavior isn't a nice-to-have edge case — for a lot of learners, it's the difference between using the app at all and giving up on it.
Technicians, healthcare workers, and field staff completing compliance or safety training in warehouses, job sites, and facilities with poor signal.
Students and staff in areas with unreliable mobile data or expensive bandwidth, where downloading once and studying offline is the norm, not the exception.
Exam prep and certification learners reviewing downloaded material on a train, plane, or subway with no signal at all.
The Moodle Mobile app isn't a thin wrapper around a browser — it's a hybrid Ionic/Angular app with its own local data layer that mirrors what's on your Moodle site.
The Moodle Mobile app is an Ionic/Angular hybrid app packaged with Capacitor. It keeps a local SQLite database on-device for cached course structure, activity data, and user actions, plus filesystem storage for downloaded files.
Each activity type (page, resource, book, SCORM, forum, assignment) ships a prefetch handler that defines exactly what gets downloaded for offline use — files, structure, and the web service responses needed to render it without a connection.
Activities that accept offline actions — forums, assignments, quizzes — each register a sync provider. It queues actions taken offline and replays them against Moodle's web services once the device is back online.
Whether the app is online or replaying a queued action, every read and write still goes through Moodle's external functions and mobile web services — offline mode just delays when those calls fire.
Offline support in Moodle Mobile is activity-specific, not a single on/off switch for the whole app. Some content is viewable offline the moment it's downloaded; some interactions can be queued offline; and some things simply require a live connection.
Queuing an action offline is the easy half of the problem. The harder half is what happens when that queued action reaches the server and the world has moved on — that's where sync providers earn their keep.
A quiz attempt whose time limit or close date passed before the device reconnected — the app surfaces this as a sync error instead of silently submitting a late attempt.
A submission made offline and again from a browser before syncing — sync providers detect the mismatch and flag it for the user rather than picking one arbitrarily.
Failed sync items stay queued in the app with a visible error state, so students and staff can retry, discard, or get help instead of quietly losing work.
Stock Moodle Mobile only knows how to prefetch and sync the activity types Moodle HQ has already built handlers for. A custom activity plugin gets none of that offline behavior automatically — it has to be declared explicitly.
Adding offline capability to a custom Moodle activity for the mobile app generally involves:
We build against Moodle's actual mobile web services and external functions layer, not guesswork about how the app behaves offline.
Offline and sync behavior is tested against genuine connectivity loss, not just simulated network throttling in dev tools.
When a custom activity type needs offline support, we build the prefetch and sync handlers it's missing rather than bolting on a workaround.
Every recommendation here is grounded in real Moodle core and mobile app architecture, not marketing claims about what an app 'should' do.
Straight answers about how offline access and sync really behave.
Stock Moodle Mobile already supports offline viewing of downloaded courses and offline actions for several core activity types (assignments, forums, some quiz attempts, SCORM). Custom development is only needed when you want offline support for a custom activity type, or want to extend what a stock activity can do offline.
Only if the quiz has "Allow this quiz to be attempted offline using the mobile app" enabled in its settings, and the student downloaded the quiz before going offline. The attempt is stored locally and submitted once the device reconnects — quizzes without that setting still require a live connection.
The app's sync process flags it as a sync error rather than silently overwriting data — for example, a quiz attempt whose time limit expired before it synced, or a submission made both offline and via the web. The user sees the conflict and can retry, discard, or resolve it manually depending on the activity.
Real-time or server-dependent features generally can't work offline — live chat, most forum discussion loading beyond what was pre-fetched, and any activity type without a registered prefetch or sync handler. Viewing already-downloaded pages, resources, and books works fine offline; starting new interactions with un-cached content does not.
You define the plugin's mobile behavior in db/mobile.php, including which external functions the app can call and which of those responses should be cached via the offlinefunctions declaration. Prefetch and sync logic then follow the same pattern the app uses for core activities.
Yes — a branded app is still built on the same Moodle Mobile codebase and web services layer, so offline storage, prefetching, and sync behave identically. Branding changes the app's identity, not its underlying data architecture.
It depends entirely on what's downloaded — a text-heavy course with pages and forums might use a few megabytes, while a course with large SCORM packages or video files can run into hundreds of megabytes. Students can choose what to download rather than caching an entire course automatically.
Web services, push notifications, custom functions, and offline sync — the full Moodle Mobile picture.
How push notifications actually work in Moodle Mobile, from Airnotifier to FCM and APNs.
The full overview of our Moodle development services, pricing, and process.
Fully white-labeled Moodle Mobile app builds under your own name, icon, and store listing.
Tell us what your learners need to do offline and we'll tell you exactly what stock Moodle Mobile covers and what needs custom development.
Talk to a Moodle Mobile Developer
