Menu

UPDATE October 7, 2016: We’ve discovered a workaround for the issue with the un-launchable system apps in iOS 10 and a fix is now out in Launcher v2.2.3 now. Please note that this is just a workaround, it doesn’t mean that Apple changed their mind on the issue. In fact, it is quite possible that they could release a new version of iOS 10 that breaks this workaround, so beware when upgrading iOS 10 versions. We’ll try to keep everyone up to date if we discover that a new version of iOS 10 breaks the workaround.

—

UPDATE September 8, 2016: Apple has released the iOS 10 final candidate and they did not restore this functionality and these system apps are still not launchable. This is disappointing, but it is still possible that Apple could restore this functionality in an update to iOS 10 in the future. If this is something you would like to see, please send them feedback. Details on how to do this are in the original post below.

The only way currently to launch these system apps is to either remain on iOS 9 or downgrade your device back to iOS 9. However, you will only be able to downgrade back to iOS 9 until September 19, 2016 or so. Here are instructions on how to do that.

—

As some of you may have heard, Apple has made changes in iOS 10 so that some system apps can no longer be launched from third-party apps like Launcher. Namely, the apps that were previously launchable in iOS 8 and 9 from widgets, but can no longer be launched in iOS 10 are: Settings, Clock, Weather, Contacts, iCloud Drive, Voice Memos, and the Phone app (just launching the app is affected, you can still make phone calls).

Obviously the removal of this functionality is as disappointing to me as it is to you. In particular, Settings launchers are very popular because of the tremendous utility of being able to directly open specific screens within the Settings app without the burden of navigating to them when you want to quickly toggle a setting.

Several users have asked me if this loss of functionality is going to remain in iOS 10 once it is out of beta and only Apple knows the answer to that question. There is a precedent of Apple removing functionality in iOS betas only to add it back before the final version is released. Apple removed the ability to lookup the device’s Wifi SSID in iOS 9 betas only to have the functionality restored once iOS 9 was released.

This is where I need your help. I’m not sure that Apple understands how many users are relying on this functionality, and I hope that if enough users contact them to let them know how useful it is and that they don’t want to see it removed, perhaps Apple will change their mind before iOS 10 is released in September.

If you have the iOS 10 beta installed on your device, you can send them feedback using the installed Feedback app. If you don’t have iOS 10 installed yet, you can send them feedback here. Please remember that calm, well-reasoned justifications will go much farther than yelling and screaming.

The following is a good example of the proper feedback to send. Feel free to use it as a template for forming your own feedback.

Dear Apple,

Since widgets were introduced in iOS 8, certain system apps like Settings were able to be launched via their custom URL schemes from widgets. However, this functionality has been removed in iOS 10 as the “prefs” custom URL scheme no longer works. The ability to have a button to go straight into the Bluetooth screen within the Settings app to quickly and efficiently connect devices is invaluable to me and the loss of this functionality greatly diminishes the utility of my iPhone. Therefore, I would like to ask you to either revert this change or create an alternative way to allow the Settings app to be launched from third party widgets in iOS 10.

Multiple Widgets! This greatly increases the number of launchers you can have in your Notification Center and helps the organization of your launchers. Each widget can be configured to show or hide based on time, day, and/or location, which is functionality never before seen in the App Store. Set up widgets for home, work, the gym, morning, weekdays, or whatever you can come up with so that you always have relevant launchers at your fingertips.

iCloud backup and restore of launchers to make your life easier when you install Launcher on multiple devices or upgrade your device.

More icon customization including circular icons and the ability to create your own custom icons to help personalize your launchers.

Intro

Since iOS 9 has been out for almost 4 months, I realize that this post is a bit overdue, but since I still see a lot of misinformation on the subject bandied about on social media, I figure it is better late than never.

Here are some examples of misconceptions I still hear propagated by developers about the changes Apple made to the canOpenURL call in iOS 9:

“You can now only call up to 50 unique custom URL schemes in an app.”

“Apple made this change to kill app launching apps.”

In this post I will try to explain the changes made in iOS 9 that affect the canOpenURL call as clearly and concisely as I can in order to quell any remaining fear or false information out there on the subject. And then I’ll probably discuss more of the mundane details for developers out there with too much time on their hands.

We are thrilled to announce that we have a new app with a useful widget live on the App Store!

Music Launcher allows quick access to play your favorite songs, playlists or podcasts from the Notification Center. Download it today!

