Reflections on 0-100 in iOS Development

I’ve wanted to learn iOS development for the past 9 months or so, beginning when my friends and I had the idea for a (now abandoned) social restaurant discovery app. We actually started off with a prototype app from Glide that worked quite wonderfully, and wanted to build the real thing as a native mobile app. I didn’t take the leap then, but once quarantine started, I suddenly found myself with a lot of undistracted time on my hands.

After two weeks of experimenting with Chrome extensions, I decided my next project would be to build an iPhone app. The only problem was that I still had no idea how to do it. I only knew that I wanted to 1) use SwiftUI, Apple’s new framework for building apps, and 2) use Snap Kit, Snapchat’s (relatively) new, and in my opinion underrated, SDK.

I brainstormed potential apps for the Snap Kit SDK and settled on the idea of sharing social challenges to your story. Not sure what that means? Story challenges are random trends that involve performing some dumb action, then nominating friends to do it next. Check out my earlier post here if you want more information. I noticed tons of these challenges popping up in March and April due to quarantine, so I wanted to build the platform for even more challenges to take off.

My app is now in the App Store, but that’s not the point of this post. I want to reflect on ~3 months of going from 0-100 in Swift development. I’m definitely not the only person who’s done this, but it certainly wasn’t easy, so I’d like to share my experience.


Learning

I spent the first 5 weeks building a solid understanding of iOS development, before jumping into anything specific to my project. But even before that, in fall of 2019, I bought a book on Swift, but found it didn’t help very much. I already knew object-oriented programming from Java and the syntax wasn’t too foreign, so nothing in the book was that new to me. Also, I should hugely stress that you need to code to actually understand the concepts. Expecting to learn any skill by reading books is probably a waste of time. Learning by doing is the best method.

In March, I began with Apple’s SwiftUI tutorials, but realized soon after that I couldn’t integrate Snap Kit with SwiftUI [1], so I bit the bullet and started learning UIKit.

In my first real attempt, I started with Stanford’s CS193p course on iOS app development. I saw a few people recommend it on Twitter, so I gave it a shot. When I took the course, the latest materials available were from 2017, which is a bit outdated, but the core concepts still stand. (While writing this post, I realized that the 2020 materials have now been published and the course has pivoted to being entirely SwiftUI-based. [2]) The best part of this course is the programming projects included as homework. If you watch the lectures, be sure to do the projects, since you won’t absorb much without them. The projects were actually quite hard; I often got stuck and felt like I could never get past the issue I was facing. There were definitely times when I felt like iOS programming was the hardest thing I had ever learned. Things just weren’t clicking, but I kept trying and eventually got the hang of it.

After finishing the Stanford course, I began making my app, so the rest of my learning was more ad-hoc. Throughout the process, I relied a lot on Stackoverflow, blog posts, and YouTube videos for help. Here are some of the (free) learning resources I used most:

  • CodeWithChris and LetsBuildThatApp – both solid iOS dev Youtube channels, best for learning how to do specific tasks. They’re good at telling you how to build features, but often gloss over how things work under the hood.

  • Stackoverflow – has answers to pretty much every question, probably the best overall resource

  • Apple Developer Forums – not as good as Stackoverflow, but has good resources as well and answers from actual Apple engineers [3]

  • Raywenderlich.com – has some good interactive tutorials on building features

  • Hacking with Swift – has concise explanations to a lot of problems, very easy to read

For specific, scoped questions, Google/Stackoverflow works best. But for general knowledge of MVC/MVVM architecture and iOS development, do not skip out on a course to learn best practices.


(Aside) on App Design


At most companies, design and development are separate departments that work together, but have separate tasks. But for an independent developer, design is certainly part of the process that can’t be overlooked, so I wanted to reflect on my design experience as well. At first, I decided I would just forget UX mockups and design everything straight from code. That turned out to be a terrible idea. I thought I had the general UX idea in my mind + some sketches, and I wanted to move quickly, so learning Figma felt like another long delay after 1 month of learning Swift.

My mockups in Figma didn't take long at all

The design iteration process in Xcode is extremely slow. Even with a sketch of your UI, determining things like padding, drop shadow opacity, and corner radii can take multiple iterations to get right. Each time, I either needed to change a property in storyboards or in my view controller, then re-build and run my app. I quickly got fed up with this, so I decided to download Figma and do it the right way. I had been meaning to learn it anyways, and the software turned out to be super simple.

Designing with Figma and then implementing my mockups in code, pixel for pixel, gave me a much clearer direction on how to implement my UI. I think of it the same way as the architect-engineer relationship. The architect (designer) pushes the limits of vision and imagination and challenges the engineer (developer) to actually implement. At times the two processes can feel at odds with each other, but overall, they create better products, so it’s best to separate the two in your mind. If you don’t, you often make subconscious compromises for the sake of time and simplicity.

Prototyping UI in Figma is also infinitely faster than in code, and the time saved on this iteration process definitely made up for the upfront cost of learning a new tool.

I’ve heard people say that SwiftUI feels like a prototyping tool, given how quick the iteration process is. Xcode previews show your changes right away­–no need to build and run on a simulator. I still think people will continue to design in Figma first (especially given how great a product it is), but who knows.


The Hard Parts

There were a lot of issues that really made me hate iOS programming. There are bugs that give you some indication of how to fix them, then there are bugs that give you no hope for the future, and make you want to cry. Like I said earlier, there were many times that I felt like iOS development was the hardest thing I have ever learned, and below are a few reasons why.


credit: xkcd.com

UIKit

After starting with SwiftUI, switching to UIKit felt like regressing 10 years in time. The framework is just so much messier and more difficult to understand. For those who aren’t familiar, SwiftUI and UIKit represent 2 completely different ways of building apps.

  • SwiftUI is declarative you tell it what you want to display, and it figures out how to transition there

  • UIKit is imperative – you have to control how the UI changes

