Lovable is very good at building the thing. The awkward moment comes later, when you want the app to notify someone.
The reason is structural: Lovable builds web apps, and a web app cannot receive an iOS or Android push notification. Push is delivered by the operating system through APNs or FCM to an installed app. There is no version of that which works from a browser tab.
So the path splits, and which side you are on decides how much work you are in for.
The Fork
| You want | What it takes |
|---|---|
| Email notifications | Nothing. No export, no code, no native app |
| Push notifications | A native shell, which means exporting the code |
If email is enough for you, the short version is below and you never have to leave Lovable. If you need push, skip to the agentic path.
If You Only Need Email
Email works on a web app because email does not care what your frontend is. Nothing needs to be exported.
Add Entrig as a chat connector in Lovable, under Connectors → Chat connectors → New MCP server:
| Field | Value |
|---|---|
| Server name | Entrig |
| Server URL | https://mcp.entrig.com |
| Authentication | Bearer token, your Entrig API key |
Then describe the notification in chat:
Email the user when their order status changes to "shipped".
Use their email column on the users table.
Subject: "Your order has shipped"
Body: "Hi {{users.name}}, your order is on its way."
Entrig reads your Supabase schema, works out the recipient path, and installs the database trigger. It fires on the next matching insert or update with no deploy.
You will need a verified sending domain first, which is one DNS record. Full detail in the Lovable guide.
Chat connectors are a paid Lovable feature. If you are on the free plan, you can do the same thing from the Entrig dashboard instead.
The Push Path: Export, Agent, Capacitor
Push needs a native app, so the workflow becomes: get the code out of Lovable, hand it to a coding agent, and let the agent do the parts that are fiddly.
This is worth doing with an agent rather than by hand, because the annoying steps here are exactly the ones agents are good at: native file edits, plist entries, entitlements, Gradle config. None of it is intellectually hard and all of it is easy to get subtly wrong.
Step 1: Get the code out
In Lovable, connect the project to GitHub and push. Then clone it:
git clone https://github.com/you/your-lovable-app.git
cd your-lovable-app
npm install
What you get is a standard React and Vite project. That matters, because Capacitor works by loading a built web bundle inside a native shell, and a Vite build output is exactly what it expects.
Step 2: Give the agent the Entrig skills
Open the project in Claude Code, Cursor, or Windsurf, and install the skills:
npx skills add entrig/entrig-skills
This is what turns the next two steps into a sentence each. The skills carry the integration details, including the native iOS setup and the mistakes that are easy to make, so the agent is not improvising from a blog post it half remembers.
Step 3: Ask the agent to wrap it in Capacitor
Convert this Vite web app into a Capacitor app targeting
iOS and Android. Set the app id to com.yourcompany.yourapp
and use the Vite build output directory as the web directory.
The agent installs the Capacitor CLI and core, creates capacitor.config.json, adds the ios/ and android/ platforms, and runs the first sync. Your capacitor.config.json ends up looking like this:
{
"appId": "com.yourcompany.yourapp",
"appName": "your-app",
"webDir": "dist"
}
Two things to check before moving on, because both are easy to miss and both break silently:
- Supabase redirect URLs. Your auth flow now runs inside a native shell, not at your web origin. Add your app’s deep link scheme to Authentication → URL Configuration → Redirect URLs in Supabase.
- Environment variables. Vite inlines
VITE_-prefixed variables at build time. Anything your app reads at runtime from the hosting platform will not be there anymore.
Step 4: Ask the agent to add push
Set up the Entrig Capacitor SDK in this project.
That one sentence triggers the entrig-capacitor skill, and the agent will:
- Install
@entrig/capacitorand runnpx cap sync - Run
npx @entrig/capacitor setup ios, which configuresAppDelegate.swift,App.entitlements, andInfo.plist - Wire
Entrig.init()at app startup,Entrig.register()on sign in, andEntrig.unregister()on sign out - Add the notification tap listeners
Android needs no native setup at all. The plugin bundles the Android SDK and wires itself on cap sync.
The code it lands looks like this, using your existing Supabase session:
import { Entrig } from '@entrig/capacitor';
// once, on app start
await Entrig.init({ apiKey: 'YOUR_ENTRIG_API_KEY' });
// when the user signs in
await Entrig.register({ userId: session.user.id });
// when they sign out
await Entrig.unregister();
// handle taps
Entrig.addListener('onNotificationOpened', (event) => {
// navigate using event.data
});
The userId is the Supabase Auth user id, and it has to match the user identifier your notification is configured against. That is the one value tying the device to the person.
Step 5: Create notifications by describing them
Add the MCP server to your agent so it can create notifications directly:
{
"mcpServers": {
"entrig": {
"type": "http",
"url": "https://mcp.entrig.com/",
"headers": {
"Authorization": "Bearer YOUR_ENTRIG_API_KEY"
}
}
}
}
Now the notification itself is a sentence:
Notify all members of a group chat when someone
sends a new message in that group, except the sender.
Send a push notification when a task is assigned to a user.
The tasks table has an assigned_to column that is the user ID.
Title: "New task assigned"
Body: "{{tasks.title}} is due {{tasks.due_date}}"
The agent reads your schema through Entrig, works out the recipient path (following a foreign key for one user, or fanning out through a join table for many), and installs the Postgres trigger in your Supabase project. There is no Edge Function to write and nothing to deploy.
You can manage them the same way:
Show me all notifications configured on the orders table.
What You Still Have to Do Yourself
Being straight about this, because no tool removes these:
- Firebase service account JSON for Android, and an APNs key from your Apple Developer account for iOS. Google and Apple require your own credentials to deliver to your app. You upload them to Entrig once.
- An Apple Developer account if you are shipping to iOS. That is $99/year and it is Apple’s toll, not ours.
- A real device for testing iOS push. Simulator push support varies by Xcode and macOS version, so testing on hardware removes a variable.
- Actually shipping the app. Capacitor gets you a native binary. Getting it into the App Store and Play Store is still the normal review process.
Why This Path Works
The thing that makes this practical is that the hard part of push is not the mobile plumbing, it is the backend.
Deciding who gets notified when a row changes is the part that normally becomes an Edge Function full of hand-written SQL, a different one for every notification type. Entrig moves that into your database as a trigger it generates from your existing schema, which is why the whole thing can be driven by a sentence rather than a pull request.
That leaves the mobile side, which is mechanical, well documented, and exactly the kind of work a coding agent handles without complaint.
A Note on This Guide
The Capacitor and Entrig half of this path is what our own Capacitor example app is built on, a Vite project wrapped exactly this way, so those steps are well trodden. The Lovable export and Capacitor conversion will vary with what your specific app does, particularly around auth redirects and environment variables. Treat step 3 as the one to verify on your own project before building on top of it.