On Upcoming Changes in iOS 11

UPDATE Sep 13, 2017: Apple released the final version of iOS 11 to developers yesterday and I am sad to report that none of the issues in this post were fixed, so all of these problems will remain when iOS 11 is released to the public on September 19. Hopefully feedback from users will encourage them to fix some of them in future iOS 11 releases.


iOS11 is currently still in beta and it’s impossible to know what the final product will be until it is released in mid-September, but based on the most current beta, I wanted to let Launcher users know about changes that will likely come with this new version of iOS if and when you choose to upgrade to it.

Here is a quick summary of the changes coming in iOS 11 so far that will affect Launcher (I will explain them in more detail below):

  1. Settings launchers will only launch the Settings app and no longer direct you to a specific screen like Wifi or Bluetooth settings.
  2. Several Apple built-in apps can no longer be launched. That list is: Camera, Clock, Contacts, Phone (can still launch phone calls, just not the app), Stocks, Voice Memos and Weather.
  3. Tapping on a launcher to make a phone or FaceTime call now prompts the user every time to make sure that they really want to make the call.
  4. Pulling down the notification center shows the Notifications screen every time even if the last time you had it open to the Widgets screen.
  5. Apps won’t launch properly the first time they are launched from the Notification Center due to a bug in iOS 11.

I don’t expect the first two issues to change in the final version of iOS 11, but I am hopeful that there could be some change in the last three. Continue reading for more details on each change. I plan on updating this post if anything changes in upcoming versions of iOS 11.

Settings Launchers

Back in March when submitting a bug fix, Apple App Review told me that I had to remove the Settings launchers from Launcher within one week or they would remove it from the App Store. This was unfortunate since the Settings launchers are extremely useful and were one of the most popular features of the app. I’ve received countless emails from users upset about their removal, but sadly it is out of my hands.

The silver lining was that even though I had to remove the ability for users to create new Settings launchers, existing Settings launchers still continued to function properly. Unfortunately, in the latest beta version of iOS 11, the Settings launchers will only launch the Settings app and they no longer take you to a specific screen within the app. I suspect that this change was intentional and that this will be the case when iOS 11 ships in September.

Many people have asked why Apple would want to get rid of this very useful functionality. The only reason they have given me is that the URLs used to get to specific screens within the Settings app are “private APIs” and shouldn’t be used. The App Store has always banned the use of private APIs and while a URL is not technically an API, App Review claims to be enforcing this part of the App Review Guidelines [2.5.1] in this case. From what I can tell this comes down to the fact that Apple engineers don’t want to bother with publishing a public API that can be used to get into specific screens within the Settings app, like they do in macOS. They created a way to do it on iOS with URLs, but they only wanted to use these internally for themselves and didn’t want third party developers to use them. Presumably they don’t think this is functionality is worth spending the time maintaining going forward so it’s just easier for them to ban its usage.

Un-launchable Apple Apps

As they did in iOS 10, Apple has again made it not possible to launch certain built-in Apple apps via their custom URL schemes. The list of affected apps are: Camera, Clock, Contacts, Phone (can still launch phone calls, just not the app), Stocks, Voice Memos and Weather.

In iOS 10, a workaround was discovered for this change and for the last year Launcher users have been able to launch these apps. However, in iOS 11 Apple has fixed it so that the previous workaround no longer works. I don’t expect to find another workaround for this problem, so it seems that it won’t be possible to have launchers for these apps going forward.

Note that you can launch most of these apps from the new Control Center in iOS 11, so not all hope is lost. But it is a hassle when you want to launch an app and you have to remember if it can be launched from Notification Center or Control Center.

Confirmation Required on Every Phone Call

Starting in iOS 10.3, Apple added a security “feature” that required a user to confirm every phone call initiated from a third party app. Most Launcher users didn’t notice this change since they usually initiate phone calls from Launcher widgets and this new feature only affected phone calls initiated within apps. Starting in iOS 11, Apple has extended this “feature” to widgets as well.

