supersonicbyte

Swift interoperability with C (Part 1)

2025-01-30T00:00:00Z

Intro

The C programming language is the backbone of modern computing. With its assembly-close nature offering speed and effectiveness it's still the main choice when writing system software since it's beginning is the '70s. Most operating systems are written in C. For any new programming language, it's crucial to have a way to communicate and integrate with existing C code.

Swift comes with exceptional interoperability with Objective-C/C and most recently with C++.

This is the first part of a series of blog posts dedicated to Swift's interoperability with C. In this post we're going to explore how does actually Swift call into C code.

Creating a simple C library

Let's create a simple C library. Consider the following C code:

#include <stdio.h>

void foo() {
  printf("foo!\n");
}

And the header:

#ifndef FOO_H
#define FOO_H

void foo();

#endif

Note: The #ifndef and #define and the beginning are called include guards.

Pretty straightforward. We define a simple function foo which prints to the standard output.

Let's compile it:

clang -c foo.c

This will compile our code and produce a foo.o object file, which contains the actual machine code. If we run:

Note: I'm on a macbook and I'm using the Clang compiler.

file foo.o

We get:

Mach-O 64-bit object arm64

Now, we just need to archive the file to make it into a static library. We can do so by running:

ar -rv libfoo.a foo.o

A static library is an archive of .o files with a .a extension

Great! Now let's try to use our newly created library in a test program:

#include <stdio.h>
#include "foo.h"

int main(int argc, char *argv[])
{
  foo();
  return 0;
}

We can now compile and run:

clang test.c libfoo.a -o Test
./Test
foo!

Alright, our C library is working well. Now we can try to call it from Swift!

Importing C in Swift

Create a new swift file, name it main.swift.

print("Hello from Swift!")

foo()

print("Goodbye!")

We just referenced the foo function as if it was imported, but naively trying to compile it with swiftc will fail. We are referencing foo which hasn't been declared anywhere. We have to express that foo should be imported from our libfoo C library. In our C program we did so by including the foo.h header which declares our foo function.

One way of doing it is to pass the header file to the compiler with the -import-objc-header flag. The other, preferred way, is with Clang modules. Clang modules are a concept from the Clang compiler. They bring a lot of improvements and solve pain points of plain header files. We won't go in detail right here, but if you want to know more about them you can find it in the documentation.

Let's create a clang module for our foo.h by making a file named module.modulemap and setting it's contents to:

module CFoo {
  header "foo.h"
  export *
}

