Rules of Engagement

TLDR; Any posts tagged with foundation will discuss Swift code that you can run outside of Apple's platforms.

I want to use this post to continue to lay some of the ground work of this blog post series, by helping readers understand the general approach I'll take to discussing Swift code.

As far as I can tell from varying social media outlets and general developer consensus, people still associate Swift as a language specific to Apple platforms. And rightfully so.

Why is this the case? Some reasons can include (but not limited to):

• General ease and ready availbility of the tools to work with Swift on Apple platforms.
• The majority of Swift specific articles being tailored towards iOS development.
• The majority of community Swift projects and repositories on Github being iOS Specific.
• The lack of obvious direction to setting up a Swift development environment outside of Apple platforms.
• The lack of useful general application programming examples on non Apple platforms.
  

It's obvious why the Swift toolset is strong on Apple's platforms. It's Apple's direct connection to their developer community that fuels their app store and general ecosystem. It's in their best interest to pump cash into the experience to streamline their developers which directly streamline their content assembly line.

This has always been the case, even when Objective-C was the primary developer language on apple's platforms. So much so that one of the core requirements of Swift was seamless interoperability with Objective-C when it first launched, even though Objective-C is even LESS popular (in my opinion) outside of Apple platforms.

It's a common practice not unique to Apple. Microsoft has always curated their developer experience to their platforms for years too and has slowly seen it expand outward thanks to cross platform projects like Mono and Xamarin.

Where Does that Leave us?

Every time I would mention to colleagues about using Swift outside of Apple's platforms, they would either gloss over or question if I was doing alright.

So how viable is Swift outside of Apple's platforms? Very - but only if you know where to look, and what your limitations are.

At the time of this post, you can download an official Swift toolchain, directly from Apple, to run and debug Swift Code on:

• MacOS (obviously)
• 3 different versions of Ubuntu
• CentOS
• Amazon Linux
• Windows 10

So basically Swift works officially on MacOS, mainstream linux, and Windows.

And if you're so bold you can also head over to the official Swift Github and checkout their build pipelines that support builds for Swift running on Web Assembly, and 32/64bit Android.

If you dive into the Swift forums too, you'll see champions like Coleman porting the latest swift releases to other architectures like Armv5 too

And who can forget the time Jordan Rose ported a swift app to run on MacOS 9

I'll stop there because by this point, you get it. Swift technically does run on all major platforms now so anyone who puts their mind to it should be able to develop Swift app's anywhere.

Nice Try, XCode is only found on Macs

If you've made it this far in the article you're probably rolling your eyes and thinking 'Yeah you can run Swift on Windows and Linux (what ever that means). That's cool and all but what am I going to do with that? Write Swift in notepad?'

The reality is, you barely even have to think about getting Swift running on any Mac because it comes packaged easily in XCode. You might even accidentally start using Swift one day on your mac because you accidentally installed XCode following a youtube tutorial on how to torrent movies or play games on emulators.

I'd be lying to you if I said it was that easy outside of MacOS. But I also would be lying if I said it's too complicated too either. Thanks to the efforts of 0xTim and other folks tinkering with getting Swift running on web apps (a story for another time), we actually have a pretty good and competent editor to use anywhere for writing Swift.

Visual Studio Code has had a first party Swift extension to support writing, testing and debugging Swift Code for over a year now.

It recently reached version 1.0 too. It comes with auto complete, little run / stop buttons and breakpoints, so you can step over your code line by line. It feels like a lighter weight XCode and works outside of the box everywhere. In order to get setup you literally just need to download a Swift toolchain above, and install VSCode.

I've personally been using Visual Studio Code outside macOS for the last year but CLion is also an honorable mention especially if you like Jetbrains IDE's. I've always been a fan but prefer the lighter weight footprint of VSCode personally (or more specifically, VSCodium because I'm not a fan of Microsoft's telemetry).

So What's The Catch?

Up to now, we've established that Swift can run on any mainstream platform, and that you can even edit Swift with a popular and approachable editor that isn't XCode. But what's stopping us from taking the full plunge? Unfortunately, the answer to that is a pretty big problem.

The fact that all the frameworks and libraries you use to write apps on iOS with Swift, are Apple Specific. Meaning that they don't exist outside of apple OS's.

You CAN get Swift running some cheesy little 'hello world' console print out app on Linux and Windows, but you can't get an iphone simulator popping up with some buttons and pictures like you see in any number of altruistic 'I made my first TODO List app today' media renditions today.

Apple own's the framework's that make drawing stuff on the screen of an iPhone / iPad or Mac, and has been building on them for decades. Even if they wanted to make these available for every platform outside of their own, it would require a significant investment in engineering efforts to rewrite, port, and constantly support anything that isn't directly related to them.

Micro$oft has been able to branch out their C# language and tools over the years, to run on other platforms, thanks to community contributions and tools that have grown at scale over the decades such as Mono / Unity, Xamarin and Maui.

Micro$oft knows there's a market for developers who wan't to use the same tools they're comfortable with, everywhere, and also keep them in their ecosystem. It's like a subtle yet firm handshake. Once you grasp it, you may not know how to release yourself from it until its too late.

The cold hard truth is, at this time Apple just doesn't see porting their tools outside of their platform, as a viable business decision. The juice is, how you say, not worth the squeeze. Why focus on getting the apple developer experience just right in places they can't control, and have no say in?

It would distract them from making their platform the best they possibly can and distract them from potentially maximizing the return they make from their products. They would rather people want to jump over the hurdles themselves to target their platform than them do it.

My feelings about this stop here because everything else feels like it's a moot point. It is what it is, so the only thing we can do is figure out how to work with what we've got.

What Can We Do About This?

The only choice developers who wan't to use Swift outside of apple's ecosystem really have, is to just not rely on apple's frameworks. It almost seems like an overwhelming task because of how easy they make using their tools and frameworks. Because by the time you've gone through any number of iOS starter app tutorials on the internet, you've basically boxed yourself into their ecosystem without even knowing just how deeply embedded you are.

So that's what I'm going to do. Part of my journey in figuring out how to use Swift outside of Apple's ecosystem will include how to avoid reliance on apple's proprietary frameworks. More specifically, anything that has a 'Kit' at the end. UIKit, SceneKit, MLKit, etc, etc, you get the idea.

So that means the only Swift framework that I'm going to rely on always, is Foundation.

The one framework that apple originally created for their ecosystem back in the old ObjectiveC days and ships with each and every version of Swift (macOS and not). This will ensure that at the very least, my Swift Code will work outside of apple's platforms. The burden of what I do with it is on me though.

As such, going forward I will be tagging any articles with foundation to indicate that you can be guaranteed to run the samples discussed, outside of macOS. If the code discussed is locked into apple's ecosystem and won't run outside of it, you'll see a tag of the relevant framework (IE: UIKit).

I hope you enjoyed this analysis of the current Swift landscape and I look forward to continuing to break down how to use Swift outside of Apple's walled off garden!