Skip to content

Apps Dissected Posts

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

As a refresher from Part 1, we’re trying to make the process of porting Objective-C to Swift code more gradual by porting classes method by method using Swift extensions. This is very helpful in keeping with the idea of “When it comes to porting, smaller steps are better.”

This only gets us so far, though.

Some of the classes you want to port are going to contain business logic for your apps. Model data, calculations on that model data, transformations, etc.

Unfortunately, you cannot move those properties to your extension; extensions don’t support adding stored properties to a class.

What does that mean? You can’t use Swift-only types for your properties, such as structs, enums, Swift arrays, optionals, etc., because they need to be accessible from both Objective-C and Swift.

Does that mean I’m stuck with ugly Objective-C types like NSArray, NSDictionary, etc. in our Swift code, until the entire class is ported?

Thankfully not. While you can’t add stored properties in an extension, you can add computed properties in an extension. By creating computed properties that bridge between the Objective-C properties and a Swift representation of that property, you can still port your class method by method, while still writing your new Swift methods using all of the power of the Swift type system.

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.