Everyday I try to think of 10 ideas. Sometimes interesting, sometimes thought provoking, and often enough pretty stupid. The point is to get the brain thinking, to exercise the brain muscle. Today will be a bit different however, just one idea that I have been mulling over in my head for a while now. It will be addressed to the Apple, Inc. Yes, I know, me telling a huge corporation what to do sounds crazy, but if I don’t, who will? 🙂
You need to make the Apple Cloud, a service that allows developers to design an entire web application, including the front end, the back end, and all of the connecting bits, in Swift, and then upload a compiled application to a cloud hosting service with dynamic scaling.
How would this work?
Ok, so with the pitch out of the way, let’s look a bit closer at this proposition. To do so let’s use a simple example 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 backend 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 stack:
- Linux Server. Either a containerized environment or a VPS with a web server like NginX.
- Backend environment. A project like this could be done in NodeJS or Django.
- Backend storage. Probably mySQL, MariaDB, or Postgre SQL.
- HTML and CSS.
- The App. 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. Would be nice to get it down to 2, wouldn’t it? And it would be possible with the Apple Cloud I am proposing here.
Now let’s imagine how this could be done on the proposed Apple Cloud. The entire web app, including the backend and the frontend 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.
Deploying this would also be simple. You would upload it to the Apple 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 machines and load balanced between them on the fly. MacOS and iOS apps are sandboxed by default, and a similar system would be used for the web apps, which eliminates the need to run containers or virtual servers.
But why Swift?
No reason in particular. It’s a well designed language (personal opinion) 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. Finally, it’s Apple’s brainchild, and Apple has the resources and scale necessary to make a project like this work, and to monetize it.
Benefits of this Approach to Developers
- It significantly simplifies development, especially at the MVP stage, by reducing deployment complexity and providing easy to access scalability.
- Maintaining one codebase is way easier than 4 or 5, and allows for faster iteration with a smaller development team.
- 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. This is not a significant concern for most startups at the moment, but could become so in the future with more AI development.
- Binary libraries also allow for further code security inside the organization. This is more useful for larger organizations.
- Built in efficiency. Fully compiled code runs faster. This means less server load, which in tern means lower hosting bills at the end of the day.
- 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.
Benefits to Apple
So, as long as I am pitching this to Apple, here are some reasons why they should do this:
- Money! Everyone loves money, right? Well, there is a lot of money in cloud hosting nowadays. AWS brings in $10 billion a year in pure profit. That alone should be worth the investment into this project.
- Cloud differentiation. While it can’t be done with a snap of the finger or a press of a button, switching between AWS and Azure isn’t a Herculean undertaking in most cases. On the other side, switching from the Apple cloud would mean rewriting most of the codebase. And even though Swift is open source, the component, HTTP, and storage libraries do not have to be. It’s a good place to be for a cloud host provider.
- 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 solution and marketing it. Of course they would charge a percentage of the subscription to cover hosting fees and to compensate them for the platform access.
With the idea like this the implementation is the tough part. Apple has the money, resources, and the capability to design something like the proposed Apple Cloud. Further, with their current push to shift from products into a service based revenue model, this could be just the project to accomplish that goal. Will this ever happen? Who knows. I have no contacts at Apple, and have no way of pitching this to anyone at the company. But this project would be very uniquely Apple. Bringing elegance to web app development.