This year's list of things that should be announced at WWDC... but won't be.
Extensions were introduced for Xcode in 2016 and Swiftly went by the wayside. It's nice to automatically generate code, but extensions should be able to do more.
Consider the case of Plists. When we edit a Plist we are using an editor wrapped by Xcode to modify a file that is guaranteed produce an XML file conforming to the specification of a plist. All of the validation and error checking needed to produce the file is performed by the editor.
Those same capabilites should be available for JSON, YAML, or any of a host of other types. Rich type file extension editors are a useful enhancement to the Extension system. We're already use to them, be it in the form of Plists or Asset catalogs or Core Data models.
Taking it further, Source Kit is wildly knowledgable about the state of our code base.
Combining that knowlege with an extension would allow for the creation of complex behaviors not necessarily best left up to source code.
State machines, in particular, are useful, but can become unwieldly as they approach full feature.
Instead of implementing a full state machine, and testing it, an extension could import a StateMachine library.
Then we would use a GUI to define the edge and nodes in a manner similar to Core Data Models.
Since the library is, presumably, tested extensively by the publisher, we now have the ability to produce complicated interactions within our application with far less code.
Since 2014 I've been saying that Swift should run in the browser. Ever year I have a better understanding as to why it doesn't... yet. Based on where Swift 5.5 is I dont expect it to happen this year.
Nevertheless, I will continue to die on this hill.
Xcodegen might be the most useful open source project I've ever discovered. And I didn't discover it, my senior did. It's wonderful. The number of Xcode Project merge conflicts since we started using it: 0
The idea that Xcode should build up the project from a few settings in easily readable text files is incredibly valuable. Swift Package Manager has adopted a few of these traits, but not to the level that Xcodegen has. Xcode should.
There are several solutions to implementing dynamic fonts in your custom font of choice. Those solutions omit the Mac due to a lack of API support.
It's not even that it's terribly hard. I'm just tired of having to do it.
Fonts should be supported as Asset Catalogs that specify a font type with sizes for the various standard TextStyles.
This is the thing I think we might actually get.
By adding Fonts as Asset Catalogs there would be a point of abastraction for both UIKit and AppKit to work from.
The only joy in my life as an Android developer is Gradle. The build system is so nice that I've started using it in for my iOS projects. If I want them to last, that is.
There should be a Swift equivalant for iOS Developers.
I'm aware of Bazel and I take issue with a number of implementation choices that were made.
Mocking network calls is a standard piece of testing your application. Yet if you ask 10 developers you're going to get about 7 different answers about what the "right" way to test them is.
It becomes particularly bad when you get to UI tests.
Ultimately, the correct answer is "Don't not test". But that's not particularly helpful advice.
As Apple has a lot of control over the simulator and what processes can communicate with it, it feels like they're in a good position to provide a well baked solution.
It took a long time for me to to get to Presentation Model. You might know it as MVVM. But now that I'm there, I'm there.
As it stands, SwiftUI doesn't have strong sense of support for the Presentation Model.
The SwiftUI View protocol maps nicely.
Any number of objects can serve as model.
A Presentation Model is still lacking in Swift UI as a defined type from Apple.
An Apple baked solution to binding the View to the Model via a Presentation Model seems due. At the very least I think we should expect a talk about it at WWDC.
As I'm a betting man, I'm going with "Presentation Model" over "ViewModel". Microsoft first co-opted Presentation Model as ViewModel. Then Google copied Microsoft. Even if Apple is the last to provide guidance, they don't like the appearance of being a follower. Returing to the source document breaks the branding cycle while presenting themselves as a leader.
There was once a leaked model of a Macbook Pro with cellular in it. If the iPad Pro can have cellular and an M1, why shouldn't the Macbook Pro.
This should be easy.