The start of WWDC 2019 is now just hours away, and — like most developers working within the Apple ecosystem — I’m getting really excited. While there’s already been a ton of predictions, rumors and leaks posted about what we might see from Apple’s biggest developer event of the year — I thought I’d dedicate my 120th weekly Swift article to something special — dreams.

These are my six biggest Swift-related dreams for this year’s WWDC. They’re not predictions, and they’re not based on any sort of insider information — they’re simply six things that I’d personally love to see introduced when the event begins tomorrow. This, is a Swift developer’s WWDC dreams.

It’s time for the Swift Package Manager to shine

How to manage a project’s dependencies has been a great source of debate within the Apple developer community for years. From CocoaPods, to Carthage, to hand-rolled scripts, submodules and good old fashioned copy-paste — there’s always been a myriad of different tools and techniques to choose from.

When the Swift Package Manager was introduced in late 2015, as part of Swift going open source, it initially seemed like the great dependency management debate was finally over. There it was, a package manager from Apple themselves — dedicated to resolving, updating, and building a Swift project’s dependencies.

However, three and a half years later, for all of its awesomeness — the Swift Package Manager remains somewhat of a niche tool. I think that it’s high time for it to shine, and to truly become what everyone thought it would be back when it was first announced — the default way of managing dependencies for any Swift project.

But my dream is for Apple to take things even further, and make the Swift Package Manager not only a tool for managing dependencies, but to manage all sorts of projects within their developer ecosystem. To enable any Xcode project to be defined using a Package.swift manifest, to make Swift Playgrounds for iPad use the Swift Package Manager’s way of structuring a project instead of using its own .playgroundbook format — and to make it easy to share project configurations between a server, an iOS app, and an iPad playground.

Server-side Swift becomes a first class citizen

Just like the Swift Package Manager, server-side Swift has so far had a bit of an ambiguous status in terms of being a part of Apple’s suite of developer tools. While it’s clear that a tremendous amount of effort has gone into developing server-side Swift into a robust and powerful alternative for server applications — both by Apple and numerous people and companies from all around the community — it hasn’t yet become a true first class citizen.

My dream is for Apple to start talking about server-side Swift the same way that they talk about iOS, macOS, watchOS and tvOS — making it a fully supported, first class Apple development platform (even though it might actually run on non-Apple hardware). While Swift team lead Ted Kremenek announced that Apple is indeed using server-side Swift themselves, in production, when he was a guest on the Swift by Sundell podcast — I’d love to see that commitment taken even further.

For example — it’d be fantastic if Xcode came built-in with server-side Swift project templates, if native support for debugging server-side requests and responses would be added, or if Apple offered some way of running Swift-based cloud functions on their infrastructure (similar to what Amazon offers through their Lambda platform) — for example in the context of CloudKit.

All of the above would both send an even stronger signal that server-side Swift is here to stay, and also make it much more accessible to all Swift developers — especially those with limited server-side programming experience.

True Swift APIs and frameworks

One of the major features of Swift 5 is that the language, for the first time, is now guaranteed to be ABI stable. That doesn’t only open up opportunities in terms of reducing dynamic linking between frameworks, or for third party apps to be able to directly call system-provided instances of the Swift runtime and standard library — but it also opens up the door for Apple to ship true Swift frameworks.

Because even though Apple has done an incredible job retro-fitting most of their C and Objective-C APIs with great Swift support through interoperability annotations — most of those APIs still lack many features and conventions that they most likely would’ve adopted if they would’ve been written in Swift to begin with.

For example, protocols like UITableViewDataSource and UICollectionViewDelegate could be made more type-safe by using associated types for things like sections and cell types, networking APIs like URLSession could adopt Swift’s Result type instead of requiring us to juggle optional Data and Error parameters, and configurations and options could be modeled using enums with associated values — rather than using dictionaries.

While Apple did already release their first “pure Swift” framework last year in the form of Create ML, I’d love to see any new frameworks introduced this year — including those made to be used in code that gets shipped to the App Store — to be written in Swift. It’s not because I hate Objective-C and want to see it completely abandoned, nor do I expect existing frameworks (such as UIKit) to be rewritten in Swift — I just think that it’s time for Apple to start fully utilizing Swift’s potential when building their developer-facing APIs and SDKs.

Xcode fully adopts the Language Server Protocol

