Skip to content

Apps Dissected Posts

Porting to Swift? Do it Gradually Using Extensions: Part 1

Despite the fact that Swift has been available to iOS developers for over 4 years now, it’s likely that many long-lived apps still have Objective-C code in them. To keep things up to date, and to take advantage of the more modern Swift language, you will need to port those at least some of those classes to Swift.

You are instantly drawn to your small, simple classes, and you think, “Sure, those won’t be a problem at all. I could knock these out in a couple hours a piece.”

But then you open up one of your large classes. And you freeze.

You know which one. Every codebase has (at least) one. It is one of the core classes of the app: hundreds (or thousands…) of lines of code, many dependencies on other classes in your codebase. It’s a core part of the app; porting this class and testing that the porting doesn’t completely break everything else could takes weeks. Nobody has time for “weeks” anymore.

So you surrender, and those big, hairy Objective-C classes stay big, hairy Objective-C.

It saves unnecessary rework to only refactor code that you are actually changing for another reason. But if you’re only changing one method, you don’t want to port the rest of the class you aren’t touching, because it means extra coding work, extra testing work, extra review work…

Is there a way to port Swift like this, method by method, property by property? There is, by writing Swift extensions for your Objective-C classes.

Xcode and its iOS DeviceSupport directory: can I delete it?

Many of you are trying to do iOS development on a budget. I’ve mentioned it before: Macs are expensive. You may be trying to get by on a small SSD, or this is your main machine and Xcode is competing for space with, well, the rest of your (computing) life.

So you occasionally run your favorite disk usage tool, and you see something like this:

What the heck, Xcode? Gigabytes of space per iOS version?

I could be using that space for something useful. What is it for, and can I delete it?

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:

Cannot convert value of type ‘ObjCBool’ to expected argument type ‘Bool’

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.