However, the introduction of non-copyable types presents a new challenge: how do these types fit into the existing hierarchy?

At first glance, one might assume that non-copyable types could be considered subtypes of regular structs and enums. However, this isn’t possible because these types are inherently copyable. Another idea might be to place them as subtypes of Any, but unfortunately, this approach also fails since Any is implicitly Copyable. 

Consider the following example:

Therefore, non-copyable types do not fit into the existing hierarchy but form their own type hierarchy instead.

However, having two independent type hierarchies makes it really challenging to write generic code. A simple example illustrates this issue:

In this case, the generic type parameter T assumes copyability, as it is a subtype of Any. Consequently, a type from the non-copyable hierarchy can’t be passed in.

We could employ a workaround here, writing an alternative function that accepts non-copyable types. However, this approach makes non-copyable types feel like second-class citizens in Swift’s type system.
The issue is even worse if you consider that you can’t use non-copyable types with Optional:

Before delving into the new type hierarchy, it is important to clarify the meaning of ~Copyable. 

This means that when a type is marked as ~Copyable, the compiler is not allowed to insert any copy operations for that type.

Here’s what this means for generic code constrained to ~Copyable:

First of all, we need to specify ownership, as the compiler needs to understand which operations are allowed within the function.

Once we do that, we can use generic functions both with ~Copyable and Copyable types.

This way, Copyable types are effectively a subtype of ~Copyable, as Copyable adds new functionality to the conforming type.

Finally, the new type hierarchy can be illustrated as follows:

At first glance, it may seem strange that we can use a copyable type in place of a non-copyable one in generic code. This is where the naming of the feature can be confusing. In generic code, we are not strictly dealing with non-copyable types, but rather maybe-copyable types.

In a way, the distinction is contextual:

Though it may seem like this distinction calls for a different syntax, in practice, both non-copyable and maybe-copyable types share the fundamental requirement: the compiler cannot assume the type is copyable.

To demonstrate the performance advantages of non-copyable types in Swift, let’s try a real-world, performance-critical task: finding the longest line in a large file. In cases where files are too large to load entirely into memory, we need to read them line by line. Optimizing tasks like this can yield significant benefits for performance, especially when processing multi-gigabyte files.

For our case study, we use a large dataset – 2,47GB of Github Commit Messages. The goal is to identify the longest line in the file as efficiently as possible.

Source code

The following code sample demonstrates a possible typical wrapper around a FILE pointer:

And this code illustrates the readLine API that the File wrapper might expose.

Finally, we can implement an algorithm to find the longest line:

Running this code on a large file won’t complete in a reasonable amount of time. Before we optimize it, we want to check the instruments trace:

We can see that over 90% of the time is spent in functions related to String handling, which is somewhat expected. Swift’s Strings are very powerful, but that power comes at a cost.

Ideally, we’d want to see file reading operations at the top of the profile.

Source code

Instead of constructing a String for every line that we read, let’s expose the [CChar] array as a return type of readLine and construct a String only when we have a result:

Let’s see how it performs now.

This change eliminates much of the overhead associated with String creation, but performance is still impacted by the memory allocations for each line. This is expected, as we are allocating a new buffer for each line read.

Source code

Let’s reuse a buffer from the previous read iteration instead of allocating a new one every time:

If we profile this code, we get the following trace:

This reduces the memory allocation cost but surfaces a new issue: the Array type in Swift is a copy-on-write (CoW) data type, and whenever we find a new longest line, the whole array will be copied.

Source code

To avoid unnecessary copying, we will not expose [CChar] directly but wrap a pointer in a FileChunk object:

This is our findLongest algorithm now:

Let’s profile it now:

The situation is looking much better. As we would expect, the majority of the time is spent on fgets and the associated C functions.

It is also interesting to notice that swift_retain and swift_release incur significant costs.

Source code

To address this issue, we’ll convert FileChunk from a reference type to a non-copyable type:

But now we are required to explicitly manage the ownership of FileChunk as it can no longer be shared between multiple owners.

First, we need to adjust our readLine function to make ownership explicit:

In this version, we mark the FileChunk parameter as consuming, meaning the function takes ownership of the argument. Once the buffer is filled, the function returns currentChunk, passing ownership back to the caller, allowing the buffer to be reused.

After making this change, we get two errors in our findLongest implementation:

Let’s solve them:

And now, let’s check the performance.

We can see that almost all of the time is spent on file reading operations, indicating a significant performance improvement.

The performance improvements across the different implementations are summarized in the table below:

Note: If you are interested, the longest line can be found in this commit.

If you look closely, you’ll notice a difference between our final implementation using a reference type and the one using a non-copyable type:

