AI App Builder Push Notifications (2026): Who Holds the Token

Quick Answer

"Does this AI app builder support push notifications" is the wrong question, because push is not one feature. It is three separable jobs: obtain a device token, store that token against a user, and send a message to it. Every builder that offers push at all does the third job. They differ almost entirely on who does the first two, and that difference is what decides whether a notification ever arrives.

Across eight builders, three structurally different answers, and the middle column of the table below is the one that matters.

The platform holds the token and you address a person. Softr and Base44 both register devices for you. You pick a recipient and write a title and a body. Softr goes further than anyone: "No third-party service or API key required, push notifications are built into every published Softr app."

You hold the token and you address a token. Lovable's Firebase Cloud Messaging connector sends to a device token, a topic, or a condition. It states the boundary twice, in plain words: "The connector does not collect tokens." Building the registry that maps users to devices is your job.

There is no documented path. Bubble, Bolt.new and v0 publish no push notification documentation at all, in indexes that are otherwise detailed. Bubble's manual covers native in-app purchases, native element differences and native payments, and contains zero pages on push.

The second axis is credentials. Softr asks for none. Lovable and Base44 both require a Firebase project you own and, on iOS, an Apple Push Notification service key from your own Apple Developer account. That is more setup, and it is also the reason those credentials are portable: they live in your Google and Apple accounts, not in the builder.

Why "supports push" tells you almost nothing

A feature matrix has one column for push, and the column is close to useless. Softr, Base44, Lovable and Replit would all take a tick in it, and the four of them require four genuinely different amounts of work from you, reach different devices, and fail in different places.

The reason is that a push notification has a longer path than most app features. Something in the client asks the operating system for permission. The operating system, if the user agrees, issues a token that identifies that install on that device. Something has to receive that token and write it down next to a user record. Later, something else has to look up the token and hand a message to Apple Push Notification service or Firebase Cloud Messaging, authenticated as somebody Apple or Google recognises.

Builders take responsibility for different segments of that path, and none of them takes responsibility for all of it in the same way. Replit's own troubleshooting page names the exact seam where it comes apart, and it is not the sending step: "Player granted permission but gets nothing: check the token was actually saved against their account, a common gap when sign-in and notification setup happen separately."

That is the finding worth carrying. The send is the easy part, and it is the part every vendor documents proudly. The token registry is the hard part, and it is the part they differ on.

Axis 1: what kind of push the platform can deliver

Web push, which needs a browser

Softr sends web push. Its documentation describes notifications that "appear directly in the user's browser or device notification center", and the setup is a toggle: open the app, go to Users then Notifications, enable push for Mobile, Desktop or both, and publish. After that, "users who visit your published app will be prompted to allow notifications in their browser. Only users who have granted permission will receive push notifications from your workflows."

Web push is real push. It reaches the notification centre and it survives the tab being closed. What it cannot do is reach a device where your app was never opened in a browser, and its behaviour on iOS depends on the user having added the site to the home screen, because Safari gates web push behind that step.

Webflow has no first-party push feature. Its own app marketplace lists exactly one push notification app, a third-party integration described in Webflow's listing data as "Push notifications for Webflow website, no mobile App required". That is an accurate description of web push, and it is also a fair description of Webflow's position: this is a website platform, and push arrives as somebody else's product.

Native push, which needs a binary and two credentials

Base44 and Replit both produce installable mobile apps and both document native push. Base44 is blunt about what this buys you: "Push notifications appear on someone's phone even when your app is closed." That sentence is the entire case for native push over web push.

Lovable is the interesting case, because it sits in both columns and in neither. Lovable publishes to a web URL and does not produce a native binary, but its Firebase Cloud Messaging connector will send to native tokens: the connection form offers "Server or native only (default) if you only send to tokens you already have, including Android and iOS", or "Include web push" if the app also registers browsers. So Lovable is a sending backend that can serve a native client somebody else built, and a web push provider for its own published apps.

No documented path

Bubble ships a native mobile app editor, currently marked beta in its own documentation, with detailed guidance on native elements, native navigation, in-app purchases on both stores and production IAP checklists. Its documentation index contains no push notification page. The only notification entries are email actions, workload alerts and a Stripe webhook example.

Bolt.new generates Expo projects and documents the whole path from prompt to TestFlight and Google Play, with nothing on notifications anywhere in its support documentation. Because the output is a standard Expo project, push is reachable in your own code with the ordinary Expo libraries. It is simply not a path Bolt describes or supports.

v0 produces web applications deployed to Vercel and documents no push notifications. Every occurrence of the word push in its documentation is git push, in the context of working branches and publishing.

