Apple's New SwiftNIO Might Be A Hint Of Bigger Cloud Ambitions To Come!

Summary

• In this article we look at the newly released SwiftNIO framework from Apple.
• We wildly speculate about how Apple can take this project further and use it to compete with Amazon's AWS and other cloud providers.
• Finally, we look at an options strategy that could result in 140% upside if Apple was to trade up to $200 by 2020.

A few days ago at the try! Swift Conference Apple (NASDAQ:AAPL) software engineer Norman Maurer introduced SwiftNIO, a new high performance network for networked server and client applications. In this article we are going to discuss this new technology and then wildly speculate about what this could possibly mean for Apple in the future. With Swift and now SwiftNIO becoming open source we see Apple finally entering the cloud computing space and challenging Amazon's AWS (AMZN), Microsoft's Azure (MSFT) and Google's Cloud (GOOG) (GOOGL) sometime in the future.

(Swift Logo from Apple.)

Swift and SwiftNIO

Swift is a programming language introduced by Apple in 2014. It's a general-purpose compiled programming language used primarily for iOS, MacOS and WatchOS development. Apple describes it as "Objective-C without the C." It generally has a modern syntax, fast prototyping capabilities and it runs close to the metal when compiled, which allows it to be very efficient on Apple's hardware platforms.

On introduction in 2014 Apple announced that they will be open sourcing the Swift language, which immediately inspired developers to attempt to use Swift for web and server side applications as well. However, since the initial introduction Apple has not made any significant push to make Swift a serious player in the server side programming market, until now.

(Photo from the try! Swift presentation by Chris Bailey.)

A few days ago at the "try! Swift" Conference in Tokyo Apple introduced the SwiftNIO framework. SwiftNIO is short for Swift Non-Blocking IO. As described on the project's GitHub page, it's a "cross-platform asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients." That sounds fancy, but what does that all mean? Well, basically SwiftNIO is a low level framework that can be used to implement communication protocols and APIs in Swift, which then can communicate with back-end Swift code for your web and mobile applications.

