My WWDC21 Wishlist
With WWDC21 less than a month away, this is a period of hope and excitement for Apple developers worldwide.
Every one of us has a long list of things we'd like to see announced, and probably an even longer list of Apple feedbacks that we cannot wait to close.
In this article, let's take a look at some of my wishes for this year's WWDC.
Floating panel component
From left to right: A floating panel in the shortcuts.app, stocks.app, find-my.app, maps.app.
If Apple gave me a magic wand and told me that I could make just one change, releasing an official floating panel UI element would be my pick.
Drawer, Floating Panel, Bottom Sheet are just a few of the names going around, this is a component heavily used in many stock apps (see screenshot above), it's very user/thumb-friendly, and it's making ways in many third-party apps as well (including my own).
Apple already has a component named
UISheetDetents for this. However, it's not public.
This element is tough to get right. There are several attempts out there, out of which
FloatingPanel is the best one.
Having a native, standard floating panel would be incredibly beneficial:
last year we saw the consolidation on how multiple column layouts look/work/behave. This year I really want to see the same for this element.
A way to "follow" Apple Developer Documentation updates
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.
Last year we obtained a feed RSS for the Developer News: maybe this year we can get another feed for the rest of the documentation?
Automatic dark/light appearance switch based on ambient light
The Books.app has been doing so even before Dark mode was announced two(!) years ago. While there are third-party tools doing this, having this functionality baked in with the rest of the system settings would be fantastic.
System HUD(s) access
Image from Custom HUDs in SwiftUI
HUDs are one of these system components that every app needs to use at some point. Instead of reinventing the wheel over and over, it would be great if we could access the system's one(s).
Having access to system HUDs would guarantee apps to look more familiar, consistent, make them more accessible, and require way less work to third-party developers.
Health.app on iPadOS/macOS
Apple's health efforts have been announced back in 2014 with HealthKit and the Health app:
from that point on, every year Apple's health capabilities broadened more and more, mainly pioneered by the Apple Watch.
While having access to all of this data on the phone is incredible, overviewing trends or stats such as resting heart rate, walking pace, etc., would be more valuable and productive on a bigger screen, especially when comparing large intervals of time.
More proactive Apple crash reporting
Until recently finding out about app crashes meant one of the following:
- opening Xcode's Organizer and download the available data from there, if the developer ever remembers to do so.
- use a third-party framework/service.
Two years ago Apple announced MetricKit, a new system framework allowing app developers to collect their app diagnostics once per day per user, allowing faster reporting.
This is not yet as real time as getting a new crash report via email (almost) as soon as it happens, like other third-party SDKs/services nearly do, but it's a step forward. My wish for this year is to see MetricKit reports not being limited to once a day, allowing reports as fast as the competition.
Xcode localization sanity checks
App localization is a must-have for the best user experience:
it's probably impossible to guarantee at build time that our app will only use localization strings, however having some sanity checks would be most welcome.
For example, if all but one
.strings file provides a
"home_title" = "..."; localization, triggering a warning would probably be the right thing to do.
Instead of these sanity checks being an extra build phase, they could be added as an external CLI tool, or triggered from time to time via an Xcode menu.
A more proactive Feedback Assistant
Currently we get a new email when an Apple engineer replies to a feedback of ours. However, we don't get notified when other feedback's statuses change (e.g., resolution, number of similar reports).
The only way we have to find out if anything has changed is by manually opening each feedback again, potentially discovering an update many weeks/months later, if ever.
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.
It's a small thing, but it'd help developers know their feedback has been received, and encourage them to use the app more, thus submitting more feedback.
Lastly here's a small subset of my SwiftUI wishes:
- a new view similar to CSS's Flexbox (e.g.
HStackwrapping into multiple rows) (FB9100345)
- a way to access to and act upon a view proposed size (FB9100350)
- have a native modifier to read a child view size (FB9100353)
- have access to
ScrollView's offset position (FB9100361)
ScrollViewpull to refresh (FB8506858)
- first responder control (FB9081556)
- more keyboard input types, e.g. date and picker (FB9079186, FB9079187)
- a navigation revolution (FB8722348, FB8910787, FB8997675)
Stackview that can switch axis via parameter (FB9061954)
- a way to snapshot SwiftUI views without having to go through AppKit/UIKit (FB9100363)
- proper device landscape orientation for SwiftUI Previews (FB7636362)
- native share sheet support (FB9088885)
Textview modifier, which returns another
There we go! Most things are way easier said than done: I'd consider it a massive success if even 10% of these nearly 25+ wishes were to become true.
If my list has something that you'd like to see as well, I urge you to please submit a feedback to Apple: this is the best way to let their teams know. Thank you!