The modulemap is pretty simple, it declares a module named CFoo (it's a convention that we add a prefix C for C modules that we import in Swift) references our foo.h header and exports everything from it.

Now, let's import this module we created by in our main.swift by adding this on the top:

import CFoo

Great! We are all set. The last thing to do is to invoke the swift compiler and pass all the required information for it to compile and link our main.swift:

swiftc -I ./ -L ./ -lfoo  main.swift -o main

Note: If we wanted to use plain header we would invoke the compiler like this: swiftc -import-objc-header foo.h -I ./ -L ./ -lfoo main.swift -o main

Voila! And if we run our executable we get:

./main
Hello form swift!
foo!
Goodbye!

Everything works!

Let's break down the flags we are sending to the compiler:

-I flag enables us to pass a directory which will be used as the import search path, basically a place where it tries to resolve our imports, we pass the current directory (because we created our module.modulemap in the same directory as our main.swift)
-L flag enable us to pass a directory which will be used as the library link search path, a place where to look for the libraries we are linking against, again we pass the current directory for the same reasons
-lfoo flag is passed down to the linker and it tells the linker to search for a library named libfoo in the library search path. More about this flag can be found in the man pages of ld.
main.swift the source file we are compiling
-o specifies the name of our output

Let's do some unwinding. On a high level, the swift compiler parses the passed in clang modules and transforms the declarations in the C headers to Swift declarations. The result of this is that our foo from C will end up as a swift declaration:

func foo()

But these imported C functions get very different treatment during the compilation from Swift functions. Their names don't get mangled so they preserve C calling convention (more on that later). Mangling is the process of encoding functions and variable names into unique names that are later on useful in the linking process. One thing mangling enables for us is function overloading, since every argument will be encoded into the mangled name thus allowing us to overload functions.

For example, consider the following function:

func bar(arg: Int)

After mangling the function name will be:

$s3barAA3argySi_tF

To demangle a name we can use:

swift demangle s3barAA3argySi_tF
// it prints out the following
$s3barAA3argySi_tF ---> bar.bar(arg: Swift.Int) -> ()

(Note that we dropped the $ prefix since that's a special character in most shells)

We mentioned that we want to perserve C calling convention. The calling convention defines the following:

how the arguments are passed onto the stack
who will clear the stack, caller or callee?
what registers will be used and how

Basically, it defines the exact way how we should setup our machine code when calling machine code that was outputed from compilaton our C code. For any two pieces of machine code that interact, it's important that the convention is aligned in other for the caller and callee to work as expected. That being said, in order for machine code generated code from Swift to correctly call a machine code generated from a C source it's important to follow the C calling convention. The convention could possibly differ regarding which underlying platform is targeted but it's important that the conventions are aligned. C doesn't support function overloading and mangling, and that's way it's important that this function name doesn't get mangled. Along the way the imported C functions also get annotated with @convention(c) (this can be seen if we print out the SIL Swift Intermidiate Language). This is also plays into the compiler treating these functions specially so it can generate adequate machine code which follows the calling convention.

Since we are linking statically against our libfoo the linker will actually embed the code that we are referencing from library into the executable and then the resolve the foo call with an actual memory address of the function.

Let's confirm this by examining the executable:

objdump -d main | grep 'foo'

This will disassemble the machine code into assembly and then we search for the foo symbol. And we can see:

...
100003d94: 94000056    	bl	0x100003eec <_foo>
...

This is the place in our main.swift where we are calling foo. In the assembly bl denotes an arm64 (this could be different depending on what platform are you executing e.g. Intel Mac) instruction called branch and link. Before branching the instruction stores the current address into the link register which is used to keep track to which address to return when the ret instruction is being executed. The instruction has one argument which determines the address to which the execution should be branched.

If we search again we can find the definition of foo in the assembly.

0000000100003eec <_foo>:
100003eec: a9bf7bfd     stp     x29, x30, [sp, #-0x10]!
100003ef0: 910003fd     mov     x29, sp
100003ef4: 90000000     adrp    x0, 0x100003000 <_swift_bridgeObjectRelease+0x100003000>
100003ef8: 913dbc00     add     x0, x0, #0xf6f
100003efc: 9400000f     bl      0x100003f38 <_swift_bridgeObjectRelease+0x100003f38>
100003f00: a8c17bfd     ldp     x29, x30, [sp], #0x10
100003f04: d65f03c0     ret

After all the instructions are executed we hit the ret instructions which takes us back to the address stored in the link register, meaning we finished the with the call of foo and we are returning to execution of our main.swift.

And at this point exactly we understand how the Swift code called our C function.

Final notes

Interoperability boils down to making the machine code generated from different languages play nicely with each other. A lot of heavy lifting is done inside the Swift compiler, which seamlessly translates the C declarations and exposes them as Swift declarations. This enables an incredible developer experience with automatic translations of C declarations to Swift declarations and autocompletion of imported C code in Xcode.

In this post we explored the bare bones way of interoperability of Swift and C without a sophisticated build system, which can be quite tedious. We did so for better understanding of what's going on on the lower level. Usually, we don't have to deal with the compiler directly and we use a more sophisticated build system, most commonly the ones from Xcode and SPM. We also explored the most basic C declaration and haven't covered more advanced types and how they map into Swift.

Part 2 of this blog series will try to explain:

how we can leverage SPM to build mixed language targets
more advanced C integrations
how to go the other way around - calling Swift code from C.

Until next time, M.

SKTestSession testing failures

2025-01-10T00:00:00Z

With iOS 17, Apple shipped a new API allows us to simulate errors when unit testing StoreKit. The API exposes a method called setSimulatedError(_ error: API.Failure?, forAPI api: API) which is intended to be used on a instance of a SKTestSession.

For example, we would use the API to simulate a NetworkError for the purchase API.

try await session.setSimulatedError(.generic(.networkError(URLError(.badURL, userInfo: [:]))), forAPI: .purchase)

This is a great addition and it allows us to test possible error handling flows we have in our code. One thing I encountered when working with this API is that the simulated errors would persist even if I called

 try await session.setSimulatedError(nil, forAPI: .purchase)

as outlined in the WWDC session.

The current workaround for this is to call the resetToDefaultState method on the session before each test executes.

session.resetToDefaultState()

Until next time, M.

Attaching debugger to system apps

2024-09-19T00:00:00Z

Recently, I was writing some UI code, and a question struck my mind: How did Apple do it? I needed a way to find out what Apple was doing to achieve some of their UI in system apps. Luckily, it turns out we can debug the view hierarchy of system apps on the simulator.

In order to do so, we must first turn off System Integrity Protection (SIP). SIP brings enormous efforts to protect your system from unauthorized code. I highly suggest turning it back on as soon as you finish your debugging session. A guide on how to turn it off/on can be found here.

After turning SIP off, we can continue. Open up your terminal and run the simulator with the following command:

open -a simulator

That should launch the simulator. Now, let's type in the following:

xcrun simctl listapps booted

We utilize the simctl CLI to list all apps on the booted simulator. The printed text contains identifiers of the apps that are on the simulator. After a bit of scrolling, you should see the following identifier::

 "com.apple.mobileslideshow" =     {
        ApplicationType = System;
        Bundle = "file:///Library/Developer/C ...

This is the identifier of the Photos app on the simulator. Now, let's run the following command:

xcrun simctl launch booted com.apple.mobileslideshow

This will open up the Photos app on the simulator, and it will print out a number. That number is the PID (process ID) of the freshly launched Photos app. Copy that PID and open up any project in Xcode. Then go to Debug -> Attach to Process by PID or Name, paste in the PID you copied, and hit Attach. Give it a minute, and voilà! You are attached via LLDB to the Photos app. You can even click on the Debug View Hierarchy button, and you'll see the view hierarchy!

Until next time!

P.S. Don't forget to turn on SIP.

Running code when App is Ready

2024-05-20T00:00:00Z

Every now and then, you find yourself in a situation where you need to run specific code when certain conditions are met. My recent encounter with this involved the following flow:

• A VoIP notification wakes up my app

• I need to handle internal call logic and start a call

The problem was that the second part of this flow couldn't start until the UI was ready. In my case, I had to ensure that the Coordinators had executed and the UI was in a state ready to handle the call logic. When developing new features, I often explore open-source codebases for inspiration, and this instance was no exception. In the source code of the popular messaging app Signal, I found a class named AppReadiness that allows you to queue some code and execute it once the conditions are met. Although the class is somewhat complex and robust, I extracted the main concepts and created a lightweight variant suitable for my use case.

Let's explore my lightweight version of AppReadiness.

final class AppReadiness: @unchecked Sendable {
    typealias Task = () -> Void
    private let queue = DispatchQueue(label: "com.supersonicbyte.AppReadiness")
    private var taskQueue: [Task] = []
    private var _isAppReady = false

    static let shared = AppReadiness()

    private init() {}

    func setAppIsReady() {
        queue.sync {
            guard !_isAppReady else { return }
            runQueuedTasks()
            _isAppReady = true
        }
    }

    func isAppReady() -> Bool {
        return queue.sync {
            return _isAppReady
        }
    }

    func runSyncNowOrWhenAppBecomesReady(_ task: @escaping Task) {
        queue.sync {
            if _isAppReady {
                task()
            } else {
                taskQueue.append(task)
            }
        }
    }

    private func runQueuedTasks() {
        for task in taskQueue {
            task()
        }
        taskQueue.removeAll()
    }
}

First, we see that AppReadiness is a singleton, interacting only through the shared instance. This makes sense since the app itself is a single entity, and we need a single source of truth to determine if the app is ready.

Next, we have three public methods: setAppIsReady(), isAppReady(), and runSyncNowOrWhenAppBecomesReady(_ task: @escaping Task).

The first method, setAppIsReady(), allows us to mark the app as ready. The goal is to call this method when all the necessary conditions have been met. In my case, I call setAppIsReady() upon the initialization of the last coordinator during app startup.

The isAppReady() method allows us to query the AppReadiness status in a thread-safe manner.

Finally, the runSyncNowOrWhenAppBecomesReady method allows us to queue code to run when the app is ready. If the app is already ready when this method is called, the task will execute immediately. If the app is not ready, the task will get queued and executed once the setAppIsReady() method is called. Internally, the class uses a DispatchQueue to synchronize access to the shared mutable state, making the class thread-safe.

As I mentioned, this is a lightweight solution, leaving plenty of room for potential improvements and additional features based on your needs. For example, if we needed a way to set dependencies between tasks (e.g., running task C only after tasks A and B are completed), we could utilize the NSOperations API.

At this repo you can find a demo of the AppReadiness.

Until next time, M.

Shortcuts URL Scheme Guide

2024-05-14T00:00:00Z

Many products have great features that aren't utilized as much as they should be. When it comes to iOS, Shortcuts are definitely one of them. To me, Shortcuts provide a meeting place for all the apps the system provides, enabling us to make different apps cooperate. We can run them and connect the outputs of one app to the inputs of others. The possibilities are infinite. This post will focus on one aspect of Shortcuts, and that's the URL scheme. While developers mostly use frameworks like AppIntent and SiriKit to expose app functionalities to Shortcuts, one might ask: how do we run shortcuts from code? The answer is good old URL schemes. So, let's dive into it.

Opening a Shortcut

To open a shortcut, we utilize the following URL: shortcuts://open-shortcut?name=[name], where instead of the [name] placeholder, we put the name of the shortcut we want to open. So, the code may look like:

let url = URL(string: "shortcuts://open-shortcut?name=Shazam shortcut")!
UIApplication.shared.open(url)

"Shazam shortcut" is a preinstalled shortcut.

Creating a New Shortcut

To create a new shortcut, we use the following URL: shortcuts://create-shortcut.

let url = URL(string: "shortcuts://create-shortcut")!
UIApplication.shared.open(url)

Opening the Shortcuts App

If we just want to open the Shortcuts app, we can use the scheme shortcuts://.

let url = URL(string: "shortcuts://")!
UIApplication.shared.open(url)

Running a Shortcut

For running a shortcut from code, we can use the following URL: shortcuts://run-shortcut?name=[name]&input=[input]&text=[text]. Same as the previous URL, the name parameter represents the name of the shortcut we want to run. The input parameter is optional, providing us with a way to send input to the shortcut. The value of the input can be text, in which case we provide an additional parameter text which will hold the text input for the shortcut, or it can have a value clipboard. In the former case, the input to the shortcut will be collected from the clipboard. I created a shortcut named Note With Input you can find it here. To run it from code, we would use:

// Input from text
let url = URL(string: "shortcuts://run-shortcut?name=Note With Input&input=text&text=This is a test from text")!
UIApplication.shared.open(url)

// Input from clipboard
let url2 = URL(string: "shortcuts://run-shortcut?name=Note With Input&input=clipboard")!
UIApplication.shared.open(url2)

Returning to the App after the Shortcut is Finished

To return to the app (call site) from which the shortcut was triggered, we utilize x-callback-url. The x-callback-url standard comes with the following parameters which can be provided in the URL:

• x-success (optional): A URL which opens when a shortcut is finished running. With this, a parameter named result is appended to the URL, containing the textual output of the shortcut. • x-cancel (optional): A URL that opens when the shortcut is cancelled by the user. • x-error (optional): A URL that opens when the shortcut fails because of an error. A parameter named errorMessage is appended to the URL, containing the description of the error.

So, if we wanted to return to the app after running the previous Note With Input action, the URL would look like: shortcuts://x-callback-url/run-shortcut?name=Add Note&input=text&text=Test&x-success=shortcutsdemo://.

In the x-success parameter, we put the URL scheme of our app. So instead of shortcutsdemo://, you would put your app's scheme.

Returning Output from the Shortcut to the App

In the previous section, we mentioned that a result parameter is appended to the x-success callback URL when the shortcut finishes and has a textual output. In order for the result parameter to be present, we need the shortcut to output a result. I created this shortcut, which outputs all created shortcuts.

let url = URL(string: "shortcuts://x-callback-url/run-shortcut?name=Get My Shortcuts&x-success=shortcutsdemo://")!
UIApplication.shared.open(url)

Now, in order to get the result, we add the following code to our ContentView:

.onOpenURL { url in
    if url.scheme == "shortcutsdemo" {
        guard let dirty = url.absoluteString.split(separator: "result=").last,
              let clean = String(dirty).removingPercentEncoding else {
            return
        }
        let shortcuts = clean.split(separator: "\n").map { String($0) }
        print(shortcuts)
    }
}

The code above reacts to URLs that correspond to our app's scheme, then we extract the data from the URL.

I created a sample app, so you can check it out here.

Introducing Publishmon

2024-05-05T00:00:00Z

Recently, I made the decision to rewrite my personal site/blog using Publish. Publish is a popular choice for iOS developers and Swift enthusiasts, and I quite enjoyed the learning curve. However, one thing bothered me: I hated the fact that I had to manually regenerate files and run publish run in the terminal to restart the HTTP server. I remembered when I was writing some Node.js code that there was a package called nodemon, which would restart the server every time a file changed. I searched for a similar solution for Publish but didn't find any. So, the idea of Publishmon was born!

I tinkered with some FSEventStreamCreate APIs and managed to make the site regeneration flow work pretty nicely with Publish. Behind the scenes, Publishmon runs publish run for you every time one of your source files changes. It's available as a Swift package on this repository.

Until next time!

Xcdatamodeld No File Inspector

2023-09-22T00:00:00Z

Recently I worked on a project that uses Core Data. The underlying model changed and I needed to update an entity. This involved changing an attribute from String? to [String]?. In order to make the migration I added a new version of the model. When I tried to set the current active model in the xcdatamodeld file, the file inspector was blank and there wasn’t a way to do it through the UI (Xcode 14.3.1). So, I tried opening the xcdatamoded file in Finder as a text file and modifying the _XCCurrentVersionName key in the XML, but that didn’t work either. The green checkmark still stayed on the old model. I ran git diff in my terminal and saw that the pbxproj file was modified. After some digging around I saw a XCVersionGroup in the pbxproj file, which looked like this:

/* Begin XCVersionGroup section */
        724C37322ABD9D030026634A /* Model.xcdatamodeld */ = {
            isa = XCVersionGroup;
            children = (
                724C37332ABD9D030026634A /* Model.xcdatamodel */,
                724C37342ABD9D030026634A /* Model 2.xcdatamodel */,
            );
            currentVersion = 724C37332ABD9D030026634A /* Model.xcdatamodel */;
            path = Cocoon.xcdatamodeld;
            sourceTree = "<group>";
            versionGroupType = wrapper.xcdatamodel;
        };
/* End XCVersionGroup section */

I updated the currentVersion to point to the Model 2 identifier. So it looked like this after the change:

/* Begin XCVersionGroup section */
        724C37322ABD9D030026634A /* Model.xcdatamodeld */ = {
            isa = XCVersionGroup;
            children = (
                724C37332ABD9D030026634A /* Model.xcdatamodel */,
                724C37342ABD9D030026634A /* Model 2.xcdatamodel */,
            );
            currentVersion = 724C37342ABD9D030026634A /* Model 2.xcdatamodel <-- THIS CHANGED> */;
            path = Cocoon.xcdatamodeld;
            sourceTree = "<group>";
            versionGroupType = wrapper.xcdatamodel;
        };
/* End XCVersionGroup section */

I restared Xcode and the Model 2 was selected as the active model version!