The Master-Detail Application template uses a split-view controller in some cases and a navigation controller in others. Originally (that is, with the launch of iPad), the split-view controller was intended for iPad, and the navigation controller was intended for iPhone. In 2014, with the advent of iPhone 6 Plus, the implementation changed.
The split-view controller is now used for larger-screen devices and the navigation controller is used for smaller screen devices. The dividing line is no longer iPad vs. iPhone: It now starts with iPhone 6 Plus, which uses a split-view controller along with iPad. Other iPhone models use the navigation controller.
This has caused a revision to the code, so even if you’ve used it for years, you should take a look at the code in this section in both languages.
The split view controller is set up in AppDelegate (AppDelegate.swift or the combination of AppDelegate.h and AppDelegate.m in Objective-C). Here, you see the declaration and the implementation in both Swift and Objective-C. As noted, you’ll encounter this approach repeatedly with legacy Objective-C frameworks.
Identifying the key method
The key to the split-view controller is a protocol — UISplitViewControllerDelegate. Within that protocol, one of the most important methods is the one that manages collapsing the secondary view controller (the master list, in most cases). Even the name of this method differs in the two languages. In the jump bar, here is how it is identified in Swift:
splitViewController (_:collapseSecondaryViewController: ontoPrimaryViewController)
Here is how it is identified in the jump bar in Objective-C:
-splitViewController:collapseSecondaryViewController: ontoPrimaryViewController:
The first point to notice is that in Objective-C, the — at the beginning identifies this as an instance method as opposed to a class method. This can be done in Swift, but only in a different way. The name of the method in Swift doesn’t reflect its class- or instance-ness.
Note that in the documentation, the Objective-C version is listed by the title. Following that, the Swift and Objective-C interfaces are shown (in that order). This pattern appears to be followed in all of the frameworks.
Comparing declarations
The actual declarations for these methods are shown here. First Swift:
optional func splitViewController(
_ splitViewController: UISplitViewController,
collapseSecondaryViewController
secondaryViewController: UIViewController!,
ontoPrimaryViewController <i>primaryViewController</i>:
UIViewController!)
-> Bool
Next, the Objective-C declaration:
- (BOOL)splitViewController:
(UISplitViewController *)<i>splitViewController</i>
collapseSecondaryViewController:
(UIViewController *)<i>secondaryViewController</i>
ontoPrimaryViewController:
(UIViewController *) <i>primaryViewController</i>
Now that you’re looking at the actual code, you can see there are more differences than just the – that marks this as an instance method in Objective-C. Here are the major differences:
In Objective-C, the return result is shown in parentheses at the beginning of the function, as in
- (BOOL)splitViewController:
In Swift, the return result is shown at the end of the function, as in
-> Bool
In Objective-C, the parameters (except the first) are shown in this order: external name, colon, type (in parenthesis and asterisk), internal name, as in
collapseSecondaryViewController:(UIViewController *) <i>secondaryViewController</i>
In Swift, the parameters (including the first) are shown in a different order: external name, internal name, colon, type, as in
collapseSecondaryViewController secondaryViewController: UIViewController!Types in Swift can include ! and ? as postfix operators to indicate unwrapping or optional status. In addition, the external name can be missing and replaced by an underscore, as in
_ splitViewController: UISplitViewController