Version 1.1 has already been submitted and we hope it will be out later this week. It includes music controls in the widget for pro version users and the ability to view and edit the tracks from the launcher edit screen. These are two critical features that normally would have been included in the initial version, but since there was a really good chance that the app would be rejected and never released, I could only put the absolute minimum functionality into version 1.0. Unfortunately this is the position that Apple’s App Review policies and lack of clear guidelines has put developers in.

For those keeping track of my struggles, Music Launcher was submitted to Apple in early December and was initially rejected with the reason given being “Shortcuts are not allowed in widgets.” I appealed the rejection asking what that meant exactly and informing them that Music Launcher doesn’t launch any apps, it just calls the Music API. I figured I would just get the same terse response that I got with all of the various Launcher appeals saying that the rejection is final. However, to my surprise they overturned the rejection and allowed me to re-submit. So I did just that and it is now live. And since this went through the appeal board, I have high hopes that it won’t get taken down after the fact like Launcher was, but you never know on the App Store.

A Quick Note Regarding Launcher

For the Launcher fans out there still keeping up hope, I actually submitted a new version of Launcher Standalone (see my previous post if you don’t know what Launcher Standalone was) that I called Launcher Configurator which doesn’t launch any apps at all since even that appears to now be forbidden (at least for me), but can still be used to add/edit/remove the same launchers that the widget uses. The main point of Launcher Configurator is to allow users who downloaded the original Launcher to upgrade its widget to the Pro Version (I still get emails from users asking for this almost daily). It also works around the bug where iPhone 6 Plus users had trouble adding launchers when a row was filled up.

Initially Launcher Configurator was rejected with the reason being that it looks too much like the home screen (this was a new rejection reason I never received on Launcher or Launcher Standalone). So I changed the look and feel of the launchers (in the Launcher Configurator app only, the launchers in the original Launcher widget would remain the same) and resubmitted. It was rejected again with the reason being that it requires another app to be installed first, which is a violation of App Store guidelines. I have appealed that rejection with the explanation that it doesn’t actually require another app to be installed, it’s just not very useful without that other app. I’m guessing that the rejection will be confirmed on appeal since Apple is taking a really hard line on Launcher and anything close to it. But you never know. I do have one successful appeal under my belt now.

Update 01/07/2015: Just got the official call that the appeal was upheld and there definitely will not be any way to get anything close to Launcher out on the App Store anytime soon, if ever. Oh well.

Since I still receive a few emails every week asking me if Launcher is ever coming back to the App Store, I figured it would make sense to post a public update now that I finally have a pretty solid answer on it.

The short answer is: No. It doesn’t appear that Launcher or anything even close to it will be making it back to the App Store anytime soon. I wish this wasn’t the case and I believe that I have tried everything reasonable that I could do to try to get it back in some form.

For anyone interested in a more detailed answer, feel free to continue reading. I’ll try to keep it as brief as possible, but I also don’t want to skip the important and interesting parts, so it may end up a bit on the longish side. We shall see.

As discussed in my prior post Apps, Facebook and the Trust Problem (which I kindly suggest you read first if you haven’t yet), modern day app users have been burned by overzealous sharing of their interactions within apps which leaves them gun shy about logging into Facebook in new, untrusted apps. Today I’d like to continue the discussion regarding a similar shyness that users appear to have developed regarding various IOS features as well.

Contact Lists

Since my app is a multiplayer game, there are various ways to make it as easy as possible for users to play with their friends. As mentioned in the prior post, you can invite partners from your Facebook friends list and similarly you can choose your partners from your IOS contact list as well. Not surprisingly, the user behavior from both actions is very similar. Namely, users seem to be equally shy allowing apps access to their contact list as they are about allowing access to their Facebook friend list.

Starting in IOS 6, Apple added new privacy controls that require permission from the user before an app can access certain data like the user’s contact list, photos, calendar and more. These controls were added because there were severalincidents where less scrupulous companies took advantage of their unfettered access. I consider this a very welcome improvement and I think most people would agree. In retrospect it seems pretty crazy that any developer had full access to a user’s contact list without that user’s knowledge or permission. However, similar to the “Are you sure you want to give this app access to your Facebook info?” dialog box, even the average smartphone user these days will assume the worst and deny access by default. I think it is overall a positive development that users are becoming more concerned about keeping their data private. However, keeping this data private comes at a cost of usability and not participating in the full experience that an app can provide. Perhaps that is a fair tradeoff, but it would be nice to have the best of both worlds.

In the initial version of my app the user was presented with 3 choices when initiating a multiplayer game:

Choose a Facebook Friend

Choose a Contact

Play with a Random Partner

