Native iOS App Development for Web Developers Explained

Aasif Khan
By Aasif Khan | December 28, 2021 5:10 pm  | 4-min read

Want to get from web development into 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 and Flutter, progressive web apps and full stack Swift development, the web and native apps aren’t so different anymore. Or… are they?

In this tutorial, we’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 tutorial is particularly useful if you’re thinking about a switch from web development to native app development. It’s mostly written from a front-end web development and native iOS/Swift perspective.

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 DevelopmentNative iOS Development
LanguagesHTML, CSS, JavaScript1Swift or Objective-C
Front-end platformsModern browsers2iOS
Back-end platforms3Any, from embedded to PaaS to microservicesCLI or Linux-based webservices (also Perfect, Kitura, etc.)
FrameworksAngular, React, Backbone, Ember, Meteor, Vue, Inferno, Dio, Polymer – are we there yet?Cocoa Touch
EditorsAnyXcode, AppCode
Package ManagersNPM, Bower, Yarn, etc.Swift Package Manager, CocoaPods, Carthage
Layout designFlexbox, grid, floats, positioningSwiftUI or Interface Builder (UIKit)
RenderingDOM, shadow DOM, tree renderingSwiftUI, UIKit, Quartz, Core Graphics rendering
Implementing UI/UXExporting images, ideally as vectors, building layouts by hand, UI frameworksExporting to @2x/@3x etc., building layouts by hand
Design PatternsMVW, MVVM, Reactive, OOP/MVC, Unidirectional flow4OOP/MVC, MVVM, Reactive, Combine, bindings
Local databasesLocal Storage, Web Storage API, Web SQL (unoff), Indexed DB, File Access, CookiesCore Data, Realm, SQLite, etc.
BooleansYay! Truthy values. They’re kinda like true, but we’re not 100% sure…true and false
Low-level execInterpretationCompilation

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 every 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, but now most new apps use Swift. There’s a few package managers, most notably the official Swift Package Manager and CocoaPods. We used to have one layout system, Auto Layout, but since 2019 you can also choose SwiftUI. We all pretty much work with the same design/architectural patterns: 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 Texture for async UI rendering. The most recent entry – a superb UI framework – is SwiftUI. 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, async and await, 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 SwiftUI’s stacks, 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.

SwiftUI definitely changes the playing field for building UIs on Apple platforms. You create UIs with a declarative approach, similar to React, and in a way, even similar to HTML/CSS. Read more here: Get Started with SwiftUI for iOS

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 came 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 Linux-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. We’re currently at ES2019, the 10th edition of JavaScript. All browsers have their own implementations of the language, based on their JavaScript engines. The best supported version is ES5, with ES6/ES76 second best supported in browsers. Frankly, I’m lost here with ES versions – that’s why we have

Swift 5 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, and Swift 5, proved 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, or at least Foundation on Linux/CLI. 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!

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

The new new contestant appears to be Flutter, which is yet another take on cross-platform development. And there’s always still WebAssembly. The closer cross-platfrom gets to the metal, the more native it gets…

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 tutorial:

  • 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…
  • ross-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!

Aasif Khan

Head of SEO at Appy Pie

App Builder

Leave a Reply

Your email address will not be published. Required fields are marked *

Most Popular Posts