The Language Server Protocol is a project started by Microsoft in an effort to standardize how source code editors handle things like autocomplete and documentation integration for different languages. The idea is that any editor that adopts LSP should theoretically be able to be used to write code in any language that offers LSP support.

Late last year, Apple announced that both Swift and Xcode will eventually adopt LSP — which would enable editors like Visual Studio Code and Atom to gain true first-class Swift support. The reason I’m excited about this — and why I hope that this year’s version of Xcode will end up fully adopting LSP as the way the editor and the underlying Swift language services communicate — is because it would enable us Swift developers to use any editor that we want, without compromises.

While good progress has already been made on this project — my dream is that, if Apple were to make Xcode itself rely on LSP, then we’d see a heavy acceleration in the effort to make Swift fully LSP-compatible. We’d also get a stronger guarantee that the bridge between SourceKit (which handles both autocomplete and syntax highlighting for Xcode) and LSP would remain maintained and supported for a long time.

Swift as a native scripting language

A big part of what makes Swift so great is that it in many ways manages to both be powerful and type-safe, but also lightweight in terms of syntax. Thanks to features like type inference, and a low-verbosity approach to both API and keyword naming — Swift code often doesn’t require a whole lot of typing, which makes it a great language for scripting and automation.

Often when scripting, we’re looking to automate or solve a specific task as quickly as possible. We’re not looking to setup a complex architecture or orchestrate a large number of types and files — we’re just looking to get something done in whichever way that offers the lowest barrier for entry. For many iOS and Mac developers, that lowest barrier has historically been through tools like Bash, scripting-focused languages like Ruby or Python, or Mac apps like Automator.

I’m personally a big fan of using Swift for scripting, but at the same time, it does come with a substantial set of barriers that I’d love to see removed. My dream is for Xcode to offer a File > New > Script option, for Siri shortcuts on iOS to be capable of running Swift code (just like how it can run JavaScript), and for the Swift command line tools to enable inline dependency declarations (similar to what swift-sh and Marathon offers):

// This annotation would be resolved by the Swift Package Manager
// under the hood, making it easy to use dependencies in scripts.
@package(url: "https://github.com/johnsundell/files.git", from: "3.0.0")
import Files

for file in Folder.current.files {
    let content = try file.readAsString()
    let html = try makeHTML(fromMarkdown: content)
    print("-- \(file.nameExcludingExtension) --")
    print(html)
}

If Swift scripting would rise in popularity, I think that’d also bring lots of benefits for the Swift ecosystem as a whole. For example, it’d most likely lead to more developers being encouraged to create utility packages (for things like file management, data processing, etc.) that any Swift project could then use.

Xcode on iPad

I did save my biggest dream for last — and I know it’s probably not happening this year — but these are my dreams, so here we go: I’d really love to see some version of Xcode on iPad.

Like I noted in last week’s review of Swift Playgrounds 3.0 for iPad, I do love to use that app, but it has some very hard limits in terms of what it’s capable of. Part of that is actually a feature of the Playgrounds app — in that its relative simplicity makes it much easier for students and programming beginners to pick it up and start learning — but it will most likely always limit the way it can be used as a professional development tool.

So I’m not looking for Apple to turn Swift Playgrounds into Xcode — I think it should remain a tool focused on education and prototyping — but instead introduce a dedicated app for professional app development on iOS. My iPad Pro is faster than my computer (2017 MBP 13” without TouchBar), and it’s also more versatile and lightweight — so I’d love to use it for all sorts of development tasks, without feeling like I’m using the wrong tool for the job.

Rather than porting Xcode to iPad (which, honestly, I don’t see how it would be even possible) — I’d love to see Apple make a new, modern, IDE that runs on both the Mac and iPad. Imagine that as the crown jewel example of what could be done using Project Marzipan — I can’t think of anything that’d be more convincing for developers to start bringing their iOS apps to the Mac.

Conclusion

That’s it — those are my six Swift dreams for next week’s big event. What do you think? Do you share some of my dreams, or do you dream of something else? Find me on Twitter @johnsundell, and let me know.

For all things WWDC, make sure to check out this site’s new spin-off — WWDC by Sundell — on which I’ll cover the conference and all of its announcements in great detail all throughout next week. I wish all of you wonderful readers a really fantastic WWDC week — whether you’re on site in San José or if you’re following the event remotely, just like me.

Thanks for reading! 🚀