{"id":32664,"date":"2021-06-01T16:52:02","date_gmt":"2021-06-01T20:52:02","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=32664"},"modified":"2021-09-06T10:17:23","modified_gmt":"2021-09-06T14:17:23","slug":"wwdc-2021-wish-lists","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/06\/01\/wwdc-2021-wish-lists\/","title":{"rendered":"WWDC 2021 Wish Lists"},"content":{"rendered":"

Becky Hansmeyer<\/a>:<\/p>\n

I really enjoy reading wishlists and predictions, so this year I’ve compiled a WWDC 2021 Community Wishlist<\/a>. You’re welcome to contribute, just submit a pull request (or send me a note on Twitter and I’ll add it for you).<\/p>\n

[…]<\/p>\n

Ability for [SwiftUI] views to become\/resign first responder, and to identify the current first responder<\/p>\n

[…]<\/p>\n

TestFlight for Mac<\/p>\n

[…]<\/p>\n

For Apple to chill out and allow apps like Riley Testut’s Delta<\/a> emulator to be installed on iOS devices in some sanctioned way (remember, emulators are not illegal)<\/p>

For Apple to chill out and let developers accept payments via some approved processors (i.e. Stripe)<\/p>\n

[…]<\/p>\n

Subscription cancellation API for developers.<\/p><\/blockquote>\n\n

Casey Liss<\/a>:<\/p>\n

\n

Given my constant kvetching about this, it should be of no surprise that the #1 thing I want from Apple is improved documentation.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

The iPad hardware is ridiculously<\/em> powerful. Please, please, can we have\nsome software improvements to match?<\/p>\n<\/blockquote>\n\n

Federico Zanetello<\/a>:<\/p>\n

\n

We saw a lot of new<\/a> SwiftUI<\/a> documentation<\/a> being added during the past year, including some technical articles<\/a>. However, there’s no way to discover when new material is added, beside constantly monitoring all documentation pages.<\/p>\n

[…]<\/p>\n

My wish for this year is to see MetricKit reports not being limited to once a day, allowing reports as fast as the competition.<\/p>\n

[…]<\/p>\n

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.<\/p>\n<\/blockquote>\n\n

Majid Jabrayilov<\/a>:<\/p>\n

SwiftUI provides you both List<\/em> and ScrollView<\/em>, but under the hood, these views still use the UIKit implementation of UITableView<\/em> and UIScrollView<\/em>. I love how UITableView<\/em> works and the API it provides us. But SwiftUI’s List<\/em> and ScrollView<\/em> don’t expose all the powerful features of UITableView<\/em> and UIScrollView<\/em>.<\/p><\/blockquote>\n\n

Andy Ibanez<\/a>:<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p><\/blockquote>\n\n

John Sundell<\/a>:<\/p>\n

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 😅<\/p><\/blockquote>\n\n

Rory Prior<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

Matt VanOrmer<\/a>:<\/p>\n

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.<\/p>

[…]<\/p>

[It’s] time for iOS 15 to finally let Shortcuts power users self-identify as such and unlock the ability to automate any<\/em> shortcut with any<\/em> Automation trigger.<\/p>

[…]<\/p>

The available notification settings on iOS have been lacking for a long time[…]<\/p>

[…]<\/p>

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.<\/p><\/blockquote>\n\n

And, perennially:<\/p>\n\n

Dan Moren<\/a>:<\/p>\n

\n

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.<\/p>\n

Which, while we’re at it, suggests that Apple ought to give us an option to have autocorrect unlearn<\/em> words as well. If the system is going to act as though it knows better than the users, it should actually know better<\/em>. 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.<\/p>\n<\/blockquote>\n\n

Chris Hynes<\/a>:<\/p>\n

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.<\/p><\/blockquote>\n\n

Previously:<\/p>\n