With UIKit, it’s harder to do simple things. SwiftUI takes care of a lot of that overhead for you.


I especially hated working with storyboards and autolayout. It felt impossible to get autolayout constraints to work on multiple device sizes, so I basically gave up on a few view controllers when they looked “good enough”. Autolayout issues are also incredibly hard to debug.

But now that I’m so much more proficient in UIKit than in SwiftUI, I find it hard to visualize how to accomplish some tasks with SwiftUI. For example, since there’s no view lifecycle methods, how do you trigger a network task when a view loads? Or since animations are based on a view’s state, how do you run continuous, reversible animations? I bet there are answers to these questions, but they probably involve thinking about the problem from a declarative viewpoint. This connects with the idea of linguistic relativity (the basis for the movie Arrival), which claims that the way you think is dictated by the language you use. If I switch to SwiftUI, I’ll have to shake many notions about how to solve app development problems, since the two frameworks each come with totally different styles of thinking.

Image Fetching with Collection Views

I got hung up for about a week on an issue where my collection view cells would display the wrong image. It turned out that this was due to asynchronous network requests returning even after the cell had been reused for a different item. Collection view cell dequeuing is an opaque and mysterious process, so it was hard to debug. I needed to find a way to discard a network request if the cell contents had changed, and even then, it took a while for me to figure it out.

Memory Leaks

These are some of the most “hidden” bugs, since they usually won’t explicitly crash your application, and when they do, it is very hard to figure out the root of the crash. Instruments is a great tool for monitoring memory leaks, but it can be intimidating for a new developer. My solution to a memory leak problem was to throw [weak self] into most closures, but that is probably not the best practice. [4]


The Best Parts


On the other hand, there are definitely some parts of iOS development that I found really well thought-out and enjoyable.

  • Xcode - has a lot of tools to make development easier. The debug window, simulators, keyboard shortcuts, and code completion are all excellent development tools.

  • Animations – they’re pretty easy to implement in Swift and give some awesome-looking results. A great way to step up your UI.

  • New collection view APIs – Diffable Data Source and Compositional Layout are new collection view features for iOS 13. They solved a lot of potential headaches for me, and since most apps involve some type of collection view, I’d suggest checking them out!

  • Strong developer community - There are 20 million Apple Developers, so there's no shortage of resources if you get stuck on something


The Future

What now? I’ve just barely scratched the surface of iOS development, and there are plenty of areas I want to explore further.

First, I’ll continue to update my current app, Swirl. I’ve mostly shifted focus toward distribution, marketing, and getting feedback from early users right now, but I already have a long list of features that would be exciting to add. On a one-person team, it’s easy to get caught up in adding cool features, but I had to hold back to test out whether people actually wanted the core functionality of my app.

Like you might have already guessed, I really want to do something with SwiftUI. When it was first launched, SwiftUI was pretty limited, but WWDC 2020 announced a bunch of new features for the framework. Now you can build full apps in SwiftUI – no more AppDelegate or SceneDelegate. It seems like Apple is really pushing SwiftUI as the future of iOS development, and I don’t want to get left behind. App Clips and Widgets, two of the biggest features in iOS 14, need to be made with SwiftUI.

The same way that many veteran iOS developers still stick with Objective-C instead of Swift, many developers will stick to UIKit just because they’re familiar with it. They’ll discount SwiftUI to rationalize their decision, but SwiftUI really will make app development 10x easier in the coming years.

Apple demo of new computer vision APIs

Another WWDC announcement that caught my eye was advances in machine learning APIs. Apple algorithms can now detect human body poses and track object trajectories. I’d usually be intimidated by machine learning, but these APIs seem very intuitive and user-friendly. Because of this, I want to make an app that takes advantage of some ML capabilities.


Finally, I’d like to continue working with the Snap Kit platform. Even if my app doesn’t get much traction, I’m using it as a learning experience to carry into future projects. WWDC basically stole the show this June, but the Snap Partner Summit announced a lot of cool features too, including Snap Minis, HTML5 mini apps that run from within Snapchat conversation windows. They also added Camera Kit, which gives apps 3rd party access to Snap’s camera and AR capabilities. I’m inspired by the creative ways that apps have built off of Snap Kit (YOLO, Hoop, TRASH, to name a few), and I want to make something that taps into the Snapchat user base.

I used to feel incompetent having app ideas but no technical expertise to build them, so learning iOS development actually feels really empowering. My overall goal is to learn to build and sell things as best as I can, and eventually use those skills to start a company. Even beyond iOS development, there are so many other things I want to learn/build, so I need to just pick one and get started. [5]



Footnotes

[1] It turns out that wasn’t true. Snap Kit doesn’t technically support any part of iOS 13, but it still worked for me. The reason was the switch from App Delegate to Scene Delegate for handling deeplinks. Oh well.

[2] I’m actually really jealous that the course is now all in SwiftUI. There don’t seem to be any other courses that give a good fundamental overview of SwiftUI development, so I will probably check this out. If you’re looking to start in iOS development, this is probably a great starting point in 2020.

[3] Apple just redesigned their developer forums to look just like Stackoverflow. I think this will become a better resource over time.

[4] Since SwiftUI mostly deals with value types (structs instead of classes), you don’t have to worry as much about memory leaks inside of closures. That’s nice, but you should still understand memory management. I’m sure memory leaks could pop up somewhere else in SwiftUI.

[5] I’d also like to explore web dev (React), Flutter, physical products, and maybe make a Kickstarter.

  • Twitter
  • LinkedIn

© 2023 by Ben Edelstein