Software Engineer job is not only exciting but also compensates well these days. You’re creating amazing products, making people’s lives better and spend your entire day in a cozy warm office with a friendly community. Few of my friends asked me how I started my career as an iOS Developer and what are the first steps they should take if they want to. First, I’d sent them to kodeco.com [ex RayWenderlich.com]. Ray had many great tutorials a few years ago which I used to get in touch with some new frameworks and technologies. As we found later, recently he started charging his users for a paid subscription for access to most of the articles. So, I want to provide you with a free, alternative guide. In this part I would start with:
- initial requirements,
- guide you through the latest technology trends
- give you some useful tips on how to make learning fun and productive
In the next part, I’ll provide you with a review of best available courses and give you some links to documentation/tutorials for the most popular technologies and frameworks we use in production environment. In the final part, I would help you with preparing for your very first job interview.
Technical requirements
You may have seen those monitors with black windows full of endless lines of text in movies. In real life, we don’t use the Terminal, Notepad or other text editing software for writing code. We have an Integrated Development Environment (IDE) for that. Writing an iOS code is only possible with Xcode provided by Apple.
Also, Xcode runs only on Macs with installed macOS. Of course, there are some alternative ways supplemented by enthusiasts. You could try to install macOS on your PC or laptop [it called Hackintosh], try running a virtual machine with Parallels, VirtualBox and other virtualization technologies. There’s no such thing as a free lunch. In return of using these workarounds, you’ll get low frame rate, a lot of freezes and crashes. It would bring you so much pain so you would drop the study eventually. So, I recommend you to get a Mac.
The new M-chips developed by Apple are extremely powerful, so even with a basic MacBook Air you would get a great performance. However, it's better to fit it with 16GB RAM, or even better with 24/32GB because Xcode would love use all the memory you have :) Here is a short list of possible options:
- Mac mini with M2 chip and with custom configuration of 16GB memory for just $799 would be a cheapest possible option to start with
- MacBook Air with M2 chip and custom configuration of 16GB memory for $1,399 is light and powerful option
- 16-inch MacBook Pro with M2 Pro chip for $2,499 would be most comfortable to work on
If money isn’t a problem for you, go for 16-inch MacBook Pro. Its high-performance, lightweight and gorgeous display makes it the best laptop to write code. It’s a de-facto industry standard for a lot of professional developers. However, if you’re tighter on a budget, you should start with Mac mini and your existing monitor. You could also try searching on eBay, but make sure to check everything is working fine before giving your money away. As an example, you could easily find 2018–2019 16-inch MacBook Pro for less than $1,000 there.
Most professional developers I know also prefer using one or two 27" monitors to work with more windows and keep the eyes safe. Apple's Studio Display is gorgeous but expensive option.
Also, you would need an iPhone. Although Xcode has a great built-in iOS Simulator, it still doesn’t support full list of features the real device has. iPad is suitable for development too. However, if you have neither of them, I would suggest purchasing an iPhone because it has a much bigger market share, therefore, more users and more apps. I wouldn’t recommend you going for anything older than iPhone X mostly because of possible performance issues. Sure, the latest iPhone is the best, but you still could run your apps smoothly even on SE.
BTW, if you’re new the Mac world, you could download latest macOS version from the Mac App Store for FREE [open Applications folder on your Mac], and you would find an Xcode there too, also available free of charge.
Apple Developer Program
Signing up to ADP is another must-have action on your way of becoming an iOS developer. However, you don’t have to pay for it from the beginning. For years Apple had two different levels of their program: Standard ($99) for publishing apps to the App Store and Enterprise ($299) for corporate app development to publish to the internal app distribution system without public access. Recently they announced a new Individual program suitable for beginners. It’s completely FREE. With this program, you would get access to all Apple-provided development resources and documentation, WWDC videos, and would also become able to launch your test apps on the physical device. You wouldn’t get access to TestFlight, a beta distribution system hosted by Apple, and iTunes Connect (which was recently renamed to App Store Connect), a web portal to submit your apps to the App Store and manage them later. When you’d need a publish your first app, you could easily upgrade your program to Standard level.
To sign up go to developer.apple.com.
Technology trends
Like any other industry, we, in iOS development, have a few "holy wars" on whether or not to use specific technology:
- Native vs. cross-platform
- Swift vs. Objective-C
- Xcode vs. other IDEs
- UIKit vs. SwiftUI
- UIKit Storyboards or writing UI in code
- Rx (RxSwift, ReactiveCocoa) vs. Combine
I’ll provide some initial points and my opinion on those topics below.
The idea of writing code once and launching it on both iOS and Android [and maybe even on Windows Phone] sounds pretty exciting. However, in real life, it doesn’t look so bright & shiny. There were four significant attempts to solve this problem: PhoneGap, Xamarin (from Microsoft), ReactNative (from Facebook) and Flutter (from Google).
PhoneGap was based on WebViews contained HTML and JavaScript. The primary issue was poor performance and usability: UI controls and animations don’t feel anywhere close to native for the user. Xamarin has chosen a different way. They tried to translate C# code you’re writing to native code. Again, they’d got poor performance, lower usability and enormously long delays supporting new features. Being a popular framework for Web development, React tried to conquer mobile apps with ReactNative extension. You need to write JavaScript code, which later compiles to two native apps: one for iOS, one for Android. JS is a very popular technology these days, and there are a lot of JS developers on the market. So, we, the native developers, were a little bit scared of losing our jobs. Hopefully, even with Facebook support, ReactNative became another great failure. It features the same problems as its predecessors: poor performance, a lot of bugs/crashes, usability issues and, as always, you still need to write some native code to get access to system features or lower level hardware. AirBnb had recently published a fantastic article of their experience with ReactNative [spoiler: they’re sunsetting it]. You’ll find more details here. Both these technologies are almost dead right now. Flutter is the same idea from Google. Once again, it's good if you need to build quick prototype, but not suitable for bigger projects focused on great user experience and stability. The main reason for cross-platform technologies failures, in my opinion, is the need to support platform-specific changes and features. Every year Apple and Google release new versions of their Operating Systems full of new functions and SDK changes. With native development, you have access to beta versions and could prepare your app for upcoming changes. With any cross-platform technology, you have to wait until the developer this technology would release an update. Usually, it takes months. As for market-specific reasons, I would estimate that less than 1 of 20 companies chose to go cross-platform. So, the market for native developers is much bigger, and that’s great for you!
There are 2 main programming languages you could use to develop iOS apps: Objective-C and Swift. When I started my career [iOS 3.x times], Obj-C was the only option. Not going more in-depth into details, would point that Obj-C is based on C language which is pretty old these days. In 2014 Apple released a new modern language — Swift and they want you to use it. My team started the transition to Swift right after its first release, and we’d got many benefits: it’s simpler, safer, faster and more expressive language. It’s also much easier to learn and understand. From my point of expertise, I would estimate that Swift adoption was very successful: every new project today starts with pure Swift and the most of existing projects either already completed transition or at 80-95% of doing so. I don’t know any single developer who would be willing to write Objective-C code, so it’s incredibly challenging to find new developers for these companies which stuck with Obj-C. However, language is just a tool, and if you’re familiar with Swift and iOS SDK, you should be able to support and bug fix old Obj-C code. SDK knowledge is much more critical in this case. So, if you’re starting your way of becoming an iOS developer, go for Swift.
There are not so many alternative IDEs to Xcode. Xcode is doing a pretty great job these days. My teammates from Android community, actually, found that it’s doing better than Android studio :) The only alternative IDE that worth looking at is App Code, but you would have to pay for it, and you’d still have to use Interface Builder built-in in the Xcode. I use Xcode. It’s Apple-provided so you would get all the latest features and updates right after release.
SwiftUI is a new modern UI framework from Apple. During first releases it missed a lot of required functions easily available in UIKit, so not many teams decided to use it in their production environment. And like any other Apple's frameworks it misses backward compatibility. Starting from iOS 15 SwiftUI had finally got most of required features and components. So it could be used in new projects. But it's still too early to use it in existing apps if you have to support older versions of iOS. That's why I would start learning UIKit first.
Another hot discussion we had in the iOS community is whether or not use Storyboards. It’s UIKit's tool to create app’s user interface without in graphical editor without [almost] any line of code. With iOS 2.0 Apple introduced an iOS Interface Builder which allowed to create a single screen of the app. You could find the names NIB or XIB. It’s the name for a file containing user interface. XIB is the latest version. A few years later they introduced Storyboards, the way not only to build a single screen, but also to create transitions between screens, or making navigation. The main issues with Storyboards are lack of ability to reuse components [you still have to write code for that] and merge conflicts happening when more than one developer is trying to make changes in a single file at the same time. Also, you could get some performance issues while trying to open Storyboards containing many screens. Apple’s solution for that is Storyboard References, the way to separate one huge file into few smaller. So, it's ok to use Storyboards while learning UIKit but it's better to write UI in code in bigger projects.
Rx [Reactive eXtensions] is the technology which implements reactive programming paradigm. In a few words, it’s an alternative way to organize data flow in a multi-threading environment. While RxJava quickly became extremely popular in the Android community, a very low number of iOS teams widely adopted RxSwift/ReactiveCocoa. I see two main reasons for this. The first is that Apple’s GCD is helping a lot working with multiple threads, while Android’s AsyncTasks were not so useful. The second is that it affects your entire project so deep, so you need to rethink core architecture and code style completely. It would also raise the bar for newcomers: due to the low adoption of this technology in the iOS community there are not so many experts in it, so you’ll have to hire and teach new guys. It’s also important to notice that with the release of Kotlin’s coroutines RxJava started losing its positions within the Android community. I think that you shouldn’t worry about Rx and could skip this technology. Lately Apple introduced own reactive framework - Combine. However it doesn't seem to be widely popular due to completely different approach comparing to normal development practice.
Let’s summarize all the above:
- Go for Native. It’s in very high demand these days
- Start with Swift, it’s the future
- Use Xcode for your first steps
- Learn UIKit first
- Storyboards would save you much time
- You don’t need to think about Rx at the beginning
Build your portfolio from the very beginning
Most of the tutorials would teach you how to use a new technology or framework. Unfortunately, that’s not enough to succeed in the interview. People want to see not just your knowledge, but also the results you’d got. The best way to do so is to write a real iOS app or two. That would also help you to get more practice making your knowledge deeper and yourself — more valuable candidate. Don’t try to make another Facebook or Instagram, they have thousands of developers working on their site. What you really could do is create a simple and beautiful app which would make people’s lives better. Here are some examples:
- Weather app
- Shopping list
- Expenses tracker
- Time tracker
Sure, you may continue this list. So, the key is taking one idea and making it real. First of all, you’d need a UI design. Don’t try to make it complete and final from the beginning. Try drawing some screens on paper, browse the App Store and iOS built-in apps to study your competitors. Pick up the most exciting ideas and focus on what’s really important. You could learn more about how I’ve done that in this article. Then find out what technologies you need to use to complete your app. For example, for Weather app you would need to learn:
- Swift as a programming language,
- Apple’s UIKit to create a user interface for your app,
- Alamofire to get a forecast from the remote server,
- How to work with JSON and parse data into objects,
- CoreLocation to get user’s current coordinates and show appropriate forecast inside your app,
- CoreData or Realm to make your forecasts available offline.
Some part of this list would be the same for any other app of your choice. Sure, some technologies would be an app-specific. If you have enough time and want to learn more in-depth, pick up the second idea and create another app. It would help you with your interviews, not only to pass it but also to get yourself a higher compensation level.
Remember:
- Pick up an idea
- Create a UI prototype (on a paper, or take screenshots of apps you like)
- Focus only on important features
- Move with smaller steps to your own very first app
Tip: if you’d choose to create a weather app, check the AccuWeather APIs, they provide some weather data for free :)
What we’d got here
After reading this first part of my tutorial, you should have:
- Mac with the latest version of macOS installed
- Xcode
- iPhone
- Apple Developer Account
- Higher-level understanding of recent technology trends
- A bright idea of your very first iOS App and some UI prototypes for that
In the second part of this tutorial I’m going to review ready-made courses and provide you with useful frameworks and libraries.
Top comments (0)