WWDC 2021 Wish Lists
I really enjoy reading wishlists and predictions, so this year I’ve compiled a WWDC 2021 Community Wishlist. You’re welcome to contribute, just submit a pull request (or send me a note on Twitter and I’ll add it for you).
[…]
Ability for [SwiftUI] views to become/resign first responder, and to identify the current first responder
[…]
TestFlight for Mac
[…]
For Apple to chill out and allow apps like Riley Testut’s Delta emulator to be installed on iOS devices in some sanctioned way (remember, emulators are not illegal)
For Apple to chill out and let developers accept payments via some approved processors (i.e. Stripe)
[…]
Subscription cancellation API for developers.
Given my constant kvetching about this, it should be of no surprise that the #1 thing I want from Apple is improved documentation.
[…]
My money is on Combine being neutered — if not straight-up scuttled — by an over-zealous SwiftUI champion, politicking within Apple. I surely hope that isn’t the case, because a rising tide raises all boats.
[…]
The iPad hardware is ridiculously powerful. Please, please, can we have some software improvements to match?
We saw a lot of new SwiftUI documentation being added during the past year, including some technical articles. However, there’s no way to discover when new material is added, beside constantly monitoring all documentation pages.
[…]
My wish for this year is to see MetricKit reports not being limited to once a day, allowing reports as fast as the competition.
[…]
It would be great if Feedback Assistant would send notifications/emails when any new update occurs, not just when there’s a new reply to a feedback.
SwiftUI provides you both List and ScrollView, but under the hood, these views still use the UIKit implementation of UITableView and UIScrollView. I love how UITableView works and the API it provides us. But SwiftUI’s List and ScrollView don’t expose all the powerful features of UITableView and UIScrollView.
Unfortunately, as it has been the case for many years now, there is not really much you can do when you attempt to integrate with the settings app as it is now. You can create a Settings bundle, but it is all managed by a plist. You cannot have any more complex settings that would allow users to login to dedicated service accounts or do anything else remotely complex.
[…]
SwiftUI is my favorite framework introduced in the past few years, but when it comes to debugging issues with it, it can sometimes be more complicated than I’d like.
[…]
Fast forward to iOS 14, and Apple introduced a new widget system. While I love these widgets and actually use them constantly, they are mostly info widgets and you can’t do much with them. Shall a widget be able to perform actions, they will launch the app. You cannot do much with them.
I’ll post a detailed #WWDC21 wishlist article next week, but honestly, if we only got a new version of Xcode in which Swift syntax highlighting, error reporting, and auto-complete always worked fast, accurately and predictably, I’d be more than happy 😅
If literally the only thing to come from WWDC this year was a fix for Xcode so autocomplete didn’t randomly fail every day I’d be so happy.
I’d take a redesign of the Home app as a start — so much potential, all locked behind a mess of tiles, rooms, zones, scenes, and painfully limited automation options.
[…]
[It’s] time for iOS 15 to finally let Shortcuts power users self-identify as such and unlock the ability to automate any shortcut with any Automation trigger.
[…]
The available notification settings on iOS have been lacking for a long time[…]
[…]
As it stands, initiating an Emoji search requires you to tap two buttons to escape back to the typical QWERTY keyboard: one to close the Emoji search by opening the Emoji keyboard, and once to swap from that keyboard to QWERTY. This confusing dance is extremely unintuitive (why would I click the button covered in Emojis when I want the opposite?), and could be solved with something as simple as a small “X”-to-close button tucked into the Emoji search UI.
And, perennially:
The fix seems straightforward enough: allow users to add words to iOS’s dictionary so they can stop fighting with autocorrect. Whether this takes the form of a contextual popover menu, a section somewhere in Settings, or somewhere else entirely doesn’t particularly matter—the important part is giving the control to users, rather than some obtuse machine-learning algorithm that already seemingly likes to replace real words with non-words.
Which, while we’re at it, suggests that Apple ought to give us an option to have autocorrect unlearn words as well. If the system is going to act as though it knows better than the users, it should actually know better. Or it should let us flag words and terms that we don’t use and remove them from the iOS dictionary at well. Let us make our mistakes, instead of having them made for us.
While auto-correct frustrates every iPhone user at one time or another, I imagine it’s an insanely complex feature to get right. After using it for 13 years now, I find that I have a list of small things I’d love to see change rather than a few number of really big changes.
Previously:
- Whitelisted Developers
- Where Is TestFlight for Mac?
- On Apple’s Piss-Poor Documentation
- WWDC 2020 Wish Lists
- iOS 13 Autocorrect Is Drunk
Update (2021-06-02): Jason Snell:
One feature that the Mac desperately needs from iPadOS is, believe it or not, Shortcuts.
[…]
I’d like to see the ability to run iPhone apps on macOS. Yes, they’re small, but so what?
[…]
I’d like to see someone from Microsoft appear on Apple’s virtual stage to explain that Windows for ARM will run on Apple silicon, even if it’s just in a virtual environment. Support for Boot Camp would be even better but seems a lot less likely.
[…]
I know it’s pretty rich for me to conclude a long list of demands by making this point, but I’m serious: The single most important addition to macOS this fall should be a focus on stability and reliability.
Update (2021-06-04): Craig Hockenberry:
Here is my anti-wish list - things I do not want to see:
More multi-tasking gestures in iPad OS. Make multi-tasking spatial, or make it stop. I hate user interfaces that are driven by guessing.
More features in macOS that I’ll never use. It’s great as-is, just fix bugs and everyone will be happy.
More Siri improvements that have nothing to do with parsing my commands.
9 Comments RSS · Twitter
No new security stupidities. No further extra work. A sane version of Music that wasn't made by developers out of primary school.
I just want macOS to be a crown jewel again. Elegant user interface designs that solve problems, native, non-Electron applications I can be proud of, and quality assurance and fit and finish that is the envy of the rest of the industry.
Actual documentation. Not minimal "doxygen" type comments. Or source code. And actual hardware specs.
Apple: "Your iPhone has LIDAR for low light photography."
Developer: "Ok, so what's the resolution?"
Apple website: "Your iPhone has LIDAR for low light photography."
Developer buys and uses IR camera in a physics experiment.
Developer: "What about the range?"
Apple website: "Your iPhone has LIDAR for low light photography."
Developer spends a couple of days coding and performing more physics experiments.
Developer: "Come on tell us something!"
Apple Documentation Engineer: "You don't need to know. Use our framework" https://developer.apple.com/forums/thread/131013
Developers: GAAAHHHH!
For whatever it's worth, we've recently done some LiDAR testing on sensors from Garmin and Benewake, and results — even on regular terrain — were sadly well below manufacturer claims.
Just think of Apple's range as 0m. That way, you'll be positively surprised!
Interesting, Sören. Problem is clients buy the magic Apple sells (not the products, just the woo-woo): It's an iPhone... it must be good! I've heard though that the Galaxy Note 10's LIDAR might be better.
Yeah, I get that.
Apple: here's a LiDAR!
Devs: Cool! Can I use it to measure the distance to… another building, maybe?
Apple: of course!
Devs: so what's the range? 10m? 30m? 80m?
Apple: …let's not talk about specs :-)
Dev: …???