When initially presented with this choice, a whopping 78% of the users chose option number three. It wasn’t even like they clicked on the first two buttons and were scared away by the permission dialog or found that none of their friends were playing the game and went back and chose a random partner. They didn’t even click on the first two buttons. When asked why, my users informed me that they didn’t want to click on the first two links out of fear that the app would spam all of their friends to play the game. So they simply chose to play the game with a person they didn’t know because that was the path with the least amount of risk.

When I examined the user behavior in my game post-launch, this result was easily the most surprising to me. I added the random player option as an after thought. The screen looked a little empty with only two buttons. Maybe the users were just trying to get a feel for how the game works and once they understood, perhaps they would then decide to play with a friend? That turned out to be case at least some of the time. When starting a follow up multiplayer game, 69% of the users chose a random partner as opposed to the initial 78%.

Seeing as how I really want people to enjoy playing my game and I strongly believe that playing games with your friends as opposed to random strangers is a lot more fun and makes you more invested in the game, having more than half of my players choosing random partners was an unpleasant realization. For the next version, I added two things: 1) A fourth option where you can enter your partner’s email address or username manually without giving access to your contact list, and 2) a short message near the first two buttons stating explicitly that we don’t share or store your friend list or contact list. Both of these changes dropped the percentage of the time that a user chose a random partner down to around 60%. In the upcoming version of the app I am now incentivizing users with in-app currency for playing with friends instead of random partners. I plan on reporting back later how much that has changed the equation.

I wish there was an easy way to get across to my users the fact that I am not some unscrupulous spammer trying to take advantage of every opportunity for my own gain. I attempt to explain this in my privacy policy, but how many people really read those? Unfortunately there is no concise way to explain to an average user that when I access their facebook friend list or contact list I go to the trouble of one-way hashing all of their friend’s facebook ids and email addresses. Only the hashes are sent to my server in order to show which of their friends are already registered and which ones aren’t. I couldn’t spam their friends or sell their contact list to a third party even if I wanted to.

Push and Local Notifications

And now we come to the most abused feature of smartphone apps: push and local notifications. In a world where installs cost upwards of $2 each, if developers are given a completely free, unrestricted marketing channel to retain their users then we shouldn’t be surprised when it is abused.

For fun, try an experiment. Go download the top 10 free apps on the App Store and agree to receive push notifications in all of them. Then wait 24 hours and see what crazy assortment of endless nagging and begging you have received in the meantime. Here is an example of the ridiculousness on the left. It is completely absurd. I totally understand why most of my users aren’t accepting push notifications.

It’s not just the constant begging and pleading either. Recently, Apple/IOS commentator extraordinaire John Gruber complained loudly on Twitter about the number of push notifications he was receiving via the official Twitter app.

Since Twitter is a fairly reputable company, I’m going to give them the benefit of the doubt that their barrage of notifications is not malicious and is infact due more to a poor algorithm. The algorithm probably works fine at pointing out “important” tweets for the average user, but goes totally haywire for Twitter power users like Mr. Gruber. Although Twitter may want to fix that algorithm quickly since you’d think the people they would like to annoy the least would be their power users.

So no matter the reason, smartphone users have been trained over the last few years that if they don’t want to be constantly harassed, even by reputable apps, it is easier to just auto-deny push notifications entirely. Even if you would like to be notified that your partner is done and it’s now your turn to play, there is a high likelihood that the app will end up sounding like your ex, crying and pleading with you to come back if you carelessly leave it alone for a few hours. It is much easier than having to root around in the Settings app, find the Notifications section, find the app in question and then click the 4 different buttons required to purge push notifications from all various locations after the fact.

Recently, Brendan Mulligan wrote an interesting post about how best to pre-prompt a user explaining the benefits of your push notifications before popping up the IOS push notification dialog. I followed his advice for my app and only after registration I concisely explain that we only send relevant push notifications about the games you are playing, no begging or pleading, and I ask the user if they are OK with us sending only these necessary notifications. And how many of those users accept them? 35%. And I assume that is a much better percentage than if my app just immediately prompted the user with no explanation that it wanted them to accept push notifications.

What makes the problem even worse is Local Notifications which are similar to Push Notifications, but are initiated from within the app rather than from the server side. Prior to IOS 8, for some unknown reason Local Notifications don’t require any opt-in by the user, and therefore they are the favored way to nag users to come back to apps. Does anyone really think that users want every app they have to bug them every day to come back? Does this meaningfully increase user retention in the long run? Has anyone ever ran a real A/B test and accurately measured the impact, including measuring how many people never come back to the app because it is easier to just delete the app rather than going into the Settings app to disable the notifications? Or are developers just assuming that it is net positive for user retention because everyone else seems to be doing it?

