Thinking about diving into the world of iOS app development but unsure where to start? You’re not alone. The process can be daunting, especially when choosing from multiple languages, frameworks, and best practices. If may need some advice to help jumpstart your learning or some some words of encouragement to keep up momentum. Here’s 5 tips to learning iOS:
Tip #1: Learn Objective C and Swift.
If you want to program for iOS but can’t decide whether to learn Objective C or Swift, don’t waste your time wavering. Also, don’t choose Swift just because its easier. While Objective C is nearly 25 years old, the reality is that it isn’t going away any time soon. Many companies still have code bases in Objective C and many iOS and OS X frameworks are written in Objective C. You’ll put yourself at a disadvantage if you only learn Swift. Plus, learning both will make you a better developer.
When I first learned to program for iOS, I didn’t have to choose as Objective C was the only option. I remember trudging along reluctantly, finding it to be an ugly, frustrating language to use. When Swift came out in June 2014, I immediately felt relieved to find a much faster, more intuitive language. I fell in love with Swift’s concise and readable syntax (i.e. semicolons are not needed to separate statements) and appreciated its many advantages over Obj-C, such as its conciseness, its speed, and its ability to handle memory management. Coding in Swift made it way easier for me to learn and experience the thrill of quickly seeing tangible results. Needless to say, I immediately jumped ship and didn’t look back.
What Changed
…that was until I started working at SWARM and realized Objective C is still relevant. While Swift seems to be the more preferred language for most projects, we do take on clients with existing apps and those apps are often times coded in Objective C. Plus, legacy libraries are in Objective C. I found myself pouring through old tutorials in order to catch up on what I had assumed would be a lost language. So do yourself a favor and learn both Objective C AND Swift. You never know when you’ll need it. While Swift may be the future, we can’t give up on Objective C just yet.
Tip #2: Storyboards, Nibs, or Code? Learn all three.
When I first learned how to program for iOS, every video tutorial I watched utilized Storyboards. They did this to lay out multiple application views and transitions between them. As a result, I became accustomed to using Storyboards with every single project. I avoided creating views programmatically since Storyboards seemed to be the standard. Even Nibs (or Xibs) I neglected using, since Storyboards seemed to encompass all the pros of using Nibs and more.
When I started at SWARM, however, I learned very quickly that storyboards are not necessarily the best way to graphically lay out a user’s path through an iOS application. I had to learn this the hard way, as when I started I was tasked with working on the new Apple tvOS, the Xcode beta would crash whenever I tried touching a Storyboard. I realized that my team was not using storyboards but instead had built almost all project views with raw code.
Storyboards are great for small projects and when handling things like a master-detail set of views or a set of views for authentication and registration. This is not the case when working on larger applications with a team. Large storyboards can become difficult to browse and maintain, and become even more dificult when multiple developers need to work on the same file. Imagine two or more developers trying to create views and commit simultaneously? Think version control conflicts. Yikes!
Now that I’ve been working at SWARM for almost 10 months I have come to appreciate the beauty and simplicity that comes from grpahically laying out iOS applications programmatically. While it may take up some extra keystrokes, it affords me full control over my creations.
My advice:
Learn storyboards, Nibs and code to create views. Not only will it prepare you for any kind of system you encounter, but it will force you to think critically about the way in which you lay out views and how those views can be reused across different screens.
Tip #3: Don’t rely solely on CocoaPods.
DRY “Don’t Repeat Yourself” is a common development adage used among programmers to avoid repeating code. Developers are encouraged to write code that is reproducible. This is one of the main ideas behind Object Oriented Programming. CocoaPods makes this possible by giving developers over eighteen thousand libraries to simplify tasks and help scale projects.
Alamofire, for example, enables network connection. SnapKit is a programmatic replacement for AutoLayout. The code is well written, it is actively maintained by an open community. While every programmer can agree that CocoaPods are valuable, it is important to be able to code from scratch as there are some scenarios when CocoaPods aren’t the most reliable. For example, when tvOS was first released the vast majority of CocoaPods had not been updated to work with tvOS. As a result, to hit that first day launch, I had to go back to the basics and utilize the native Apple frameworks to get tasks done.
My advice to you is be mindful of the following:
- CocoaPods are relatively new and therefore it’s possible there is a bug or security flaw in the cocoapod. Do your research as much as you can to ensure that it is well documented, supported and secure.
- Updates to cocoapods can cause apps to bugs due to changes in the code.
- Sometimes you can’t use cocoapods i.e when tvOS came out cocoapods weren’t initially available
While CocoaPods can be useful, only the ones that are regularly maintained should be used. Knowing how native frameworks work can also be crucial as it will help you craft your own tailored solutions to client problems. By learning how these frameworks work you could even write your own cocoapods and stand out as a developer.
Tip #4: Unit test your product to minimize the risk, and do it every time.
Unit Testing is often overlooked by developers. With the need to complete features as quickly as possible, most developers skip writing unit testing. Yet we all know that feeling of looking through code for hours to find a bug only to realize it was caused by the simplest of errors. Unit tests can help diagnose bugs and verify that an app is functioning as it should. It will ensure that your code is more reliable, safer and easier to debug. While unit tests cannot be used to test for every single feature, they do help verify that certain portions are functioning exactly as intended. While it may add on to development time, it could significantly reduce bug triage time. In fast paced environments such as agencies like Swarm, utilizing testing has helped us to track down issues early and avoid bugs in builds we supply to our clients.
Tip #5: Your portfolio matters, so build and build often when learning iOS.
The best thing you can do for yourself as a Junior developer, or developer at any level, is to build as many apps as you can. This may sound obvious but many developers forget to commit or submit projects to the app store or to Github. Remember, if your app solves a problem it most likely will solve the same problem for someone else. Even if it’s just a passion project that you enjoyed making, throw it on your Github and showcase your work.
Many job applications have as a base requirement that you must have submitted x apps to the app store. While this is not always a hard and fast requirement, it is important as submitting apps gives you extra confidence knowing that your portfolio speaks for itself. In addition, submitting to the App Store comes with many little details that need to be right before an app will be accepted on the store. Knowing the ins and outs of this process by submitting an app or two will extend your skillset beyond just your ability to write lines of code.
If you don’t decide to submit to the App Store, push it to your Github so that others can see. Even if your project isn’t at the level of complexity you had hoped, you can always improve on it. Don’t just leave those smaller projects unattended and undocumented. Ensure that they are properly documented because if they’re on Github and public then your code is accessible to just about anyone. Quantity matters, but quality matters more. Don’t build the exact same apps. Try to challenge yourself and diversify your portfolio. Go out there and build that Find Chicken and Waffles app you’ve envisioned and send us the link when you’re done!
Check out more helpful tips here.
