BLACK FRIDAY: Save 50% on all my Swift books and bundles! >>

The pitfalls of string bridging

Swift's strings are designed to work flawlessly with languages around the world, but sometimes – just sometimes – you need to be careful using them. Let's explore why…

This is a free sample from Hacking with Swift+, a subscription that delivers high-quality tutorials as both articles and videos. Click here to find out more >

Watch the video here, or read the article below

If you want to follow along with this tutorial, create a new macOS project using the Command Line Tool template.

Download the completed project for this tutorial here.

Learning some geography

One of my favorite features of Swift's strings is that they have been designed for internationalization out of the box – they support English, French, German, Japanese, Chinese, and more. Some of the time this causes problems: some simple string manipulations that are easy in most languages are bizarrely hard in Swift.

The benefit is that when we need complex string manipulations – for example handling emoji – Swift makes them just as hard as easy manipulations, but in many other languages they are just broken because they expect strings to contain only ASCII characters.

However, Swift also builds on top of very old Objective-C libraries such as Apple's own Foundation framework, and this can cause all sorts of quirks and problems.

Let's look at some code. You're planning a roadtrip in North America, so you put some destinations into a string:

let vacation = "🇨🇦🇺🇸"

Those flags are emoji, but Swift manipulates them just like any other character. So, we can check whether our vacation includes Canada like this:

print(vacation.contains("🇨🇦"))

We can check whether our vacation includes the US like this:

print(vacation.contains("🇺🇸"))

And for a negative case, we can check whether our vacation includes Australia, like this:

print(vacation.contains("🇦🇺"))

So far, so good.

But let's have a little fun with our destination. We've just confirmed we definitely aren't going to Australia on our road trip, not least because it would be rather hard to drive to. What would happen, then, if we replaced Australia in our string with a different country?

We can try it out – we can replace Australia with Nicaragua, a country that's much more drivable:

print(vacation.replacingOccurrences(of: "🇦🇺", with: "🇳🇮"))

And now… our road trip contains China and Iceland?! Those definitely aren't drivable, but they also aren't Canada and the US, or even Australia or Nicaragua for that matter.

What gives?

The smart way to match strings

It's common to want to have some strings to compare, such as an array of names of books, and some search text provided by the user – you might want to filter the books to show only those that match the user's input.

For example:

let array = ["The Hobbit", "Lord of the Rings", "The Silmarillion"]
let search = "Sil"

let matches = array.filter { $0.contains(search) }
print(matches)

That will print one match, but it has a problem: most users don't really care about case sensitivity, and would expect the lowercase string "sil" to match as well.

The contains() method is case-sensitive, meaning that "sil" won't match "The Silmarillion", so sometimes you see code like this:

let matches = array.filter { $0.lowercased().contains(search.lowercased()) }

That's a little better, but it still has a problem: many languages have diacritics, such as the acute accent é in cafe or the ï sometimes written in naïve, and other languages have special characters in some localizations, such as the word "Straße" in Germany being written as "Strasse" in Switzerland because one country uses the Eszett character and the other doesn't.

So, this won't match:

let array = ["strasse"]
let search = "straße"
let matches = array.filter { $0.lowercased().contains(search.lowercased()) }

Swift doesn't contain code to match this kind of text, but Foundation does – it has a separate method called localizedStandardContains() that automatically ignores case, ignores diacritics, and automatically adapts to language variations such as the Eszett.

So, this code will work no matter which variant of German is being used:

let matches = array.filter { $0.localizedStandardContains(search) }

This localizedStandardContains() is described by Apple as being "the most appropriate method for doing user-level string searches," and in fact if you want to do string matching in SwiftData this is your only choice because at least right now it doesn't support lowercased() in its predicates.

You're probably wondering why I've started talking about hobbits and the German language, so let's loop back to a check from earlier:

print(vacation.contains("🇦🇺"))

Our vacation doesn't include Australia, because we're only going to Canada and the US. But what if we had used localizedStandardContains() instead? Let's try that:

print(vacation.localizedStandardContains("🇦🇺"))

And that's going to return true. You thought the location was restricted to North America, but Foundation clearly has other plans!

Going down to Foundation

What's happening here is a disconnect between Swift and Foundation. Remember, Swift's strings are all designed for internationalization, with support for emoji baked in, but Foundation isn't quite as good.

Foundation doesn't use Swift's strings, but instead relies on a much older type called NSString. NSString is used in all of Apple's Objective-C APIs, such as AppKit and UIKit, and so Apple worked a bit of magic: they made Swift silently convert its strings to NSString when working with Objective-C APIs, so we could set button titles in UIKit without lots of workarounds.

