Native iOS App Development for Web Developers Explained

Written by: Reinder de Vries, August 16 2017, in App Development

Native iOS App Development for Web Developers Explained

Want to switch from web development to native iOS app development? Here’s what you need to know…

The gap between native development and web development is drawing closer. With tools like React Native, progressive web apps and full stack Swift development, the web and native apps aren’t so different anymore. Or… are they?

In this article, you’re going to take a look at the differences and similarities between web development and native iOS app development. Especially when it comes to programming languages, tools and frameworks.

This article is particularly useful if you’re thinking about a switch from web development to native app development. It’s mostly written from a JavaScript and iOS/Swift perspective.

Did I make any heretic mistakes in this article? Which side are you on? Let me know in the comments!


  1. Web vs. Native: A Side-by-Side
  2. Languages: JavaScript vs. Swift
  3. The Holy Grail: Cross-Platform Tools
  4. What’s Next?

Web vs. Native: A Side-by-Side

Let’s start out with a quick side-by-side comparison of web development vs. native app development.

Web Development Native iOS Development
Languages HTML, CSS, JavaScript1 Swift or Objective-C
Front-end platforms Modern browsers2 iOS
Back-end platforms3 Any, from embedded to PaaS to microservices Mostly Ubuntu-based webservices like Perfect
Frameworks Angular, React, Backbone, Ember, Meteor, Vue, Inferno, Dio, Polymer – are we there yet? Cocoa Touch
Editors Any Xcode, AppCode
Package Managers NPM, Bower, Yarn, etc. CocoaPods, Carthage, Swift Package Manager
Layout design Flexbox, grid, floats, positioning Auto Layout with Interface Builder
Rendering DOM, shadow DOM, tree rendering UIKit, Quartz, Core Graphics rendering
Implementing UI/UX Exporting images, ideally as vectors, building layouts by hand Exporting to pixels, in different sizes, building layouts by hand
Design Patterns MVW, MVVM, Reactive, OOP/MVC, Unidirectional flow4 OOP/MVC, MVVM, Reactive
Local databases Local Storage, Web Storage API, Web SQL (early), Indexed DB (early), File Access, Cookies Core Data, Realm, SQLite, etc.
Low-level exec Interpretation Compilation

1 Also languages that compile to JavaScript, like TypeScript, CoffeeScript, Dart.
2 This includes tools like Electron.
3 Platforms that run JavaScript or Swift, so not back-ends you can connect to.
4 These things change about once a week…

The first thing that stands out is: you can almost put “Any” in the Web Development column, because there’s so much choice!

The iOS app development environment and ecosystem is pretty monotheistic: there’s one platform, iOS, that you can build for with one IDE, Xcode, with one SDK, Cocoa Touch. For years you could choose from one language, Objective-C. There’s one major package manager, CocoaPods, one layout system, Auto Layout, and we all pretty much work with the same design pattern: OOP / MVC / MVVM (with the exception of Reactive Programming).

In recent years, there’s come more choice for iOS developers. If you’re sick of Xcode, you can choose to work with AppCode (from JetBrains). Objective-C was switched out for Swift, and is now the beginner’s language of choice. Reactive programming and stuff like promises came to iOS, as well as more elaborate framework-like libraries such as AsyncDisplayKit, for async UI rendering. On iOS, Core Data, a long-time default for persistence and data modeling, got more nimble and agile competitors, like Realm.

A web environment is different than an Operating System’s environment. When coding apps for the browser, you almost never have to worry about memory allocation, or in which thread you update the UI.

JavaScript has a callback flow, i.e. function calls are executed in order once the main stack is empty. JavaScript handles asynchonous code very well, by design, with promises, yield and async (ES6/ES7), but it doesn’t have bare-bones control of threads. All that is different on iOS.

Likewise, in a web app it’s fairly easy to make changes to the DOM and see them reflected in the web page. On iOS, changes to the navigation, layout, constraints and views all need to be made at specific points, with specific functions. In that sense, an OS environment like iOS is stricter and less forgiving than a browser environment.

Auto Layout, the most commonly used layout system for native iOS apps, has a predecessor: Autoresizing. With Autoresizing, you’d position a UI element in an position: absolute-like manner, and give it a few ideas on what to do if the screen size gets bigger or smaller, like “expand to the left”.

With Auto Layout, you position UI elements in a “relative” manner, mostly based on margins between items (called Constraints). Unlike CSS media selectors, Auto Layout can’t set specifics on minor screen changes, like a rotation from portrait to landscape. It can, however, distinguish between major screen changes, like the difference from iPhone to iPad (with Size Classes).

