My Top 3 Wishes for WWDC 2022

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!

#3: Importing App Icons in all sizes from One Image

Problem

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.

Solution

When dragging & dropping a 1024x1024 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.

Probability

.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?

#2: App Modularization Support in Xcode

Problem

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 private or 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.

Solution

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.

Probability

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?

#1: New Swift-only Database Framework

Problem

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:

import CoreData

@objc(Category)
class Category: NSManagedObject {
  @NSManaged
  var colorHexCode: String?

  @NSManaged
  var iconSymbolName: String?

  @NSManaged
  var name: String?

  @NSManaged
  var group: CategoryGroup?
}

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!

Solution

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:

import SwiftData

actor Category: PersistableObject {
  @Persisted
  var colorHexCode: String

  @Persisted
  var iconSymbolName: String

  @Persisted
  var name: String

  @PersistedRelation(inverse: \CategoryGroup.categories)
  var group: CategoryGroup
}

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 awaitkeyword, but some magic property wrappers could simplify this to:

import SwiftUI
import SwiftData

struct CategoryView: View {
  @PersistedObject
  var category: Category

  var body: some View {
    Label(
      self.category.name, 
      systemImage: self.category.iconSymbolName
    )
    .foregroundColor(
      Color(hex: self.category.colorHexCode)
    )
  }
}

And writing to an actor property isn’t possible from outside, but the @Persistedproperty wrapper might have some Binding magic to allow this:

import SwiftUI
import SwiftData

struct CategoryView: View {
  @PersistedObject
  var category: Category

  var body: some View {
    TextField("Name", self.category.$name.bind())
  }
}

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 …

Probability

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.

Conclusion

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!