Email:info@softosmith.com
Working Hours:Mon - Fri: 9 AM - 5 PM (PKT)
Push notifications in Moodle Mobile aren't magic — they run through a specific chain: Moodle's messaging API, the Airnotifier message processor, and then Firebase or Apple's own push services. Here's how it fits together, and where a branded app changes the picture.
Push notifications look like a toggle, so most sites treat them like one — and end up with deadlines, messages, and announcements that silently never reach a phone, or a branded app that can't push at all because it's still pointed at infrastructure that isn't actually configured for it.
The message processor exists in core but was never actually enabled or connected properly for the site.
A custom-branded app still pointed at Moodle's shared Airnotifier instance, which can't deliver to an app with a different bundle ID.
Notification needs specific to the organization's workflow that core Moodle simply has no event or message provider for.
A push notification passes through four distinct layers before it reaches a device. Understanding each one is what makes troubleshooting — or customizing — the system possible.
Every notification starts as a message generated through Moodle's core messaging API — triggered by an event, routed to whichever message processors a user has enabled in their notification preferences.
Moodle core ships an Airnotifier message output plugin. When enabled, it forwards mobile-bound notifications to an Airnotifier server — Moodle's own hosted instance by default, or a self-hosted one for a branded app.
Airnotifier hands Android-bound pushes to Firebase Cloud Messaging, which delivers them to the device using the app's registered FCM project credentials.
For iOS, Airnotifier hands the payload to APNs, which delivers it to the device using the app's registered APNs key or certificate.
Every push starts as a message created through Moodle's messaging API by a specific event, then routed through whichever message processors — mobile included — a user has enabled for that notification type.
Discussion and reply notifications, controlled per-forum by subscription settings and per-user by notification preferences.
Upcoming and overdue assignment reminders, generated by scheduled tasks that check due dates against submission status.
Direct messages between users, delivered as push notifications when the recipient isn't actively in the conversation.
Course and site calendar events with reminders configured, surfaced to enrolled users ahead of the event.
Notifications when an assignment, quiz, or other graded activity receives a grade or feedback comment.
Any plugin that defines its own message provider and fires it through an event observer can generate push notifications the same way core does.
This distinction is the single biggest source of push notification confusion, and it's the line between "it just works" and "it needs custom setup."
Beyond just getting push to deliver, most organizations building a branded app also want notifications tailored to their own workflow — not just what stock Moodle triggers.
We work directly with Moodle's messaging API, message providers, and event observers — not a bolted-on notification service.
For branded apps, we deploy and configure your own Airnotifier instance against your Firebase and Apple Developer credentials.
Push notifications are verified against actual iOS and Android devices before launch, not assumed to work from a config screen.
Every setup here reflects real Moodle messaging architecture, not guesses about how notifications 'should' behave.
Straight answers about how push notifications actually work, and why they sometimes don't.
Mostly yes. Moodle core ships the Airnotifier message processor pre-configured to use Moodle's own hosted Airnotifier service, so once it's enabled and users opt in via their notification preferences, core triggers like forum posts and messages will push to the stock Moodle Mobile app.
A branded app has its own app ID, its own Firebase Cloud Messaging project, and its own Apple Push Notification service credentials — none of which match Moodle's shared hosted Airnotifier instance. A branded app needs its own self-hosted Airnotifier server configured with those credentials.
Airnotifier is the open-source push gateway Moodle HQ built specifically for this. It sits between Moodle's messaging API and the platform-level push services — it doesn't deliver the push itself, it hands the payload to Firebase Cloud Messaging or Apple Push Notification service, which handle actual device delivery.
Yes. You define a message provider for your plugin, fire it through an event observer at the moment that matters (a custom submission, an approval, a status change), and it flows through the same messaging API and Airnotifier path as core notifications — no separate push infrastructure needed.
To a degree. Airnotifier supports customizing notification content per message, and platform-level branding (app icon, name) comes from the app build itself. Deeper customization of notification behavior on iOS/Android is bounded by what FCM and APNs support.
They need the app installed with notification permissions granted on their device, and the relevant notification type enabled in their Moodle notification preferences — mobile push can be turned off per notification type, per user.
It's a defined, documented process — deploying the Airnotifier server, registering it with your Moodle site, and configuring it with your own FCM project and APNs key — but it does require your own Firebase and Apple Developer accounts and correctly matching credentials to your app's bundle ID.
Broader questions about mobile alerts, third-party notification tools, and push messaging in e-learning environments — answered specifically for how Moodle's messaging architecture actually works.
In Moodle, that integration point already exists — it's the Airnotifier message processor. Airnotifier sits between Moodle's messaging API and the platform push services (Firebase Cloud Messaging for Android, Apple Push Notification service for iOS), so 'integrating a third-party service' in Moodle terms means enabling Airnotifier and registering your app's FCM and APNs credentials against it, either on Moodle's hosted instance or a self-hosted one for a branded app.
For Moodle: enable the Airnotifier plugin under Site administration > Plugins > Message outputs, allow it as an output for the notifications you want pushed, and confirm users have mobile notifications turned on in their preferences. If you're running a branded app rather than stock Moodle Mobile, you'll also need a self-hosted Airnotifier server configured with your own Firebase and Apple Developer credentials, since the shared hosted instance only recognizes Moodle's own app bundle IDs.
For Moodle specifically, the natively compatible path is Airnotifier → Firebase Cloud Messaging → Apple Push Notification service — that's what Moodle's messaging API is already wired to. Generic push providers like OneSignal or a direct Pusher integration aren't natively connected to Moodle's message provider system; using one instead of Airnotifier means building a custom message processor plugin to bridge Moodle's messaging API to that service.
Push reaches students where they already are, which email and in-app badges don't — deadline reminders, grading feedback, and forum replies get seen in minutes instead of at the next login. For course teams, that translates directly into fewer missed assignments, faster response to instructor announcements, and higher completion rates on time-sensitive activities.
Moodle HQ's Airnotifier documentation on moodle.org/docs covers the plugin's own setup, and this page walks through the full delivery chain — messaging API, Airnotifier, FCM, and APNs — along with what changes when you're running a self-hosted instance for a branded app rather than the stock configuration.
Airnotifier is Moodle's own push gateway — free, open-source, and already integrated with core's messaging API, but it only handles the transport layer (handing payloads to FCM/APNs), not delivery itself. Third-party platforms like OneSignal bundle their own dashboard, segmentation, and analytics on top of FCM/APNs, but connecting one to Moodle means writing a custom message processor since Moodle doesn't ship one for them out of the box — for most Moodle sites, Airnotifier is the lower-effort, better-supported choice.
For Moodle, Airnotifier is the standard tool — it's the message processor Moodle HQ built and maintains for exactly this. Firebase Cloud Messaging and Apple Push Notification service are the actual delivery services underneath it, handling final delivery to Android and iOS devices respectively; you don't interact with them directly unless you're self-hosting Airnotifier for a branded app.
See the 'What's Involved in Custom Push Notification Setup' section on this page for the concrete steps on Moodle — deploying and registering a self-hosted Airnotifier server, creating an FCM project, generating an APNs key, and wiring up any custom message providers your workflow needs. Moodle HQ's own Airnotifier documentation on moodle.org/docs covers the plugin configuration in more detail.
In Moodle, that server is Airnotifier. You deploy it (self-hosted for a branded app, or use Moodle's hosted default for a stock install), register it with your Moodle site, configure it with your Firebase Cloud Messaging project and Apple Push Notification service key, and then define message providers and event observers for whichever course activities — submissions, grading, custom workflows — should trigger a push.
The most common one on Moodle is a bundle ID mismatch — a branded app pointed at Moodle's shared Airnotifier instance simply can't receive push, because that instance is only registered against Moodle's own app IDs. Beyond that: APNs keys and certificates that expire and quietly break iOS delivery, over-notifying students until they disable push entirely, and course-specific triggers that need custom plugin development because core Moodle has no message provider for them.
Web services, push notifications, custom functions, and offline sync — the full Moodle Mobile picture.
How offline access and sync actually work under the hood in Moodle Mobile.
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 how your app is set up and we'll tell you exactly what's missing between Moodle and your users' phones.
Talk to a Moodle Mobile Developer
