Objective-C Introduces Zero-Runtime-Cost Direct Methods

Write for InfoQ

Since Swift was launched in 2014, Objective-C has known only minor changes, mostly aimed at improving its interoperability with Swift. Far from being a fringe language, though, Objective-C has recently added support for "direct" methods, which look like ordinary class methods but behave more like a C function.

While Swift has attracted the most interest as the language of choice to build iOS apps, Objective-C is still popular among developers. Indeed, if it is true that Swift overtook Objective-C in TIOBE index in 2016 for the first time, it is also true that Objective-C has climbed to the 12th position in TIOBE index as of November 2019, with Swift ranking 10th. Interestingly, too, the two languages have swapped their TIOBE rankings a number of times. Similarly, Stack Overflow language ranking, which measures language adoption based on the number of questions that were asked on the popular Q&A forum, highlights declining interest in Objective-C. Stack Overflow figure can be specifically explained with Swift gathering most of the new developers entering the iOS development arena, as well as with the reduced number of changes made to Objective-C in the last few years.

For all of this, Objective-C new feature came somewhat as a surprise for many. In a nutshell, a direct method enables the definition of some special kinds of properties that will carry no Objective-C metadata attached to them and whose getter and setter methods will behave almost as straight C function. The syntax for this new feature is an immediate extension of Objective-C @property syntax:

@property (strong) NSArray* array;
@property (direct) NSString* directString;

The use of direct methods removes some overhead related to Objective-C runtime method resolution through objc_msgSend. This makes the use of this new feature interesting to optimize some critical path, as Peter Steinberger, iOS developer of PSPDFKit fame, remarked on Twitter. Not all overhead is removed, anyway, since direct method implementation in LLVM strives to make it compatible with standard Objective-C methods. In particular, both the implicit self and _cmd arguments are preserved and a few checks are made to ensure both are sane at the moment the method is called.

There are a few limitations to how developers can use direct methods. First and foremost, direct methods can only be used on internal, private APIs, and cannot be exposed by frameworks. Additionally, overloaded methods cannot be direct, nor direct methods can be overloaded; an implementation cannot redeclare a non-direct method of an interface it conforms to as direct; required protocol methods cannot be direct; finally, you cannot send an unqualified id a direct method.

Besides the possibility to optimize critical paths, reactions to this new Objective-C feature were not entirely on the positive side. iOS developer Tanner B remarked that direct methods impairs a number of fundamental Objective-C features, such as KVC, KVO, method swizzling and so on. Day One app developer BJ Homer expressed his concern direct method could be used by Apple to make tweaks harder to accomplish:

The objc_direct_members annotation seems to effectively implement truly-private methods for ObjC. Statically dispatched, not overridable. I can see Apple using that a lot internally to avoid people calling private methods.

This concern got somewhat dismissed by well-known iOS developer and book author Nick Lockwood, based on the fact direct methods can only be private::

That should go some way to alleviating the concerns that it will fundamentally change the nature of Objective-C by blocking swizzling and breaking features like KVO.

This was also confirmed by Apple senior software engineer Pierre Habouzit.

As a final note, while direct methods have been already merged into LLVM, it is unlikely they will be available in Xcode before next year WWDC.

Related Topics:

• Development
• Objective-C
• Mobile
• Apple
• iOS
• Xcode

We protect your privacy.