Skip to content

Send push notifications from your App ​

What App push notifications are ​

A published App can send push notifications to its visitors — short messages that pop up on a visitor's device even when your App isn't open in a browser tab. Use them to bring people back: a "your order shipped" update, a daily reminder, a "someone replied to you" alert.

This is web push, so it works on the open web — no phone-app store step, and it is not native iOS-app push. Desktop browsers and Android browsers that support web push can be prompted straight from a tab; on an iPhone or iPad the visitor has to add your App to their home screen first, and the prompt only works from the installed copy. Two things always hold: a visitor sees a notification only after they opt in (grant your App permission), and your App has to be published, because notifications reach your published App's visitors.

In the App editor, push lives on the Equip tab, under Messages, as Push — beside Email, Texts and Slack, the other ways your App reaches people. It reads On or Off, and it is Metered.

Turn on the home-screen install first ​

Push rides on the same machinery as installing your App to a home screen, so it only sends once the home-screen install is on. That switch is what makes window.mfPush and ctx.push send anything, and it creates your App's list of subscribers.

In Equip › Messages, select the Settings icon on Push. The window shows its Status, and under Needs, whether Home screen is on. Its Settings button takes you to the one place the install is switched: the Live window on Publish, in the Manage tab. There, under Home screen, turn on Installable. On a published App the change is On Live at once.

Until it is on, window.mfPush.isSupported() answers false and your App offers no prompt.

Ask visitors to opt in ​

Nobody can be sent a notification until they choose to allow it. Your App's page code asks for permission with the built-in window.mfPush helper, which prompts the visitor's browser and registers their device if they accept:

js
// Page code in your App — for example, behind a "Turn on notifications" button
if (window.mfPush.isSupported()) {
  await window.mfPush.subscribe(); // resolves once this device is registered
}

subscribe() resolves once the visitor accepts and this device is registered, and rejects if they decline or their browser can't do push, so wrap it where you want to react to either. window.mfPush.unsubscribe() opts them back out, and isSupported() is what you gate your button on — it answers false both when the browser can't do push and when the home-screen install is off for your App.

Call subscribe() in response to something the visitor does — a tap on a Turn on notifications button — rather than the moment the page loads; browsers show the permission prompt far more reliably that way, and it's a better experience. If the visitor declines, they simply won't receive notifications; you can offer the button again later.

Only visitors who accept join your App's subscriber list, which MotherFluxer keeps for you — one list per environment, so your Draft and your Live App each have their own. A device that opted in on the Draft is not on your Live App's list.

Send a notification from an action ​

Your App sends notifications from its actions — the server code in Equip › Automations — using the built-in ctx.push helper. Sending happens on the server, so you decide when a message goes out: after an order is placed, on a schedule, when new content lands.

js
// Inside one of your App's actions
const { sent } = await ctx.push.send({
  title: 'Your order shipped',
  body: 'Track it in the app.',
  url: '/orders', // opened when the visitor taps the notification
  userIds: [visitorId], // omit this line to notify everyone who opted in
});

Leave userIds out to send to every opted-in visitor, or pass a list of signed-in user ids to target specific people. It answers with how many were sent. Anyone who hasn't opted in, or who turned notifications off, is simply skipped, and a device that no longer accepts notifications is dropped from the list. You never handle device or subscription details in your code; MotherFluxer keeps the list of who opted in, on which device, and ctx.push sends to it.

See what was sent ​

Every notification your App sends is listed in Sent in Equip › Messages, beside the emails. A push row reads Push in the Type column, and says how many of the subscribers it was meant for it was delivered to, with which App sent it — Draft or Live — and When.

The "Notify your users" starter recipe ​

You don't have to wire this up from scratch. When you're building your App, ask the building assistant to notify your users. It drops in a ready-made pattern: a control that prompts visitors to opt in with window.mfPush, plus an action that sends them a message with ctx.push. It's a working starting point you then shape to your App — change the button wording, the message, and when the notification fires. Reach for it first rather than assembling the pieces by hand.

Test it, then publish ​

The running app beside the editor is your real Draft, so the opt-in prompt works there — a device that accepts joins the Draft's list, and an action tested on the Draft sends to it. To reach your real visitors, publish, then test the opt-in on your live address.

So the order is: turn on Installable under Home screen, add your opt-in prompt and your sending code (or the starter recipe), try it on your Draft, then publish so visitors can subscribe and start receiving messages.

Browser support caveats ​

Web push depends on the visitor's browser and operating system, and support isn't universal. It works on desktop browsers and on Android browsers that support web push, and on an iPhone or iPad only once the visitor has added your App to their home screen — in an ordinary Safari tab isSupported() answers false and no prompt appears. Some devices and browsers don't support it at all, and on those no notification will arrive. This is web push only — it does not reach a native iOS app.

Because of this, treat notifications as a helpful extra, not the only way your App tells a visitor something important. Anything a visitor must not miss should also be visible inside the App itself. When you call window.mfPush.subscribe(), handle a refusal so your App responds gracefully — showing your normal experience — when a device can't support push or the visitor declines.