Method Internals in Swift 5.0

Method Internals in Swift 5.0

One of the nice things about Swift 5 is the final stabilization of the ABI. This is actually a big deal. The application binary interface defines exactly how data is stored in programs, shared from libraries, things like that. It includes name decoration, class and object definitions, and so on. Now that we have a stable ABI, building tools that analyzed and manipulate these binary representations will become much, well, not easier, but not as much a waste of time. Until now, you were just about guaranteed to have any tools you created broken by new Swift versions. With a stable ABI? This shouldn't happen.

In this post, we continue to get a better understanding of the internal workings of Swift by examining how methods work in this language.

One of the nice things about Swift 5 is the final stabilization of the ABI. This is actually a big deal. The application binary interface defines exactly how data is stored in programs, shared from libraries, things like that. It includes name decoration, class and object definitions, and so on. Now that we have a stable ABI, building tools that analyzed and manipulate these binary representations will become much, well, not easier, but not as much a waste of time. Until now, you were just about guaranteed to have any tools you created broken by new Swift versions. With a stable ABI? This shouldn't happen.

We just covered how classes are defined in Swift 5, and we discovered that they reflect the basic design in Objective-C. There are some key differences though, and one of those is member method definitions.

In Objective-C, you might remember that methods defined in a data pointer are stored in the class definition. This data pointer contained another pointer than references a list of method structures. The method structures contained a name, a pointer to an implementation, and a few other things. Let's see what Swift does.

First, we know swift does use the objc_class structure, and in this case it looks like this:

_$s9swift_cmd7PrinterCN:
  struct __objc_class {
  _$s9swift_cmd7PrinterCMm, // metaclass
  _OBJC_CLASS_$__TtCs12_SwiftObject, // superclass
  __objc_empty_cache, // cache
  0x0, // vtable
  __objc_class__TtC9swift_cmd7Printer_data+1 // data
  }

There's a slight difference here, it seems that the final pointer, the object data pointer, actually points to an offset from the beginning of the objcclassTtC9swift_cmd7Prointer_data structure. If we take a look at that address, we find this:

__objc_class__TtC9swift_cmd7Printer_data:
  struct __objc_data {
    0x80, // flags
    16, // instance start
    32, // instance size
    0x0,
    0x0, // ivar layout
    aTtc9swiftcmd7p, // name
    0x0, // base methods
    0x0, // base protocols
    __objc_class__TtC9swift_cmd7Printer_ivars, // ivars
    0x0, // weak ivar layout
    0x0 // base properties
  }

Okay, so far so good right? Very similar to what we've seen in Objective-C, even with the offset. But look a little closer — there's no corresponding list of methods. Uh oh.

Well, we know that methods are associated with class instantiations somehow. But how? Well, let's take a look at the procedures defined in the executable.

Hopper gives us a list of 29 procedures. The two we're interested in are:

  • _$s9swift_cmd7PrinterC8printMsgyyF  
  • _$s9swift_cmd7PrinterC11printString7messageySS_tF 

How do I know? Well, even though the swift-demangle utility has yet to catch up with the name mangling in Swift 5, if you look closely you can see the names of the methods we're interested in embedded in this procedure names. Let's take a look at $s9swiftcmd7PrinterC11printString7messageySS_tF — it's the method we call, and if you take a look at the Swift implementation you can see it calls printMsg():

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

Perhaps it'll give us a clue as to how methods are defined on classes.

Here's the disassembly:

_$s9swift_cmd7PrinterC11printString7messageySS_tF:
  push rbp
  mov rbp, rsp
  push r13
  sub rsp, 0x48
  xorps xmm0, xmm0
  movaps xmmword [rbp+var_20], xmm0
  mov qword [rbp+var_28], 0x0
  mov qword [rbp+var_20], rdi
  mov qword [rbp+var_18], rsi
  mov qword [rbp+var_28], r13
  mov qword [rbp+var_30], rdi
  mov rdi, rsi
  mov qword [rbp+var_38], rsi
  mov qword [rbp+var_40], r13
  call imp___stubs__swift_bridgeObjectRetain ; swift_bridgeObjectRetain
  mov rsi, qword [rbp+var_40]
  mov rdi, qword [rsi]
  mov rdi, qword [rdi+0x60]
  mov r13, qword [rbp+var_30]
  mov qword [rbp+var_48], rdi
  mov rdi, r13
  mov rsi, qword [rbp+var_38]
  mov r13, qword [rbp+var_40]
  mov rcx, qword [rbp+var_48]
  mov qword [rbp+var_50], rax
  call rcx
  mov rax, qword [rbp+var_40]
  mov rcx, qword [rax]
  mov rcx, qword [rcx+0x78]
  mov r13, rax
  call rcx
  add rsp, 0x48
  pop r13
  pop rbp
  ret

