Xcode 10 wish list: native iOS support, codegen, and more

Now that Xcode 9 is out it’s time to look forward to next year

Paul Hudson    September 19th 2017    @twostraws

Xcode 9 was released on the Mac App Store a few hours ago, and there’s no doubt it’s the most feature-packed Xcode release to date. Not only does it include faster editing, named colors, Swift refactoring, and wireless debugging, but it also comes with a huge simulator revamp that allows us to run multiple simulators at the same time.

So, now we’re free to look forward to Xcode 10 and start thinking: what features would we most want to see added in Xcode 10? Or is it Xcode X? Here are some to get you started…

Codegen for assets

Codegen – the practice of generating code either statically or dynamically – has been in Xcode for some time, for example when generating Core Data classes. In Xcode 9 this was taken further so that Core ML models also have their classes generated dynamically at build time so that developers never have to worry about their internals.

However, large parts of both macOS and iOS rely on strings to work: table view cell identifiers, storyboard identifiers, image names, and more are all as stringly typed as they come. In Swift 4, many macOS APIs have veered away from strings in favor of strongly typed typedefs like this:

typedef NSString *NSImageName;

If Objective-C isn’t your bag, that translates more or less as “whenever we say NSImageName we really mean NSString”. That has no impact to Objective-C developers because they can continue providing strings for image names as they always did, but Swift developers must now use NSImage.Name for all their image names, like this:

let img = NSImage(named: NSImage.Name("banner"))

The goal here is to encourage developers to create static variables for each of their names so they can instead write:

let img = NSImage(named: Assets.banner)

This has the advantage of eliminating typos and duplication when using the same image in many places, although it does mean you need to put in the extra work to define all your images up front.

In Xcode 10 it’s time we moved to full codegen for precisely this sort of situation: all images in the asset catalog will be dynamically compiled as static variables available to use in the project. So, if you have an asset catalog called Assets.xcassets that contains the image “banner”, you would automatically be able to use Assets.banner in your code – no need to define them yourself, and no risk of typos or duplication like the old system.

In case you were wondering, this is precisely the approach Android uses: its R variable provides access to all strings, styles, images, colors and more, all generated at compile-time.

Increased support for extensions

Xcode extensions were introduced with Xcode 8, but they proved to be a bit of a damp squib. This is mostly because of the way they have been implemented: when an extension is triggered it gets given all the code in the current file along with whatever part of it the user has selected, and it can send back the amended lines and selection.

That’s it: it receives some lines and can send back some lines. As a result, the list of extensions that have been built is remarkably short - you can sort your imports, you can clean your closure syntax, and you can run SwiftLint, for example, but not much more.

In Xcode 10 it would be great to see this revisited – could extensions receive an array of all the warnings and errors that are in the current file? Could they receive a struct describing the classes, methods, and properties in there? Could they receive a subset of the user’s settings? Could they show simple input prompts to let the user enter a value? Could they let us access the project’s asset catalogs? Could they let us hook into autocomplete?

Even a small step forward could offer up many opportunities for developers to help make Xcode better.

Native iOS support

The ability to create iOS apps inside an iOS app has been a major feature request since Swift Playgrounds showed the world what was possible, and now the revamped Xcode editor should bring this possibility even closer.

If you’ve ever used a 12.9-inch iPad Pro with the smart keyboard, you’ll know just how computer-like the experience is – you get extraordinarily powerful hardware, fast drag and drop interaction, and of course a screen that rivals even 15-inch MacBook Pros.

If Apple were able to leverage all that power to build a native iOS version of Xcode then it would in theory massively reduce testing time for apps – you could press play and have your app running in only a second or two, because all deployment time is effectively removed.

At the same time, there are more than a few complications to resolve: handling touch is great, but Interface Builder often requires fairly delicate positioning, particularly because it has a great many controls squeezed into a small space. iOS, with its naturally chunkier UI, would need to be dramatically rethought.

And let’s face it: there’s very little chance any version of Xcode for iOS would support Objective-C. And nothing of value was lost…

Cleaner templates

Some of the Xcode templates need to be burned with fire, and the others need to be burned with fire then nuked from orbit. Yes, it’s time for Apple to rethink from scratch how we start new projects in Xcode, because most of them come with far too much code that no actual project needs.

The point of template projects is to give you a foundation: to set you up with the basic skeleton of an app that you then add to in order to build your own thing. What Xcode currently has is a bizarre mix of template apps and sample code, meaning that if you want to get started quickly you first need to spend five to ten minutes cleaning out what is already there.

The worst example of this is the SpriteKit template, which gives you eighty lines of code that make spinning nodes on the screen when you touch it, an Actions.sks file that adds scaling and fading actions as part of a “pulse” animation, and a GameScene.sks file that includes an “Hello, World!” label node in the center of the screen.

“Oh, yay!” said no developer ever. So, when you start a new SpriteKit project you need to begin by deleting almost all of GameScene.swift, deleting Actions.sks, then cleaning GameScene.sks – those things are literally never of any use.

Templates aren’t supposed to be sample code, and hopefully Xcode 10 will clear that up once and for all.

And let’s not forget Swift 5

It’s all but certain that Xcode 10 will ship with Swift 5, and although it would be great to see progress made on some sort of async/await support, the feature everyone most wants is ABI stability.

ABI stability – the ability for applications and libraries to interact even if they were compiled using different Swift versions – was originally promised for Swift 3, then pushed back to Swift 4, and then pushed back to Swift 5.

The lack of ABI stability continues to stop some developers from adopting Swift, which is a shame – it would be great to remove this last major hurdle, particularly for enterprise developers who support closed-source libraries.

Of course, it’s important to say that rushing ABI compatibility is a terrible idea, because no one wants to be stuck with a broken or flaky implementation. It’s been pushed back twice now, and that just means the Swift developers have had longer to think about it – and that’s no bad thing.

What developers want

I sent out a tweet asking developers a simple question: if you could ensure one feature got added to Xcode 10, what would it be?

Here’s a selection of the best responses:

This goes back to what I said about codegen earlier – Android makes all strings available in code through its R constant, and perhaps Xcode could follow suit.

You have to admit, this happens a lot.

He's right: Cocoapods has served us well for a long time, but Swift Package Manager seems to be Apple's preferred way forward now – is it time to make the switch?

It’s true that compile time continues to improve (anyone remember how bad Swift 1.0 was?), but it still pales in comparison with Objective-C.

In the meantime, you should learn how to make Swift compile faster.

Using the Mac’s webcam to simulate an iOS webcam would be awesome, but Frederik is quite correct: UI testing continues to be a pain, and any improvement would be most welcome.

This seems like a relatively easy one to implement. At the very least it would be nice to use dark gray for the increasing amount of diagnostic gibberish that iOS likes spitting out…

Yes! This would help make the Magic Trackpad live up to its lofty name a little more – trying to simulate gestures currently is irritating.

Debugging stability seems to come in waves, but even today your chances of the LLDB prompt working as intended are about 50/50.

Eh… well maybe.

An embedded terminal instance is pretty much a standard feature in all other IDEs I’ve ever used – it’s curious that Xcode steers clear.

Now that we can run multiple simulators at the same time this would be the logical next step.

If you have features you’d like to see added to this list, hit me up on Twitter.

In the meantime, I want to re-iterate that Xcode 9 is a really great release – easily the biggest and most exciting Xcode release since 4.0, when Xcode and Interface Builder were merged. I expect the Xcode team are proud of their work, and rightly so: if Xcode 9 is an indicator of how Apple’s IDE will evolve in coming years, we have a lot to look forward to.