Skip to content

Apps Dissected Posts

Faster UI Code Reviews Using Screenshot and Video Diffs

Code review is an integral part of multiple developers working on the same project, whether you are on a team of developers, or contributing changes to public open source projects. In either case, the reviewer needs to be comfortable with your changes before they will merge them.

This leads to one law of code review: The clearer it is to the reviewer what changes you made, the faster the reviewer can review and merge your changes.

Unfortunately, this gets complicated when you’re developing iOS UI. Whether your team has chosen Storyboards, programmatic UIs, or a combination of the two, reading either Storyboard XML or code diffs is really hard to visualize for anything beyond trivial changes. Worse, if you have a combination of storyboards and code — which is often the case — you can’t necessarily trust that the storyboards before and after even look like what the app does.

To make the intent of your changes clear, you need another way to show that diff. For larger UI changes, representing those diffs as either screenshots or video is key in making those changes as clear as possible.

When is a Bool not a Bool?

This is a silly question — or rather, it should be a silly question — but it’s going to bite you sometimes when you integrate Objective-C and Swift code together (*cough* UIKit).

You will try to use what you think is a Bool from an Objective-C API, and suddenly you’re getting this compile error:

This is a Boolean value; why can’t I use this @($^ thing as a Bool?

Normally the standard types play nice between Objective-C and Swift. But Bools are an unusual case that require a non-obvious solution.

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.