We have two CALL opcodes. The first calls out to an external function, bridgeObjectRetain(). That's not really what we're interested in, so let's take a look at the second:

mov rcx, qword [rbp+var_48]
mov qword [rbp+var_50], rax
call rcx

The second CALL references the RCX register, which is loaded with an address from the stack. Yes, from the stack. This is a MAJOR change from Objective-C, and we'll need to start up LLDB to look at this a bit more closely.

Originally published by Christopher Lamb at dzone.com

------------------------------------------------------------------------------------------------------------------------------------------

Follow great articles on Twitter


Learn More

☞ iOS 12 & Swift - The Complete iOS App Development Bootcamp

☞ Learn Swift 4: From Beginner to Advanced

☞ Creating an iOS app with user presence using Node.js and Swift

☞ Learn Swift 4 for Beginners

☞ What’s new in Swift 5.0?

Accessing Swift protocol property implemented in an Obj-C class from another Swift class

I've seen lots of questions regarding implementing Obj-C protocols in Swift, but not so much the other way around, and I haven't seen this specifically.

I've seen lots of questions regarding implementing Obj-C protocols in Swift, but not so much the other way around, and I haven't seen this specifically.

I am using a mixed Obj-C / Swift codebase. I have a Swift protocol defined as follows:

NamedItem.swift

@objc protocol NamedItem {
    var name: String { get }
}

I have an existing Objective-C class that currently has its own name property:

MyObjcClass.h

@interface MyObjcClass : NSObject
@property (nonatomic, strong, readonly) NSString* name;
@end

I have a couple other classes that have a name property, so obviously I'd like to associate them all with a protocol instead of typecasting to a bunch of different types. Now, if I try to switch my Obj-C class from having its own property to implementing the Swift protocol:

MyObjcClass.h

@protocol MyObjcProtocol
@property (nonatomic, strong, readonly) NSString* place;
@end

@interface MyObjcClass : NSObject
@end

MyObjcClass.m

@interface MyObjcClass () <NamedItem>
@end

@implementation MyObjcClass
@synthesize name = _name;
@synthesize place = _place;
@end

This works great, in my other Objective-C classes, but if I try to access the name property from a Swift class:

SomeSwiftClass.swift

let myObj = MyObjcClass()
myObj.name // error
myObj.place // no problem

I get the following error:

Value of type 'MyObjcClass' has no member 'name'

If I don't remove the existing @property declaration from MyObjcClass.h and omit the @synthesizestatement everything builds correctly. Which seems weird and wrong - If you adopt a Objc-C protocol from an Obj-C class you don't have to re-define the property, just the @synthesize statement is sufficient.

I've tried defining the Swift protocol about every way I could think of and have been able to find suggestions about, but I haven't been able to get around this.

So, what is the correct way to implement a Swift protocol property (maybe specifically a read-only property?) in an Objective-C class such that another Swift class can access it? Do I really have to re-declare the property in the Obj-C header? I know I could always give it up and just define the protocol in Objective-C, but... Swift is the future! (or something like that...)

Swift- Waiting for asynchronous for-in loop to complete before calling completion handler swift

I'm baffled as to what is the best way to achieve this. I am trying to keep a running total of Double values that I am looping through and adding together, via a network call. Everything I've read says to use DispatchGroup. My completion either calls too early or doesn't get called at all and I've tried every configuration of .enter, .leave, and .wait that I can think of.

I'm baffled as to what is the best way to achieve this. I am trying to keep a running total of Double values that I am looping through and adding together, via a network call. Everything I've read says to use DispatchGroup. My completion either calls too early or doesn't get called at all and I've tried every configuration of .enter, .leave, and .wait that I can think of.

    let group = DispatchGroup()
    var runningTotal: Double = 0.00
ref.observeSingleEvent(of: .value) { (snapshot) in
    guard let bills = snapshot.value as? [String: AnyObject] else {
        //error
        return
    }

    for billId in bills.keys {
        group.enter()
        print("Entering")
        Database.database().reference().child("bills").child(billId).observeSingleEvent(of: .value, with: { (snapshot) in
            guard let bill = snapshot.value as? [String: AnyObject] else {
                return
            }
            if let amount = bill["amount"] as? Double {
                runningTotal += amount
            }
            group.leave()
            print("Leaving")
        })
    }
    completion(runningTotal)
}
group.wait()

}