Upon closer inspection, we can see that the reference type implementation contains a hidden bug – it overrides the longest line found because the buffer is being reused. This issue is avoided with the non-copyable type, as it enforces unique ownership and prevents unintentional buffer reuse.

As we’ve seen, non-copyable types offer not only performance benefits but also improved safety compared to reference types. They are a safer and more ergonomic alternative to dealing with raw pointers.

One of the reasons the programming language C is known for its speed is that it exposes the full complexity of memory management, allowing direct manipulation through pointers. Swift, as a high-level programming language, abstracts much of this complexity. With the introduction of non-copyable types, Swift strikes a balance – allowing developers to write safe, high-performance code while maintaining the high-level programming experience.

For reference, the associated source code for this article can be found here.

The diagram shows three mutually exclusive states of our program:

To provide a consistent experience, it is useful to represent this idea in code explicitly. In SwiftUI, we can define something like:

This allows us to handle loading, error, and success states generically and consistently throughout the app.

ErrorView can look something like this:

This way, users will always see localized descriptions of the error, and they will be able to retry the operation. We also have the flexibility to expose other relevant information such as error code or error user info.

This pattern can either be applied to the whole screen or partially, to some of its elements.

To ensure this pattern works well, all your errors should conform to LocalizedError and provide a meaningful message to the user.

Unfortunately, in many cases, we will get an error from some API in either a third-party SDK or an iOS SDK. If it’s important to provide a human-readable message in those cases, you will need to handle those errors explicitly and provide your error message.

One of those cases can be a state of no internet connection. The code that handles it might look like this:

If the app uses backend APIs, this will most likely be the main source of errors. Try to define an error body contract with the backend team. This will transfer the ownership of error messages to the originator. The backend has more context required to return a good error message to the user.

This can be optionally parsed from the response of URLSession and thrown as a more detailed error:

We all prefer convenient and easy-to-use APIs. But we need to be aware of what goes on in the background.

For example, it might be tempting to expose Keychain API as a property wrapper. That would allow us to do something like this:

This is very expressive code. In just one line, it is clear that we are dealing with a keychain item that automatically gets serialized and deserialized to the keychain.

Unfortunately, with such an API design, we fundamentally limit our program to handling keychain errors. The reason is that the underlying keychain API returns the status of the operation being performed. By exposing such an API as String?, we effectively map all errors to optional values.

The same advice can be applied to choosing libraries. Understand what you get by integrating a library.

We can summarize this with a few simple rules:

By following these rules, we also get some positive side effects:

Users are generally interested in human-readable descriptions of errors. But for programmers, it is critical to have as many details as possible about the error.

We can expose these details in our ErrorView by providing an additional Details button. If you can’t do that in production, it might be a good idea to enable detailed error handling at least in staging builds. This can make finding issues easier and shorten the feedback loop between the person reproducing the error and you.

Firebase non-fatals are a great way to get more detailed information about errors that occur in production. This can usually provide critical information for debugging user-reported issues. To utilize and analyze them effectively, we need fine-grained error grouping.

As the Crashlytics guide states:

This means that, to group Swift errors properly, we need to conform them to CustomNSError. For example, our APIError can conform to CustomNSError in the following way:

This will group all API errors with the same status code.

The additional benefit of conforming to CustomNSError is that we can provide additional details that will show up in Firebase:

An application crash is usually the worst outcome our app users can experience, and we should do everything we can to prevent it. However, avoiding crashes is not something to be done at any cost. In some cases, we want to “fail fast” and use those crashes to find issues more effectively.

Generally speaking, when we can’t handle some condition in a meaningful way, we should expose it as an error to the user.

However, we are also limited by the programming language and the ecosystem we operate in. Sometimes we need more expressivity in the language to represent some concept.

Let’s look at the following example:

In general, force unwrapping is a pattern that we would like to avoid. But in this case, making init throwing wouldn’t convey the right message and would pollute the code. It would require all upstream functions to be annotated with throws, which would obscure the true value of genuine errors.

Here is another example:

In this case, we believe that all preconditions for creating CVDisplayLink are fulfilled when this code is invoked. Therefore, instead of propagating optional CVDisplayLink through the codebase, we declare that this operation will crash the program, which allows us to catch holes in our assumptions quickly.

The decision whether to crash, throw an error or return optional value needs to be made on a case-by-case basis. Here are some questions you should ask yourself to make this decision more easily:

If you want to explore this topic further, here are some good resources:

Looking at the stack trace can very often lead us to a clear root cause of the crash and the conditions under which it happens. Unfortunately, this is not the case for all crashes, and any associated information might prove useful for investigating, understanding, reproducing, and fixing the crash.

We can abstract this idea into the following protocol:

And we can implement Firebase crash info logging:

