A step-by-step approach to using Swift with Objective-C.
If you’ve got an existing app written in Objective-C, migrating it into Swift is an excellent exercise for learning Swift, experimenting with Swift, and deciding whether to adopt Swift on a full-time basis. I’ve performed this migration with several real apps, so here are some tips culled from my actual experience.
You’re surely not going to translate all your code into Swift at once; you’re much more likely to translate one class at a time. As soon as you add a Swift file to your Objective-C app target, you’ve got a hybrid target: some classes are written in Swift, while other other classes are written in Objective-C. Thus, declarations in each language will need to be visible to the other language. Before you start, it’s a good idea to understand how this visibility works.
Recall that an Objective-C class declaration is conventionally spread over two files: a header file (.h) containing the
@interface section, and a code file (.m) containing the
@implementation section. If a .m file needs to know about a class, it imports the corresponding .h file.
Visibility of Swift and Objective-C to one another depends upon this convention: it works through .h files. There are two directions of visibility, and they must be considered separately.
RYO small floating view containing any interface you like
Of all the new features and APIs that iOS 7 provides to developers, none, in my opinion, is as important from a user interface perspective as custom view controller transitions, the ability to insert your own animation when a view controller’s view takes over the screen. Thus:
- When a tab bar controller’s child is selected, you can now animate the change.
- When a view controller is pushed onto a navigation controller’s stack, you are no longer confined to the traditional “slide in from the right” animation.
- When a presented view controller’s view appears or is dismissed, you are no longer confined to a choice of the four
In the third case — a presented view controller — iOS 7 introduces a further innovation: You can position the presented view wherever you like, including the possibility of only partially covering the original interface.
In other words, the presented view controller’s view can float on top of, and partially reveal, the original view controller’s view; the user sees the views of both view controllers, one in front of the other.
What to look out for when updating your code
As a bewildered Dorothy says in the movie The Wizard of Oz, “I don’t think we’re in Kansas anymore.” When you open your iOS 6 project in Xcode 5 and run it in the iOS 7 simulator, you’ll know instantly that things have changed:
[contextly_sidebar id=”e027d3655ea50711dd31b81666c293d7″]Gone is the colored status bar background; the status bar is always transparent, and all apps are full-screen apps, underlapping the status bar. A button has no rounded rect bezel, unless you draw it yourself as the button’s background. Many interface objects are drawn differently, with different dimensions. The subtle bar gradient is gone; colors are flat, unless you draw a gradient background yourself.