State those three carefully. What is measured here is the absence of documentation, not a proof that the capability is impossible. On a platform where your app is code you can edit, an undocumented capability is often still a capability, and it is entirely your problem.

Axis 2: who holds the device token

This is the axis that decides how much work push actually is, and it is invisible in every feature comparison we could find.

The platform holds it, and you address a person

Base44's built-in integration is named SendPushNotification, and its documentation describes it as something that "sends a native push notification to one person in your app". You do not handle tokens. You call it from a backend function, a flow, an agent or an automation, and Base44 resolves the person to their devices. The message carries a title of up to 100 characters, a body of up to 500, an optional action button label and an optional link to a page in your app.

Softr works the same way with a different vocabulary. The Send Push Notification action takes Recipients, which are "one or more users to notify. Recipients must be users of the selected application. Map a user email from an earlier workflow step, or provide multiple emails for targeted delivery." An email address, not a token.

The trade is visible in Base44's own note: "Each call sends to one person. To notify several people, call SendPushNotification once for each of them." There is no topic, no segment, no broadcast. Person-addressed push is simple until you want to tell everybody something.

You hold it, and you address a token

Lovable's connector documentation is unusually candid, and it repeats the boundary rather than burying it. Under sending: "The connector does not collect tokens. Android, iOS, and web clients obtain them with the Firebase SDK, then your app stores them for later sends." Under limitations, the first bullet: it cannot "Register devices or obtain FCM tokens. Your app's Firebase client SDK does that, and your backend stores the tokens."

Each message targets exactly one of a device token you collected and stored, a topic that devices already subscribed to, or a Firebase condition expression. That is the full Firebase addressing model, which means topics give you the broadcast that Base44 and Softr do not have. It also means you are running a token table, handling registration on the client, and pruning it: a token that returns UNREGISTERED "is stale. Delete it from your database instead of retrying it."

The agent wires it, and the seam is documented

Replit sits between the two. Its push notification walkthrough is three steps, and the middle one is the registry: ask permission, then "Agent registers a push token for the signed-in player, so PixelGames knows which device to notify", then send. The agent writes the code that Lovable expects you to write.

What makes Replit worth reading closely is that its documentation does not pretend this always works. It tells you to trigger the real condition rather than asking the agent for a test notification, because that "confirms the whole path works: the score save, the check for who to notify, and the send, not just that permission was granted". And its troubleshooting names the join failure directly, the token not being saved against the account when sign-in and notification setup happen separately.

Two independently written documentation sets, Lovable's and Replit's, identify the same step as the fragile one. That agreement is stronger evidence than either page alone.

Axis 3: whose credentials do the sending

Push is authenticated. Somebody has to hold a credential that Apple or Google will accept, and the builders differ on whose account it comes from.

Softr: none. The documentation lists it as a benefit in as many words, "Native to Softr: No third-party service or API key required, push notifications are built into every published Softr app." Nothing to create, nothing to rotate, nothing to lose.

Lovable: your Firebase project. The prerequisites are a Firebase project, a Google Cloud service account in it carrying the Firebase Cloud Messaging API Admin role, and, for browser push, a Firebase web app plus a Web Push certificate VAPID key. You upload the service account JSON to the connection. Lovable stores it and "exchanges it for a short-lived Google token when sending", and your app code never sees it. The billing follows the credential: "Sends through this connector use your Firebase and Google Cloud project. Quotas and any Google Cloud billing are handled by Google, not Lovable."

Base44: your Apple key and your Firebase project, both. iOS needs an active Apple Developer Program membership and an APNs auth key created under Certificates, Identifiers and Profiles. Android needs "a Google account and your own Firebase project", from which you upload two files: google-services.json, which "is built into your app so it can receive notifications", and a service account key, which "lets Base44 send them". Base44 notes that Firebase's free Spark plan is enough for this.

Replit: not surfaced. Its push notification documentation never mentions APNs keys, Firebase projects or service accounts. Its Apple Developer requirement appears in the publishing flow rather than the notification flow. That is a genuinely different posture, not a gap in our reading: the credential question does not reach the user on this path.

Notice what this does to the usual lock-in argument. The two builders that demand the most setup are the two where the sending credential is an asset in your own Apple and Google accounts. Softr's zero-configuration push is the least portable of the three, because there is nothing to take with you. Ownership and convenience point in opposite directions here, and neither answer is wrong.

The comparison table

Documentation checked September 2026 against each vendor's own published pages. "None documented" is a statement about what the vendor publishes, not a claim that the capability cannot be built in code you control.

The details that decide whether it works at all

You cannot test iOS push without registering the app with Apple. This is the single most expensive surprise on the list. Replit states it plainly: "Android can test this right away in Expo Go. iOS needs the app uploaded and installed from TestFlight first, Apple requires the app to be registered with them before it can receive any notification, even for testing." Its troubleshooting repeats it, because people hit it: "Expo Go can't receive pushes on iOS." If your plan is to validate push before committing to an Apple Developer Program membership, there is no plan. Everything about that first submission is covered in our comparison of who actually presses submit on an app store release.

The permission prompt happens once. Both platforms ask before the first notification, and a decline is durable. Replit: "Decline means silence until the player re-enables it from Settings." That makes the moment you ask a product decision rather than a technical one, and asking on first launch, before the user knows why they would want it, is how you lose the channel permanently.

Turning push on later means a new binary and a new review. Base44 puts push behind the same window that generates your store files, which has a consequence it states outright: "People who already installed your app receive push notifications after you generate new app files and submit an updated version to the Apple App Store or Google Play." Existing users do not get push until they update. This is the native boundary in its usual place, and we mapped where every builder draws it in which fixes reach users without a new review.

Push does not survive an export. Base44's mobile documentation is explicit about the wrapper route: if you take your exported code and wrap it with Capacitor, PWABuilder or Trusted Web Activities, "these wrappers are managed outside of Base44, and any native-only features like push notifications must be set up separately." Push is a property of Base44's build pipeline, not of the code it hands you.

Two files ending in .p8, and only one download each. Setting up Base44 for iOS means creating an App Store Connect API key and an APNs auth key. Base44 warns about both the confusion and the finality: the APNs key "is a separate key from the App Store Connect API key you add earlier in the same window. Each has its own Key ID, and both files end in .p8, so keep track of which is which." And, separately, "Apple only lets you download your APNs auth key once. Save the .p8 file somewhere safe, because you cannot download it again."

The preview pane cannot test browser push. Lovable documents an iframe problem worth knowing before you conclude your code is broken: "The Lovable preview runs your app in an iframe. Browsers block the notification permission prompt there. Open the preview in its own tab, or test on the published app."

Nobody here reports whether a notification was opened. Lovable's limitations are the clearest statement of the ceiling: the connector cannot "Read delivery analytics, open rates, or per-user reach. Those live in the Firebase console (and its BigQuery export, if you enable it)." If open rate is a metric your product depends on, that measurement lives in Firebase or in whatever you build, on every option here.

A push may be metered. Base44 notes that each notification sent through SendPushNotification "typically uses ~1 integration credit". Lovable's sends draw on your own Google Cloud quota and billing rather than on anything Lovable meters. Neither of these changes which tool to pick, but a high-volume notification product should know which meter it is spending before it builds on one.

Verdict, September 2026

Pick on the token registry, not on the feature list.

If you want push working this week and your users live in a browser, Softr is the shortest path in this group by a wide margin. No credentials, no token table, a toggle and a workflow action. Accept the two limits honestly: it is web push, and you address individual users rather than segments.

If you need a notification to reach a phone with your app closed, and you would rather not build a device registry, Base44 is the most complete first-party native path here. You will spend an hour in the Apple Developer portal and the Firebase console, and after that you address people by name from a backend function. Budget for the fact that adding push later costs a store submission.

If you are already building on Replit and shipping through its Launch flow, its push walkthrough is the most integrated of the lot, and its documentation is the most honest about where the wiring breaks. Plan the iOS test around TestFlight from the start, because there is no earlier checkpoint.

If you want the sending layer to be a portable asset, Lovable's connector is the one that leaves you owning the pieces: your Firebase project, your service account, your token table, your topics. It asks the most of you and gives you the full Firebase addressing model in return, including the topic broadcasts nobody else here offers.

If you are on Bubble, Bolt.new or v0, treat push as unbuilt rather than unavailable. Bubble's native editor is in beta and this is a documented gap in an otherwise thorough manual, which is a reasonable thing to watch. Bolt hands you an Expo project, so the ordinary Expo notification libraries are available to you and entirely unsupported. v0 hands you a web app, where web push is a standard browser API and a service worker you write yourself.

One closing observation, because it cuts against the usual reading. On this criterion the platform that gives you the least control is the one that works soonest, and the platform that gives you the most control is the one that asks you to build the hardest part yourself. That is not a flaw in either. It is the trade, stated plainly, and it is worth choosing deliberately rather than discovering after the first user asks why they never got the alert.