Free trials are one of the best ways to convert users into paying subscribers — but they can backfire. When a user forgets they started a trial, the unexpected charge feels like a betrayal. They refund, leave a bad review, and never come back. Even worse, that one bad experience can make them reluctant to try any subscription app again.
A simple reminder notification a day or two before the trial converts changes the dynamic entirely. The user feels respected, not tricked. They either cancel (which they would have anyway) or they convert knowing exactly what they’re paying for. Either way, you build trust — and trust is what drives long-term retention.
I’ve written about building trial reminders before using RevenueCat and Zapier to power email-based notifications. In this tutorial, we’ll build a similar system using local and remote push notifications in React Native — though the same concepts apply to Kotlin and Swift.
How to plan trial reminders
Trial reminders don’t have to be complicated, but sending out more than one reminder builds trust, and removes uncertainty. I would recommend a lightweight three-notification pattern:
- Activation nudge (same day)
- Mid-trial reminder (two days before end)
- Trial-ending alert (morning of last day)
“Your trial ends today. Keep access by staying on your plan — or cancel anytime.”
How to implement trial notifications in React Native
There are two approaches: local notifications (no server needed) and remote notifications (requires a small backend). We’ll walk through both, starting with local.
Local notifications approach
With local notifications, all the reminder logic lives on the device — no server needed. When a user starts a trial, you grab the trial expiration date from RevenueCat’s customerInfo.entitlements (specifically the expirationDate on the active entitlement), then schedule notifications relative to that date.
Local notifications are the simplest approach — very little code and no backend to maintain. The trade-off is that the notification schedule can only update when the user opens your app. If someone cancels their trial through the App Store settings page, for example, the app won’t know to unschedule the reminders until it’s opened again. The same applies if they switch to a plan without a trial.
Additionally, local notifications will fail if the user’s device is powered off, and orchestrating other notification channels such as email is harder with local notifications. Some Android phones also have limitations on delivering local notifications at the exact scheduled time.
Remote notifications
The alternative to local notifications is a server-driven approach. You run a lightweight backend that listens for RevenueCat webhook events and schedules or cancels trial reminders accordingly.
This approach takes more work to set up, but it’s significantly more reliable. You can update notification content without shipping an app update, use multiple channels (push notifications and email, for instance), and cancel reminders immediately when a user unsubscribes — no app open required. The backend itself doesn’t need to be complex: a single endpoint that digests webhooks and schedules notifications is all you need.
On the client side you only need to take care to store users’ push notification token, which is something RevenueCat can actually help you manage. You can save push tokens in Attributes, from which they are available using either REST API or Webhooks.
Choosing a notification package to use
React Native does not come with notifications included, so you need to install and configure an external dependency to run them. Here are a few options that support both remote and local notifications:
Expo Notifications Expo notifications is excellent for notifications, especially if you have an Expo project. This tutorial will use Expo Notifications for the examples.
react-native-notifications Wix has been maintaining their own notification package for React Native for over 10 years already. It’s stable and has all the features you need for notifications.
@notifee/react-native Notifee is a feature rich notification library for both iOS and Android. It’s especially powerful when you want rich notifications, with images, custom sounds and interactability.
Subscription reminders with local notifications
The next parts assume that you’ve installed and configured your notification package for your project.
Step 1: create a trial schedule object
We will want to remind users three different times, so let’s build a trial object that will be used for scheduling when and containing the messages we want to send. The following trialSchedule follows the 3-part trial reminder structure we discussed earlier.
Step 2: schedule notifications during subscription process
Scheduling the trial reminders will happen when users subscribe. We can use getCustomerInfo to check if user is running a trial:
The first step to adding remote trial notifications is to track the users’ push tokens. This is made easy with RevenueCat Attributes, where you can store additional structured information about customers. These attributes can later be read using the REST API.
If you take a look at the documentation for Attributes, you see that both $apnsTokens and $fcmTokens are reserved attributes. This means that we can store push tokens in RevenueCat as well. Doing that through code is just a few lines:
That is all that is needed from the client side, as long as you have configured your notifications correctly. The rest of the tutorial will focus on what needs to happen on the server side.
Step 2: build a notification backend
All of the logic for trial reminders will happen on the backend side. For this we need to build an endpoint that accepts webhooks from RevenueCat and then schedules notifications based on those. To understand which types of Webhook events we need to support, we can take a look at the webhook sample events.
In this example we are going to use a Cloudflare worker, but it’s not a requirement. You could also build this using Zapier and OneSignal.
Here’s some example code:
Let’s go through the main functions of the code.
Unwrapping the webhook payload is the first step.
The POST request from RevenueCat webhook is sent to our worker which then unwraps the contents. In this case the interesting parts are:
period_type, tells us if the subscription is TRIAL type
purchased_at_ms, tells us when user made the purchase
expiration_at_ms, tells us when the trial will convert
subscriber_attributes, from here we can get the push notification token to use
Scheduling notifications
In our code we check first if the purchase is trial type, then we schedule a notification 6 hours from that if the purchase was made before 12pm, otherwise we schedule it for the next day. Then we schedule a mid-trial reminder 2 days before the trial ends. Last scheduled reminder is set for the morning of the expiring subscription. If the subscription expires in the morning, we schedule it for the evening of the previous day.
Unscheduling notifications
The last logic we have for the apps is that we unschedule the notification if the user cancels the trial. In this case we monitor for the cancel_reason being UNSUBSCRIBE and then remove the scheduled notifications.
Running logic to send notifications periodically
The last part of the code is that we run a different worker every hour to send notifications to users based on their scheduled times. This is done through a cron job.
Step 3: enable webhooks in the RevenueCat dashboard
Navigate to the RevenueCat dashboard, and select the Integrations tab from the sidebar. Under Core Tools, select Webhooks. Click Add Webhook and set the Delivery URL to your worker endpoint (e.g. https://your-worker.your-subdomain.workers.dev). Set the Authorization header to match the RC_WEBHOOK_SECRET you configured in your worker. Make sure to enable at minimum the INITIAL_PURCHASE, CANCELLATION, EXPIRATION, and TRIAL_CONVERTED event types.
Wrap-up
Trial notifications are one of the fastest, lowest-effort ways to improve trial quality and conversion. With clear data (purchasedDate, expiresDate) and a small amount of React Native code, you can build a trust-first notification flow that feels more like Blinkist — transparent, helpful, and user-centred.
Start with the three-message sequence, keep the messaging honest, and iterate based on user behavior. You’ll see the lift.