unpredictable.tech

Private APIs, Objective-C runtime, and Swift

2020-09-08T00:00:00+00:00

Sometimes when building an app, we find ourselves in a situation when we want to use a private API. It may provide some important functionality that is not exposed (yet), or we may want to work around a known platform issue. Or, you may be just debugging your code and poking around to get extra details.

Whatever you are trying to achieve, keep in mind that private APIs are fragile and can change without notice, leaving you with a broken product and frustrated users.

Swift adds another dimension here: restricted APIs marked as NS_SWIFT_UNAVAILABLE. Those are not technically private, but they are considered not safe enough and thus are not exposed in Swift. Calling into such unavailable APIs is pretty ok as they are fully documented and accessible from Objective-C code. This post will focus on accessing a group of Swift-unavailable APIs related to dynamic message dispatch provided by NSMethodSignature, NSInvocation, and NSObject classes. I encourage you to check the documentation if you are not familiar with those.

Nothing is private as long as Objective-C runtime is involved. Things have changed slightly with the introduction of direct methods. Still, a lot of APIs remain accessible if you know how to invoke them.

Invoking private APIs from Swift

But how do you call a method that is not exposed by the SDK? Back in the Objective-C days, everything was easy — thanks to the language’s dynamic nature, you could declare a category with any private methods. They would automatically resolve at runtime.

Swift is a type-safe language, and you no longer allowed to do that. Common approaches rely on Swift-compatible Foundation APIs like perform(_:) for simple functions or low-level method_getImplementation and/or objc_msgSend when dealing with more sophisticated signatures. Unfortunately, this results in complicated, verbose, and error-prone code.

Can we do something better? While the original category-based approach is not available in Swift, we can try something similar — we are still calling into Objective-C.

A cleaner approach

The idea is analogous to the category trick we did previously: we can define an @objc protocol containing methods of interest, use the runtime to add conformance to the class in question retroactively, and then ask Swift to do the typecast. Thanks to the dynamic dispatch used in everything coming from the Objective-C world, the protocol will be implemented automatically by existing class methods we are looking for.

To get started, we will define a protocol for NSMethodSignature matching what we can see in the Objective-C documentation. Notice the @objc(getArgumentTypeAtIndex:) annotation I used here. Normally, the compiler will generate the appropriate selector based on the method name, yet we may want to alter the auto-generated name. Using correct selector names is crucial in our case, where we have to match underlying API signatures perfectly.

@objc protocol NSMethodSignaturePrivate {
    static func signature(objCTypes: UnsafePointer<CChar>) -> NSMethodSignaturePrivate?
    var numberOfArguments: Int { get }
    @objc(getArgumentTypeAtIndex:) func getArgumentType(at index: Int) -> UnsafePointer<CChar>
    var frameLength: Int { get }
    var isOneway: ObjCBool { get }
    var methodReturnType: UnsafePointer<CChar> { get }
    var methodReturnLength: Int { get }
}

Once we have that protocol, we can attach it with explicit objc runtime calls:

// Obtain class reference from runtime:
let `class` = "NSMethodSignature".withCString {
    return objc_getClass($0) as! AnyClass
}

// Add protocol conformance:
class_addProtocol(`class`, NSMethodSignaturePrivate.self)

// Get `NSMethodSignaturePrivate.Type` meta-type reference
let NSMethodSignatureClass = `class` as! NSMethodSignaturePrivate.Type

Whoa, that’s some boilerplate, and we haven’t added any error checks yet — looks like the right candidate for a helper function. We will fix that right after testing that everything works as expected.

We will be working with method signatures here, and if you are not familiar with those, I recommend reading an excellent article from NSHipster to learn more about type encoding in Objective-C. As a quick recap, I’ll remind that v@: signature stays for “a method that returns void and accepts two implicit parameters: instance reference and method selector.”

// Call private class function:
let signature = "v@:".withCString {
    return NSMethodSignatureClass.signature(objCTypes: $0)
}

// Call private instance function:
print("Number of arguments: \(signature!.numberOfArguments)")

As intended, this says, “Number of arguments: 2,” which means that we have successfully constructed a signature for a method accepting two parameters.

Reducing boilerplate

Now back to the class import code. At first, it seems like we can leverage generics in a helper function to remove protocol reference duplication like this:

func importClass<T>(_ className: String, as protocol: T.Type) -> T.Type {
    fatalError("Not implemented yet.")
}

