Recorded – watch the full episode on YouTube.
There are some things that we developers do with modifications that are bad ideas, that might result in decreased user trust or apps being deleted. What do you think are the most common sorts of mistakes folks make when working with notifications?
Kaya Thomas: Oh, that's a really good one. I think the one mistake is when you have your app and your app launches, and I'm a new user to your app. If you give me the notification prompts within the first like two seconds, I don't even know what your app is yet. Give me some time. I think it's important also to give information on why do you want to send me notifications? What type of notifications are you going to be sending me?
An app allows us as developers to customize that message. So when they get a prompt, right, for allowing notifications, you can tell them what type of notifications you're going to send, or why you want to send notifications. Make sure that you actually take the time to put that information in there so that you're making it clear to the user, what you're going to be sending them or why, right?
“Make sure that you actually take the time to put that information in there so that you're making it clear to the user, what you're going to be sending them or why.”
I want to know why you want to send me notifications. And then I think after that, if the user opts into a notification and then you start just bombarding them, right. You just start bombarding them with notifications of all types and kinds, that's not good at all. Be really thoughtful about how often you're sending notifications. So I really liked the example you used with the lingo is like after five days they sent you notes or however many days they sent you notifications. They say, “Hey, this is going to be our last one. We understand that you may not be interested.” So thinking about how you can customize your notifications to take into account, have they engaged with it or when was the last time I sent a notification, right?
“You just start bombarding them with notifications of all types and kinds, that's not good at all.”
If you're doing local notifications, you can do that right from the app. When was the last time you sent a notification, you keep track of that date. If I send them a notification today, I probably shouldn't send them another one, right? So things like that is making sure that you're really taking that user when they press allow, they're trusting you not to bombard them, not to send them notifications every hour or whatever, making sure that you're really being thoughtful about how often you're sending notifications and what types of notifications. It should be the same type that they agreed to sign up to.
Paul Hudson: Once again, I want to backtrack here because there are just nuggets flying out left, right and center. Let’s slow down and go to some more detail here because you've just mentioned a number of awesome things.
First up, if you ask for push permission straight away, they are going to just say no. And of course we all do the same thing because it's a lot of trust. “Yes please, hit me with your spam,” we're saying, without any further knowledge, right. And we don't want that. And what I've seen done very effectively is “point of use” requests. – the app doesn't ask to push at first. And then a week goes by and you try a feature and it goes, “well, this thing needs push.” So now let's ask for push. And you're like, “okay, I wanted that feature so I'm going to actively choose push.” Because it matters when you actually want push to be enabled for the things we care about.
Another thing I’ve seen very effectively done is folks having like a pre-permission screen shown. “Listen, you've asked to push to be shown. This is what it means, are you sure?” And then the Apple dialog appears. Because if you say no to the Apple dialogue, it's basically a block on push; you've missed your chance to say no to your dialogue you can show that again later on when they want X, Y, Z feature. So both of those I think are better ways of handling push and hopefully increasing push opt in, which is a big thing, presumably.
“You don't want to put all your text into the alert. So if you have a pre prompt screen, that can be really powerful and allow you to really get that information clearly to the user.”
Kaya Thomas: Yeah, 100%. I think those two are really great examples. Especially having the pre-permission prompt screen because if you have your own prompt screen, then you can disseminate as much information as you want, right? Apple’s alert is pretty small, and you don't want to put all your text into the alert. So if you have a pre-prompt screen, that can be really powerful and allow you to really get that information clearly to the user. And then if you are an app that only has notifications for one particular feature, yeah, that is a really great point. Like only then show the prompt when they interact with that feature for the first time.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
Link copied to your pasteboard.