Let's look at an example. Say you are making a social media app, they tend to be popular these days. The app lives on your user's phone, but all the up to date data, pictures and status updates reside on the back end servers in the "cloud" (AWS, Azure, Digital Ocean, etc.). In the past you would have your back end code run in PHP, Python, or any number of programming languages and the back-end would communicate with the client app through HTTP protocol and a web server such as Apache, NGINX, or Microsoft IIS (rarely IIS, unless you're a government or large nontechnical corporation contractor, because no one has ever been fired for choosing Microsoft, no matter how bad of a choice it is in this particular case).

So the communication pathway is something like this: back-end code <-> web server <-> Internet <-> client application. That doesn't look too bad, why switch away from that? Well, web servers are designed to do a slew of different things and accommodate all kinds of use cases by default. They are kind of a Swiss Army knife in this case, lots of features for all your life's little needs. The problem with this is that every server feature you are not using is also a potential attack vector for hackers. You can judiciously turn off unused features but this is rarely done properly in practice and even in the best case scenario a properly configured server with minimal number of features turned on will still expose a greater attack surface than a custom written application that's designed to ONLY answer specific API calls and throw an ERROR in all other instances.

As a result, in recent years we have seen a push from many online companies to bypass the whole web server link in the communication chain and have the back-end code implement the protocols directly. NodeJS, Google's GO language and several Python frameworks are popular for this, as is Netty, a popular client-server framework for Java. SwiftNIO is basically the same thing, Netty, but for Swift.

So, it finally looks like Apple is pushing Swift into the world of server computing and there is a HUGE opportunity waiting for them there.

Apple's AWS

Everything in this section will be speculation and supposition, but based on clues Apple has been sprinkling lately I think we are about to see some movement in the direction of them running their own cloud services company. Of course, being Apple, they are not going to try to compete in the highly competitive generic virtualization space currently dominated by Amazon's AWS and Microsoft's Azure. Instead, I believe they are going to offer, first internally and then externally, a Swift cloud. A cloud hosting provider for back-end swift code.

So, let's take a look at how this "Swift Cloud" could look like in a real world application. A few years ago I wrote a ToDo list app called Simplifi. It's currently available in the App Store, in case you want to check it out. At the moment Simplifi is a single device application, with no sync capabilities. It would be easy to rewrite the storage back-end to use the iCloud storage and allow the app to sync between multiple iOS devices, but let's say I wanted to make this app cross platform and let's say I wanted to add a web interface. Let's look at the software stack I would currently use:

1. Linux Server - either a containerized environment or a VPS.
2. Web Server - NginX, Apache, etc.
3. Back-end Code - Django, PHP, JS, etc.
4. Back-end Storage - mySQL, MariaDB, or Postgre SQL.
5. Javascript Framework - Angular, React, or EmberJS should work or the new Google Flutter (still reading about it).
6. HTML and CSS.
7. The App - It's currently written in Swift.

So, let's sum up. At the very least this project would involve maintaining some sort of Linux environment and 5 different code basis. Hmm, not a happy prospect. It would be nice to get it down to 2, wouldn't it? And it would be possible with the proposed "Swift Cloud."

Now let's imagine how this could be done on the proposed Swift Cloud.

The entire web app, including the back-end and the front end could be developed in Swift. Libraries would have to be written to generate CSS and HTML necessary for various interface elements and client side Swift code would be compiled to WebAssembly. The server side code would be a compiled, self-contained, native application, also written in Swift using the SwiftNIO framework to communicate with the front end code over the Internet.

Deploying this would also be simple. You would upload it to the Swift Cloud, configure a few things and you are off to the races. Because the entire code base is a single executable application, it can be easily propagated to multiple physical servers and load balanced between them on the fly. MacOS and iOS apps are kernel sandboxed by default and a similar system would be used for the web apps, which eliminates the need to run containers or virtual servers.

So, you have one code base for the back-end and one code base for the front end, both in the same language and no web server or Linux server configurations! For a small startup, that's a win! And when those small startups become large startups Apple will make a killing on the hosting service fees. Look at Snap Chat (SNAP), a company that's making more money for Amazon's shareholders than it does for its own, by a huge margin.

Of course this single language paradigm is already possible with JavaScript and NodeJS, but, if developed properly, Swift might be a better choice. It's a well-designed language that compiles down to machine code, it's strongly typed, which helps with bugs and yet easy to read and understand. And it has a large code base due to the prevalence of iOS.

Here are a few other potential benefits for the developers of this approach:

1. It significantly simplifies development, especially at the MVP (minimum viable product) stage, by reducing deployment complexity and providing easy to access scalability.
2. Maintaining one codebase is way easier than 4 or 5 and allows for faster iteration with a smaller development team.
3. Built in security by only having to ship fully compiled code. Since only compiled code is shipped to Apple servers, you don't have to worry about code security as much. This is not a significant concern for most startups at the moment, but could become so in the future with more AI development.
4. Binary libraries also allow for further code security inside the organization. This is more useful for larger organizations.
5. Built in efficiency. Fully compiled code runs faster. This means less server load, which in turn means lower hosting bills at the end of the day.
6. Overall security. Having a single codebase allows for more predictable failure scenarios. You don't have to rely on 3rd party programs to fail properly without leaking information.

And here is a non-exhaustive reason why this is a huge opportunity for Apple, if they execute on it well and quickly:

1. Money! There is a lot of money in cloud hosting nowadays. AWS is Amazon's cash cow. That alone should be worth the investment into this project.
2. Developer lock-in. The more people code in Swift, the more likely people are to make Apps specifically for iOS and MacOS. With WebAssembly gaining steam, the next battleground will be the preferred browser language and it's not entirely obvious that JavaScript will remain on top. By offering a compelling and easy to use development environment Apple would assure that "first on iOS" will remain the norm into the future.
3. Cloud differentiation. While it can't be done with a snap of the fingers or a press of a button, switching between AWS and Azure is NOT a Herculean undertaking in most cases. On the other side, switching from the Swift Cloud would mean rewriting most of the codebase. And even though Swift is open source, the component and storage libraries do not have to be. Apple can Open Source most of the language, but keep nice and easy to develop against libraries and components close sourced, encouraging developer buy-in at first and lock-in later. It's a good place to be for a cloud host provider.
4. More money! I know, I have mentioned money already, but there is even more money here! Web app marketplace. In addition to simply hosting for other companies, Apple can also start a WebApp marketplace that allows people to purchase and use web apps, such as blogs, accounting software, or any number of consumer oriented software. They would handle the subscription charges, login, authentication, data storage and load balancing, so as a developer you only need to worry about developing a compelling SaaS (software as a service) solution and marketing it. Of course Apple would charge a percentage of the subscription to cover hosting fees and to compensate them for the platform access.

With an idea like this the implementation is the tough part. Apple has the cash, resources and the capability to design something like the proposed Swift Cloud. Further, with their current push to shift from products into a service based revenue model, this would be just the project to accomplish that goal. This project would be very uniquely Apple. Bringing elegance to web app development.

Conclusion

In this article we talked about the newly introduced SwiftNIO framework and proposed a Swift Cloud solution that would be a huge opportunity for Apple. Of course, there is no evidence as of yet that Apple is working on anything similar to the Swift Cloud, but there are hints, from the open sourcing Swift and now SwiftNIO, to their current push into the business market, to their increased emphasis on the service model. Apple is becoming much more than just a device manufacturer and this is just the project to build an enormous service juggernaut.

We have been quite optimistic on Apple since before the pre-split days, bought on the weakness at $92 and again recently when Apple slipped below $160 during the recent small correction. Our end of the year target remains at $205, but if there are hints that Apple will expand into the hosting market, we can see the stock trading much higher on valuation adjustment.

It is our hope that Apple will use their overseas cash for capital investment and expansion, rather than capital returns, as in the long run that would be much more profitable for the current shareholders. With a project like the proposed "Swift Cloud" above we believe they will do exceptionally well deploying that cash.

At the time of writing this APPL is trading at $177, which might be a short term peak. We suggested loading up on Apple on weakness post earnings and this might be a good strategy come next earnings around May, or if you are comfortable with options, you can consider a vertical spread.

You can purchase a 2020 call with a strike of 170 for $29 and sell a 2020 call with a strike of 200 for $16.50, which should give you a net debit of roughly 12.50 (give or take due to exchange volatility). If Apple hits $200 by 2020, you would be looking at roughly 140% upside and your break-even is at $182.50, not too bad. This is similar to one of our own current positions. Of course, if we experience a significant overall market correction, you can lose the entire position, so trade options with care.

Analyst’s Disclosure: I am/we are long AAPL. I wrote this article myself, and it expresses my own opinions. I am not receiving compensation for it (other than from Seeking Alpha). I have no business relationship with any company whose stock is mentioned in this article.

Comments

[neals58]

Why the heck did the stock drop today whenever FB was up is the bigger question? Do not see any negative news out there?

[Glen Rivard]

Neal, Some point the fact they peaked in 2015 and iPhone, iPad and Mac sales all peaked a couple of years ago will catch up with share price.

http://bit.ly/2yHMAz4

http://bit.ly/2G6Wa2W

http://bit.ly/2lpk3rG

But the biggest is now Apple user base is in decline.

“Apple install base declining”

http://bit.ly/2gNLnwE

[Swordmaker]

Glen—"Some point the fact they peaked in 2015 and iPhone, iPad and Mac sales all peaked a couple of years ago will catch up with share price."

Some, Glen? Only you keep making that false claim. The rest know the history. You are perfectly willing to explain away Google's loss as being due to an extraordinary one time event, but you are NOT willing to accept that Apple had an extraordinary one time event in 2015. You are a hypocrite.

[User 316261]

I find this annoying too.

If you chose a select period in history and select other investments then you could have done better than invest in apple.

So what?

That was also true of Google yesterday, today and will be true tomorrow.

I have respect for Glen's opinions on future technologies and impact. There's meat there.

This refrain that you could have chosen this rather than that three years ago is utterly pointless.

Even if you give it merit, and own a time machine, you wouldn't choose Glen's investments from three years ago anyway.

[jef.holtmyer]

Zynath,
If Apple is headed in the direction you are pushing here. Would it not be like Apple to keep the, higher end, back end processing coded for an in house CPU? And if Apple does this. They would be pushing for the highest performance with the lowest security issues, as well as the lowest overall cost for themselves. In this way they will continue to provide the most profitable cloud framework with the highest margin. Once again gaining the highest percentage of the cloud profits while owning a minority of the cloud business. And by keeping the hardware side of the high end backend keyed to an in house CPU it all becomes possible for them only. Keeping the low end back end open source will allow startups and hobbyists to create the initial web sites with out losing out on the larger customers and those that grow into larger customers.
I believe keeping it all open source is key to long term acceptance. Even if long term users will be dragged into Apple's Walled Garden by the sheer weight of their project.
Love your article.

[Gregg Thurman]

With 2020 being nearly two years out I would look at a delayed construct vertical spread. Buy your JAN 2020 $170 Calls today (at $12.50), then within the next 9 months sell the JAN 2020 $200 Call at a higher price than is available today. Doing so reduces exposure during 2019 AND increases your ROI (depending on how much more you can sell the JAN 2020 $200 Call than you can today).

Personally, I like the 2020 $200/$230 Call Spread at $7.85 (ROI 275%). During 2017 AAPL went up 50% YoY. So far this year AAPL is up 25% YoY. Given Apple's initiatives in iPhone X (much higher ASPs that are only going to get higher), Apple Watch Series 4 and 5 (expansion of health functionality) and HomePod (coupled with AppleTV, Apple produced content and AR), AI personalization of functionalities, and governmental benefits of lower corporate taxes and cash repatriation, I think it is realistic that AAPL conservatively goes up another 35% in the next 21 months. That puts AAPL, at minimum, at $240 by January 2020 with an 18.50 PE.

[akvadrako]

Non-blocking IO is nothing special - it's a standard piece of any major software ecosystem for the past 20 years. Somehow connecting it to the "cloud" is just absurd.

[Glen Rivard]

Ak,. Agree. A great example is Node.js. But we have had async for over 30 years. VMS it was common. Unix it depended on the kernel. Sys V was not renterable so avoided but BSD was. Linux no problem.

[User 316261]

We've had async since the 1960s, a decade and a half before VMS.

If nothing else, that's how the teletype was connected.

So many breakthrough developments in software are a neat repackage of old principles.

Heck object orientation was used by the Egyptians when they built the pyramids.

On topic of the article, I agree with the author there could be an really interesting market for developers already captive to a Swift front end in offering more integrated back end services.

That doesn't negate comments that there are other technologies which won't be directly challenged by this.

[Glen Rivard]

Bob,. I would agree long before VMS but I am only so old.

[brimcgann]

I find myself well over my head but the conflict in the various comments lead me to believe that ANY outcome within a reasonable period of time 4 years will in fact not effect my stock in Apple.. I will continue to buy the dip and hold for a future . Either to understand that future or not. Go Apple.

[Glen Rivard]

Apple failed in creating their own cloud. They just use Google now.

"Apple confirms it uses Google's cloud for iCloud"

http://cnb.cx/2sYJdFm

Everywhere but China. In China they use GCBD which is managed by the China government.

The iCloud head left a couple of months ago which is a pretty strong sign they done trying.

"Apple's head of iCloud infrastructure leaves company, report says"
http://bit.ly/2Ffsi32

Apple spent billion on MacQueen named after the MacQueen movie "The Great Escape" but Apple failed to escape.

[Bradmeister]

@Glen Rivard - Not true. Apple takes a hybrid approach to its cloud services, combining massive Apple owned and operated data centers throughout the world with outsourced cloud storage provided by Amazon S3 and Google. The departure of one Apple executive means nothing.

[Glen Rivard]

Brad,. Apple outsources their customer facing to Google and just does their internal stuff. Apple failed to build their own.

[JP24]

Glen - "Apple outsources their customer facing to Google and just does their internal stuff.".

Can you point us to the information that supports that claim?

[AmazinMazen]

This is just plain wrong. Creating a cloud platform has nothing to do with programming languages or backend frameworks, just take a look at Amazon Web Services.
Doubt Apple would offer a cloud platform while it is a customer of Amazon and Google.

[vicwinkler]

I agree that it isn't what Apple are doing, but being a customer of Google or Amazon wouldn't stop anyone from doing this. (Other things will, such as customer focus ...you can't do everything.)

[skifun333]

Eventually Apple will not need to be a customer of google or amazon.

[vicwinkler]

This does not look like an Apple push into providing a fundamentally different cloud service than what iCloud is. It is certainly possible, but the investment in software would need to go far far beyond event handling.

That said, Apple is —across the board— in a longer-term push to provide low-level functionality via higher-level abstractions. Thats what the frameworks are really. Apple's various frameworks provide the means for a developer to easily and reliably access low level functionality in areas like voice interaction, machine learning, augmented reality, IoT, health, ... And now, Apple is sharing their internal learning around Swift event handling with developers.

It does make sense to me for Apple to provide additional cloud services, but at this stage they don't need to. If they are headed there I tend to believe that we will see many more of these kinds of projects.

...AWS? That is a completely different game, with very different revenue models than what Apple is doing well at this stage.

[arty123]

I think this is a rather far fetched postulation by the author. The uptake among the developer community will face an uphill battle. Why would I switch when I already have node JS and react native to write my apps? That's applicable for web, android, and iOS. AWS and google cloud are much further along and have extensive offerings, competitive pricing, and geographic availability. Why would I switch? I just don't see this playing out the way the author thinks it will.

[stoplosing]

right. the story for swift for the front end is great if you are just targeting iOS devices but JS has a wider reach. swift on the backend needs to provide all the features of Google firebase before it becomes a reasonable choice there.

[md#23]

Agreed. And speaking of Web Assembly the author should also consider C# that already has the application framework yet to be build with SwiftNIO.

Actually I do not understand why use SwiftNIO for such an article. Kitura would be better and it also has been mentioned at try!

[User 49081631]

You have to take a growth outlook, knowing that this will be in it’s infancy, but eventually will come to compete with the big boys like AWS and Azure. Apple hasn't been first-to-market since the iPhone, but everything else they've stayed patient with (allowing other products to come first, but in the meantime refining a product and then dominating the space) has come to bear fruit. They may be late, but that's not surprising. They have the engineers and time to start competing in the near future.

[mistacurt]

Well, congratulations on this article and thank you very much for this nice piece of software-technical analysis! As a SW-Developer myself, I am with you on the technical side (reduced dev stack) and as an investor I would really like to see something along your line of though to be implemented, because AAPL cannot depend on just the iPhone alone forever.
Thanks once again!

[peterinjapan]

Interesting. Remembering that Apple has a fundamental problem running cloud like networks, they just don't do them well. But we shall see...

[User 7738301]

Yes you're right. Their battery life, and iCloud are their Achilles heels. I can't stand the iCloud I need it but it's so poorly developed it drives me insane. And I'm a huge fan of Apple and a stockholder but I call it like I see it

[User 49081631]

You do realize that Apple has been using Google's/Alphabet's cloud services right?

[G H]

Jiren,

Proof?