There’s a new hero in the world of web applications, services, and microservices: Server-Side Swift is making serious waves across the industry. At Beezwax, it’s changing how we approach and solve many typical, long-standing coding challenges.
Meet a New Hero 🤠
From the moment it was introduced, Swift’s singular combination of elegant brevity, type safety, flexibility, and raw power made it the new vehicle of choice for developing native apps for iOS, macOS, and other Apple hardware. But the unexpected surprise with Swift has been its remarkable and rapid emergence as an open source, server-side platform for creating robust cross-platform web applications, services, and microservices.
We love and work with both of these aspects of modern Swift, building native apps for the Apple ecosystem, and creating cross-platform web apps and services. But we’re finding that Swift’s rapid emergence and extraordinary capabilities as a web architecture powerhouse are revolutionary. And, not surprisingly, we’re also finding that Server-Side Swift is much less understood and appreciated than it deserves to be. For this reason, we’ll focus on describing this emergence of the Swift ecosystem, and its power as a tool even outside the realm of native/mobile app development.
Who Is That Masked Man?
Like any good hero, Server-Side Swift is a valiant game changer.
But then a second wholly unexpected thing happened: On December 3, 2015, Apple announced that Swift would be fully open sourced. Beginning with version 2.2, not only would the full Swift language itself be released under the open source Apache license, but the future evolution of the language would itself be made deeply transparent and opened to community input.
Open Source, Community.
It’s hard to overstate the thoroughness of this paradigm shift: This single stroke deftly transformed Swift from “Sure it’s great, but it’s just for Apple devices”, to a potentially universally available language waiting to be ported and used anywhere, on any device. In response, the development community rapidly ported Swift to a wide range of popular environments. Even more importantly, there was an immediate explosion of efforts to leverage Swift’s singular capabilities for creating web services and apps. Over the next several months, several new Server-Side Swift frameworks emerged, most notably including these 4 key frameworks:
In future posts, we’ll talk more about the merits of specific Server-Side Swift frameworks from our perspective. (Teaser: Vapor and Kitura have rightfully emerged as two leaders in the space. Each is compelling, both technologically, and also as practical, real-world choices for enterprise-grade web app and service implementations).
For our present purposes, though, the most important point to note is that this emergence and interchange prompted by the ongoing “co-opetition” amongst these several frameworks has helped foster a surprising maturity among these still-new server-side platforms. Given the relatively short time since it’s even been possible to use Swift to create web apps and services, it’s truly astounding to see a depth of toolsets and capabilities that would typically only be found in far more mature platforms and frameworks. Combined with the deeply revolutionary properties of Swift itself, these robust server-side Frameworks are ready to be next generation superheroes.
What This Means For Your Weekend
As interesting and compelling as all that may be, we should step back here and ask: What aspects of this are relevant to most of us in the (more or less) “real” world? For example: If I’m a busy workgroup manager or a hard-working knowledge worker looking for tools to increase my team’s efficiency and capabilities, is there any reason I should care?
After all, deep developments in the high tech world are sometimes as relevant to where the rubber hits the road of business as, oh, last week’s micro developments in 11-dimensional String Theory.
What makes this Server-Side Swift stuff any different?
Universal International (?!)
The first reason we’re compelled by Server-Side Swift is quite simply, its surprisingly portability. Because of the profound interest and ongoing efforts of the open source community, we can deploy Server-Side Swift apps to virtually any platform. Practically speaking, this means that most any Mac, Unix, or Linux machine (physical or virtual), and an increasingly wide range of web hosting platforms and services, can all host a Swift web app or service. There are even multiple cloud hosting services dedicated to hosting Server-side Swift, including Kitura’s IBM Cloud offerings, and perhaps most compellingly, Vapor Cloud.
And where Server-Side Swift really shines is in the details of what it uniquely offers developers and end users.
Heroic Type Safety ⛑
Swift, at its very core, is a fundamentally type-safe language. Swift handles type safety in an extremely elegant manner, avoiding the verbosity and stiffness seen in other type-safe environments. In most cases, Swift silently infers the types of each object, leaving our code transparent and uncluttered. But under the hood, every variable, every constant, every function has a highly specific and immutable type to which it is inextricably bound.
What does this mean in the real world? Swift’s precise approach to handling type safety requires us to code with clarity and consistency. This is enforced at the compiler level, meaning that we cannot choose to ignore these requirements, because our apps simply won’t build (compile) if we violate these rules even once anywhere in a complex app.
A common refrain of those learning Swift is that initially, this feels like a constricting limitation, but soon it becomes clear that thinking and building in this way enables us to create more reliable, robust, fail-proof applications. As Apple pointed out on the day of Swift’s release, core type safety makes many types of the most common errors seen in complex native and web apps quite simply impossible. And having that kind of core deep reliability built into business-critical apps and services everyone relies on most certainly matters to everyone’s daily work life, and every manager’s bottom line.
More than Meets the Eye
We just mentioned that Swift won’t build if we violate its basic rules. Let’s unpack this: Swift is a compiled language, which means that the human-readable code we conceptualize, write, and share as developers — the source code — is not what eventually runs. Instead, we must manually compile our projects before they can be run: The compilation process transforms the human-readable source code into binary code that’s thoroughly checked for consistency, and then deeply optimized and transformed into machine code tailored for a specific hardware target. Binary code is the stuff of which all native software and applications are built.
Server-Side Swift’s compilation allows it to bring many core advantages traditionally found in native apps to the realm of web apps:
First, compiled code is incredibly secure wherever it is deployed. Why? Quite simply, while source code is readily human-readable, compiled bitcode is not (it looks like long sequences of seemingly randomized hexadecimal characters if you ever try to read it). If a server containing readable source code were to be compromised, anything in that codebase would be exposed to the hostile party, and both core business logic and potentially sensitive data could potentially be exposed to this hostile party. On the other hand, if a Server-Side Swift server were compromised, this would not be true: Any code and other assets found would be compiled and no longer in human-readable form. Of course, all server applications require ongoing diligence in establishing and maintaining security at multiple levels. But at the level of securing deployed code, Swift’s compiled code is a huge benefit in securing critical information.
Second, compiled code is deeply optimized for performance. Modern compilers are marvels of engineering, and the best of them — which definitely includes Xcode and Swift’s LLVM compiler — are masters at optimizing the performance of code as human-readable source code goes through multiple layers of the compilation process and optimization for specific hardware targets. This compilation is specific for each class of target device: If we compile a Swift app for Linux, that build target will result in bitcode deeply optimized for Linux, and will only run on that specific class of device. Repeated tests of both the Vapor and Kitura frameworks have shown stunning levels of performance.
A final key benefit of Swift’s compiled nature is efficiency — the flip side of Server-Side Swift’s extraordinary speed. We’re finding that in the real world, we typically need far less server hardware than we’d expect in order to run Server-Side Swift apps and services. In many business applications, Server-Side Swift performs like a world-class runner out for a comfortable morning jog. Where a couch potato like, oh, say, some guy looking a lot like me, would be panting hard and needing assistance to reach the end of the block, the sprinter’s heart rate barely increases. In the world of web servers, apps, and services, this translates into real world dollars and cents: Server-Side Swift’s cool efficiency means less money required for servers, and less strain on key resources day in, day out. That’s not as splashy as world-class speed, but it’s about as real as it gets when it comes to the bottom line.
Riding off into the Sunrise…🌅
Phew! If you’ve read this far, congratulations! Obviously, we’re excited by both the broad range and exceptional depth of Server-Side Swift’s technical capabilities, and we’re even more inspired by the kinds of solutions it’s helping us deliver to our clients.
Swift’s heroic elegance, power, performance, and security are compelling, and its broad reach across platforms and types of solutions greatly multiplies its impact. We love its ability to complement and magnify other native and web platforms’ natural capabilities. And it fits like a glove with our ongoing offerings of native (client-side) Swift apps for iOS, macOS, and other platforms.
The Swift logo is a trademark of Apple Inc.