Perhaps the biggest difference in layout systems is that on iOS, views don’t wrap. When a view is too big, it’ll cap its size and clip (or overflow), but it’ll never jump further down the page until there’s room. Not until recently iOS developers got access to the StackView, which allows subviews to stack on top of each other similarly to how flexboxes work.

Similarly – because there are distinct differences. Perhaps the only thing that’s truly the same is that all of these layout systems take some getting used to.

Grab My Free iOS Development Course

Get complementary access to my course, Zero to App Store, and learn how you can build a real-time chat app with Firebase and Swift!

Yes, Send Me The Free Course!

Languages: JavaScript vs. Swift

Grab your popcorn…

Apart from HTML and CSS, JavaScript is your language of choice if you’re a front-end web developer5. Chances are that if you build back-ends as well, you’re working with JavaScript there too, which makes you a “full stack” developer.

Until recently, “full stack” didn’t exist when it comes to native iOS development. When Swift went open source, a few back-end Swift platforms were created, most notably Perfect, Vapor and Kitura. Unlike JavaScript, that can run on anything that has a JS interpreter, Swift back-end programming is mostly bound to Ubuntu-like webservers.

But… which is greater, JavaScript or Swift? It’s hard to say. Both languages are great for beginners, and both languages have smart syntaxes, and they’re widely used.

The biggest differences are the languages themselves. Swift is strong-typed and static, whereas JavaScript is untyped and dynamic. JavaScript runs on an interpreter, whereas Swift code is always compiled before running.

You could say that in typical Swift code you’ll find mostly functions and code blocks, whereas in typical JavaScript code you’ll always find a third-party framework and more scripting. A JavaScript-based web app always provides the interpreter with framework code, whereas Swift code uses operating system frameworks like Cocoa Touch, and only executes compiled frameworks.

JavaScript’s versions are… confusing. There’s a JavaScript 2015 version that’s also called ECMAScript 6 (ES6), and JavaScript 2016 === ES7. All browsers have their own implementations of the language, based on their JavaScript engines. The best supported version is ES5, with ES6 second best supported in browsers, and ES7 being the most recent but poorly supported version6.

Swift 3 is currently the most recent version of the Swift language. It was initially developed by Chris Lattner at Apple, who is best known as the main author of LLVM. The development of Swift is now in the hands of the open-source community.

The switch from Swift 2 to Swift 3 was a challenge for many iOS developers, because the language upgrade introduced many breaking changes in existing code. The Swift language has seen a surge in adoption rate since 2015, resulting in a lot of new questions on sites like StackOverflow, which resulted in wrong or out-of-date StackOverflow questions and answers. The change to Swift 4 promises to be less of a hassle.

You could conclude that:

  • Swift is a smaller language compared to JavaScript.
  • Swift is less a scripting language than JavaScript, relying heavily on classes, structs and protocols.
  • Both languages are suitable for functional programming.
  • Swift is almost always used together with Cocoa Touch. This is different than a web app environment, where you either use a framework like Angular or React, or you code “vanilla” JavaScript (or a language that compiles to JS).
  • Perhaps the one thing that makes Swift more compelling for developers, is that there’s simply not so much choice!

5 Unless you go for something like Dart, CoffeeScript, TypeScript or… heaven forbid: ActionScript 3!
6 See:

Quick Note: Are you learning how to code iOS apps? Check out Zero to App Store, the iOS development course I created.
» Learn more about Zero to App Store

The Holy Grail: Cross-Platform Tools

If there’s one thing that native iOS developers and web developers have in common, then it’s an unwavering religious belief in some tool, some language, and some framework. I haven’t ever met a developer, from both camps, that wasn’t ecstatic about some new tool.

All religion come with beliefs, and for web and native developers that’s no different. Many of them even share a belief: that there’s one platform, one language to rule them all.

As a web developer, you have intricate knowledge about making a web app or website work in all browsers. As a native app developer, you always try to make your apps work on both iOS and Android.

We all believe in that holy grail: the cross-platform tool. It doesn’t matter how hard Apple, Google, Microsoft, Facebook and Amazon try to keep their cashflows separate – we’ll keep marching onwards to that one tool that will run on all platforms.

The latest contestant: React Native.

Don’t get me wrong – I’m skeptical of all cross-platform tools. If you go all the way back to when I started coding apps, you’ll come across jQuery Mobile, Cordova, PhoneGap, Xamarin, Sencha Touch,, Ionic… These platforms provide a native-like experience, but some have drawbacks, mainly because they’re based on HTML 5. In some cases you have to write platform-specific code, which defeats the purpose of a truly cross-platform tool.

