Skip to content

Apps Dissected Posts

Force unwrapping is not just “not Swift-like.” It’s wrong.

Swift comes with a number of features that help developers write correct bug-free programs: optionals, safe casting, and built-in error handling. But for every one of these, there is an escape hatch: !, the force unwrapping operator.

You may know another developer or team member who plays a little fast and loose with force unwrapping. Or you don’t feel like doing the additional boilerplate to unwrap an optional, so you do it when “nobody’s looking.”

You may not have a good argument for why safe unwrapping is good and force unwrapping is bad, other than that the Swift documentation says so, or “that’s how it’s done.”

The reason behind safe unwrapping comes from a long history of languages that didn’t provide strong safeties such as these. This often resulted in trying to interpret random memory locations as objects, resulting in crashes at best, hard to debug app behavior at worst. Not using all of Swift’s safety mechanisms at your disposal is not just not Swift-like, it is bad programming.

Why do these $?@!% files keep changing? Stop the file churn in Xcode with a gitignore file

Xcode has had Source Control support via git for a long time. Somehow it’s amazing that even now, in its default configuration, you may find that all sorts of files that show up in your repos that you don’t want: .DS_Store, xcuserstate, build, .ipa files, just for starters.

You want to do the right thing, and you know or have heard that checking user-specific files, temporary files, or build products into source control is not the right thing. You want to avoid merge conflicts that result from files that frequently change. Or you’re just tired of doing something in your IDE, and suddenly your project has modified files to commit.

You should be able to tell Xcode that you want Source Control in your project, and it should handle everything the right way. But Xcode lets you down by not handling this correctly.

What do you do? The good news is that the solution is just a couple of steps away, by applying a gitignore file in your repo.

MVC? MVVM? VIPER? Which iOS architecture do I start with?

When you’re investigating iOS development, early on you will run into discussions about iOS app architectures, and start getting hit with a wall of acronyms and jargon: MVC, MVVM, MVP, VIPER, RIBS, Clean, RxSwift, ReactiveCocoa, and even more. You will also find heated discussions online where developers sing the praises of the architecture of their choice, whether it is the more modern patterns such as MVVM or VIPER, or the tried and true MVC.

With all of these choices and all of these opinions, you will quickly ask the question: which one do I start with?

While many of the other architectures are newer, and can solve some of the problems of iOS development (when done correctly), there is really only one answer to the question which one you should start with: MVC.

When am I ready?

When we all start learning app development, there is a primary reason: to be able to develop and publish apps. Once you have some lessons, tutorials, and books under your belt, the nagging questions start:

How much do I need to learn?
What are the things I absolutely must know?
What are the right decisions? The best practices?
What if I haven’t learned the right thing yet?

WHEN AM I READY?

BREAKING NEWS: There are no gatekeepers. There is no group of anointed gurus who will look at your learning, see that it is good, and decree, “Yes, you may now develop apps.” The good news is that if you are asking this question, the answer is simple: now.

Got JSON? Need objects? Stop typing, and start generating your object models with Quicktype

It’s time to integrate another API into your app.

That statement alone brings all these feelings to mind:

  • Poring over the API documentation, teasing out the JSON requests and responses for each call you need to use
  • Extracting a schema out of those requests and responses, being mindful of the structures, types, and required/optional state of each field
  • Writing the Swift or Objective-C code to translate those JSON schema into an object model

Hours gone in an instant. Isn’t parsing and translation something a computer should be taking care of? It can, using a tool called Quicktype.