Xcode 12 wish list: SwiftUI, iPadOS, and more

With nine months before WWDC20 now is the time to dream.

Paul Hudson    September 20th 2019    @twostraws

Xcode 11 is about to ship as gold master, which means Apple’s teams are already hard at work on future features. Although it’s always nice to have surprise new functionality, it’s also smart to let Apple know what features would make the biggest difference to us, and now – with nine months until WWDC20 – is the perfect time.

So, I put together my wishlist for Xcode 12, and also asked the community what they most wanted to see. Unsurprisingly I was inundated with responses – as much as we love working with Xcode, there are always things it can do better.

Let’s dive in…

Sponsor Hacking with Swift and reach the world's largest Swift community!

SwiftUI or bust

WWDC19 came with lots of massive announcements from Apple, but almost all of them were swept away by the behemoth that is SwiftUI. Although it’s still very early in SwiftUI’s public life, it seems pretty clear this is going to be the future of Apple development – we’re only really seeing the tip of what this technology can do.

So, what could Xcode 12 bring for SwiftUI? Here’s Luis Ascorbe, who helps organize NSSpain:

This view is surprisingly common: iOS 13.0 hasn’t been a particularly great release for developers, and is shipping with quite a few bugs. The fact that iOS 13.1 is already only days away – presumably as close as Apple’s dares to come to a day one patch without incurring a PR nightmare – says a lot about the stability of the initial release, and iOS 13.1 definitely fixes a raft of SwiftUI bugs.

What we don’t know yet is whether Apple will version gate existing SwiftUI functionality. That is, if an app looks a certain way because of a bug in iOS 13.0’s SwiftUI, will that app automatically change in iOS 13.1 or do we need to recompile/resubmit our build? This is particularly pressing because there are actual layout changes in 13.1 – apps literally look different.

Putting early bugs to one side, some folks are missing major features in this initial release of SwiftUI:

Collection views are a particular sticking point, not least because they got such a massive upgrade in iOS 13 with the new composition layout system. I’ve seen a few folks attempt to wrap them for SwiftUI, but it’s proving a slow and complicated process – hopefully this is at the top of Apple’s to do list for SwiftUI 2.0.

Keep in mind that it’s easy to say “oh, why didn’t Apple add…?” But the truth is that SwiftUI has been under production for years at Apple, and a large part of their work has involved figuring out a syntax that works well – while also shaping Swift to make that syntax possible.

More importantly, until recently only comparatively few people even knew SwiftUI existed, and now that it’s public hopefully Apple’s other teams are thinking how they can integrate their frameworks too. So, high on my hopes for the next year are MapKit, Safari, photo importing and more, all getting smart SwiftUI wrappers to make them easier to work with.

Next stop: iPadOS

SwiftUI is great, but how about SwiftUI on iPad?

Getting Xcode onto the iPad has been a popular request for years, and until recently it looked like a pipe dream – can you really imagine Interface Builder on a small screen? No, neither can I.

But with SwiftUI we now have a dramatically simpler, more interactive way of build user interfaces – one that would work great on iPad. Honestly, the thought of me being able to write SwiftUI right on my iPad Pro really sets my mind off in a variety of exciting directions, so I’m really hopeful this is on the cards at some point.

However, as exciting as that is there are other things I think need to be addressed.

For example, the gap between Swift Playgrounds and Xcode’s playgrounds is far too big, and just creates a learning chasm where really there ought to be none. Swift Playgrounds on iPad has stacks of awesome interactive learning material provided by Apple and others (including me!), made possible by the Playgrounds Book system that doesn’t exist in Xcode.

There are a few options here:

1. Apple adds the features from Swift Playgrounds into Xcode playgrounds. This would certainly avoid the naming confusion between the two, but runs the risk of annoying a heck of a lot of Xcode users.
2. Apple does a straight port of Swift Playgrounds to macOS, either using Catalyst or building a native AppKit/SwiftUI release. This would be a massive shot in the arm for Everyone Can Code, and help bridge the gap between Swift Playgrounds on iPad and Xcode on macOS.
3. Apple does an enhanced port of Swift Playgrounds to macOS, then adds some features from Xcode into Swift Playgrounds so the tool becomes even more useful.

Of the three I suspect the second is most likely because it’s the easiest to do – take the existing iOS app and make it work on macOS as a standalone app, with no relation or real dependence on Xcode. It would also allow them to port their entire curriculum across smoothly, which would be great.

However, the last option is where I think Playgrounds needs to be. Can you imagine building SwiftUI apps in Swift Playgrounds? How about sharing those apps with others around you? How about shipping those apps to the App Store?

iOS development is a costly hobby to get into, and if Apple could find a way to help folks learn, build, and ship apps right from their iPad then the cost of entry comes down to $299. Now that is what it looks like when everyone can code.

(And hey, if I’m dreaming: I’d love to see Swift Playgrounds on my iPhone, even if just so that I can run Swift code in a simple editor.)

Tell us, don’t show us

You might think that if you had to choose between making something work and explaining how something works, the latter would be much easier than the former.

Well, no. What should Apple change in Xcode 12?

It’s certainly true that Apple’s documentation has had a rocky few years, and more recently it’s struggled to keep up with the vast numbers of changes in iOS 13.

Almost two years ago I wrote Apple, can we please talk about your documentation because so many pieces of API were still down as “No overview available.” Jon Maddox recently pointed out that even some of Apple’s landmark new features in iOS 13 have suffered the same fate, which is sad.

More recently, I ended up writing How to read Apple's developer documentation, trying to help folks learn how to read comments in headers and more as a way of figuring out how things actually work.