Since then, these tools have grown up, but I haven’t seen an exodus yet from native platforms to one cross-platform tool. If anything, the cross-platform app landscape has become more fragmented, much like the web itself.

React Native is different:

  • First off, you can use JavaScript. When you’re coming from the web, JavaScript is probably already your programming language of choice.
  • Second, despite the fact that React Native apps don’t compile to native apps, the experience is still native, i.e. your React Native JS code powers native components, unlike clunky HTML5 webview hybrids.
  • Third, React Native uses many of the native frameworks, like UIView from UIKit. With typical cross-platform tools you literally throw away good platform frameworks – with React Native, you don’t.

But… is it really cross-platform? I’ve asked around and two common opinions arose:

  • React Native is semi-cross platform. You learn JavaScript once, and code per platform, and build per platform. Your React Native code doesn’t cover both iOS and Android for 100%, but you can reuse much of the common codebase on both platforms.
  • React Native is fully cross-platform. You code once, and deploy on both platforms. Components such as NativeBase and wix/react-native-navigation fill the gaps between native wrappers for iOS and Android.

Working with any cross-platform tools, React Native included, has some cons and risks:

  • When React Native is all you know, you become platform-dependent. Compare it to learning to play piano. You don’t want to be that person who can only play one song. Because React Native uses native code under the hood, it definitely helps to understand how native code works – and for that you have to learn about Swift, iOS and Cocoa Touch. If you want to integrate iOS-only frameworks like SiriKit, understanding the native iOS SDKs becomes even more important.
  • The web and an Operating System like iOS are different environments. When you’re coming from the web, it’s easy to think your app UI gets updated in a simple non-blocking runloop – but reality is different. When you never learn native iOS development, you risk never understanding it. When the job requires you to do something different, you get stuck. If you decide to stay stuck, building apps with React Native is nothing more than a point-and-click prefab app builder. Hone the “native” in React Native!
  • React Native is created by Facebook, one of the Internet Big Five, that simply wants a piece of the mobile platforms pie. Even though’s shutdown doesn’t really compare, I still wouldn’t put all my eggs in one basket. On top of that, React Native’s patent and its licensing practices remain controversial.

So.. what do you do? When in doubt, ask yourself: “Which tool is best for the job at hand?” Never choose a platform because everyone uses it7, or because you believe that cross-platform is by definition better than native. There’s nothing worse than choosing a platform simply because you think it’s the best, regardless of use case and implementation.

7 This is called HDD – Hype Driven Development

What’s Next?

Still interested in switching from web development to native iOS development? Here’s what you need to know:

  • It’s easiest to pick Xcode, Interface Builder, Auto Layout, CocoaPods and Swift as your weapons of choice.
  • Either go straight for React Native, or any other cross-platform tool, or choose native development with Swift. When you go React Native-first, it’s strongly recommended to also learn native development.
  • Start with a simple app project, and build on top of that with features of your own design. It may help you to find native equivalents for things you used to do on the web, like your favourite framework, back-end, or layout tool.

Key take-aways of this article:

  • When it comes to comparing web and native development, native developers have less choice, and this can limit you, but it also makes developing simpler.
  • A browser environment is different from an Operating System environment. If you don’t reset your sights, and create a native app thinking it works just like a browser-based app, you’ll definitely run into problems.
  • JavaScript can be confusing – Swift too. Swift is less a scripting language, more a object- and protocol-based language. Both are equally decent – you’ll find that Swift feels familiar, coming from JavaScript.
  • Layout and design systems can be wholly confusing, Auto Layout is in that sense no different than flexbox, and different in any and every other way…
  • Cross-platform tools are great, and React Native appears to be the first tool to really deliver on the “cross” in “cross-platform”. Mind the downsides, though!

Learn more about iOS app development:

Did I make any heretic mistakes in this article? Which side are you on? Let me know in the comments!

Enjoyed this article? Please share it!

Native iOS App Development for Web Developers Explained Click To Tweet

Written By: Reinder de Vries

Reinder de Vries is an indie app developer who teaches aspiring app developers and marketers how to build their own apps at Since 2009 he has developed over 50 apps for iOS, Android and the web, and his code is used by millions of users all over the globe. When Reinder isn't building apps, he enjoys strong espresso and traveling.

Grab My Free iOS Development Course

Get complementary access to my course, Zero to App Store, and learn how you can build a real-time chat app with Firebase and Swift!

Yes, Send Me The Free Course!

Comments & Thoughts