Framing the Problem

As I see it, there are at least 2 problems that I have pointed out:

Users are afraid to let apps access their contact lists or Facebook friend lists out of fear that the app may end up spamming their friends to also install the app.

Users tend to disallow push notifications by default, assuming that the notifications will be more annoying than useful.

Some might argue that users being protective of their sensitive information and eschewing push notifications is not a problem that needs to be rectified, and that argument certainly has some merit. But I would argue that if an app provides real value in exchange for access to a user’s contact list and/or push notifications then users denying by default are having subpar experiences in the app and are doing themselves a disservice.

So if we can agree that in at least some cases that this is a problem, how can we as developers and/or Apple or someone else rectify the situation?

What To Do

I could plead with my fellow developers to try harder to treat their users with respect and not fall prey to ill-advised ways to gain or retain users. I might as well plead with everyone on the Internet not to send spam email or create computer viruses, but I’ll give a plea a try anyway. Look, I get why developers are employing some of these shady methods. Acquiring and retaining users is really, really hard, or at least really expensive. As long as sleazy tactics work, or at least are perceived to work, people will (ab)use them. We have to compete with Candy Crush and Clash Of Clans which have insanely high LTVs which means they can spend a bunch of money acquiring users. So we try to take advantage any way we can. But please, put the users first and think about whether some retention feature is something that won’t completely annoy your users 99.9% of the time. Chances are that you are losing more users than you are retaining in the long run with some of these questionable actions.

(Full Disclosure: I decided to add the somewhat questionable “Please rate my app” pop-up in my app, but I have it configured to not pop up very often and one of the choices is “Never remind me again” which I think is fair for a free app. You are free to disagree and call me a hypocrite.)

As far as what Apple can do, they appear to be fixing the Local Notification opt-in issue in IOS 8 which should certainly cut down that annoyance channel. But what else can they do either in the OS or through the app review process? Here are some possible ideas I’m going to throw out, in no particular order and with no guarantee that any of these will make one lick of difference:

Require apps that access a user’s contact list (and other sensitive information) to have an explicit privacy policy that clearly explains how that information is used. Publish guidelines on what is and is not acceptable to do with the information. Review during the app review process.

Come up with an explicit policy of what developers can and cannot do with push (and local) notifications and enforce it through the app review process.

Limit the number of push notifications that each app can send and enforce the limit in the push notification system. Obviously this could be an issue with some chatty applications such as instant messaging/social networking applications where one could conceivably get hundreds of legitimate notifications per day, so perhaps allow the user to specify the limit on a per app basis?

Make opting out of push and local notifications much less cumbersome. For instance, if there was some way to easily disable notifications from within the notification itself, perhaps that would encourage users not to disallow by default as much.

Allow for a developer-created explanation of what the push notifications will be used for when the notification opt-in pop-up is shown to the user, similar to the way developers can customize the messages that show up when they request access to the contact list, camera, etc.

Finally, what can anyone else do to help the situation? There are independent third party privacy verification companies out there, although they aren’t going to cover things like “this app doesn’t annoy you to come back every day.” Plus, getting certified by them costs time and money that most independent developers probably couldn’t afford.

Perhaps we developers could come up with something similar. Some sort of alliance where we pledge to not be dicks and then we get the right to put some sort of logo in our app. If enough developers do that, then the users will learn that when they see the logo that means that the app developer has pledged to treat them as adults and they will be more trusting as a result. The biggest issues with this proposed solution of course would be the fact that not everyone agrees on what constitutes dickish behavior and enforcement would also be an issue. I guess if the logo was copyrighted, you could complain to Apple on copyright infringement grounds if there were developers using the logo and not following the pledge.

Maybe greedy developers have already burned too many bridges and we are at a point of no return where app users are going to always be suspicious of apps and will auto-deny access by default. Perhaps when we create new apps we shouldn’t put too much effort into features that require a user’s permission anymore if the majority will not grant access even when we make a strong case for the benefit of doing so. If that’s the case, then the user experience of future apps will certainly suffer, which is a shame.

Please let me know if you have any other good ideas for how best we can solve these issues. I would love to hear them.

