Adding Push Notifications to AI-Built Apps

Push notifications are one of the clearest ways to turn a wrapped web app into a real mobile app. They are also easy to get wrong: permission prompts at the wrong moment, messages nobody wants, tokens that go stale. This guide explains the moving parts and how to add push to an app built with an AI builder or coding agent.

How push delivery works

Your server does not talk to the phone directly. It sends a message to a platform service, which delivers it to the device. On iOS that service is the Apple Push Notification service (APNs). On Android it is Firebase Cloud Messaging (FCM). Many teams use FCM as one interface for both platforms, with APNs behind it for iOS devices. Check the vendors' current documentation for setup details.

1. The app asks the user for permission to show notifications.
2. The operating system gives the app a device token.
3. The app sends the token to your backend, linked to the signed-in user.
4. Your backend sends a message through APNs or FCM using that token.
5. The operating system displays the notification, and a tap opens the right screen.

What a web-to-app project needs

• Native plugin or module that registers for notifications and receives tokens.
• Capabilities and keys: push entitlement and an APNs key for iOS, and a Firebase project for Android.
• Backend endpoints to store, update and delete tokens, and a sender that handles invalid tokens.
• Deep links so a notification opens the relevant content; see deep links for converted apps.
• Preferences where users choose which notifications they receive.

Design the permission moment

iOS shows the system permission dialog once; if the user declines, you can only send them to settings. So do not ask on first launch. Show a short explanation screen at a moment when the value is obvious, for example after a user creates a booking, and then trigger the system prompt. Android also requires a runtime permission on recent versions. Explain what the user will receive and how often.

Good notification habits

Store review considerations

Apple expects push notifications to serve a purpose and not be used for advertising without opt-in consent. Google Play has its own notification and permission rules for recent Android versions. Describe your notifications in the review notes, and make sure users can control them in settings. Push also helps with Apple's Guideline 4.2 concerns, because it demonstrates native behavior; see our guide on that guideline. Verify current policies for both stores.

Privacy and security

Device tokens are identifiers tied to people, so include them in your privacy documentation. Do not put sensitive information in a notification payload, because lock screens are visible. Keep APNs keys and Firebase credentials on the server only, never in the app.

Testing push properly

Push is difficult to test on simulators alone. Use real devices, with the release configuration, in each state: app in foreground, background, and fully closed. Test with notifications disabled, with focus modes active and after reinstalling the app. Check that tapping a notification opens the right screen even after a cold start, that badge counts update and clear correctly and that token changes are saved when a user signs in on a new phone. Log delivery errors on the server, because platforms return useful codes when a token is invalid or a certificate is wrong.

How apprat.io handles push

Push notifications are a module in the apprat.io app builder, which saves you from setting up the native layers by hand. For custom projects, coding agents help write the integration, while an AI Code Engineer reviews every change, tests delivery on real iOS and Android devices, and handles credentials and store submission with accountability for the result. Learn more on the features page or book a call for free.