This is a process known as bridging, and although Apple adjusted how it works a little over time the essence is that Swift's strings gain a whole bunch of extra functionality for free – we see method calls on strings that actually get executed on an Objective-C NSString, with Swift silently converting to and from the two types for us.

There isn't really much logic for which parts belong to Foundation and which belong to Swift. For example, these are from Foundation:

print(vacation.capitalized)
print(vacation.components(separatedBy: "\n"))
print(vacation.replacingOccurrences(of: "🇦🇺", with: "🇳🇮"))

Whereas these are from Swift:

print(vacation.lowercased())
print(vacation.split(separator: "\n"))
print(vacation.replacing("🇦🇺", with: "🇳🇮"))

So, perhaps now you might be starting to see where our problem lies: I deliberately used replacingOccurrences(of:) in my example code, which silently converts our Swift string to and from an Objective-C NSString for its replacement.

That might already give you an idea of what the underlying problem is, but if not let's try two more lines of code:

print(vacation.count)
print((vacation as NSString).length)

That prints the string's length, but then explicitly converts the string to an NSString and prints the resulting length – it will print 2 for the Swift string, then 8 for the NSString.

A trip into Unicode

If you're still not sure what the problem is, consider this code:

let saying = "The rain in Spain falls mainly on the Spaniards"
print(saying[38])

That prints character 38 in the string, a capital S. Or at least it would if Swift supported reading characters inside strings using their integer offsets.

You see, that kind of code isn't allowed in Swift. It's not because it's tricky, because it's actually pretty easy with a small extension such as this one:

extension String {
    subscript(idx: Int) -> String {
        String(self[index(startIndex, offsetBy: idx)])
    }
}

However, Swift doesn't include such a thing by default because it's terrifically efficient: looking for character 38 means starting at startIndex and counting forward 38 places.

This is intentional, and explains why Swift's string and NSString report back different character counts: complex emoji are actually made up of smaller emoji combined. For example, the emoji 👩🏻‍❤️‍💋‍👩🏿 combines symbols for woman, light skin tone, a red heart, a kiss mark, and a dark skin tone, stitched together with a hidden character called a zero-width joiner.

Each of those are individual characters, so for Swift to read the whole character correctly it has no choice but to start at the beginning and count through each one step by step. If reading index 3 accidentally read out only half an emoji, it would cause all sorts of problems!

And now hopefully you can see the issue: our vacation contains the Canadian flag and the United States flag side by side, which are both emoji created from subsymbols called regional indicator symbols. For Canada that's regional indicator symbol C followed by regional indicator symbol A, "CA", and for the United State it's regional indicator symbol U followed by regional indicator symbol S, "US".

If we put them together, we get the regional indicator symbol CAUS, and – you guessed it – the Australian flag is made from the regional indicator symbols A and U. So, from Swift's perspective we have a Canadian flag followed by an American flag, but from Objective-C's perspective – and therefore from Foundation's perspective – we have four separate letters that could be Canada then the US, or could be a C, Australia, and S.

Now let's look at this line again:

print(vacation.replacingOccurrences(of: "🇦🇺", with: "🇳🇮"))

That's using Foundation API, so our vacation string will be treated as an NSString, and the hidden Australia flag will be replaced with Nicaragua's flag – AU will be replaced with NI.

That means our CAUS string will become CNIS, which in turn means suddenly we're visiting China (CN) and Iceland (IS).

So, the reason our code behaves badly is because Foundation's String APIs behave badly with Unicode. Yes, we took a bit of a roundabout route to get there, but I hope you learned something along the way!

Using this to our advantage

Before we're done, let's at least look at one way we could – in theory, at least! – use this behavior to our advantage.

I have two daughters, and they both enjoy watching women's sports. So, let's say we had a whole bunch of sports emoji like this:

let sports = ["🤼‍♀️", "🤸🏽‍♀️", "🚴‍♀️", "🏊🏿‍♀️", "🏊🏻‍♂️", "🏄🏻‍♀️", "🧗‍♂️"]

How could we know which of those feature women? Well, if we treated each of those as a Swift string there's not much we can do, but if we treated each of them as an NSString then we could take advantage of the fact that each of those emoji contains a separate symbol, ♀, which is used to mean "woman":

for sport in sports {
    if sport.localizedStandardContains("♀") {
        print(sport)
    }
}

That uses localizedStandardContains() because it decomposes the emoji – normally a bad behavior, but actually helpful here!

Now, I'm not saying that's a good idea, but I hope you've definitely learned something new!

If you liked this, you'd love Hacking with Swift+…

Here's just a sample of the other tutorials, with each one coming as an article to read and as a 4K Ultra HD video.

Find out more and subscribe here