Ahhh, the week before Dub Dub.

Dub Dub is, of course, Apple's WWDC - the annual Worldwide Developers Conference.

There are things that everyone is expecting - a preview of the new OSs, this year's Swift and SwiftUI updates, async used in more of Apple's APIs, and the rumors around iPad OS improvements and AI/ML/Reality related announcements.

As usual there has been a lot of activity in Swift evolution running up to the conference leading us to wonder what we'll see around the reg ex announcements and others.

I'm actually very excited this year. I generally come away pretty happy and rush to update my training materials, books, and apps to include the latest when appropriate. I'm guessing this will be a busy summer for me.

Here are some random thoughts.

Async or swim

I decided last year not to start writing a book on async/await and friends because I didn't feel I understood the issues enough and because I expected there to be more pieces in place this year and more API support.

This may be the year I write it - mainly because even though I still haven't learned my lesson that taking six months to write a book is not a financially sound decision it still is one of the best ways I know to really understand a topic myself.

Look for APIs like the asynchronous ways of making a network call or retrieving images in Swift and SwiftUI.

My favorite async calls, however, are when we register for updates with an async sequence and then we use a for await in loop to respond to changes. Apple does this with checks to your Apple Music subscription and Revenue Cat does this with their APIs for checking on the current app subscription level and they make code simple and readable.

I expect to see a lot more of this style of coding available in Apple APIs this year.

In addition, I'm looking forward to seeing what distributed actors will bring us. There are a lot of possibilities when you have all of these Apple devices speaking the same language on networks near and far. I loved the promise of Jini, Java Spaces (or any tuple spaces), or even project JXTA and have been dreaming about infrastructure like that available on our platforms. Jini, by the way, was a distributed protocol oriented framework that accounted for the unreliability of the network. Java Spaces used a very restricted programming model to do incredibly powerful distributed computing. Imagine what we could do now with a Swift Spaces with the machines we have now.

In addition to distributed actors, we should get more direction and examples from Apple when it comes to actors and Sendable. It might have been nice if there was a beta or experimental flag around the async features released last year. I think some of us adopted them before we really understood what we were doing.

With the async operator libraries that Tony Parker posted about, Apple seems positioned to provide us with async support for many of the things they told us to do with Combine just a few years ago.

That brings me to the next thing I'd like to see at WWDC but don't expect to see.

Guidance

What I want out WWDC is a story comprised of possibilities, practicalities, and a combination of standards and best practices.

For me the promise of what Bonjour could do for me was raised when Steve Jobs' iTunes library was shown on the big screen and Phil Schiller joined him on stage, opened his laptop and Phil's library was visible on Steve's device as well.

Possibilities sparked in the heads of so many of us in the audience. We could share documents and edit them together while each one looked at their own device. Sure, you say, anyone can do that - but this was many years ago when Dub Dub was in San Jose before it went to San Francisco and then came back and then went online and then ...

The practicalities were the APIs we saw in the appropriate Network sessions where we saw examples in C and Obj-C and were walked through the steps we would need to follow to advertise or find a service.

The best practices were found on newsgroups and in sample code and in the public specs which described the mechanism beautifully.

WWDC is pretty good at showing us possibilities and often good enough at showing us some of the practicalities. I'd love to see more of the practicalities and some attention to standards and best practices.

Anytime I've asked for guidance I've been told, "we don't know the standards or best practices yet - it's too early."

To me, this is like tabs vs. spaces or what line a closing brace goes on. Even if I have an opinion, I'd much rather we were consistent than that I got my way.

And I'd much rather that we get some standards and that it change than that we get get nothing at all.

Remember when enum cases started with an uppercase letter and then it changed? We changed because that was the new standard.

Remember when we used to put spaces on either side of the colon in certain situations and then we didn't? Again we changed because we noticed everyone else changing around us.

I loved Erica Sadun's book on Swift Syntax but she never should have had to have written it. It was a developer's missing manual because none shipped in the box.

There have been many changes to the Swift language - I would love to see some updatable publication from Apple with bite size snippets of advice of standards and best practices that is consistently updated. Next week, for example, it would have the new if let foo syntax.

For SwiftUI, I would like to see best practices for navigation and architecture. We've clearly made great strides in the past few years with the disappearance of the Info.plist and the App Delegate - what are the best ways to structure an app.

I loved Paul Hudson't detailed description of SwiftUI lists, but again this was a missing manual.

I hold up the sessions from the SwiftUI Data team as examples of the type of sessions I find invaluable. They are well thought out - and the advice or at least the level of details about the advice has changed over the years. I have a much deeper understanding each year than I did the year before.

Every session that shows code on the screen should provide us with the code sample it came from and that code should be available on the day that the video is posted. There have been sessions where they showed us code that depended on code they didn't show us and never showed us so we couldn't recreate how something was done.

Think of the number of people watching these sessions and imagine the problems that could be eliminated if we had working code that illustrated what was being demonstrated.

Playgrounds 4 allows us to write working code on a Mac or an iPad and can contain descriptions that walk us through different scenarios. Apple could show us that they really believe in this platform and format by providing Playgrounds 4 walkthroughs that accompany say even one third of the WW sessions.

