I wanted to start a discussion around push notifications — specifically how others are handling them now that Glide’s native push feature has been deprecated.
From what I can tell, there isn’t an official replacement yet, but I’ve seen a few people mention possible workarounds using OneSignal or third-party tools like Make (Integromat).
I haven’t implemented anything myself yet, but I’d really like to explore what’s currently possible.
In theory, it seems like it might be achievable with:
A Make or webhook integration that sends events to OneSignal’s API
A way to store device tokens or player IDs for each user (though I’m not sure if that’s viable with PWAs right now)
Possibly email or in-app notifications as temporary alternatives
So before diving in, I wanted to ask:
Has anyone successfully set up OneSignal or a similar service for Glide apps?
How are you handling user registration and permissions for push notifications since the change?
Are there any confirmed working approaches or partial setups that others could learn from?
Right now, my app has zero push functionality, and I’m just trying to find a direction that could realistically work long-term.
If anyone has experience or insights to share — even if it’s just partial progress — it’d be great to collaborate on documenting a community workaround.
Thanks in advance to anyone who can shed light on this — it feels like a lot of us are in the same spot.
Thanks for sharing! I’ve actually seen that video — and working through that exact method is what prompted me to start this topic.
I’ve managed to get the base setup working, but I’m struggling to figure out how to send different push notifications for various events across the app — things like new messages, order updates, or community replies.
I understand the general flow using OneSignal, but I’m not sure how to structure the logic or payloads so each event triggers its own unique notification.
Any insight or examples on handling multiple notification types would be massively appreciated.
I am DESPERATE for push, I tried this video as well, and go everything set up as shown, but I could never get it to work reliably at all. I did request help from the video creator, but heard nothing, so I abandoned ship, but any ideas would be great.
Just a quick update — I’m currently testing a Glide → OneSignal → Make workflow to handle multiple different push notifications across various user actions. Still in early testing, but it’s looking promising so far.
I’ll share my findings (and setup steps if it works reliably) once I’ve got everything stable — hopefully this can help anyone else struggling with push setups too
Hey, thank you so much, my clients are absolutely desperate for some kind of notifications as most other app builders offer that feature, but I am Glide through and through because I think it’s the best so I’m stuck
Quick update now that we’ve got a working first-party push notification setup running with Glide.
What’s working well
Android & desktop: flawless — notifications appear instantly and behave like native ones.
Branding: fully ours — only the small Chrome logo remains; all other icons and badges are customised.
Stack: first-party service worker hosted on Netlify, connected to Make for event triggers and delivery.
iOS caveat
Users still need to add the Netlify web app to their Home Screen to enable notifications.
Once added, everything works perfectly — but it does mean iOS users effectively have two apps (the main app and the push-enabled one).
How we approached it (high level)
No OneSignal or third-party dashboards — everything runs through our own infrastructure.
Each event, key, and trigger is configured manually through Make, giving us full control and flexibility.
You can also build an admin dashboard to send system or group notifications.
Security & privacy
We’ve put a big focus on keeping the system safe and transparent:
All requests are handled through secure HTTPS endpoints hosted on Netlify.
User identifiers are tokenised — no personal data is ever stored in plain text.
Device registration keys are unique per user and used only for sending app notifications.
No data is shared externally — everything stays within the Glide, Make, and Netlify ecosystem.
The system can be expanded with authentication keys or access rules if needed for larger deployments.
Heads-up on Glide updates
During testing, this setup burned through a fair few Glide updates (lots of webhooks, writes, and recalcs).
Once the build is stable, I’ll monitor usage more closely and share some stats on what’s manageable.
For anyone testing, I’d suggest throttling Make polling and batching webhook actions during development.
Still building
Android and desktop are running beautifully.
We’re still refining iOS handling, automation structure, and some internal workflows — updates will follow as we continue to test and optimise.
If you’re exploring similar setups, drop your findings — would be great to share notes and shape a proper community workaround together.
One theory I’ve been exploring is to make the push setup part of the onboarding process on the Netlify-hosted version.
The idea would be: users install that version first (so their device gets registered and subscribed properly), and then — once that’s done — we automatically redirect them to the main app.
In theory, that could result in just one installed version that’s already subscribed, instead of users ending up with two separate apps.
We could then manage a superficial notifications toggle inside Glide — letting users turn notifications on or off within the app UI without actually unsubscribing the device.
That would keep the subscription intact while still giving users the sense of control.
That said, I’m not entirely sure on the legality or compliance side of that approach yet — especially around consent and data handling — so it’s just a working theory for now.
What’s working well
iOS caveat
How we approached it (high level)
Security & privacy
Heads-up on Glide updates
Still building