Native iOS App Development for Web Developers Explained
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.
Table of Contents
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
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
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
2 This includes tools like Electron.
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.
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
Grab your popcorn…
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:
- Both languages are suitable for functional programming.
- 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, Famo.us, 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:
- 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 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 Parse.com’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…
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.
- 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!
- How to Improve Website SEO With Chatbots?
- Arrays in Swift Explained
- How to Design the Perfect App Store Icon?
- How GDPR Would Enhance Website Design and Development?
- Which MacBook is Good Enough for iOS Development?
- Native vs Hybrid App Development – Choosing the Right Development Path for your App
- Revealed – A Flaw Which Allows Hackers To Modify Apps Without Changing Signatures In Android
- 9 Asana Integrations to Change the Way You Work!
- Reasons Why Mobile Apps Fail & How To Avoid Them
- What is a Finsta?
Most Popular Posts
- Dates, DateComponents and Formatting in Swift
By Aasif Khan | December 6, 2021
- How Slack Improves Workplace Productivity? [Top 10 Slack Integrations]
By Abhinav Girdhar | September 9, 2020
- Watch Out For These E-commerce Trends In 2018
By Abhinav Girdhar | December 7, 2017
- How To Build Apps for Enterprise and B2B
By Abhinav Girdhar | January 3, 2022
- Major HubSpot Integrations for Workflow Automation
By Abhinav Girdhar | February 3, 2021