WW can be overwhelming. There's so much to learn. I've long wanted a weekly 3 minute video that presents a short tip or topic and then links to the WW session. These could start rolling out in August as we get closer to the OS releases. It would help point us back to these fantastic sessions later when we need to revisit them or see one or two we missed. It might be nice to hear short ten minute audio podcasts with the engineers explaining the why's and when's of some of these APIs. I know that I've benefitted every time I hear someone from the Swift Core team appear on someone else's podcast. Apple should produce audio and video developer centered podcasts to clarify and give us guidance.

Previews

So I'm working on a SwiftUI project and I add a property to a View or I change a property's type or I add a custom init.

Now the build is broken because the preview doesn't work because the preview is creating an instance of the View to display it.

So I do what anyone who just wants to work on their app does, I comment out the preview code.

Now the app builds and runs on my device or in the simulator and I go on to work on the next thing. I never remember to go back and uncomment that preview.

Or maybe my preview is for a view in a view hierarchy where some view up the tree has an environment variable that some view down the tree needs. My current view doesn't need this environment object so I don't have to import the module where the environment variable's class is defined. My app builds and runs fine.

But not the preview.

The preview needs me to add the environment object which means I have to import that module - not for my shipping code but for my preview.

I think previews needs to take some inspiration from testing.

The preview code should be in separate files and use the naming conventions that Xcode currently provides. With this naming convention the preview for Foo.swift (a View) would still appear with that file if available even though the code for the preview would be in Foo_Preview.swift.

Command-B and Command-R should build and run the production code while some other command should build the previews - maybe the Resume key and corresponding keyboard shortcut.

Just as a broken preview should never break the build, it would be nice if we could preview a view even if some other portion of our app didn't compile so long as that other portion is not used to present this preview.

It would be nice to have analogues to the .constant() that we use to stub out @Bindings so that we can mock or stub out Core Data objects just to preview them.

Just as @testable exposes things for testing maybe we need an @previewable which we can use to import modules needed only by the preview.

Anyway, I really like the preview feature but there are too many reasons to work around it or turn it off and then forget to turn it back on.

Misc

This has somehow transitioned from a "what I expect" to a "what I would like" post.

I've used Core Data in two of my apps this past year. One is shipping and one is in test flight.

I found myself using patterns to essentially isolate Core Data from the rest of my app. I would still love to see Apple release a Swift friendly Swift Data with actors and some of the same declarative style in the persistence layer that we use in the view layer.

I don't expect that they will - and if Core Data is around after this WW, I may release a short book on how I use it.

I just did a rewrite of my simple Dough temperature app and I use Swift packages for each module. I really love Swift packages and separate modules.

This is going to sound silly, but the thing I miss most from Obj-C is the explicit import of header files. I like being able to explicitly see dependencies and to have it be apparent when I have two things that each depend on the other.

Separate modules lets me better isolate units of functionality and see explicitly what depends on what.

They let me see which packages I must minimally add to my project and watch as the dependencies are loaded automatically.

Unfortunately, I cannot declare a package to only support a specific platform. I can declare a minimum platform support but if I say that the platform is only .iOS("15.5") that doesn't mean what I think it does.

I thought it meant that to use it your target had to be iOS 15.5 or higher. So if you want to include it in an iOS 15.4 you'd get an error.

It does mean that.

I also thought it meant that it wouldn't work on macOS since I didn't include macOS in the platforms.

It doesn't mean that.

So now I get errors that navigation bar and other related things aren't supported in macOS. So now I have to pollute my iOS only application code with #if os(iOS) and #endif even though the whole thing is iOS only.

Again, I'm loving Swift Packages but I'd like a way to specify in the package platforms that I don't care to support.

Another tiny thing is VIM support in Xcode.

When Xcode and Nova added support for VIM I finally decided it was time to learn the editor.

As pretty much everyone predicted, I found myself liking VIM but missing the things (like ".", search, visual mode, ...) that weren't part of Xcode's implementation. I would love to see them round out the support as it's a constant reminder of what's not there.

Other than that, I'm looking forward to better understanding async and for SwiftUI enhancements and additions.

Whining about these things just serves to point out how generally happy I am with Swift, SwiftUI, the Dev tools generally, and developing for Apple platforms.

That said, let's finish with a trivial observation.

What the "L"

When I worked in radio we had to say the station's call letters at least once an hour. Often we said it multiple times each time we opened the mic.

"W D M T - more music and less talk - continuing our F M 1 0 8-in-a-row with The Gap Band on W D M T."

Two "W"s in under ten seconds.

And so we learned to say "W". It was "double-you" not "dubba-you". Believe me, we had aircheck sessions where we were critiqued on everything we said and how we said it. We couldn't dwell on the "l" in "double" but we couldn't skip it either.

Stations east of the Mississippi almost all began with a "W". For stations that only had one you could soften the "W" and go on to hit the rest of the letters harder. That helped. But in Cleveland we had WWWE and WWWM. Most of the hour they were "three double-you e" and "M 1 0 5" but the on air staff or a recording would have to say "double-you double-you double-you" at least once an hour as part of the station id.

I say all that to make the most trivial dub dub comment of all. It bugged me and probably only me to hear the Apple promo for the conference say "Dubba-you Dubba-you Dee Cee". Either say "Dub Dub" or "Double-you" but no "Dubba-you."

I can remember sessions for clients where they didn't like one particular "s" in my read and asked me to retake the entire commercial. As I said, this bothers me and no one else.

To be fair, I have a slight speech impediment that you likely have never noticed - but once you notice it you'll never be able to not hear it. My wife was a speech therapist so of course she heard it.

Man, I've turned into that crabby old guy.