It makes sense that Apple doesn’t want nefarious app developers tricking users into making unwanted phone calls. However, they have implemented the fix for this issue without regard to its impact on user experience at all.

Starting in iOS 10, Apple added a confirmation prompt the first time a third party app launched another app. You see these pop ups now in Launcher when you tap on a newly added app launcher that says “Open in AppName?”  They are annoying, but at least they only pop-up once and don’t show again for the launched app once you confirm by tapping the Open button.

I filed a ticket with Apple asking them to update the implementation of this new phone call security feature in a similar fashion — only prompt the user the first time they make a phone call to a specific phone number. Once a user confirms that they really want to make that phone call, then don’t prompt them again. So far Apple has ignored this request and I don’t know if they will fix it before iOS 11 is released.

I have hopes that Apple will actually make this fix more user friendly if they receive enough feedback from users complaining about its impact on user experience. So, if you are running the iOS 11 beta, please send Apple feedback in the Feedback app telling them how the implementation of this feature needs to be improved.

Notification Center Always Opens to Notifications

As you may recall, Apple changed the behavior of the Notification Center in iOS 10 to always open to the Notifications screen which means that to get to widgets you now have to swipe down and to the left every time. It had previously always opened to either the Notifications or the Widgets screen based on which was the last one open. Thankfully, Apple reverted to the older behavior in iOS 10.2 and fans of Launcher, heavy users of widgets, rejoiced.

For some reason Apple has decided to always open the Notification Center to the Notifications screen again in iOS 11. Maybe they’ll change their mind again or perhaps this time it will stick. Feel free to send Apple feedback in the Feedback app complaining about the extra required swipe to get to widgets if you are running the iOS 11 beta.

App Launches Fail the First Time

When you add a new app launcher for a third party app, iOS will pop up a dialog and confirm that you want to launch it. This dialog says “Open in AppName?” and if you tap “Open” then the app launches and the dialog doesn’t pop up again for that app. However, this behavior is broken for widgets in the Notification Center and on the Lock Screen in iOS 11 (but not in the widgets you access by swiping right from the Home Screen for some reason). When you tap “Open” in the dialog, nothing happens and that app doesn’t launch. The workaround is to launch it again from the widget and the dialog won’t pop up again and it will launch properly.

iOS 11 is easily the buggiest iOS that Apple has released in years, possibly ever. I filed 9 different bugs with Apple that affected Launcher in iOS 11 and they fixed 3 of them. Some easily reproducible crash bugs were completely ignored. Luckily I was able to work around most of the unfixed bugs in the upcoming Launcher version 3.1. However, there is a bug that I cannot work around because it occurs outside of the Launcher app and widget. I hope that Apple will fix it soon and if you send them feedback letting them know of this bug, that may encourage them to finally get around to fixing it.


So far every change in iOS 11 that affects Launcher is a negative one. In previous iOS upgrades they at least added some useful new functionality along with new restrictions, but so far I don’t know of any positive changes for Launcher in this coming iOS version. As always, the only way to avoid these negative changes is to to stay on iOS 10 as long as you can.


On Upcoming Changes in iOS 10

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.

Thank you for your consideration.

Launcher v2.0 now out

We are thrilled to announce the the next major version of Launcher is out on the App Store today. It took by far the biggest development effort so far to get this version complete and out of the door. A special thanks to all of our great beta testers for helping test all of the great, new features.

The new features in v2.0 are:

  1. 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.
  2. iCloud backup and restore of launchers to make your life easier when you install Launcher on multiple devices or upgrade your device.
  3. More icon customization including circular icons and the ability to create your own custom icons to help personalize your launchers.



Explanation of canOpenURL changes in iOS 9


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.

Continue Reading

Music Launcher now available on the App Store

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.

Launcher Followup and Thoughts on the App Store Review System

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.

Continue Reading

Apps, Apple and the Trust Problem

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

pathSince 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 several incidents 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:

  1. Choose a Facebook Friend
  2. Choose a Contact
  3. 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

pushAnd 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.

nagFor 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.

gruber_twitter gruber_tweet2

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:

  1. 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.
  2. 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.