With Apple announcing WWDC week for June 6–10 this year, let’s dive into what new frameworks, APIs, and tools I hope to see unveiled and what using them might feel like with examples.
Each year, there’s this very special time, when a specific group of people is making wishes and getting their hopes up for all sorts of things. Some share their wishes with others, some just keep them secret in their heads to not get too disappointed if not fulfilled. I used to be in the latter group, but this time I’d like to share my wishes to improve the probability of them coming true — if not this year, then maybe the next. After all, Santa might be listening.
I’m going to skip any of the obvious topics that are on top of almost every iOS developer’s list, such as a more stable Xcode, a more bug-free Swift, a more complete SwiftUI, or more reliable SwiftUI Previews. Let’s get started!
Every app is required to have an app icon. Xcode requires us to provide the app icon in dozens of different sizes though, without any support to resize them. While there are many apps & tools to help get there, only a few of them support the latest set of sizes as Apple likes to add new sizes over time. This is an unnecessary obstacle for new developers just starting.
When dragging & dropping a 1024×1024 image to the
AppIcon set or the
App Store entry inside of it, Xcode should ask us if we want to use this as a reference image to generate all other sizes from. The same might also happen when dragging & dropping an SVG file, although I would already be happy with the 1024x sizes one.
An alternative to drag & drop could be an option on the right pane when selecting the
AppIcon image set named something like “Generate sizes on archive” so you always only need to provide and even commit one size and Xcode would generate the others on the fly when archiving for a release.
.xcassets were introduced alongside Xcode 5 in 2013. They haven’t received much love since then, so I doubt this is ever coming. On the other hand, Swift Playgrounds on the iPad does seem to be able to generate all sizes from just one “image”. While this might technically work with vector graphics, maybe we might see this exact same icon generator in Xcode sometime?
Working in app targets with lots of files that are grouped in folders to loosely represent features that belong together is simple but has its drawbacks. For example, to test out the smallest code change, you need to build the entire project. This also comes with SwiftUI previews working less reliably or just taking very long to show your changes. While incremental builds aren’t that slow, in practice you do make changes in other places too and then Xcode has to build more than needed. Or you’re explicitly telling Xcode to make a clean build because, well, somehow Xcode doesn’t behave as expected.
But build times aren’t the only problem of a single-target project. Having all your types in one
main module means that you have access to all types from everywhere because Swift defaults to the
internal access level — this isn’t good as it could make your code harder to reuse and test. And even if you wanted to mark all your properties & functions explicitly with a lower access level, you can’t use
fileprivate As soon as you have to access them from just one other file — it’s also easy to forget to add these.
The current workaround I personally use is explained by Stephen and Brandon from Point-Free in this video in detail. While it fixes both the above problems, it’s a hassle to keep the
Package.swift file updated manually. Just look at this manifest file of my (currently) one-screen only Focus Timer app.
Apple could provide a new UI within Xcode that allows for creating packages for our app’s modules without having to do any workarounds like mentioned above. I think the easiest way to do this is to add support to the existing “targets” UI, but with an extra section for Swift packages and with SwiftPM as the underlying technology. Also, whenever I would reference a type from a module, Xcode could warn me that I’m accessing an inaccessible module and ask me if I wanted to add it as a dependency to the current module.
This could even go so far that Xcode might ask us if we want to create an Xcode project-based app or a SwiftPM based one. While I don’t expect (or request) a full replacement of the
.xcodeproj file with a
Package.swift file this year (there’s still some work to be done in SwiftPM for that, like adding build scripts, etc.), I think it is possible to at least migrate over the linking of packages to a SwiftPM based foundation.
As much as I’d like to see this year, I think Apple isn’t going to do much in this direction until SwiftPM is ready to fully replace
.xcodeproj files. I think they’re “all or nothing” in this area, so I don’t have my hopes up for this year. But maybe next year with a beta flag to opt into?
Core Data was introduced by Apple in 2005 alongside Mac OS X 10.4 Tiger as a way to provide developers a nicer API than using SQL directives. Quickly it became the go-to database framework for native app development, and it still is. But it was written for Objective-C, clearly. Just look at this simple model:
Note that all these fields are specified to be non-optional in Core Data:
But they are all generated as
Optional types in swift code anyhow. This and the whole
NSManagedObjectContext API design feels quite outdated and not very “Swifty” (as in “not safe”). It’s time for something new!
Apple could introduce a new Swift-only framework (like
SwiftUI) named something like
SwiftData which provides a high-level API to define and manage persistable models. Defining a model could look something like this:
For models to store in iCloud, you’d need to prepend
distributed in front of
actor. Normally accessing any property of an
actor would require the
await keyword, but some magic property wrappers could simplify this to:
And writing to an
actor property isn’t possible from outside, but the
@Persisted property wrapper might have some
Binding magic to allow this:
I have to admit, I have not used Actors in practice yet, so forgive me if some of the above examples don’t make any sense. But I have a feeling that Actors could play an important role in a
SwiftData framework for safe access.
Additionally, Xcode could come with a UI that makes it easy to version data models and provide a graphical migration tool that could be written in a declarative Swift syntax and be previewed as a UML diagram on the right (like SwiftUI previews). But maybe I started dreaming too big here…
Many were expecting this already for the last two years because it’s a logical next step after SwiftUI. But this year, with Actors already shipped in Swift 5.5 and Distributed Actors (for iCloud support) being accepted just recently as well, the technology might just be ready to ship the first version by September.
There are lots of things Apple could announce in June, and the above are just my personal wishes. But in the past, I was always surprised by at least one or two frameworks entirely, like SwiftUI in 2019, WidgetKit in 2020, and DocC in 2021. What will it be this year? I can’t wait to find out!
Want to Connect?Follow me also on 👾 Twitch, on 🎬 YouTube, and on 🐦 Twitter.
Note: The 2nd part of my “Streaming on Twitch” series is postponed to next week.