Real alerts on a parent's or teacher's phone the moment something new is published — even when Notipa isn't open — instead of only finding out next time they check the app.
Planned Not yet started — this page describes the intended design and build plan.
Overview
Notipa is already a Progressive Web App — it can be installed to a
phone's home screen and works offline — but that's install and caching, not messaging. Today, nothing
pops up on a parent's or teacher's phone when a new announcement goes out; they only see it the next
time they happen to open the app. Push notifications close that gap: a service worker running in the
background can show a real notification the instant a teacher publishes something, whether or not
Notipa is open at the time.
This is a genuine build, not a quick add — it needs a place to store each device's push subscription, a
push-sending step wired into every publish/create action, and permission-prompt UI on the client. The two
major mobile platforms also behave quite differently, which shapes how the feature has to be scoped and
rolled out.
How it behaves per platform
Android (Chrome)
Full support. The existing service worker at /sw.js can register for push and show notifications even when the app isn't open, using the Push API and Notification API together. Works essentially like a native app — no install requirement beyond having the site open at least once.
iPhone (Safari)
Workable, but more limited, and only on iOS 16.4+. Web push only reaches an installed PWA — a Safari tab can't receive push, only the home-screen app icon can. The user also has to explicitly grant notification permission after installing. Below iOS 16.4, there's no web push at all.
How it will work
Install, then opt in. A user installs the PWA (already supported today), the app then asks for notification permission, and on approval the service worker subscribes to push and sends that subscription to the Django backend.
Server-side push on publish. When a teacher publishes an announcement, posts homework, sends a fee notice, or opens a permission slip, the server pushes to every subscribed guardian's (or teacher's) device, reusing the same publish/create code paths that already exist for in-app notifications.
Delivered even when closed. The service worker's push event handler shows the notification regardless of whether the app is currently open, tapping it opens straight to the relevant item.
Respects the platform gap. On iOS specifically, the UI needs to clearly explain that notifications require installing to the home screen first — Notipa can't push to an open Safari tab, so the app should guide iPhone users toward installing rather than silently failing to notify them.
Development plan
1Backend push infrastructure
Add a web-push library with VAPID key support to the Django backend, and generate/store the app's VAPID key pair as part of deployment configuration.
New PushSubscription model: FK to user, the subscription endpoint/keys returned by the browser, device/platform metadata, created-at.
Endpoint for the client to register (and unregister, e.g. on logout or permission revoke) a subscription.
2Service worker & client-side subscribe flow
Extend the existing /sw.js with a push event handler (show the notification) and a notificationclick handler (focus/open the app to the relevant item).
Permission-prompt UI: ask at a sensible moment (not immediately on first load), explain why, and handle "denied" gracefully rather than nagging repeatedly.
iOS-specific messaging: detect when a user is on Safari but hasn't installed the PWA yet, and prompt them to install first, since push isn't available otherwise.
3Wiring push into publish/create actions
Hook push-sending into the announcement publish step, homework post creation, fee notice creation, and permission slip creation — the same trigger points that already drive in-app read tracking.
Respect each user's existing notification preferences (and, once messaging or SMS fallback exist, keep push as one more channel in that same preference model rather than a separate on/off switch).
Batch sends efficiently for classes/schools with many subscribed guardians, since a single publish can fan out to dozens of devices at once.
4Testing & rollout
Manual testing across both platforms: Android Chrome with the app closed/backgrounded, and iOS Safari with the PWA installed on 16.4+ and on an older iOS version to confirm the graceful-unsupported path.
Automated tests for subscription lifecycle (subscribe, unsubscribe on logout, expired/invalid subscription cleanup when a push send fails).
Rollout behind a feature flag or gradual enablement, since this touches every publish path in the app and failure modes (a bad push call) shouldn't be able to block the underlying publish action itself.
Technical considerations
Push sends must never block or fail the underlying publish/create action — if the push step errors, the announcement still gets posted, and the push failure is logged separately.
VAPID keys are per-instance configuration (like the app's other environment-based settings), so each self-hosted school generates and keeps its own, with no shared push service in the middle.
Expired or invalid subscriptions (a user who uninstalled the PWA, or an OS-level permission revoke) need to be cleaned up automatically when a push send comes back rejected, so the subscription table doesn't accumulate dead entries.
The iOS 16.4+ / installed-app requirement means push adoption will lag on iPhone relative to Android — the UI needs to set that expectation clearly rather than imply push "just works" everywhere.