let NSMethodSignatureClass = importClass("NSMethodSignature", as: NSMethodSignaturePrivate.self)
let signature = "v@:".withCString(NSMethodSignatureClass.signature(objCTypes:))

Except this fails to compile, producing an error: “Static member signature(objCTypes:) cannot be used on protocol metatype NSMethodSignaturePrivate.Protocol.”

You see, NSMethodSignaturePrivate is a protocol, and thus we need a concrete conforming type to create an NSMethodSignaturePrivate.Type value. Because of that, the NSMethodSignaturePrivate.self syntax was repurposed to produce an NSMethodSignaturePrivate.Protocol, which we can use with runtime functions. But that thing does not allow us to call class functions like signature(objCTypes:).

Let’s give it another try:

func importClass<ProtocolType>(_ className: String) -> ProtocolType {
    fatalError("Not implemented yet.")
}

let NSMethodSignatureClass = importClass("NSMethodSignature") as NSMethodSignaturePrivate.Type
let signature = "v@:".withCString(NSMethodSignatureClass.signature(objCTypes:))

Now, this looks better, but how do we get NSMethodSignaturePrivate.Protocol from NSMethodSignaturePrivate.Type? I haven’t found any clear way to convert between those two, but we can use the type name as a middle ground here — use Swift reflection API to get the protocol name and then find it’s runtime counterpart with objc_getProtocol:

func importClass<ProtocolType>(_ className: String) -> ProtocolType {
    let typeNameSuffix = ".Type"

    let protocolTypeName = String(reflecting: ProtocolType.self)
    guard protocolTypeName.hasSuffix(typeNameSuffix) else {
        preconditionFailure("Type `\(protocolTypeName)` is not a protocol type.")
    }

    let protocolName = protocolTypeName.dropLast(typeNameSuffix.count)
    guard let `protocol` = protocolName.withCString(objc_getProtocol) else {
        preconditionFailure("Type `\(protocolName)` is not an objc protocol.")
    }

    guard let `class` = className.withCString(objc_getClass) as? AnyClass else {
        preconditionFailure("Class `\(className)` not found.")
    }

    if !class_addProtocol(`class`, `protocol`) {
        assertionFailure("Failed to attach protocol `\(protocolName)` to class `\(className)`.")
    }

    guard let result = `class` as? ProtocolType else {
        fatalError("Failed to cast class `\(className)` to protocol `\(protocolName)`.")
    }

    return result
}

Conclusion

Objective-C runtime, together with Swift expressiveness, provides a lot of opportunities. We can access Swift-restricted or private APIs using a little hacking, just like we did in Objective-C (all safety measures are on us, though):

let object = NSDate()
let objectPrivate = object as! NSObjectPrivate
let selector = Selector("description")
let signature = objectPrivate.methodSignature(for: selector)!
let invocation = NSInvocationClass.invocation(methodSignature: signature)
invocation.selector = selector
invocation.invoke(target: object)
var unmanagedResult: Unmanaged<NSString>? = nil
invocation.getReturnValue(&unmanagedResult)
let result = unmanagedResult?.takeRetainedValue()
print(result ?? "<nil>")

Check this gist for a full example: https://gist.github.com/victor-pavlychko/8a896917d8c73f4dded594ab4782214e

Bringing the Best of SwiftUI to Our Team’s UIKit Code

2020-05-26T00:00:00+00:00

Like pretty much all our colleagues in the field, iOS developers at Grammarly are excited about SwiftUI. Released at the 2019 Apple Worldwide Developers Conference (WWDC), it represents a major step forward in Apple’s support for building great user experiences. But as much as we want to use SwiftUI for everything, we can’t. For one thing, the libraries are still new and will probably take a few years to completely stabilize. Plus, SwiftUI is only bundled in iOS 13+, and we need to continue to support Grammarly for older versions of iOS. And finally, our existing UIKit code represents a huge, years-long investment for our team—we don’t want to just throw it out.

String Index Type Safety in Swift

2019-12-19T00:00:00+00:00

Code is much like a conversation, and misunderstandings can happen when assumptions aren’t stated upfront. It brings to mind a quote (perhaps apocryphal) from the Enlightenment philosopher Voltaire: “If you wish to converse with me, first define your terms.” Though he is unlikely to have anticipated how this advice might apply to computer science, it rings true when considering the code development process. Misunderstandings lead to bugs—which our team found out when working with our iOS text manipulation logic.

DRY String Localization with Interface Builder

2017-08-21T00:00:00+00:00