And now we have the final nail in the coffin: SwiftUI’s protocol-based approach has made its API reference almost unusable. The core of Apple’s documentation has always been type names and function signatures, but in the era of SwiftUI that just isn’t working any more.

For example, here’s the documentation for NavigationView. It doesn’t have any examples of actually using the thing, but instead has almost 200 links to everything any SwiftUI view can do – the same list shown by all the other SwiftUI types, leaving you to dig through for things with Cmd+F.

However, Apple did launch a whole new type of documentation: its Learn to make apps with SwiftUI series has been built on top of a new presentation platform that is dynamic, interactive, results-driven, and full of pictures to bring it to life.

While this does little for experienced developers who just want the facts, Apple’s new tutorial platform seems to herald a shift in their focus that must surely reflect experience from Everyone Can Code. This new approach is focused on structured teaching, real-world results, and testing – the way each step ends with a short quiz is simple and smart, and opens up a huge range of gamification options in coming years. My Unwrap app for learning Swift lets you earn badges for learning different parts of the language. Could Apple – would Apple – do something similar?

Again, this won’t sound great to experienced developers who just want simple, searchable text documentation, and it’s true that I find Apple’s SwiftUI tutorials hard to learn from. However, this stuff isn’t written for me and neither should it be – Apple seems to doubling down on helping more folks get into Swift development, which is awesome.

Now we just need to wait and see whether their documentation resources can stretch to cover both new- and old-style documentation…

What is the SwiftUI of Core Data?

SwiftUI forced everyone (including Apple!) to rethink what it meant to build apps, so many folks are wondering what it would look like if that same dramatic rethink were applied to Core Graphics, Core Image, and even Core Data.

Although I know some folks aren’t a fan of building SwiftUI apps using the visual editor, you have to admit that having a visual readout for Core Data would be really helpful.

On the other side of the discussion, I encourage everyone to explore how Vapor handles databases – you define your object types in structs and it creates them automatically. It then provides search, filter, and sorting APIs that lean heavily on keypaths and associated types, making for an extremely Swifty solution that makes Core Data’s @NSManaged classes look a little dated.

While we do have new property wrappers for dealing with Core Data in a slightly nicer way, I’m still holding out hope for a refresh in the future.

The future of frameworks is SPM!

One of the biggest and most important improvements in Xcode 11 was the introduction of Swift Package Manager for iOS. Trust me: it will take a little time for projects to switch over, but I expect in 12 months SPM will be the standard across the majority of projects.

Of course, it can still be improved:

This would do a huge amount for discoverability in SPM, and would certainly help drive up adoption rapidly. In the meantime, Dave Verwer’s SwiftPM Library is an excellent way to discover code and does a great job of filling the gap left by GitHub’s mythical Swift package collection.

Asset catalogs redux

Whether you’re storing bitmaps, vectors, textures, or colors, asset catalogs are the preferred storage mechanism in Xcode. They can get a big laggy, particularly when you have lots of things in folders, but at least they get the job done.

Can they work harder? Of course!

One solution for both of these is codegen, something I had way back on my Xcode 10 wishlist – if asset catalogs compiled down to constants such as Image.logo or Color.primary, not only could that be extended to fonts, storyboards, table view cell identifiers, and more, but it could also be used to create Rahul’s unused assed detection.

Xcode for the world

Apple’s Everyone Can Code initiative continues to advance, and hopefully is finding the success it deserves. But although Xcode offers us a range of tools for localization, it remains one of Apple’s very few applications that is entirely in English regardless of your settings.

Yes, you read that correctly: if you switch your Mac to Spanish / Japanese / Chinese / etc, Finder will update, Safari will update, many third-party apps will update, but Xcode will still show you absolutely everything in English.

Yes, many companies around the world develop software in English because it’s common to see folks working remotely in various countries or traveling between offices, but it’s worth remembering that the largest (non-Apple) conference for Swift takes place in Japan, and is live-translated in both Japanese and English so that everyone can follow along.

Streamlining version control

Xcode already has some Git integration, but there’s a lot of scope for improvement:

“More mergeable IB and project file formats” is a statement that will might cause eye twitches in some folks, because Xcode’s project files can be inscrutable and cause all sorts of merging problems if you aren’t careful.

To be fair to IB, the storyboard XML has improved over time – Xcode used to change storyboards even if you just opened them, which was a real pain.

If we’re talking improved Git integration, would it be useful to access Git through an Xcode terminal? Thiago Cruz certainly thinks so:

I’ve used editors with embedded terminals previously, and while it’s certainly nice to have it’s never been quite the productivity booster I had imagined. Still, there are lots of other folks who would find it a welcome improvement, and Xcode’s debug area has lots of space.

Ready? Fight!

Time for something a little more controversial:

It’s well known that most people are in favor of official coding styles, as long as their particular coding style is the one that gets used.

Jokes aside, SE-0250 did start a wider conversation about what an official Swift style should look like, and it has become more pressing now that Xcode’s visual SwiftUI editor started generating Swift code on our behalf.

While I’m all but certain I’d need to make a few changes to fit in with whatever was decided, having an official Swift style guide would be a welcome thing for me.

And finally…

More features? Maybe, but…

Although I’ve not had the misfortune of Xcode crashing twice an hour, I have found remote debugging to cause all sorts of freezes, and the less said about playground stability the better.

This has been another big year for Xcode, so perhaps having an “iOS 12 year” ahead isn’t such a bad idea…

What did I miss?

What features do you think would be a great addition to future Xcode releases? Tweet me @twostraws and let me know!

Sponsor Hacking with Swift and reach the world's largest Swift community!