iOS devs work alongside us, Android guys, on most projects. But in spite of having the same goal— satisfying end users, I always felt like we speak different languages. Driven by curiosity and goal of improving communication across different technical teams, I decided to try iOS development for a while. The article summarizes what I’ve learned during this short period in 5 parts: high level concepts, basic deep dive findings, resource management, releasing and going out.

Huge kudos to my iOS mentor Leszek Kaczor. This post would not be possible without his willingness to share knowledge.

High Level Concepts

I was very curious to know what architectural pattern is mostly used across AppStore apps. After all, even in Android world, we’ve heard quite a bit about Viper, so I was prepared to get to know it a bit better. To my surprise, the preference of many iOS programmers is good old MVVM.

Xcode remains the most popular IDE in iPhone world. Coming from IntelliJ based Android Studio, I had many problems navigating inside it, but, luckily, there’s also AppCode for comfortable guys like myself.

I was really excited to see how Apple’s shift from Objective-C to Swift in 2014 was similar to current Java-to-Kotlin migration in Android world. Both languages share many commonalities.

Human Interface Guidelines is the only analog to Google’s Material Design I managed to find.

Basic Deep Dive Findings

AndroidManifest.xml and build.gradle are files where general information about your Android app is contained. IMO, iOS made it a bit simpler using visually appealing project files.

Building user interface for iPhones is based on entirely different concept. Whereas on Android we use Activity to create window inside which elements (like TextViews) can be added, on iOS each of such elements (or a group of them) possesses own view controller derived from UIViewController. It is up to developer to decide on creation of main controller for entire screen or dividing responsibilities e. g. one UIViewController for button with text and the other for bottom navigation bar. In a nutshell, one screen can contain multiple view controllers (unlike on Android, where one screen is tied to one Activity).

As a consequence of that, each UIViewController, and its subclasses, can manage state of assigned view (or view group) by using lifecycle callbacks.

iOS is very strict regarding what work can be done for a user in the background. App is only allowed to keep running out of user’s view in very specific cases, which you can browse in Capabilities section of project file. On the other hand, Google introduced similar limits only in the latest Android 8.0.

To reactive programming lovers: RxSwift is very similar to RxJava (or RxKotlin)! The only problem I stumbled upon was a shift from lambdas to Swift’s closures.

I noticed, that iOS coders are masters of delegation and I finally figured out why. Intent may be a big convenience inside Android apps for communicating between system components e.g. Activities, but on Apple’s platform delegate pattern is the best solution for this task! Protocols, which, more or less, are analog to Java’s interfaces are used to achieve a higher level of decoupling from actual implementation of delegate.

Mobile developers targeting iPhone devices were blessed from the very beginning with Core Data, which facilitated persistent storage. Their users were also under constant control of permissions during runtime. Google later caught up on these two essential features by introducing Room and dividing permissions into normal and dangerous.

Adding new dependencies to your Xcode/AppCode project is a bit tricky. It certainly requires more configuration in the beginning than simple copy-paste of few lines into build.gradle. The most popular package managers are CocoaPods and Carthage.

Resource Management

I fell in love with storyboards, which are used to create layouts (later rendered into complicated xml file) using simple, intuitive and bug-free GUI — just drag and drop desired widget. Auto Layout takes care of a proper view positioning by applying constraints (very similar to Constraint Layout on Android).

iPhone comes with only 3 sizes that graphic designers need to take care of: @1, @2 and @3 (for plus). Text localization is not supported out of the box (no strings.xml file) and has to be done by hand.

Releasing

Picture below illustrates the biggest nightmare of every Android dev:

Unfortunately, we don’t only need to support hardware from different manufacturers, but also API ranging even from 4.4 all the way up to latest 8.1. Let’s look at the iOS fragmentation chart from official Apple’s docs:

I’m getting so jealous comparing 65% iOS 11 adoption on January 2018 to 4.6% Android Oreo adoption on April 2018…

Deploying iOS app to physical device is tedious (though it’s all about security). It requires you to enroll in the Apple developer program and go through some setup..well a lot of setup:

App Store review takes about 48 hours for majority of apps.

Going Out

At the beginning of my career, during important internship interview, I was asked interesting question: who is your Android hero? You’ve already read about equivalents of Material Design, Activities or Room, but who is Jake Wharton’s analogue? Though the answer may differ, I found Ash Furrow to be iOS devs’ superhero. Be sure to also check out objc.io or visit WWDC conference for more exposure.

Glossary

To wrap up, I want to try a little experiment. In the comments, post as many Android equivalents from the iOS world and let’s make a little glossary! I’ll start here:

TextView — Label

ProgressBar — Activity Indicator View

this keyword — self keyword

List<String> — [String]

Hope you enjoyed my one-night stand diary.