Great applications should have great localization. And users will appreciate an option to use beloved apps in their native language. There is no excuse for developers not to support interface localization even on early stages of the development process, especially when it’s so easy to do.

I prefer to design mostly with the Interface Builder. In this article I would like to share an approach I use in my projects to localize those resources.

Normally, when you try to localize a XIB file or storyboard, Xcode will happily clone the resource and you get stuck with duplicated view layouts. Yuck… That’s hardly a good option if you are trying to follow the DRY methodology 😕

Instead of doing that I suggest filling “at”-prefixed localization terms in the Interface Builder and replacing them with the localized values in viewDidLoad or awakeFromNib methods of the corresponding objects. Here is an example of how it looks like in the Interface Builder:

I use @ prefix for localization terms to allow mixing them with any real values as needed. Additionally, leading @@ sequence is replaced with a single @ in case you need to specify unlocalized string starting with the “at” symbol.

As it usually happens in Swift, we start with a protocol:

public protocol Localizable {
    func localize()
}

Followed by an extension containing some helpers to localize strings and apply localized values to properties:

public extension Localizable {
    
    public func localize(_ string: String?) -> String? {
        guard let term = string, term.hasPrefix("@") else {
            return string
        }
        guard !term.hasPrefix("@@") else {
            return term.substring(from: term.index(after: term.startIndex))
        }
        return NSLocalizedString(term.substring(from: term.index(after: term.startIndex)), comment: "")
    }
    
    public func localize(_ string: String?, _ setter: (String?) -> Void) {
        setter(localize(string))
    }

    public func localize(_ getter: (UIControlState) -> String?, _ setter: (String?, UIControlState) -> Void) {
        setter(localize(getter(.normal)), .normal)
        setter(localize(getter(.selected)), .selected)
        setter(localize(getter(.highlighted)), .highlighted)
        setter(localize(getter(.disabled)), .disabled)
    }
}

Note: substring API is deprecated in Swift 4, should be replaced with dropFirst which also describes the original intent better.

Note: second localization helper should be upgraded to use the new KeyPath syntax when moving to Swift 4.

Ok, so far, so good. Now let’s start implementing some localization. The process itself is clearly recursive where each container asks its children to localize themselves:

extension UIView: Localizable {
    public func localize() {
        subviews.forEach { $0.localize() }
    }
}

Having implemented that, let’s add localization support for common controls required in most applications. The implementation is straightforward:

public extension UILabel {
    public override func localize() {
        super.localize()
        localize(text) { text = $0 }
    }
}

public extension UIButton {
    public override func localize() {
        super.localize()
        localize(title(for:), setTitle(_:for:))
    }
}

Notice that for UIButton title we use another helper function which applies localization for all possible control states.

Views are not the only objects we can configure with the Interface Builder. We should keep in mind the following objects too:

UIBarItem with it’s subclasses: UIBarButtonItem and UITabBarItem
UINavigationItem

Any other objects you decide to use in your app

extension UIBarItem: Localizable {
    public func localize() {
        localize(title) { title = $0 }
    }
}

public extension UIBarButtonItem {
    public override func localize() {
        super.localize()
        customView?.localize()
    }
}

extension UINavigationItem: Localizable {
    public func localize() {
        localize(title) { title = $0 }
        localize(prompt) { prompt = $0 }
        titleView?.localize()
        leftBarButtonItems?.forEach { $0.localize() }
        rightBarButtonItems?.forEach { $0.localize() }
    }
}

Finally, we have to start the flow somewhere. I usually rely on the following events:

Localize title, navigationItem, tabBarItem and view in the viewDidLoad method of my UIViewController subclasses.
Localize contents of UITableViewCell and UICollectionViewCell subclasses in the corresponding awakeFromNib methods.

For the UIViewController here is a helper method to localize content, navigation and tab items:

extension UIViewController: Localizable {
    public func localize() {
        localize(title) { title = $0 }
        navigationItem.localize()
        tabBarItem?.localize()
        view.localize()
    }
}

Generic Optional Handling in Swift

2017-08-13T00:00:00+00:00

Sometimes you want to write a generic algorithm working on any Optional type no matter what actual type is wrapped inside. Ok, this can be easily done with a free generic function, but what if you want to write a Sequence extension to remove all nil values for example?

Things get a little bit complicated here since Optional is not a protocol but a concrete type and so it can’t be used as a generic type constraint.

Generic protocols and concrete types in Swift serve different purposes: we create instances and declare variables of concrete types while protocols can be used as a generic type constraints.

