Going iOS side: 5 months in.

Yevhenii Kanivets
Nov 4 · 8 min read

Being an Android developer is an extremely interesting and empowering journey. There are so many technologies to learn, so much cool stuff to try, so many apps to develop. But why not take a side-quest and try something different?

Exactly 5 months ago, my onboarding as an iOS developer began. I’m thankful to my team (Mobile Squad @ 360Learning) for giving me this opportunity and supporting me on the way. In this article, I’ll share my pains and gains, so other Android devs can imagine how it’s going on the other side 🍎 and decide for themselves if it worth it.

Much easier than you think

Unfortunately, too many among us have forgotten that we are not just one-language-for-all-the-life coders. But Software Engineers we are! A fresh start on the new language / technology may seem like a radical change, but it’s not. Let me convince you in that.

You’ve spent 5 years in the university learning a wide range of things from Assembler to Haskell, from Algorithms to Concurrent Programming and so on. Then countless hours of self-learning of let’s say Android development to get your first job. And now what?

Talking about the move from Android to iOS, you will probably need 2–4 weeks to ship your first moderate-sized feature to production. Taking into account you have a good mentor, who will be doing reviews and helping you to quickly get the difference between platforms.

Swift ≈ Kotlin

To be honest, it was my second pass to iOS. The first one was almost 3 years ago and only for 2 months. At that time Swift wasn’t that popular and we were refactoring a legacy SDK, so we used Objective-C. It’s really strange (even though C-like) language, which is difficult to start with.

Swift is much better and very close to other modern languages. In essence, it’s almost the same as Kotlin, which we are using for development in our Android app for almost 2 years now. Java isn’t that close, but even that would be enough to make the change simple.

Of course, there are many small syntax-level differences, like:

  • let instead of val
  • func instead of fun
  • switch instead of when
  • and other differences of the same magnitude
Both languages have very similar syntax

Well, it takes a few days to get used to these odds. What if you need to switch between Swift / Kotlin a few times per day? No worries, you will learn to do it on the go. And there is an IDE for that, anyway 😉

But there are also some more fundamental differences in the capabilities of languages, which hurt much more when you are thinking that something is possible, but it isn’t.

  • no abstract classes in Swift, really…
  • no generics in interfaces, but you can use typealias
  • no coroutines, alas
  • extensions are working and used in somewhat different way
  • and many others you will learn on the practice

To overcome these differences you will need a help of a mentor and code reviewers, so they can indicate you the right direction.

XCode, App Code, just code…

Of course, we are all used to Android Studio and are pretty sure that there is an IDE, at least, of the same quality and capabilities for each major development platform. At least for iOS, yeah?

Well, maybe I’m just not an Apple-guy, but XCode s*cks from my personal experience. I was using it for almost 2 weeks and got a noticeable decline in my productivity 😐

Some random picture from the Internet on how XCode looks like

In XCode you are using “Search” to find usages of a given method because “Find Usages” doesn’t really work. There is also very limited capabilities for refactoring. And almost no auto-formatting 🤦‍♂️

I honestly wanted to be the true iOS developer and use XCode, but finally gave a try to App Code (IDE from JetBrains for iOS) and fell into love from the day one. It’s almost like Android Studio, but for iOS.

Some random picture from the Internet on how App Code looks like

Well, it’s not free, but even if 360Learning didn’t pay for my license I would buy it myself. Also I still need to go back to XCode in some cases, like viewing XIBs / Story Boards, publishing the app to App Store, etc.

In my opinion, Apple needs to listen to developers and make changes to their IDE to stay competitive. Otherwise they will loose their own game.

Structuring the project

Can you imagine the situation when you want your project structure to be different from how files and folders are located in the file system? I can’t! But guys from Apple surely can…

Well, let’s imagine there is a good reason for that. But how would you implement such a mapping? Surely, it won’t be a huge single file in a not human-readable format. Yeah?

