Swift vs. Objective-C: Generated Code

Frequently, when disassembling apps or applications I need to determine weather the app is implemented in Objective-C or Swift. You can do that in a variety of ways, usually, including looking into the application via otool or jtool to understand what libraries the app needs or looking for tags in various function names (like there word "swift," for example).

I thought it would be interesting to start to compare the function semantics in Objective-C and Swift to see how they differ. I've recently gone over function vs. message passing semantics to prepare for this comparison, so we can start to take a look at Swift code, which is much more complex than Objective-C. We're going use two similar programs for this comparison - though that similarity is only skin deep, as we'll see.

In both cases, we want to use a simple call to a class that prints a string. In both cases, we're going to put together a simple class that has a single property (str_to_print, a string) and two methods (printMsg(), which will print the property in the class, and printString(message: string), which sets the string property and then calls printMsg()).

Here are the program listings. First, the Objective-C program:

#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]);
}

- (void) printString: (NSString*) message {
self.str_to_print = message;
[self printMsg];
}

@end

int main(int argc, const char * argv[]) {
  @autoreleasepool {
  Printer *printer = [[Printer alloc] init];
  [printer printString: @"Hello World!"];
  }
  return 0;
}

Next, the Swift Program:

import Foundation

class Printer {

  var str_to_print: String

  init() {
  str_to_print = ""
  }

  func printMsg() {
  print(str_to_print)
  }

  func printString(message: String) {
  str_to_print = message
  printMsg()
  }

}

let printer = Printer()
printer.printString(message: "Hello World!")

Really simple, both of them. This will help us identify the code the Objective-C and Swift compilers add to the generated executables. Before we start looking at program disassembly though, let's take a look at properties of the executables. First, let's take a look at the program sizes:

$ ls -alh
total 20824
drwxr-xr-x 4 user group 136B Apr 9 12:02 ./
drwxr-xr-x 6 user group 204B Apr 9 11:11 ../
-rwxr-xr-x 1 user group 20K Apr 9 12:02 obj-c-cmd*
-rwxr-xr-x 1 user group 10M Apr 9 11:15 swift-cmd*

WOW. The Swift executable is 10M, while the Objective-C executable is only 20K. Let's take a look at the libraries used to see if we have statically linked a bunch of functions we shouldn't have:

$ jtool -L obj-c-cmd
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
/usr/lib/libobjc.A.dylib
/usr/lib/libSystem.B.dylib
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
$ jtool -L swift-cmd
/usr/lib/libc++.1.dylib
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
/usr/lib/libobjc.A.dylib
/usr/lib/libSystem.B.dylib
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
/usr/lib/libicucore.A.dylib

Well, the Swift program imports a bunch more libraries too, including graphics libraries, which is odd for a command line executable.

I think it's important to point out at this point that these projects were created and built using XCode defaults in XCode 9.2, so your mileage may vary if you're following along. But I encourage you to do so if you can.

Let's take a look at the symbols defined in the file:

$ nm -U obj-c-cmd | wc -l
10
$ nm -U swift-cmd | wc -l
43488

Well, that's something. We have a few more symbols in the Swift file. Just a few. Now all of these symbols won't necessarily have code in them but some will. We'll get a better view into the inserted defined functions when we look through the disassembly. Certainly, though, the Swift program is larger, contains more code, and is accessing more dynamic libraries. Even ones that we're not explicitly using in the program.

That's likely enough of a quick overview from the outside of the executable. In my next post, we'll dive in.