Type erasure is a technique used in case we want to declare a variable able to hold any concrete type conforming to a specific protocol. What we want here instead is another part of the same puzzle, we need a protocol allowing us to use the concrete generic type as a constraint.

This may sound complicated in English but, as it usually happens, looks much simpler when written in plain Swift 😄

public protocol OptionalType: ExpressibleByNilLiteral {
    associatedtype WrappedType
    var asOptional: WrappedType? { get }
}

extension Optional: OptionalType {
    public var asOptional: Wrapped? {
        return self
    }
}

So here we just define an OptionalType protocol declaring WrappedType associated type and conform Optional enum to it. Note that generic type parameters do not automatically fulfill protocol requirements, but we have type inference covering us here.

In order to make the protocol useful we expose some basic Optional functionality:

asOptional property gives us an access to the optional binding syntax.
ExpressibleByNilLiteral conformance allows us to use nil for initialization.

Having done that, we can now use OptionalType as a generic constraint:

public extension Sequence where Self.Iterator.Element: OptionalType {
    public func removingNils() -> [Self.Iterator.Element.WrappedType] {
        return flatMap { $0.asOptional }
    }
}

If you are looking for more tricks that can be done with the Optional enum, you should check an excellent article by Russ Bishop.

Using Self in Swift Class Extensions

2017-08-10T00:00:00+00:00

It might be tempting to use Self as a parameter type when extending classes but Swift only allows it in a protocol or as the result of a class method invocation.

In fact, this is a semantically correct restriction for non-final classes in most cases, except when we want to use Self as an argument of the closure, think about completion handlers for example. In that case Self is used just as an another method call result which is absolutely valid option.

My favorite example here is the continuation helper for the Operation class:

Using continuation operation instead of completion block gives control over its execution context.
I tend to define result accessors in my Operation subclasses and I usually want to access them in a continuation.
Accessing operation from the continuation does not introduce a retain cycle because any operation already owns its dependencies.

So we need to pass a block receiving operation that has just finished execution as a parameter. That is not allowed in a class extension.

Hm, but we can use Self that way in a protocol, right… Protocols to the rescue! The plan is to define a dummy protocol, conform our class to it and extend the protocol instead of the class.

public protocol BlockContinuable { }

extension Operation: BlockContinuable { }

public extension BlockContinuable where Self: Operation {
    public func `continue`(on queue: OperationQueue = .main, with block: @escaping (Self) -> Void) {
        let continuation = BlockOperation { block(self) }
        continuation.addDependency(self)
        queue.addOperation(continuation)
    }
}

Now we can use our continue(on:with:) extension and access operation result in a type-safe manner:

public class SampleOperation: Operation {
    public var result: String?
    public override func main() {
        result = "Hello, Continuation!"
    }
}

let operation = SampleOperation()

operation.continue {
    print($0.result ?? "operation failed")
}

OperationQueue.main.addOperation(operation)

Managing Temporary Files in Swift

2017-08-08T00:00:00+00:00

Reference counting is great in taking unused objects out of memory. The same can be applied to the temporary files we allocate.

Let’s say you are building a video sharing app, here is what you have to do each time user decides to upload some content from the app:

Take a movie and store into a temporary file.
Present filter/crop/whatever editing UI to the user.
Render the final video to another temporary file, the first file can be safely removed by now.
Upload video to the cloud and remove the second file when done.

Taking care of those files manually adds extra complexity and can be easily overseen resulting in an excessive storage use caused by the lost data. I faced this myself when my pet project suddenly took over all my storage 😂

Reference counting comes to the rescue here: we can create TemporaryFileURL class wrapping regular URL and performing cleanup in its deinit method. Now the temporary file will be removed automatically when it becomes unreferenced from the application.

public final class TemporaryFileURL: ManagedURL {
    
    public let contentURL: URL
    
    public init(extension ext: String) {
        contentURL = URL(fileURLWithPath: NSTemporaryDirectory())
            .appendingPathComponent(UUID().uuidString)
            .appendingPathExtension(ext)
    }
    
    deinit {
        DispatchQueue.global(qos: .utility).async { [contentURL = self.contentURL] in
            try? FileManager.default.removeItem(at: contentURL)
        }
    }
}

Notice the rarely used capture with assignment syntax I used here to pass contentURL for the deferred file cleanup: we’d better not capture self during deallocation so we just copy the underlying file URL and let self deallocate properly.