Nope! This is exactly what you have in *.xcodeproj file, which must be present in any XCode project and tracked by Git. It's the real hassle to resolve merge conflicts, which occurs often only in this "smart" file.

Keeping XCode groups in sync with file system folders is another pain. And even App Code won’t save you from doing this. But there is always a solution, even though it isn’t an official one.

Just few days ago one of our Lead developers finished migration to XCodeGen — open-source tool, which allows you to declare all settings for project in *.yml files and then generate *.xcodeproj automagically.

Finally, we were able to add *.xcodeproj to .gitignore 😉

Crafting beautiful UI

It’s true that UI / UX on the iOS is better than on Android. There are many reasons for that, but here I just want to talk from the developer’s perspective. XIBs and Story Boards are just horrible.

Well, they are pretty to make a demo on WWDC. You know, drag-and-drop a button, quickly add few constraints and voilà, you have everything working in a blink of an eye. But it doesn’t work like that in real life, at least, when you are not the only one working on the project.

Visual Editor to build UI in XCode

Story Board in essence is a huge XIB file, which in its turn just some kind of XML, generated automatically when developer drag-and-drops all that cool stuff. And it’s the main problem — XIBs are not supposed to be human-readable or human-editable.

But nonetheless you get merge conflicts over there, many of them. It’s almost impossible to resolve in a timely manner, so at 360Learning we are using TinyConstraints, which allow to create views and constraints right from the Swift.

Handling errors

Crash-free sessions are much higher on iOS than on Android. I’ve seen it many times across many applications. There are 2 main reasons for that: fundamental approach and fragmentation of ecosystem.

Under difference in fundamental approach I mean that when you have an error on Android (Java / Kotlin) it’s usually thrown as an exception and if it’s unchecked one and you didn’t caught it, your application is crashed. On iOS in case of an error just some special value is returned.

Fragmentation of ecosystem is an obvious reason. On Android we have dozens of thousands different devices with different or custom OS versions, different sets of preinstalled SDK and so on. On iOS you have only dozens of devices, most of which you don’t even support because everybody so obsessed with a new iPhone.

But when you finally get an error on iOS don’t count on logs, which would say on which exact line it happened with all call stack on top of that. I still can’t decrypt some of them.

Typical crash log on iOS

Signing & distributing applications

Capabilities of both developer consoles are pretty much the same, even though for Apple’s Program you must pay $99 / year (for Google Play it’s $25 single payment).

Do you remember struggling with a keystore on Android for the first time? That's nothing comparing to what you need on iOS 😈 Testing devices, testers, developer certificates, provisions are only the part of what you need to just let another person launching your app.

Then there is a review process, which is actually a good idea, but may take a few days and even weeks. So don’t be surprised to get rejections from time to time for reasons you never thought of.

So much pain… Is it that bad?

No, it’s OK, in general. I would say it’s rather a perception shift, which made me notice all that struggles and write about them first. There are many advantages, which make me continue my journey.

  • Unbelievably comprehensive and user-friendly documentation for popular and often-used APIs.
  • Quick adoption of latest version of OS. So support for old ones can be dropped much faster than on Android.
  • Maturity of tools and standard components. UITableView is so multifunctional and feature-rich, that can be used almost for everything.
  • Hardware / software synergy, which makes new features (i.e. ARKit) available for most of devices almost instantly.
  • More generous users on average 🤑
  • And many others, which duplicates Android ones, like great community, open-source tools, events, etc.

Conclusions

I’m fully satisfied with my experience on the iOS side and wouldn’t change anything. I’m planning to switch between Android and iOS contributing to consistency between platforms and increasing overall bandwidth of mobile team.

Thanks one more time to all my team for making it possible!

The original article has been published in my blog.

Links

Yevhenii Kanivets

Written by

Professional Mobile Engineer since 2014, passionated by #EdTech, learning and teaching. Competitive programming enthusiast. Marathon Finisher.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade