Introduction to Swift and iOS development for Web developers

This is the first of a new series of Swift and iOS application development tutorials I will write.

I did a Swift introductory series a few months back, and you can see it here.

I’m not new to iOS / Mac development. I created several applications and games for iOS back in the pre-Swift days, 2011 or so, with Objective-C, and a couple apps in the early days of Swift. Swift is just 6 years old.

I also created several applications for Mac, but based on a Web stack (HTML + CSS + JavaScript), so I don’t count them as native applications.

There’s something special about creating applications that run native code.

Compared to JavaScript, Swift is lower level and due to this it’s inherently more complex, but it also gives you the opportunity to do things that are impossible with JavaScript and the Web in general. The whole ecosystem or iOS frameworks and primitives is much wider and more complex.

This does not mean one is better than the other. They are completely different tools living in a completely different environment. Let’s do a little comparison on the differences between the Web and iOS.

The Web is open. There is nothing stopping you from creating a web site or web application and publish it into the Web. An iOS app on the other hand lives inside Apple’s walled garden. This improves the quality and the security of the platform, at the cost of freedom (and the yearly developer fee). Apple might decide your application does not satisfy its quality requirements, or its policies.

They can deny the publication, or take down the app down the road. And every time you want to release an update, you must wait their approval which might take a few days.

Something that on the Web we don’t have to deal with. On the Web, we are the owners of our work.

The Web is not one single unit. It’s a collection, an ecosystem of tools, each controlled by different companies with different goals. You don’t have any control over your users devices and browsers. With iOS you can decide which devices you support, and there’s just one vendor: Apple.

One thing that is invaluable with writing native code is that your apps live on the iPhone, iPad or Apple Watch as first-class citizens. Having your app, your code, running on these wonderful devices feels great.

Also, on the Web there’s a lot of different vendors each working independently on a particular piece of the pie. There are browsers implementing features with different roadmaps. There are organizations defining standards.

With Swift/iOS development, there’s just Apple deciding for us what’s the future of Swift, what’s the future of the devices, and what will be the shiny new things in the years to come.

On one hand it’s just a single company deciding your future work, and how you’re going to develop for their platform. They can move faster, improving things at speed and at scale. On the other hand, it’s a melting pot of different companies. Which can be good, or bad, depending on how you look at it.

On the Web we can create useful applications that can be used on desktop and laptop computers but also on mobile devices. The problem is that the mobile experience is often sub-par, not because of us developers but due to the platform.

There are limitations put in place by Apple, for security reasons. Web applications can access some hardware like GPS, sensors, camera, and more, but some of the things that make native iOS apps great are an exclusive of a native iOS app.

The push with Progressive Web Apps helped making Web apps better integrated with the system, but I think it worked better with Android than iOS, since the push was mostly driven by Google.

Talking about making your app discovered by people, on the Web, you must take care of the distribution, provisioning and managing servers.

With an iOS app, Apple takes care of that.

And you have access to a market of 1 billion iOS users, one search away in the iOS App Store from your app. This does not mean your app will be used by anyone just because it’s in the App store. Even though the audience is huge, most people just use those famous 5-10 apps all the time. That’s another topic, more related to marketing than to building apps.

You have the same discoverability problem on the Web. Except on the Web we have a better first-time impression with our users. With an app, it’s often times a decision of “install or not install”, while on the Web we can craft a first-time experience as we want.

Those are just a few points I wanted to talk about, a little introduction to iOS for Web Developers, in general terms.

In my mind, there is no competition between the Web and iOS. Both are absolutely great platforms, and some apps might be better suited to one, rather than the other.