Overview

This document covers the progress of the original, approved Push Notifications in Mobile Apps proposal (Push Notifications in Mobile Apps ) and proposes to complete the original approved scope of work (Milestone 1: Push Notifications | M1: Discussions Notifications · Issue #455 · openedx/platform-roadmap ).

The previous work for notifications in the mobile apps was halted after some progress. The purpose of this document is to answer:

• what was the scope in the originally approved Milestone 1 (M1)

• what has been completed to this point

• what needs to be delivered to finish the approved M1 work

• what are the implementation details

Previous Work

The previous effort to introduce a mobile notifications inbox to the mobile app was proposed in May 2025. This proposal was approved through Milestone 1 (M1). Milestone 1 was scoped to include:

• Discussions-related notifications

• A learner facing notification inbox and inbox settings

This initial work was intended to be push-provider-agnostic. The target implementation used the edx-ACE channel to route notifications through configurable ACE push channels, with the current FCM-backed path available when Firebase configuration is present.

The approved plan, though it mentioned “push notifications” by name, did not include phone-tray push notifications, and was initially scoped to just a mobile inbox.

Completed to Date

The M1 scoped work was halted after some progress. To date, the following has been implemented:

• openedx-platform repo PR feat: send mobile push notifications by jawad-khan · Pull Request #36272 · openedx/openedx-platform . The merged platform PR established the mobile notification delivery foundation: Open edX can register mobile device tokens and route selected notification events through the platform notification system into the ACE push channel path.

• The provider path is FCM-backed: the mobile token registration endpoint supports FCM, and ACE push configuration can register Firebase-backed delivery when Firebase credentials are configured. Another push provider can be configured.

Merged iOS work includes:

• Push notification and deep-link abstraction support through PushNotificationsManager, provider/listener protocols, DeepLinkManager, and PushLink.

• Native deep-link and push-navigation flow, including discussion route support.

• Firebase Cloud Messaging integration, including FCM token handling, token sync to /api/mobile/v4/notifications/create-token/, push receipt handling, and notification tap routing.

• Analytics tracking for push notification permission status.

Merged Android work includes:

• Braze push capability using Firebase Cloud Messaging.

• External deep-link routing from push notifications to native app screens, including discussion route support.

• Firebase Cloud Messaging integration, including token refresh, token sync to /api/mobile/v4/notifications/create-token/, push receipt handling, and notification tap routing.

• Branch deep-link handling for Braze-originated push notifications.

• Note: there is a broader Android plugin architecture; however, the current push handling remains more hard-wired than the iOS provider/listener model.

Not Yet Completed

The following items from the originally approved M1 proposal have not yet been completed:

• Mobile inbox and notification settings UI

• Android: push provider/listener extensibility comparable to the iOS PushNotificationsManager provider/listener model.

Web Notifications: Current State

Since the M1 proposal, notifications have been introduced to the web. Web notification types currently include discussion, ORA/grading, and course updates.

Web seen/read semantics are implemented as below:

• Seen: if a user clicks the notification icon, notifications for the selected app/tab are considered seen. last_seen is updated, and the count and red circle on the notification icon are removed. Grouping is platform-owned and only groups into existing rows where last_seen is null; marking a row seen closes its grouping window.

• Read: if a user clicks a notification row, it is marked as read; last_read is updated for the notification and visually, the styling changes from ‘unread’ to ‘read’ styling. last_read is not strictly a click signal because it can also be set by mark-all-read behavior.

M1 Revised Scope

Proposed M1 Scope

As part of this work, we propose keeping the scope of the previously approved M1 with the addition of Course Update and ORA notifications as default enabled for the mobile apps. The remaining work includes:

• Introducing a mobile inbox UI

• Introducing a mobile notification settings UI accessible both through the mobile inbox and from the Profile>Settings page.

• Introducing a notification icon to the app level “Learn” page

• Android: Removing hard-coded Braze references and implementing a similar plugin architecture for custom notification providers as already exists in iOS

For the mobile inbox, we plan to have a single inbox where both discussion and course update notifications will exist in one view without tabs. This differs from the current web tray which has tabs for notification type (ie: Discussion, Updates, Grading).

Note: push notifications to the iOS or Android notification tray were not part of the original scope; M1 was focused on in-app inbox notifications. We are keeping phone-tray push notifications out of scope but plan to include push in the second milestone (defined below).

Open Questions & Recommendations

Before development begins, there are some open product questions that require confirmation:

Q1: Should we introduce a new setting type for the mobile inbox?

Currently the settings are web , email , push , email_cadence , and non_editable. push should affect the eventual settings for notifications get sent to the iOS / Android notification tray. Separate settings for push and mobile-inbox reflect differing interruption levels. In-app inbox notifications are lower interruption as they appear for learners while using the app. Push notifications are an interruptive channel that appear as soon as sent. Given this, we recommend combining the web and mobile tray notifications into a tray setting. (previous recommendation kept for the record: Given this, we recommend adding a mobile_inbox setting.)

Thoughts on a mobile_inbox setting vs combining into a tray setting:

• Option A: combined tray setting:

  • Pros: easy to understand, reduces # settings for learners to grok, easy to distinguish between inbox and push.

  • Cons: some notifications may not be actionable on mobile: two methods:

    • Make un-actionable notifications un-clickable. con: confusing interaction. OR

    • Hide un-actionable notifications on mobile. con: would we hide the corresponding setting in the tray for mobile? is that more confusing to see the same setting but they appear different on web vs mobile?

• Option B: add mobile_inbox setting group:

  • Pros: solves some of the complexity above. more control for users

  • Cons:

    • two settings for mobile is confusing!

    • For settings page on web: would we surface all setting groups? then it becomes very heavy: four columns, four toggles: web, email, push, mobile inbox.

Q2: Should mobile and web share notification read and seen state?

We recommend sharing row-level last_seen and last_read state for the same notification row across web and mobile. This means that if a learner marks a notification seen or read in the mobile inbox, that same notification row is also seen or read for web.

Implementation Plan

After the open questions are resolved, Schema plan to contribute this work in advance of the Willow release.

Future Milestones

Milestone 2: Push Notifications

In the previous proposal for mobile notifications (Push Notifications in Mobile Apps ) the M2 scope was around learner motivation. Before adding learner motivation notification types, we propose delivering OS-level push notification behavior as the next milestone.

Milestone 3: Additional Improvements

After delivery of push notifications, we plan to introduce additional improvements. Potential improvements include: tabbed navigation following the web-notification tray pattern, additional notification types, improved grouped row interactions.