And finally, we can provide a convenient extension for it:

This way, we can log some key events during the program’s execution. If the app crashes, these key events will be associated with the crash report in Firebase.

Whether it is crashes or errors, some problems might never be reproducible in your local setup. For these kinds of issues, we often need to experiment with the fix.

In that case, we need some way of confirming if the fix helped or not. Firebase can provide valuable information about that. The following graph is an example of an issue that was fixed and confirmed by production data:

Firebase also provides a lot of valuable associated data. For example, this crash is only happening on iOS 15:

This is key information that can help us reproduce and fix the issue.

App Store Connect can also provide valuable information about your crash rate and how you compare to other apps in your category. It is important to monitor this trend and ensure it does not grow.

Beyond technical concerns, there are legal and regulatory aspects to consider with crash and error handling. For example, this includes data protection laws such as the General Data Protection Regulation (GDPR). 

Furthermore, it’s worth noting that some companies have strict policies prohibiting the transmission of any data to third parties, regardless of the circumstances. These policies may stem from privacy concerns, contractual obligations, or industry regulations.

Logging errors or even crashes to third-party systems can have a legal impact on the product you are building, so always check with your legal department to see what you are allowed to do.

Even if we follow all the best practices and invest significant resources into this area, errors and crashes are almost impossible to avoid. Therefore, it is important to be upfront about the situation with your clients and have open discussions about it.

It is more professional to inform your client that a new application version has introduced a crash than to have them come to you with a complaining user report.

Clients are generally not interested in individual crashes. Instead, you can set up a cadence where you check the status and inform your client in a public channel. This builds trust and understanding and allows you to handle issues professionally.

Robust error handling requires intention and care, but it is fundamentally not difficult.

Following the best practices creates substantial benefits for your organization, including more effective debugging and issue resolution, a deeper understanding of user behavior, stronger client relationships, and more reliable applications. 

We hope this guide has equipped you with the knowledge and tools to enhance your error and crash-handling strategies. Take action today to implement these practices and reap the benefits for your organization’s success.

Before diving into the details of Swift’s default ownership system, let’s clarify what ownership means for value types compared to reference types:

Before Swift 5.9, there was no way to control ownership of parameters passed to functions.

Instead, Swift’s default argument passing semantics were as follows:

But what does this mean in practice? Let’s explore a small example:

Looking at the assembly code generated by the compiler in Godbolt, we observe the following:

We can see that before calling A.init, the compiler inserts a retain. The reason is that, by default, initializers are taking ownership of their arguments, and to do so, they need to be passed with a +1 retain count.

On the other hand, this short code snippet:

compiles to:

We can see that there is no retain before calling A.f. That is because, by default, functions do not take ownership of their arguments.

But what if a function needs ownership of an argument? For example, in this case:

In this case, the function will retain the argument:

You might wonder why initializers are not borrowing as well. The reasoning would be – if an initializer doesn’t need ownership of an argument, we avoid the extra retain. If it needs it, it can retain it in the same way as functions.

To understand this, let’s look at this example:

In this example, when we initialize b, it is automatically retained. However, pay attention that b is not used anymore. So we create b just to pass it to A.init. In this case, b can pass ownership to A.init, and no extra retain needs to be emitted.

To get a better understanding of why these choices are important, we will examine a performance benchmark that measures the impact of the retain operation.

You can run this performance benchmark by executing:

Keep in mind that this only demonstrates the performance impact of retain. When we retain an object, we usually need to release it, making the impact even more significant.

SE-0377 introduced new function parameter modifiers: borrowing and consuming. Syntactically, they are used in the same position as inout and are mutually exclusive with it.

Semantically, the low-level meaning of these operations can be summarized in the following table:

To understand the performance impact of these annotations, we will actively work against Swift’s default ownership system. This means:

Let’s consider the following example:

What is the performance difference between calling init(test:) and init(borrowingTest:)? 

You can run the performance benchmark for this example by executing:

Let’s consider the following example:

What is the performance difference of calling assignTest(test:) vs assignTest(consumingTest:)?

You can run this benchmark by executing:

Even without annotating parameters such as borrowing, the compiler can sometimes have visibility that the initializer borrows the argument and can optimize away unnecessary ARC traffic. For compiler optimization tips and tricks, check out this document. 

However, compiler optimizations depend on the optimization mode, code structure, and other factors that are not always in our control. 

For performance-critical code, we want guaranteed predictable behavior, which the new parameter modifiers provide.

Introduced in SE-0366, the consume operator allows us to end the lifetime of a variable. 

For example:

After we consume x, the attempt to use it will throw a compiler error “x used after consume.”

This is great for passing ownership of local variables explicitly to the initializer and works well with its consuming counterpart.

