June 8, 2020
One of those memories popped up in a social media feed reminding me of where I was and what I was doing three years ago.
It was a picture of badges for the week from WWDC 2017, Alt-Conf, the CocoaConf Next Door conference, and a staff pass for the James Dempsey and the Breakpoints show.
In addition to the badges were the not-pictured receipts and memories from so many coffees, dinners, lunches, walks, and conversations with friends, colleagues, and people I was just meeting for the first time and would soon consider friends.
I'm so old I remember going to WWDC in San Jose before it moved to San Francisco. Back before it sold out. Back when there were "meet the team" sessions where attendees could line up at a mic and ask questions. Heck, I'm so old that I remember when Apple had a Java team there running one of those sessions.
If you went as an attendee, months later you would get disks in the mail with videos of the sessions. In those days that was a big deal to produce. Not only did someone have to record the audio and video of the sessions but they had to somehow mix it with the slides from the presentation decks.
The conference moved to San Francisco and the vibe changed. The keynote was streamed and suddenly the keynote wasn't for us developers anymore.
In a way it never was. That was the only session the media was allowed in to. In the old days the media was escorted out after the keynote. I also remember contracting at some big companies where the VPs would have WWDC passes so they could attend the first day and see the keynote and maybe the state of the unions and then head back to their companies for the week letting their ticket go to waste.
But once the keynote was streamed, it definitely wasn't for developers anymore. Oh sure, there's stuff for us - but we're not the prime audience for it. Really do we care about demos of iPhoto templates or memoji's?
So, when Apple announced they weren't cancelling this year's WWDC that told me that they're going to put a lot into delivering a first class keynote.
I love Apple keynotes.
There are always the moments that make me smile and always at least one moment that makes me cry. I expect both this year.
One other thing about Apple keynotes - you don't always know what they're hinting at for the future but you can always look back and see that they were preparing us for where they were heading.
Here are a couple of thoughts on what else I'm hoping to see this year.
I've spent the last year playing with, teaching, and presenting SwiftUI. I'm a big fan of what it is today and what it can be. It requires that you rethink about how you create and communicate with your UI.
Also, if you look back at the famous Crusty talk on Protocol Oriented Programming you can see many of the ideas that SwiftUI embraces in Dave's portion of the talk. I'm not saying that Dave was talking about SwiftUI in particular. I am saying that many of the foundational ideas are there in that talk.
So any way, clearly SwiftUI wasn't finished. It was good enough to get going but not finished. You could feel that it grew out of something for watchOS. There are some things that feel like they're missing.
One of the main things that we got outside of SwiftUI last year was diffable collections and improvements to UICollectionView. We don't have either of those in SwiftUI. I was reminded of this by a great post by one of my favorite devs - Drew McCormack. He's launched his new blog with the post Why TextView is my SwiftUI canary. This model for a view which requires less rebuilding of the UI extends from TextView to List to (if we get it this year) a Collection View.
I would love some of the sharp edges smoothed in the way we write SwiftUI so that it feels like part of a comprehensive whole.
I'm hoping that in this year folks at Apple who ship Apps have used SwiftUI in anger and felt some of the issues we feel and have addressed those - in particular using it for large apps with lots of data and complicated views and navigation.
Again - this is not a complaint. Last year was a first release.
Oh - and I don't care if these changes are source breaking changes. Last year was a first release. One of the things that has made Swift so much better in its lifetime is that they were willing to break it repeatedly in the first few releases.
Also, one of the questions I'm asked most often is why isn't @State available outside of a SwiftUI View struct. @State is a brilliant hack that allows us to treat a value type property in a struct as if it were a reference type. I also don't understand why an @ObservedObject changes from a let to a var. You're getting a signal that this thing that the variable points to is changing. The thing you're holding on to isn't changing. Anyway, I guess what I'm saying is that the things that require you think differently about them in SwiftUI than in the rest of Swift feel odd because of that fact.
Of course we expect the compiler team to make SwiftUI faster, more robust and easier to debug.
I've been sorry not to see the Function Builder proposal again. I know that there's been a lot of progress on it and I appreciate Doug's updates.
I assume that the community reaction from last year when the Function Builder proposal appeared in the forums at WW means we won't see it the same time this year and that makes me sad. I really want this to become more than an experiment. I think Function Builders and Property Wrappers are huge for our platform and can't wait to see what FB will actually look like.
For SwiftUI I hope to see changes, additions, and code-breaking improvements. For Combine I expect to see more integration with Apple APIs, additions, refinements, and some rounding out to provide some of the things the community has been creating on the side.
It would be nice to have align not strongly retain self unless we want it to.
I would like to see more sessions on Combine that use more than small code bits where the publisher and subscriber are in the same file. I'd like to get more of an idea of when you use a given operator as opposed to doing processing further down the pipe.
Oh - that brings me to ...
Sample Code and Docs
There used to be a fair amount of sample code after WW so you could see how to implement certain things. Last year there was almost no sample code available. In addition, a lot of the existing sample code is aging out. I recently looked for some AVFoundation code and the project hadn't been updated in long enough that it wouldn't run in Xcode 11. What happens as we move away from UIKit and AppKit (and the ObjC of 4-5 years ago) and these projects no longer build.
For some reason Apple has moved away from Programming Guides. These were hugely helpful for doing more than the intro demo. The cute intro SwiftUI Tutorial was fine but left you with a "then what"? And there were no docs for the "then what".
I love Paul Hudson, Erica Sadun, and John Sundell, and others - but a lot of what they (and I) write about are because there aren't the relevant resources from Apple Dev Pubs.
As painful as this was last year, it will be much more of a problem if we don't have significantly more up-to-date docs, tutorials, programming guides, and sample code this year with a remote WW and with a presumably shorter time between WW and the OS release.
And, I would add, there is no excuse. I can name literally dozens of talented developers with great communication skills who have a great deal of time available because the conferences they usually present at are cancelled, the contracts they usually work on have scaled back, or the jobs they usually work at aren't there anymore. Dev pubs could have staffed up with contractors to produce the docs they need and to update and produce sample code. This was and is a unique opportunity to knock this out of the park.
Xcode made great changes last year. These last few years have seen great improvements to the tools. The editor has improved, the error reporting is better, the package manager, the support for the SwiftUI preview...
I expect the improvements to Xcode to continue. It still freezes on me way too much although I don't need to relaunch projects or playgrounds nearly as much as I used to.
I still prefer Xcode playground to Swift Playgrounds - but I still would like both to be more of a, um, playground. I've always wanted "kits" in playgrounds so that newcomers can experiment with cool APIs without having to know deep calls.I want wrappers or simple high level APIs for kids and adults to come to our platform.
I think Function Builders can help here.
Look at how easy it is to create a VStack containing a Text, a Picker, and a Button appropriately styled and spaced. Think of what is possible with higher level APIs supporting Function Builders that allow you to build Sprites and Worlds.
We've been getting updates to AR and ML each year and this year there should be more. Maybe there will be a new cool framework to think about this year or - now that differentiation is added upstream in Swift - better integration with TensorFlow. I have no idea what to expect here.
I think the hardest thing to navigate this year is tone.
This is such a hard moment in time. In the US alone we have more than one-hundred thousand dead from the Corona virus and many of us have been working from home (when we can find work) for months.
We're witnessing and participating in protests for rectifying racial inequities while working in an industry that doesn't employ nearly enough women and minorities at high levels.
Forget about the keynote. Forget about the state of the union. What tone will Apple take in the developer sessions.
We don't need to see the developers - there were years when the WWDC videos were just voices over slides and demos. This year that would be fine.
You know how now you see a tv show where a character comes in and they all shake hands and sit way too close. It looks wrong.
If I see professional video of developers presenting, I'm going to wonder who else was in the room capturing the session. Who sat together to edit and produce the session. I hope that the developer sessions are produced with care for the presenter and the crew.
I don't envy Apple's job in finding and hitting the right tone. I hope they manage it well.