When setting up any native mobile app, you’ll invariably come across the topic of push notifications. They’re a very popular method of boosting engagement with your application and encouraging users to return. These can take several different forms depending on both their intended purpose alongside the nature of the app itself.

Reminders and Notifications are two of the most common implementations for these. Notifications are fairly straightforward for the most part. Simply “When X happens, send push notification to the relevant user”. This could be something like a venue change for an event the user has a ticket to, or the user has received a message/friend request on your social platform.

Reminders can come in many forms, sometimes it’s like popular apps with “hey, you’ve been inactive, come back”, but another which can sometimes prove to be more complex to handle are recurring reminders. These are often ones that are set up based on data provided by the user themselves, and can sometimes be desired to fire at a time specified by the user.

These recurring reminders can cause challenges during implementation, especially if you want to get more granular with your scheduling and let users specify the time that they want their notifications to fire at. Say you’ve got an app that helps users remember to take their medications, you’d need a way for all users to set multiple times for reminders to be sent to them at, and you’d want these times to be customisable per user.

In cases like this, simply having a global recurring daily workflow may not suffice, as users may change these triggering times at any point, alongside having potential for multiple reminders per day. A potential implementation for this would be having individual runs for each user, which is heavier on WUs but allows for this level of customization in the triggering times. The only thing to watch out for with this is that for each additional notification you add to the app, you are increasing the number of scheduled workflows by the predicted number of users to use this feature.

As users can change these times at whim, it also means that a pre-scheduled workflow may now fire at an incorrect time. For example, you set one for 2pm, it schedules for 2pm, but you then change it to 1pm before it fires. This workflow would now fire incorrectly. To this end, I highly advise storing the ID of each workflow to the database, attached to a data item that can be easily called back, perhaps a data item that also records the time (hour + minute) of the notification, as well as the purpose of it. This way, whenever the time is edited, you can cancel the existing scheduled workflow and schedule a new one in its place.

As with most features of this type, it’s always a balancing act between WU usage/efficiency and functionality/flexibility. To help minimise the impact of functions like this, I try to minimise the number of database searches that are needed through redundant field references. For example, attaching the “notification time” data type to the user directly, meaning I don’t need to search for “where user = specific user”, I can just use “specific user’s notifications:filtered”.

This is because filtering will generally use less than searching, due to the list being significantly smaller. E.g. 3 notification times on the user vs 300 in the entire database.