For example:

The performance implications of this are shown in the chart below, but you can run this benchmark by executing:

While the new borrowing and consuming modifiers can be considered “advanced” features, understanding them at a basic level provides a better insight into how the Swift compiler and optimizer work. It is also critical to understand them for writing low-level code without sacrificing the type safety provided by Swift.

However, even with these new “advanced” features, Swift remains a beginner-friendly language. As nicely summarized in A roadmap for improving Swift performance predictability, “we want these features to fit within the “progressive disclosure” ethos of Swift.”

The Ownership Manifesto confirms a similar approach:

“It is the core team’s expectation that ownership can be delivered as an opt-in enhancement to Swift. Programmers should be able to largely ignore ownership and not suffer for it. If this expectation proves to not be satisfiable, we will reject ownership rather than imposing substantial burdens on regular programs.”

You can find the associated source code here.

​Saved presets are stored in a specific location. To access them, go to: ~/Library/Audio/Presets/Apple/AUSampler.

However, you can also easily navigate to them within AU Lab by pressing CMD+P, selecting a preset, and choosing ‘Show in Finder’ from the menu.

The default AUSampler property list files are more than 300 lines long! Here is an example of a preset’s high-level structure with irrelevant details removed:

Once you have obtained the AUPreset file, you can proceed to load it into AVAudioUnitSampler:

This allows you to integrate the customized instrument into your audio app and take advantage of the rich capabilities offered by AUSampler.

While AUPreset files allow us to statically configure the sampler, music apps are more fun and enjoyable when they are interactive.

We would like to allow performers to play notes and adjust their instrument parameters in real-time. This dynamic experience allows them to receive immediate feedback and enhance their creativity.

How can we achieve such a dynamic experience?

In the context of AUSampler, connections provide a powerful mechanism to map source events to destination events, allowing for real-time updates and control. When we add an instrument in AU Lab or any other compatible environment, a default set of connections is automatically created.

Let’s take a specific example to illustrate the concept of connections. One common connection is the ‘Key Velocity’ connection, which maps the velocity of the pressed key to the gain of a specific layer in the instrument. In simpler terms, when a performer hits a note with more force or velocity, it will cause a louder sound to be produced.

By establishing this connection, we can create a more expressive and nuanced playing experience.

Similarly, we can set up a ‘Gain’ connection, where the expression pedal controls the gain, or volume level, of the played notes:

Let’s break down the structure of a connection:

Connections are a great and user-friendly way to set up a dynamic experience. Unfortunately, they only support a limited number of parameters that AUSampler exposes. Additionally, some of them simply don’t work.

One useful feature of AudioUnit is its ability to load and export presets using AUPreset files. This functionality allows users to create and save their preferred configurations, making it convenient to switch between presets based on different situations.

When an AUAudioUnit is loaded with an AUPreset file, the state is stored in the fullState property. Any changes made to the configuration are reflected in this property as well. By dumping the contents of the fullState property into a new AUPreset file, users can save and load their customized settings at a later time.

We can use this to our advantage and dynamically modify the fullState property.

For example, if we want to control the resonance of the sampler, we can utilize the following approach:

This method provides great versatility by allowing us to update any aspect of the sampler dynamically. It’s important to note that such modifications will require the sampler to reload its state, which will result in a momentary interruption in the sound output.

However, there is another approach that can be considered to be the most powerful. You might have noticed that the AUSampler custom view allows you to control sampler properties in real time. Taking our example of resonance, the resonance knob functions flawlessly in AUSampler custom view. We can play notes, and the resonance is updated instantaneously without any interruption in the sound output.

Can we somehow achieve the same effect, even when not in custom view?

In the first blog post of this series, we explored how to query the hidden Voice Count property by hooking into AudioUnitGetProperty. In our case, we need to go in the opposite direction and hook into AudioUnitSetProperty instead:

Intel:

ARM:

This approach will provide us with the secret property ID (4162) that enables us to control the resonance property without any audio interruptions.

There is barely any mention of AUSampler property IDs in the Apple documentation. This is unfortunate because, as it turns out, following our approach of finding the property ID for resonance control, we can find a lot more powerful properties. But one more aspect of AudioUnitSetProperty remains unclear – inElement. 

The documentation simply describes it as:

For global properties, inElement is always zero, but how can we distinguish between resonance for Layer 1 and Layer 2?

There is a convention that AUSampler uses: every layer item has its base element ID, which increases by 0x00000100 for subsequent layers:

LFO – 0x10000000

Envelope – 0x20000000

Filter – 0x40000000

Zone – 0x70000000

Connections – 0x60000000

Thus, setting resonance for the given layer index requires the following code: