Gui Rambo’s WWDC 2021 wishlist
Following the tradition started with last year’s wishlist, it’s time to share my top wishes for this year’s WWDC.
WWDC 2020 recap
Before going into this year’s wishlist, let’s recap my list from last year, and see if I got any of my wishes fulfilled between June 2020 and June 2021.
Custom extension points / XPC 🔴
Last year I shared my wish that we as developers would be able to include custom extension points and use XPC on iOS. This unfortunately did not happen, and it still stands as a wish for this year.
Native iOS color picker 🟢
This was just briefly mentioned in last year’s wishlist, but it did happen! Apple released UIColorPickerViewController with the iOS 14 SDK.
Improvements to developer services 🟠
Another one of my wishes was that Apple’s overall offering of developer services would be improved, including App Store Connect reliability improvements, app management directly within Xcode, and more. Some of this did happen in my opinion, especially when it comes to improvements to App Store Connect, which has become a lot more reliable lately.
UIKit components for modern UI paradigms 🔴
This is another one that still stands as a wish for this year, because it unfortunately did not happen last year. There are many modern UI paradigms on iOS that are still not covered by UIKit or SwiftUI, like the famous bottom sheet example that I gave in last year’s post.
WWDC 2021 wishes
With that recap out of the way, now it’s time to check out my new wishes for this year’s WWDC. It’s worth mentioning that these are in fact just my wishes, I don’t have any idea of what’s actually going to be announced at the conference.
TestFlight for macOS
There are more and more apps being released for both iPad and Mac at the same time nowadays, given the advances in Catalyst, SwiftUI, and the ability to run iOS apps natively on Apple Silicon Macs.
A big struggle for many iOS developers who wish to release their apps for the Mac as well is how to offer beta versions to testers, which is something that can be done quite simply on iOS, through TestFlight. There are ways around that, for example by shipping betas for macOS directly, but that requires a lot of setup work and doesn’t have the same integrated user experience that something like TestFlight does.
I understand that there are probably technical challenges with bringing TestFlight to macOS, but I also believe that Apple has had enough time to work out a solution, and I hope that we’ll see an announcement next week.
CloudKit functions
It’s no secret that I love CloudKit, which is Apple’s solution for syncing user data across devices, among other things. But sometimes an app needs to perform a bit of work in “the cloud” that can’t be done by simply storing records using CloudKit, and for those use cases I would love for Apple to introduce cloud functions that developers can write themselves and then call from within their apps.
I would be even happier (and impressed) if we could write such functions using Swift, and perhaps even test and deploy them right from within Xcode. It’s already possible to integrate your own backend with iCloud through CloudKit Web Services, but it’s nowhere near as practical as it would be if we could host our functions directly within the iCloud infrastructure.
Swifty data storage
Core Data is an incredibly powerful persistence framework for Apple’s platforms, used extensively by both Apple and third-party developers. However, it was created back in the Objective-C days, and relies on many features of that language and its runtime which don’t translate well at all into Swift.
With so many new features coming to Swift, including property wrappers and the imminent launch of Swift 5.5 with support for async/await, I think it’s time for Apple to introduce a new persistence framework that feels completely native to Swift and SwiftUI. This new framework could even be powered by Core Data under the hood, but without exposing that to the API consumer, just like how SwiftUI is currently powered by AppKit and UIKit.
Always-on display API
Another API that I would love to see, and I think would make both developers and users very happy, would be one that enables third-party applications to take advantage of the always-on screen of the Apple Watch. Even some of Apple’s own apps don’t really use that feature, with the most obvious example being the Timer app. There are many classes of apps that could benefit from being able to leave some information on screen, but one example that comes to mind is workout apps.
Improvements to UIKit and Catalyst
It’s interesting that, before its introduction, Catalyst was seen as the next big thing® when it comes to development for Apple’s platforms. But at the same year they also introduced SwiftUI, which can also be used to share significant amounts of code between platforms. While SwiftUI does seem to be the future of UI development for Apple’s platforms going forward, Catalyst still has its place for many developers and teams, including within Apple.
Something that almost every shipping Catalyst app has to do is to include a bundle of code that links against AppKit in order to be able to access some Mac-specific APIs for things like window and menu management, since a Catalyst target can’t directly access most of AppKit. It would be great if that limitation could be lifted, perhaps even to the point where UIKit-based apps on the Mac would be able to embed AppKit views within their view hierarchies, for things that just aren’t available in UIKit.
So that’s my WWDC 2021 wishlist! I’ll be super happy if even just a single item becomes a reality, and we’ll know soon, because the keynote is on Monday. I can’t wait to see what’s announced.
BitriseAutomatically build, test and distribute your app on every Pull Request, and use a powerful new suite of add-ons to visualize your test results, to ship your app with ease, and to add crash and performance monitoring to your project. Get started for free.