Skip to content

Apps Dissected Posts

Everybody wants React Native. Should I still learn native iOS?

The market for mobile developers is larger than ever. There’s a good chance that the reason you started learning iOS development in the first place was to get a full-time job building apps.

If that is your motivation, you may have looked at job boards and already had feelings of regret about your decision when you see a major requirement many companies ask for:

React Native.

Even if you really like native iOS development, you wonder whether you would be more marketable as a candidate by learning React Native instead. “I mean, after all, React Native is still mobile development, and I can claim both iOS and Android development, plus knowledge of JavaScript. That’s good, right?”

”I can give up the platform I love for the platform that gets me paid, right?” [cue tiny piece of soul dying inside]

I’m here to say, you shouldn’t need to. There is more than enough interest in native iOS development that — even if you don’t learn React Native at all — you will have no problem finding a job.

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.