With nine months before WWDC20 now is the time to dream.
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…
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:
SwiftUI 1.0— Luis Ascorbe (@Lascorbe) September 3, 2019
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:
Definitely a SwiftUI 2.0— Alice (@CheshireChild_) September 3, 2019
I can do a lot with current SwiftUI but it’s yet way behind what I was able with UIKit to the point it’s not worth it for now
One improvement that comes to mind is that it’d be nice if the object library could show your own types. That way you could drag them in within previews rather than have to add them via code— Harshil Shah (@_HarshilShah) September 4, 2019
Collection View in Swift UI.— J-Cab (@iJustinCabral) September 3, 2019
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.
SwiftUI is great, but how about SwiftUI on iPad?
SwiftUI in Swift Playgrounds on iPad, aka "Xcode on iPad"— John Goering (@epaga) September 3, 2019
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:
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.)
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?
Complete documentation— Manoj Karki (@mskarki) September 4, 2019
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…
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.
Visual Core Data: I want to see how the data is organized, even if it’s just a table. I want to see conflicts from one data model to a new data model so that I can update schemas with more confidence.— Tim Isenman (@TimIsenman) September 3, 2019
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.
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:
I would like an App Store for SPM. Looking for a framework, just search it and add it. Also gives you the option on how much of the Dependency you want to bring in to your project.— Blind Power (@blind_power_yt) September 4, 2019
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.
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!
Named fonts, similar to named colors.— Dr. Michael Lauer (@DrMickeyLauer) September 3, 2019
I would love to see remove unused assets feature.— rahul vyas (@imrahulvyas) September 4, 2019
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.
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.
Xcode already has some Git integration, but there’s a lot of scope for improvement:
Project: Project/file level Xcode theme to differentiate windows. More mergeable IB and project file formats.— Ed Rutter (@NSGoat) September 4, 2019
“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:
It would be nice to be able to start a terminal session inside Xcode. For the ones like me that prefer to do git commands in there (instead of using the Xcode integration) or just test a script that is automating something. All this without switching context too much.— Thiago Cruz (@thiagohmcruz) September 3, 2019
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.
Time for something a little more controversial:
An official Swift style guide and auto-formatter + format-on-save.— Tristan Diependael (@Tridie2000) September 3, 2019
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.
More features? Maybe, but…
Make it stable, I don't care about new features for now. I want Xcode to not crash on me twice an hour.— Don (@donbytyqi) September 3, 2019
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 features do you think would be a great addition to future Xcode releases? Tweet me @twostraws and let me know!
SPONSORED Why the top iOS apps rely on Instabug for crash reporting. Crash reporting + Bug reporting + Customizable in-app surveys all in one SDK. Know which line of code caused the crash along with network logs, repro steps, and the session profiler to identify and resolve severe crashes quickly. See more detailed features comparison and try Instabug for free here.
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and a speaker at Swift events around the world. If you're curious you can learn more here.