Now you may want to unify all the code working with files no matter if they are normal or temporary. That’s what ManagedURL protocol stands here for. We can conform URL struct and/or NSURL class to the protocol and pass ManagedURL references all around.

public protocol ManagedURL {
    var contentURL: URL { get }
    func keepAlive()
}

public extension ManagedURL {
    public func keepAlive() { }
}

extension URL: ManagedURL {
    public var contentURL: URL { return self }
}

I have also added a no-op keepAlive function whose sole purpose it to allow easy object capture by various closures used as a completion handlers. This allows us to keep file while background operation is executed like this:

URLSession.shared.uploadTask(with: request, fromFile: fileToUpload.contentURL) { _, _, _ in
    temporaryFile.keepAlive()
}

As James Richard reminded on Twitter, this technique is called Resource Acquisition is Initialization, or RAII, and has beed commonly used in C++ for ages. The trick is good for managing lifetime of any external resource but is often overlooked since destructors are not very common in the modern world of ARC, GC, defer, try/finally and others.

Storyboard Tricks

2017-08-06T00:00:00+00:00

While looking through another sample project today, I have once again noticed how many string literals and force downcasts accompany most of the storyboard-related code.

Having realized that, I decided to share a few practices I use myself to make my view controller and storyboard handling code more conscious.

Instantiating View Controllers

Let’s start with the instantiation process: we rely on file name to create UIStoryboard instance, then we use view controller identifier to call instantiateViewController(withIdentifier:) and all this mess is followed by the force downcast to the actual type.

View controller instantiation code should be much cleaner, here is an example of what I’m looking for:

private func presentDetails(for item: ItemModel) {
    let viewController = DetailsViewController.makeWithStoryboard()
    viewController.delegate = self
    viewController.model = item
    present(viewController, animated: true, completion: nil)
}

To achieve that we have to avoid “massive storyboard” pattern and keep each flow in a separate file. Having done that we can establish simple conventions allowing us to hide all that UIStoryboard stuff in a helper function:

Only instantiate initial view controllers from code.
Access all other view controllers in the same storyboard via segues.
Use initial view controller class name to name the corresponding storyboard. This is obvious for good old NIBs but we tend to not use the pattern with storyboards.

After establishing the conventions we can easily instantiate any view controller given only its class, everything else is derived programmatically. Helper function code should be something similar to the following snippet:

private func dynamicCast<T>(_ object: Any, as: T.Type) -> T? {
    return object as? T
}

public extension UIViewController {
    public static func makeWithStoryboard(_ name: String? = nil, bundle: Bundle? = nil) -> Self {
        let name = name ?? String(describing: self).components(separatedBy: ".").last!
        let bundle = bundle ?? Bundle(for: self)
        guard bundle.url(forResource: name, withExtension: "storyboardc") != nil else {
            fatalError("Can't find storyboard named `\(name)` in bundle `\(bundle)`.")
        }
        let storyboard = UIStoryboard(name: name, bundle: bundle)
        guard let initialViewController = storyboard.instantiateInitialViewController() else {
            fatalError("No initial view controller defined in storyboard `\(name)`, bundle `\(bundle)`.")
        }
        guard let resultViewController = dynamicCast(initialViewController, as: self) else {
            fatalError("Wrong initial view controller found in storyboard `\(name)`, bundle `\(bundle)`: expected `\(self)`, found `\(type(of: initialViewController))`.")
        }
        return resultViewController
    }
}

I’d like to note two tricky moments here:

We use Bundle(for: self) instead of nil or Bundle.main to properly load resources from dynamic frameworks.
That weird dynamicCast(_:as:) function helps us to work around Swift limitation which prohibits us to write initialViewController as? Self. Doing the former results in a compile error stating that “Self is only available in a protocol or as the result of a method in a class”.

Handling Segues

Another popular place to find string identifiers when working with storyboards is prepare(for:sender:) method. Here we test segue identifier and downcast view controller depending on that. Something like this:

override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    if segue.identifier == "OpenAnotherViewController" {
        let destination = segue.destination as! AnotherViewController
        destination.delegate = self
        return
    }
}

The snippet employs two bad practices at once: error-prone string identifier comparison followed by force downcast.

It seems to me that the only thing that actually matters in most cases is our destination view controller type. In those cases we can simply switch over the possible destinations and fatalError for everything else. The following code snippet shows how this may look in your code:

override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    switch segue.destination {
    case let destination as AnotherViewController:
        destination.delegate = self
    default:
        fatalError("Unexpected segue: `\(self)` -> `\(segue.destination)`")
    }
}