Firebase offers an ‘out-the-box’ functionality to customise In-App Messages. But there is an easier way
In-app Messages are messages you send to your users in response to actions they take in your app. This powerful functionality can increase engagement and customer buy-in. You could certainly imagine using these messages to drive a featured product or app personalisation. Firebase offers this functionality out of the box, however, it’s fairly complex to customise the behaviour of these messages.
The Firebase docs recommend editing the storyboard files in the library directly. Although this is fairly easy to do it comes with one notable drawback; you’d be unable to update the library without having the headache of migrating changes you make to the storyboard files.
But there is an alternative.
Although Firebase has all the necessary functionality for the messages (including the analytical events), we found that the default had a certain “Google-y” look and feel which didn’t fit the brand of the app we were writing. So, we decided to create our own views which did match the brand. We discovered that we could implement “InAppMessagingDisplay” when importing “FirebaseInAppMessaging” which allowed us to decide what view to display in response to the type of message Firebase is wanting to show.
Here’s an example of how we did that:
We basically switch on the “type” of “InAppMessagingDisplayMessage”. It’s important not to forget the delegate methods here i.e when the message is displayed/dismissed calling the relevant functions to tell firebase X message has been displayed and dismissed, this allows Firebase to queue up messages and makes sure the subsequent messages are displayed correctly.
In creating our own custom views we have more control of when to show certain types of messages. For example, we wanted to improve the opt-in rate of people accepting notification permissions within the app, to do this we thought targeted messages in response to certain events (such as a purchase or a product coming back in stock) with custom wording reflecting the action taken would improve opt-in rate.
The problem here is that we wouldn’t want to show this message to users that had already opted into push notifications. Firebase wouldn’t know which users had opted in or not and so the out of the box messages wouldn’t be able to make this distinction.
In our new customised message manager, you can do this in a couple of ways. You could either check the status of the notifications when you see a certain URL in the action button, or check a certain field on the additional data fields within the message. Remember if you decide not to display a message you must call the dismiss function on the delegate to let Firebase know your app is ready to display another message.
Creating our own custom views unfortunately meant we had to rewrite the display logic of the views so the messages felt natural and would not just appear on the screen. When we display Cards, ImageOnly or Modal messages we grey out the background and animate the view appearing up from the bottom. This felt natural and inline with the UX of the app. For the banner we mimicked the behaviour of standard iOS notifications, the view appears at the top for a number of seconds before disappearing.
Given that we have now implemented “InAppMessagingDisplay” we are able to customise the messages we want to display to our hearts content.
A note on versioning; when we add new views/actions to respond to messages we have to be mindful of the version of the app that they exist in because they’d require a new release to display. We keep track via confluence of what message/action is in what version and make sure we only target that version in the console when setting up a new campaign.
Search over 400 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!