A better way to do App Permissions on iOS

Jan 23

A better way to do App Permissions on iOS

The problem: users typically deny app permissions requests

Users are fatigued with permission requests when they freshly install your App – so they decide “NObefore knowing value of “YES” and you’ll never get them back!).

The big, big problem: Its hard to reverse that decision – its tough, tough, tough to get users to opt-in again.

January 26 is the 9th Anniversary after Bill Gates was supposed to “Solve” spam – that went well didn’t it? 🙂

So when app permissions for push notifications were designed for the consumer to control opt-in probably everyone thought that was a great idea. Then things went pair-shaped…Apps were lazy and started broadcasting push:

  • irrelevant
  • often
  • not segmented
  • without considering the mobile UX (people are busy doing stuff – not in a leanback desktop experience)

So users started to reject push permissions and a general “I hate push” malaise emerged – especially amongst older demographics.

In previous posts I’ve covered the benefits and methods of Deferring Push Permissions. Effectively lets the App earns the trust of the user before request permission.

But the “elephant in the room” is not the opt-in model but Apple’s approach to “re-opt-in”. Push Opt-ins are much higher (sometimes up to 3x higher!) on Android over iOS. This is a massive “eco-system” failure on the iOS side.

To get an iOS user to opt back in to push, once they’ve rejected it once is a Herculean task for the User. Here is how bad it is:

  • The developer (via email of InApp encouragement might suggest the User opt-in to push)
  • The User agrees and wants to opt-in – but doesn’t know how!
  • Eventually they might be able to navigate to: System Settings->Notifications->Find Your App->Slide “Allow Notifications”

I’m always amazed with user testing how these tasks are actually much harder for consumer users than us technologists this! There are just too many steps to go wrong!

This is the only way: the permission dialog won’t appear again even if the User deletes and re-installs App – the previous opt-out is retained.

(Aside: unlike location permission which does re-prompt on re-install).

NOTE:  Its got a little better in iOS8 – see below.

Little White Lies or User Education

So the best practice to date (and what I outlined in Deferring Push Permissions) is to attempt to educate the user about the benefits. Here is an example of a “pre-prompt-prompt” from the hugely popular “Mailbox” App.

photo-1

credit: http://adriancrook.com/

photo-2

credit: http://adriancrook.com/

As you can see they inform the user before the scary Apple Notification pops up. This gives a better chance of conversion. But as mentioned – if the user clicks “Don’t Allow” on the second prompt, then you (the App marketer/developer) are toast!

A Proposed Heretical Best-Practice

Some Apps are doing the following but I’m going to recommend it as “Best-Practice”:

  1. Present a FAKE Push Opt-In prompt. The FAKE prompt might also educate the user and the negative option is “Later” not “Don’t Allow”
  2. Record and respect the User’s wishes
  3. Potentially ask them later (in the Apps normal pages and functionality) if they would like to accept push
  4. Here it is:
Best Practice Push Permission

 

Is this Evil?

I contend that a fake opt-in is a necessary step in the face of an untenable situation – the justification is:

  • Push Opt-in/Opt-out is actually very different to email permissions. Why?
    • Email is delivered in a common infrastructure, if a sender had a recipient address they have a good chance of getting an email into the users common “inbox”
    • A bad marketer can continue to spam emails who ignore Opt-out requests (under the CAN-SPAM law) into the user’s common “inbox”
    • In stark contrast:
      • Apps can ONLY push if their own App is installed on the Mobile Device.
      • If a user dislikes an App (for excessive push or any other reason, uninstalling terminates the relationship).

Faking and respecting the user’s is the best solution to this untenable situation.

An over-reaction?

For technologists we think if a path exists then it will work. But as Henry Cho (who has performed hundreds of direct end-user testing sessions) says in this podcast that many users still actually interpret push notifications as SMSs and quite often can’t find them again as they were not aware of the notification center.

This seems bizarre to us technologists but its true that the average mobile device user has also not discovered the intricacies of Apples Settings App.

It got a little better in iOS8

You can launch settings like this:

StreetHawk Users:


    [StreetHawk launchSystemPreferenceSettings];

Non StreetHawk Users:


    if (&UIApplicationOpenSettingsURLString != NULL) {
    NSURL *MyAppSettings = [NSURL URLWithString:UIApplicationOpenSettingsURLString];
    [[UIApplication sharedApplication] openURL:MyAppSettings];
    }

This gets you to this settings page:
iOS App Settings Permissions Page
But still you can’t do anything under the control of your App except ask the user and then launch settings. This code gets you to the Apps settings page but you still can’t actually get them back into the App, so you’ve lost them for this session – hopefully they won’t get distracted!

[EDIT]: Stuart Argue who featured in the recent Walmart Podcast pointed out to me that “It is even worse than that because you can’t get users to the ‘Notifications screen’ so you land them on the settings for app screen and hope they tap that nav table cell.”

 

How to implement this Best Practice

At App launch time (didFinishLaunchingWithOptions) don’t ask for push.


    StreetHawk.isDefaultNotificationEnabled = NO;

When you want to ask for push use something like the following snippet:


    NSString *appDisplayName = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleDisplayName"];
    SHAlertView *alertView = [[SHAlertView alloc] initWithTitle:[NSString stringWithFormat:@"\"%@\" Would Like to Send You Notifications", appDisplayName] message:@"Are you ready to accept notifications?" withHandler:^(UIAlertView *view, NSInteger buttonIndex)
       {
           if (buttonIndex != view.cancelButtonIndex)
           {
               StreetHawk.isNotificationEnabled = YES;
              [StreetHawk removeTag:@"push_optout_date"];
           }
           else {
              [StreetHawk tagDatetime:[NSDate date] forKey:@"push_optout_date"];
           }
       } cancelButtonTitle:@"Later" otherButtonTitles:@"Yes Please", nil];
    [alertView show];

So when you run campaigns you pre-filter remove users the tag push_optout_date


    BOOL isNotificationDisable = StreetHawk.systemPreferenceDisableNotification;

Provide Settings in the App

If you elect to let the user absolutely disable Push as the system level, then as part of user education and familiarity its important to give the user an options to re-enable settings (such as push) of their own accord. In this page you can display the current settings and if the user has disabled push then show all the UISwitches as of. There is also an opportunity here to have a settings for push displayed and these notification types (“notify me when X happens”, “notify me about Y”) that are useful and relevent to your App.  When the user turns the switch on you pop up a message to prepare them that you are leaving the App and suggest what they should do.

Summary & Conclusion

App Push marketers are completely different to email marketers. If an email marketer chooses to disrespect a users’ wishes then they deserve to be punished. In countries like Australia and Canada opt-in in law. In the US – the CAN-SPAM law is opt-out and culturally and subject to more abuse. I think the App Push ecosystem has been “tarred with the same brush”, as I mentioned above if a user thinks an App is too push, then they can just uninstall the App – App Push marketers are therefore more incented to respect user Push wishes.

This Best Practice for App permissions puts control back into the responsible Push marketers hands rather than being trapped in the “re-opt-in” jail.

CAVEAT

I’m not sure if Apple will ban apps that adopt this approach. Certainly you deserve to be banned if you don’t respect the user’s wishes.

  Get our Referral Program Guide