Objective C Detailed Implementation

Swift is unarguably the language of choice for the iOS and MacOS development communities. It was expressly designed to enable developers to build more stable apps and software more quickly. While Objective C has been around for a long, long time, and is still the language most common in iOS apps, that's changing. And the tooling we're used to when working with various Objective C apps isn't around yet for Swift. There are reasons for that — while Swift is certainly more expressive, and arguably the more powerful, of the two languages, it generates more complex executables. Just like C++ creates more obfuscated programs than C, Swift produces more obfuscated programs than Objective C. Let's see how much more complex.

This is the first post in a series describing the differences between C, Objective C, and Swift code. In the previous article, we introduced the programs we're using for this comparison. So, you don't need to go back to refer to the programs; I'm including them here:

We also looked over the complexity of the generated programs using JTool and NM in the previous article. Rather than recreate everything here, let's just say that the Swift program was much larger, linked to more libraries, and had something like three orders of magnitude more defined symbols than it's Objective C counterpart.

Here, we're going to use Hopper to disassemble and decompile the generated executables and take a look at what's on the inside.

Let's take a look at our simple Objective C program again:

#import <Foundation/Foundation.h>

@interface Printer : NSObject

@property NSString *str_to_print;

- (void) printMsg;
- (void) printString: (NSString*) message;

@end

@implementation Printer

- (void) printMsg {
printf("%s\n", [self.str_to_print UTF8String]);
}

This generates this kind of disassembly:

push rbp
mov rbp, rsp
sub rsp, 0x20
mov dword [rbp+var_4], 0x0
mov dword [rbp+var_8], edi
mov qword [rbp+var_10], rsi
call imp___stubs__objc_autoreleasePoolPush
mov rsi, qword [objc_cls_ref_Printer]
mov rcx, qword [0x100001200]
mov rdi, rsi
mov rsi, rcx
mov qword [rbp+var_20], rax
call imp___stubs__objc_msgSend
mov rsi, qword [0x100001208]
mov rdi, rax
call imp___stubs__objc_msgSend
lea rcx, qword [cfstring_Hello_World_]
mov qword [rbp+var_18], rax
mov rax, qword [rbp+var_18]
mov rsi, qword [0x100001210]
mov rdi, rax
mov rdx, rcx
call imp___stubs__objc_msgSend
xor r8d, r8d
mov esi, r8d
lea rax, qword [rbp+var_18]
mov rdi, rax
call imp___stubs__objc_storeStrong
mov rdi, qword [rbp+var_20]
call imp___stubs__objc_autoreleasePoolPop
xor eax, eax
add rsp, 0x20
pop rbp

This is the disassembly of the decompiled C code we outlined previously. It shows how objects are added to the autorelease pool and removed from the autorelease pool as well as outlining the obj_msgSend()  methods. We can see object creation too:

mov rsi, qword [objc_cls_ref_Printer]
mov rcx, qword [0x100001200] ; @selector(alloc)
mov rdi, rsi
mov rsi, rcx
mov qword [rbp+var_20], rax
call imp___stubs__objc_msgSend

If you look over this code, you can see that we're sending a message to the alloc() method to create a new object. One of the arguments in the message is a pointer to a class definition for the Printer class. The class definition structure looks like this:

_OBJC_CLASS_$_Printer:
  struct __objc_class {
    _OBJC_METACLASS_$_Printer,
    _OBJC_CLASS_$_NSObject, // superclass
    __objc_empty_cache, // cache
    0x0, // vtable
    __objc_class_Printer_data // data
  }

There's a lot here; I won't dig into all the details. But this gives you an idea of the information that's used to create a class object in Objective C. The component structures contain information on the class, class data, methods, object data, and that kind of thing. The allocated object is then passed to the init(.) method on the new object itself following allocation for object initialization.