Every year, Mac and iOS Developers all around the world welcome WWDC with excitement, high hopes, and a long list of wishes that we would love Apple to announce.
Some of those wishes are very humble, like a fix to a radar filed 5 years ago, while others are very ambitious, like the opening of a private framework and much, much more.
I thought it would be fun to make my #wwdc19 wishlist public, without further ado:
This is a given: macOS gained Dark Mode in 2018 and, with Apple releasing Marzipan this year, UIKit apps must gain Dark Mode support. I’m really excited for this new feature and can’t wait to try it out myself.
Apple has done a tremendous job with ARKit. This is probably the framework that Apple is pushing the most, and I don’t expect that to change anytime soon, especially since there are rumors of an Apple AR headset in the works.
One of the main limitations of this framework has been the lack of a native way to enable obstacle occlusion. As seen in the gifs above, this addition is key to maintain the illusion of an immersive AR experience: having this feature offered in ARKit would improve greatly the AR experience for millions of users.
End of Subscriptions Madness
If you follow me, David Barnard, Greg Pierce, or other developers that offer auto-renewable subscriptions in their app, you already know the pain we have to go through: the rules around such subscriptions, particularly regarding the subscription details disclosure, are ever-changing, subject to personal interpretation (inconsisten even within the App Review Team), and by far the main source of constant app rejections. It’s very, very frustrating.
Apple even launched a Subscriptions Human Interface Guidelines Page early this year, however fellow developer David Barnard quickly pointed out that not even Apple’s own examples would pass a real App Review 🙃.
I would love for Apple to end all of this. Thousands of hours have been wasted, between both Apple employees and third party developers. It is beyond nonsensical. Apple’s own apps don’t follow their own guideline, it’s just bad all around.
I’m certain that there’s a legal reason behind all of this, however, since Apple already presents a confirmation sheet where people have to authenticate and approve a transaction, I believe that it would make sense to move all these fine prints in there, too (maybe this confirmation sheet could be a two step process, or something similar).
This way developers could focus solely on the content of the app, while the legal side is taken care of by the iOS sheet.
Alternate App Icons Management
Users can change their apps icons since iOS 10.3.
While this is awesome, the developer implementation is not friendly:
all these alternate icons images must be placed at the root of the app project, which means having tons of
.pngs (one for each size, for each custom icon) just sitting there.
all alternate icons (again, one for each size, for each custom icon) must be declared, one by one, into the app’s
there’s no native way to automate this.
The whole process is very error prone and could be completely replaced by letting developers add alternate icons directly in one assets catalog. As someone with several apps on the App Store, this would make me very happy and make me want to offer way more alternate icons.
Multiple Bedtime Scheduling
One of my favourite introductions in iOS 12 is Bedtime.
I work out three times a week: on the days that I work out, I must wake up before 6am in order to hit the gym and then go to work at a reasonable time. Currently, there’s no way to set two different bedtimes, depending on the day of the week.
Even If I had a more regular schedule, I still would like to have a weekday bedtime, and a weekend bedtime. Again, with iOS 12 this is not possible.
Having the possibility to define multiple bedtimes would be awesome: for the moment, I’m back to normal alarms.
Push Notifications Spam Reporting
iOS 12 brought us great notifications enhancements such as Deliver Quietly, Group Notifications, and a quick way to turn off an app notifications directly from any notification.
These are great ways for users to protect themselves from noisy apps however, this is not the best user experience.
Instead, I expect Apple to notice misbehaving apps (a.k.a. the ones that continuosly push advertisements as notifications) and remove their notifications privilege altogether (maybe only temporarily first, and permanently later, if the misbehaviour continues), don’t ask the users to manually protect themselves, for every device they own.
I completely understand that detecting this behaviour is basically impossible for the Apple Review team, especially since an app could “play nice” when it is in review, and start sending notifications only once it has been approved.
I think we, as app users, could be of great help: as soon as we get an iMessage from a unknown contact, Apple prompts us with an action to report it as junk (see picture below on the left, just under the text bubble).
Apple could implement something similar for notifications, you can see a mock on the image below on the right.
Once Apple receives multiple reports of the same app, then, and only then, an internal investigation is opened and it is decided whether to take further action or not.
- Apple doesn’t need to observe this behaviour during app review (again, apps can act nicely when in review, and start sending spam notifications only after approval)
- Apple doesn’t need to actively analyze every single notification that goes through its Push Notification service.
- We users do the reporting for Apple.
It’s a win-win situation.
Smarter, Self-conscious Siri
My best purchase of 2018 was an HomePod: it feels empowering to simply shout actions anywhere at home and having them executed, especially after I started using HomeKit.
With that being said, Siri still has a long way to go: among the improvements that I would like to see, there’s Siri being more self conscious.
Questions like “When is the next Apple Event?”, “What is the battery on my phone?“ should always have a clear answer. When asked for an action that has to run on a device, I would like Siri (from the HomePod) to forward it to the correct device, not saying that it can’t do that on an HomePod. And other small details like this.
Being able to handoff music from one device to another, a-la “Hey Siri, continue play on my iPad/HomePod/iPhone/Airpods” would also be great.
Lastly, I would like to see Siri improving every week: so far it seems like Siri improves only when a new major iOS release comes out.
Variable Width App Title
Apple does an astounding job to improve iOS accessibility every year: every time I show these features to people, they’re blown away.
One aspect that is not yet very accessible yet is the app title, currently statically defined in the app
info.plist under the
Bundle Display Name key (
CFBundleDisplayName): it can be localized, but that’s it.
If the title is too long, it will be truncated: even if the title is not truncated at the current font size, this doesn’t guarantee that it won’t be truncated when the user set a different font size (see example above).
Since Xcode 10, we have the possibility to use Variable Width Strings, where the actual content of our string varies based on the space available.
It would be awesome if we could use this for the app titles, too.
Another situation where the title might get truncated is after updating the app, or when the app is being tested via TestFlight: this is because of the blue/orange indicator next to the title that appears under these circumstances. While the dot is a nice reminder of the app state (just updated for blue, beta for orange), this indicator actually steals space from the title, which might therefore get truncated.
iOS does an awesome job at protecting the privacy of its users. Want to listen to the microphone? Ask for authorizathion. Use the camera? Ask for authorizathion. Access the photo library? User location? Contacts? Reminders? Ask for authorizathion.
One aspect where apps have been completely free to do as they please is networking: as soon as any app is launched, without the user knowing, said app can start sending requests and data to any server in the world.
Even if the user trusts the developer behind an app, that app might use a framework that does more than what it promises on paper, and both the user and the developer using that framework cannot do anything about it (yet).
In short, Apple could demand developers to disclose which domains their app need to access to, and make sure that any other request outside those is blocked. Felix goes more in detail in his article, I suggest you to have a look there if you’re interested in this topic.
A macOS-friendly Marzipan
Having iOS apps like Home, News, Voice Memos etc on the Mac is way better than no app at all.
However, there are some elements in those apps that don’t have a home on the Mac: the screenshot above shows an example of an option window, very different than anything we’ve seen so far on desktop.
My hope is that the version of Marzipan that we will see released next month will give a chance to developers to make their iOS apps feel and look like native macOS apps (on macOS).
Speaking of Marzipan, I’ve always wanted to access my Health.app data on iPad and Mac, maybe Marzipan will take care of this 🤞🏻.
Obviously these are only a few points, I’m sure I’ve forgotten plenty and, to be honest, I haven’t put much thought on it (I want Apple to surprise me 😁).
I know that many wishes above are easier said than done, as pretty much anything in the sofware world, however a man can dream!
Regardless of whether any of these points will become a reality or not, I’m super excited for next month WWDC and can’t wait to play with all the brand new technologies that we will see!
What do you think? Did I completely miss something? What are your wishes for this year WWDC? Let me know on Twitter @zntfdr 😁.
Thank you for reading and stay tuned for more articles!⭑⭑⭑⭑⭑