I knew there might be an issue before my app was released when I had my wife try it out. She initially clicked on the Facebook login button, but when a confirmation dialog popped up that asked her if she was sure she wanted to grant access to her profile info and friends list, she flinched and then clicked “No”. Then when the login failed, she called me over to see what was wrong. I asked her if she said “No” to granting the app access to her Facebook account and she replied, “Yes I did, I don’t want this app having access to that information.” To which I then inquired, “You understand that I wrote this app, right? So by not trusting the app to have access to your Facebook information, you are saying you don’t trust me, your own husband, with that information?” I don’t remember her exact reply, but it was clear that she wasn’t even sure why she clicked “No”, but some alarm went off when she saw the confirmation dialog and she reacted impulsively in the negative.

One of my biggest worries when working on my first multiplayer iPhone/iPad game was how many people would download, install and run the app and then be turned away by an initial registration screen. I wondered if I should delay the release of the app just so that I would rework the front and backend to allow for some initial, limited game play without registering first. I had fears of more than half of people running the app balking at registration and immediately deleting the app.

I totally understand. I’m just some guy who started a company you’ve never heard of who wrote an app. Why should you trust me? I have a very clear privacy policy which states what I will and will not do with this information, including the fact that I will not share it with anyone, but who reads those really?

Ultimately, I decided to just release the app with required registration and see how it went. If the drop rate was too high, I could always release a new version which didn’t require registration. To my pleasant surprise, so far it seems that around 75% of the people who run the app end up registering. I don’t like the idea that I’m losing 25% of potential users and I may add limited, registration-free game play eventually, but I think that a 75% registration rate is pretty decent and is much better than I had feared.

Like many other multiplayer smartphone games out there, my app’s registration process has two options: Facebook login and email/password registration. As an end user, I generally prefer Facebook login so that I don’t have to remember yet another login and password and I figured that my users would be similarly inclined. But I was wrong.

So far after a few thousand registrations, 75% of my registered users have opted for email/password registration over using Facebook login. I had figured it would have been the other way around. And considering that this is a multiplayer game in which I was expecting most people to choose their Facebook friends as partners (the game is collaborative, not competitive, thus partners instead of opponents), this lack of Facebook usage is a bit concerning.

Then after the app was released, I announced it to all of my friends on Facebook and several of them logged in with Facebook, but some of them did not. I asked a couple of them why and their answers were mostly some form of “I don’t want the app spamming all of my Facebook friends.” Some of these were friends I have known for over 20 years and I wondered what sort of horrible things I have done in the past that my friends don’t trust me not to be some low class spammer mail bombing everyone they know to play my app.

After probing more, it turned out that my friends didn’t really understand who was responsible for the spam they have received in the past from their friends playing various Facebook games. It could have been Facebook themselves, the app developers, or some nefarious third party. So it wasn’t so much that they didn’t trust me, but they didn’t understand the inner workings of the exchange that took place when they granted someone permission to their Facebook information. They just knew that there was some possibility that if someone was granted access to that information, it could be used for bad deeds.

Facebook is obviously aware of the tendency of their users to now be more shy about sharing their information than ever before. They recently announced some features to Facebook Login aimed at helping in this regard:

1) They now allow a user to choose what parts of their Facebook information they allow an app to have access to. So if a user wants to allow an app to have access to their profile information, but not their friend list, they can uncheck the friend list permission when logging in.

2) They added something called “Anonymous Login” which allows a user to log in via Facebook without giving the app any access to any personal information.

Until these new features are out in the wild, it is hard to say how much effect they will have in increasing Facebook Login usage. Since the dialog to allow/disallow different permissions occurs after a user has clicked on the Facebook Login button, it likely won’t have much effect on users who avoid clicking the button entirely.

The Anonymous Login feature might help since it is intended to be a completely different button with a different look. However, a question still remains whether or not users will understand what the Anonymous Login button is for and will therefore be more likely to use it. The button also has a disadvantage in that if you don’t have access to the user’s information such as their friends list, you can’t provide easy ways to have users start new multiplayer games with their friends.

I wish I had some solution to this problem, but I’m not sure there really is one until the day someone invents a time machine and goes back to warn Facebook of the dangers of the Farmvilles of the world before they take over everyone’s news feed with their “growth hacking”. As has happened many other times in history, those who came first didn’t play nice and they screwed it up for everyone else. Now we’re left with users who are afraid to share any information and they’re not even sure why. And then we developers spend weeks creating elegant and simple interfaces for users to easily choose friends to play with and it turns out that our users are too afraid to use them.

In a recent update to my app I added more verbiage in an attempt to explain to my end users that I don’t store or make any use of their Facebook friends list or phone contact list in any way other than to help them find friends to play with. Once I have enough data from the new version I plan on reporting how much of an effect that had, if any. Stay tuned.