Now I know that the majority of the world uses QWERTY, but there are also AZERTY, QWERTZ, and other less common keyboard layouts. So the prefix “ib” that I chose for my UIViewKit framework happens to be part of the common set across these layouts—I got lucky.

Now I realize that the choice is more complex and should probably be made with the QWERTY layout as a reference.

In upcoming posts, I am going to share my findings about keyboards, UHID, system keyboard layouts, and using a keyboard when you are bilingual.

Look at your keyboard.

Now look at a 19th-century typewriter.

Different materials. Same structure.

The first commercially successful writing machines introduced QWERTY to solve a mechanical problem: metal typebars were colliding. The layout wasn’t optimized for speed or ergonomics. It was engineered to prevent jams.

Read more

For nearly two months, I’ve been publishing notes and deep dives on Unicode and Swift’s String.

You’ve followed the journey. 👀

Now it’s time for the crash course. 👨‍💻

The content is ready.

This course is built for Mobile Leads and iOS developers who want a clear, structured understanding.

The goal is straightforward:

Fast-track Unicode from abstract tables to Swift’s String model.

Understand normalization, equality, hashing, sorting, and searching in practice.

See how real user input, real Unicode, can quietly affect your production apps.

Focused. Practical. Directly applicable.

Here is the link: Link

Join the crash course. See you inside. 🚀

It can be confusing when deleting a single visible character requires two or more backspace taps. You press delete once, nothing seems to happen. Press again, and only then does the character disappear. This is not a keyboard bug. It is usually a consequence of Unicode composition and normalization.

In Swift, a String is a collection of extended grapheme clusters, not Unicode scalars or UTF-16 code units. What looks like one character on screen can be composed of multiple scalars. Normalization (NFC vs NFD) affects equality and storage. Compatibility normalization (NFKC) goes further: it folds compatibility characters into their canonical equivalents.

import Foundation

// Canonical normalization (NFC)
let decomposed = "e\u{0301}" // se + ◌́
let nfc = decomposed.precomposedStringWithCanonicalMapping
print(nfc.unicodeScalars.count) // 1

// Compatibility normalization (NFKC)
let ligature = "fi" // U+FB01 LATIN SMALL LIGATURE FI
print(ligature == "fi") // false

let nfkc = ligature.precomposedStringWithCompatibilityMapping
print(nfkc == "fi") // true
print(nfkc.unicodeScalars.map { $0.value }) // [102, 105]

Today, someone posted on LinkedIn about the Chain of Responsibility pattern, which reminded me of that document. There is still an HTML version available online. I hope someone will find it helpful. Here is the link: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW6

The project is open source. Its main repository is at github.com/SwiftFiddle/swiftfiddle-web, licensed under MIT and maintained by the SwiftFiddle organization. Contributors have been active on the codebase for years, and the playground shows up in community links as early as 2023.

You can use SwiftFiddle at https://swiftfiddle.com, where you pick a Swift version, write code, and run it in the browser. Because all versions execute on the same Linux/ICU environment, Unicode behavior — including String equality and canonical equivalence — is consistent across tests.

SwiftFiddle is useful for:

• sharing minimal reproducible examples

• quickly experimenting with language features

• embedding runnable Swift snippets in docs or discussions

Comparing strings for equality using the equal-to operator (==) or a relational operator (like < or >=) is always performed using Unicode canonical representation. As a result, different representations of a string compare as being equal.

let cafe1 = "Cafe\u{301}" // NFD - Normalization Form D (Canonical Decomposition)
let cafe2 = "Café" // NFC - Normalization Form C (Canonical Composition)
print(cafe1 == cafe2)
// Prints "true"

The Unicode scalar value “\u{301}” modifies the preceding character to include an accent, so “e\u{301}” has the same canonical representation as the single Unicode scalar value “é”.

Basic string operations are not sensitive to locale settings, ensuring that string comparisons and other operations always have a single, stable result, allowing strings to be used as keys in Dictionary instances and for other purposes.1

Dictionary keys rely on hashing for fast lookup and fall back to == to resolve collisions. Because String equality is Unicode-aware, keys with different code points but canonically equivalent values are considered equal. When creating a dictionary, this can trigger a duplicate-key conflict (requiring a conflict-resolution closure) or even crash the app, depending on the initializer used; when assigning a value later, the new value replaces the existing one.

Set behaves similarly: canonically equivalent strings represented with different code points (for example, NFC vs NFD) are treated as the same element. In such cases, only one value is stored, and the actual stored representation depends on which variant was inserted first.

Concatenation, user input, copy-paste, JSON payloads, and localization frequently introduce mixed normalization. You don’t see it. Swift does.

Rule of thumb: when a string is used as an identifier, key, or lookup value—and there is a risk of mixed normalization (NFC vs NFD)—normalize it explicitly (and usually case-fold it) before storing or comparing. Unicode equivalence is great for text—but dangerous for identifiers.

Even though a and b are built from different Unicode scalar sequences, Swift treats them as equal. That’s because Swift normalizes strings for equality and hashing. If two strings are canonically equivalent in Unicode, they are considered the same value when inserted into a Set or used as dictionary keys.

This is a deliberate design choice. Swift optimizes for human-perceived equality, not raw binary representation. From a user’s point of view, “é” is “é”, regardless of how it was typed, copied, or transmitted.

The subtlety is that this behavior is invisible until it matters. It shows up when you deduplicate user input, process international text, or handle data coming from multiple systems. If you assume that different scalar sequences always produce different values, your mental model of Set is already wrong.

import Foundation

// ORIGINAL JSON payload (VALID JSON)
// Two canonically equivalent strings encoded differently
let originalJSON = """
{
  "tags": ["\\u00E0", "a\\u0300"]
}
""".data(using: .utf8)!

struct Payload: Codable {
    let tags: [String]
}

// 1️⃣ Decode original JSON
let decoded = try JSONDecoder().decode(Payload.self, from: originalJSON)

print("Original decoded JSON:")
print(decoded.tags)
print("count =", decoded.tags.count) // ✅ 2
print()

// 2️⃣ Inspect internal representations
print("Decoded strings:")
for tag in decoded.tags {
    print(
        "\"\(tag)\" scalars:", tag.unicodeScalars.count,
        "characters:", tag.count
    )
}
print()

// 3️⃣ Convert Array → Set
// ISSUE:
// Set<String> collapses canonically equivalent strings.
// Information is lost here.
let rawSet = Set(decoded.tags)

print("After Set conversion (DATA LOSS):")
print("count =", rawSet.count) // ❌ 1 (was 2)
print(rawSet)
print()

// 4️⃣ Re-encode after Set
// This JSON is NOT equivalent to the original input.
let reencoded = try JSONEncoder().encode(
    Payload(tags: Array(rawSet))
)

print("Re-encoded JSON (information lost):")
print(String(data: reencoded, encoding: .utf8)!)

Output:

Original decoded JSON:
["à", "à"]
count = 2
Decoded strings:
"à" scalars: 1 characters: 1
"à" scalars: 2 characters: 1
After Set conversion (DATA LOSS):
count = 1
["à"]
Re-encoded JSON (information lost):
{"tags":["à"]}

The key takeaway: in Swift, string equality is semantic, not structural. Unicode normalization, for some operations, is baked into the language.

This is one of the edge cases I cover in my Unicode training.

String semantics is a higher-level concept. Although the word semantics looks plural, it refers to a single domain: meaning. At the semantic level, a string represents human-perceived text rather than its construction details. Different syntactic forms can therefore map to the same semantic value. For example, “\u{00E9}” (precomposed é) and “\u{0065}\u{0301}” (an e plus a combining acute accent) are syntactically different, yet semantically equivalent. Humans read the same character; the string system’s job is to bridge low-level Unicode mechanics with high-level meaning.

Why does the ~/Developer folder in the Home directory show up with a hammer icon in the sidebar?

Because this is a preferred location defined by Apple for storing Xcode projects. It is not mandatory, but if you choose that location, macOS displays a dedicated pictogram—similar to the Downloads or Desktop folders.

The ~/Developer folder is the natural place to:

• store Xcode projects

• clone GitHub repositories

• keep code projects executed or generated by Codex, Cloud tools, or other generative CLIs, and Android Studio

If you are a hobby developer and are not interested in keeping your projects under Git control, you can place them anywhere. To back up such projects, simply duplicate or zip them. Typical locations include ~/Desktop or ~/Documents.

PoC / temporary / test projects stored on ~/Desktop?

Yes — it’s a convenient location when creating a new project with no business value.

If you keep projects in ~/Desktop or ~/Documents and those folders are synchronized with iCloud Drive, you get automatic backups. However, there is a risk: synchronization can be partial.

A realistic failure scenario:

• You work on an app

• The internet connection is slow or intermittent

• Some files sync, others don’t

• You leave (for lunch, for example)

• Your computer is stolen

• You buy a new Mac

• iCloud restores the project, but not all files are at the same revision

Result: the app no longer compiles.

This is a rare case, but it can happen.

1. The Surprising Result

let result = "🇨🇦🇺🇸".replacingOccurrences(of: "🇦🇺", with: "🇳🇮")

Result:

🇨🇳🇮🇸

At first glance…

Read more

Yes — Swift can run without the standard library.
But once you remove it, you quickly realize that most of what you think of as “Swift” isn’t the language itself, but the standard library layered on top of compiler primitives.

To understand why, you need to understand Swift built-in types.

What “built-in types” actually are in Swift

Swift built-in types are compiler-internal primitives exposed under a special namespace called Builtin. They exist below the standard library and are used by the compiler to model memory, values, and operations before anything becomes Int, Bool, or Optional.

Examples include:

• Builtin.Int1, Builtin.Int64

• Builtin.Word

• Builtin.RawPointer

• Builtin.NativeObject

• Builtin.BridgeObject

• Builtin.FPIEEE64

• SIL-only token and vector types

Key facts:

• You cannot import them

• They do not appear in autocomplete

• They are not stable APIs

• They are meant for the compiler and standard library only

These types exist so Swift can lower high-level code into LLVM IR efficiently and predictably.

Built-ins vs the standard library

Int, Bool, Optional, Array, and even String are not built-in types. They are standard library abstractions built on top of built-ins.

For example, Int is effectively a wrapper around a compiler-known integer representation backed by a Builtin.Int* type. Arithmetic, comparisons, overflow behavior, and literals are implemented via compiler intrinsics operating on built-ins.

The actual layering looks like this:

LLVM IR
↑
Swift Built-in Types (Builtin.*)
↑
Swift Standard Library (Int, Bool, Optional…)
↑
Your Swift code

Once you remove the standard library, you lose everything above the Builtin layer.

Where built-in types live in the source

You won’t find built-in types in Xcode documentation. You need the Swift compiler source maintained by the Swift Project.

Important locations:

• swift/include/swift/AST/Builtins.def

• swift/include/swift/AST/BuiltinTypes.def

These files define what built-ins exist and how the compiler understands them.

To see how they’re used:

• swift/lib/SIL/ — Swift Intermediate Language

• swift/lib/IRGen/ — lowering to LLVM IR

To see how the standard library wraps them:

• swift/stdlib/public/core/Builtin.swift

• swift/stdlib/public/core/Int.swift

• swift/stdlib/public/core/Optional.swift

This is where compiler magic turns into user-facing APIs.

So… can Swift really run without the standard library?

This exact question is discussed in depth on the Swift Forums in the thread “Swift with no standard library”. The conclusion is consistent and blunt:

• You can compile Swift with -nostdlib

• You can execute code using only built-ins

• You lose literals, collections, strings, ARC helpers, and most conveniences

• Writing meaningful programs becomes extremely low-level very quickly

That discussion also points to an interesting experiment: μSwift, available as the compnerd/uswift repository on GitHub. It provides a minimal stdlib-like core designed for constrained or experimental environments. It’s not a replacement for the real standard library, but it demonstrates that built-in types are sufficient to bootstrap higher-level abstractions — at a significant engineering cost.

Takeaways

• It is technically possible to write and execute Swift code without the standard library.

• Swift built-in types are thin compiler-level primitives that map directly onto LLVM representations.

• A public GitHub repository compnerd/uswift demonstrates that this approach works in practice, not just in theory.

• There is a thoughtful and technical discussion on the Swift Forums “Swift with no standard library“ that explores the limits, trade-offs, and motivations behind running Swift without its standard library.

To split a String into an Array using the Swift Standard Library, use the split(separator:) method.

Example split-1:

"Poland,France , Germany,, ".split(separator: ",")

["Poland", "France ", " Germany", " "]

Example split-2:

"Poland,France , Germany,, ".split(separator: ",", omittingEmptySubsequences: false)

["Poland", "France ", " Germany", "", " "]

Example split-3:

"Poland,France , Germany,, ".split(separator: ",", maxSplits: 1)

["Poland", "France , Germany,, "]

Example split-4:

"Poland,France , Germany,, ,.Europe".split(omittingEmptySubsequences: false) { $0.isPunctuation }
["Poland", "France ", " Germany", "", " ", "", "Europe"]

In all cases, the result type is Array<Substring>.

To obtain String values, a transformation is needed:

let s :[Substring] = "Poland,France".split(separator: ",")
let s :[String] = "Poland,France".split(separator: ",").map(String.init)

There is also a Foundation’s components(separated:By) method.

Example components-1:

"Poland,France , Germany,,".components(separatedBy: ",")

["Poland", "France ", " Germany", "", ""]

Example components-2:

"Poland,France , Germany,, ,.Europe".components(separatedBy: CharacterSet.punctuationCharacters)

["Poland", "France ", " Germany", "", ""]

The result type is Array<String>. No transformation is needed to obtain String values.

What is the difference between Swift Standard Library split(separator:) and Foundation’s components(separatedBy:) methods?

There are differences between split and components methods of a Swift’s String. The components method is defined in Foundation and part of NSString and available in files which imported Foundation framework. The split method is part of Swift’s Standard Library. NSString API was evolving from 1990 and was impacted by development of Unicode, that’s why NSString memory storage is UTF-16 encoded and it’s API mainly is working on Unicode code units, in some cases it can be code units. Swift’s String is backed by UTF-8 encoded storage and it’s API is working with cluster code points. If needed the String’s API incudes access to code units via UTF-8, UTF-16 views.

When using components(separatedBy:) NSSting API must use additional operations to interpret Swift’s storage which is encoded in UTF-8 as UTF-16 which is the base for operations of NSString API.

Important to remember is that split can behave as components for adjacent occurences of separator but omittingEmptySubsequences must be set to false.

Unicode and Fonts

From custom app fonts to the Last Resort font

This post explains the relationship between Unicode and fonts, with a focus on what happens when custom fonts lack glyphs. It covers font coverage limits, system fallback behavior, and why missing characters appear as fallback glyphs or, in the worst case, the Last Resort font in applications.

1. What Is Unicode?

Unicode is an ordered system that defines characters and their identifiers.

More precisely, it defines a set of code points—numeric identifiers that uniquely represent characters in text. A code point identifies what a character is, not how it looks.

Unicode is more than a simple table. The standard also specifies algorithms for combining marks, bidirectional text ordering, normalization, segmentation, and shaping behavior for complex scripts. These rules are implemented by operating systems and text engines.

Unicode itself does not draw anything. It defines characters and their behavior; visual rendering is handled elsewhere. The same Unicode character can appear differently depending on the font and platform.1

2. What Is a Font?

A font is a collection of designed glyphs, metrics, and typographic rules packaged together to render characters visually. It defines appearance, spacing, shaping behavior, and stylistic variations, and is distributed as a font file.

A Unicode font is a font that maps glyphs to code points defined by the Unicode Standard. Fonts do not define Unicode; they implement it by providing visual representations for some subset of code points.

Fonts that support a wide range of scripts and symbols are sometimes called pan-Unicode fonts. However, a single font file is limited to 65,535 glyphs, because glyph identifiers are 16-bit values. As a result, no single font can provide distinct glyphs for all defined Unicode characters (159,801 characters in Unicode 17.0).

In practice, “pan-Unicode” does not mean one font file. It refers to a family of coordinated fonts, each covering different scripts or character ranges.

Notable examples include Noto (Google), Arial Unicode MS (Microsoft), DejaVu Sans, and GNU Unifont.

3. What Is the Noto Font Family?

The Noto2 font family is a collection of open-source fonts created by Google that aims to provide consistent coverage across Unicode scripts. “Noto” means “No Tofu”, referring to the goal of eliminating missing-glyph boxes.

Rather than a single massive font, Noto is composed of script-specific fonts (Latin, Arabic, CJK, Emoji, and others) designed to work together visually. Despite its broad coverage, Noto is not fully complete, and systems may still fall back to other fonts or the Last Resort font for rare or newly added code points.

4. Font Fallback Mechanism

Font fallback3 is handled by the operating system’s text rendering stack, which sits between applications and fonts. When an application requests text rendering, the system maps Unicode code points to glyphs provided by the selected font.

If a glyph is missing, the text engine automatically searches a prioritized set of fallback fonts that better match the script, language, and typographic context. This resolution happens at the glyph level and may result in multiple fonts being used within the same line of text.

If no available font contains the required glyph, the system ultimately uses the Last Resort font, indicating missing font coverage rather than invalid text.

5. What Is the Last Resort Font?

The Last Resort font4 is a special-purpose font used by operating systems as the final step in the font fallback process. It does not attempt to render characters correctly or aesthetically.

Instead, it provides a generic placeholder glyph for every possible Unicode code point. Each glyph typically appears as a box containing a visual representation of the character’s Unicode value.

This makes the Last Resort font diagnostic rather than typographic. Its presence indicates that the character is valid Unicode, but no installed font provides a proper glyph for it. If you see this font, you have a font coverage problem.

6. Debug Fonts

Adobe also provides specialized diagnostic fonts such as Adobe Blank5 and Adobe .notdef. Adobe Blank is a font that intentionally contains empty glyphs for most characters, making rendered text effectively invisible. It is used to detect unintended text rendering or layout dependencies. Adobe .notdef focuses on exposing missing-glyph behavior by forcing the use of the .notdef glyph. Unlike the Last Resort font, these fonts are developer tools, not system fallbacks, and are used deliberately to debug font coverage and rendering assumptions.

7. Custom App Fonts

When an application specifies a custom font and that font does not contain a glyph for a given code point, the operating system performs fallback:

• Try the custom font

• If the glyph is missing, try system fallback fonts

• If no glyph exists anywhere, display a tofu box or the Last Resort font

This fallback often appears as a sudden change in style inside a word, label, or paragraph.

8. Practical Advice for App Developers

Use the system default font unless your app’s identity truly depends on a custom typeface.

System fonts provide broad script coverage and built-in shaping support, but they can change across OS versions. Metric adjustments may occur, which can lead to screenshot testing failures.

Choosing a custom font can be a deliberate way to gain visual stability and independence from system font changes. If you choose a custom font:

• Verify that the languages most important to your users are supported

• Expect fallback for unsupported characters

• Remember that, in the worst case, missing glyphs will be rendered using the Last Resort font

Unicode guarantees character identity, not font availability or visual appearance.

Let’s break down what this option claims to do versus what actually happens.

1. The “Text Encoding” option in Xcode 26.1 does not function

When you change the encoding in the File Inspector:

• Xcode prompts for confirmation

• Xcode pretends it will convert the file

• But the final result is: nothing changes

Xcode does not detect the file’s actual encoding, does not convert it, and does not re-encode it to the selected option. The feature appears to be a leftover UI component that no longer matches how the Swift toolchain works.

If you expect Xcode to convert a file to UTF-16, UTF-32, ISO-Latin-1, or anything else, it won’t.

2. Xcode source files must be UTF-8

Regardless of what the UI suggests, Xcode’s only accept UTF-8 encoded source files.

If a .swift file is saved as UTF-16 or any non-UTF-8 format, Xcode displays:

The compiler does not auto-convert the file, and Xcode does not fix the encoding.

You must manually resave the file as UTF-8 with for example Visual Studio Code

3. Swift itself rejects non-UTF-8 source files

Swift source code must be valid UTF-8.1 If a .swift file is saved using UTF-16 or UTF-32, the Swift compiler immediately stops with an error and will not attempt any recovery or transcoding.

4. Conclusion

The “Text Encoding” control in Xcode looks like a real feature, but in modern toolchains it is effectively non-functional. Swift requires UTF-8, Xcode enforces UTF-8. Everything else will produce errors — and Xcode’s encoding selector won’t help you. If you’re assuming that Xcode can convert or detect encoding for you, it won’t.

Want to learn more about encodings?

This is part of a larger story: Unicode, UTF-8 as Swift’s native storage format, and the differences between encodings like UTF-8, UTF-16, and UTF-32. I cover all of that in this post:

1. A short history of Unicode (with key dates)

Before Unicode, computing was a patchwork of character sets: ASCII in the US, ISO-8859 variants in Europe, Shift-JIS in Japan, KOI8-R in Russia, and many others. There was no universal representation of human scripts. Unicode was created with a clear goal: one universal character set for all present and ancient scripts, encoded in multiple efficient ways.

Major milestones:

• 1963 — ASCII created (7-bit). Good for English, useless for anything else.

• 1987 — Unicode project begins, aiming to create a unified character set for all languages.

• 1991 — Unicode 1.0 released (first official version).

• 1996 — UTF-8 invented by Ken Thompson and Rob Pike; becomes the dominant web encoding.

• 2000s — Widespread adoption across OSes, browsers, mobile devices.

• 2010s — Emoji explosion, including ZWJ (zero-width joiner) sequences and multi-person, multi-skin-tone combinations.

• Swift 5 (2019) — Swift adopts a stable UTF-8-based String storage.

2. What are UTF encodings?

Unicode defines code points: conceptual identifiers like U+0041 (“A”) or U+1F600 (“😀”). These are not bytes and not glyphs — just unique identifiers for characters.

Encodings define how to store these identifiers in bytes.

Example: Code point U+41 (character: “A“)

• UTF-8 → 0x41 (1 code unit, each of 1 byte, gives 1 bytes)

• UTF-16 → 0x0041 (1 code unit, each of 2 bytes, gives 2 bytes)

• UTF-32 → 0x00000041 (1 code unit of 4 bytes, gives 4 bytes)

Example: Code point U+1F600 (emoji: “😀”)

• UTF-8 → 0xF0 0x9F 0x98 0x80 (4 code units, each of 1 byte, gives 4 bytes)

• UTF-16 → 0xD83D 0xDE00 (2 code units, each of 2 bytes, gives 4 bytes)

• UTF-32 → 0x0001F600 (1 code unit, each of 4 bytes, gives 4 bytes)

Encodings exist because different trade-offs matter: compactness, speed, compatibility.

3. UTF-8 vs UTF-16 vs UTF-32

UTF-8

• number of code units per code point: 1 to 4

• code unit: 1 byte

• maximum size in bytes: 4

• maximum size in bits: 32

• ASCII and Latin text remain compact (ASCII stays 1 byte; Western European characters usually 2 bytes)

• Standard on Linux, macOS, iOS, web

UTF-16

• number of code units per code point: 1 to 2

• code unit: 2 byte

• maximum size in bytes: 4

• maximum size in bits: 32

• Basic Multilingual Plane (BMP - most of characters used in Western European and China/Japan/Korean CJK languages) fits in 2 bytes

• Supplementary characters (emoji, flags) use surrogate pairs

• Historically used by Windows, Java, .NET, NSString

UTF-32

• number of code units per code point: 1

• code unit: 4 byte

• fixed size in bytes: 4

• fixed size in bits: 32

• Unicode code point directly as a 32-bit integer.

• Simplest for indexing

• Wasteful in RAM and storage

• Rarely used outside internal processing

4. Swift’s String is UTF-8

Since Swift 5, String stores its contents in memory using UTF-8 encoding as the native representation. When you call String.count, Swift does not count bytes or Unicode scalars, it counts extended grapheme clusters, meaning the number of characters as a human perceives them.

Example:

let s = "🇵🇱" // it is composed emoji of two regional letters 🇵: U+1F1EA and 🇱: U+1F1FA  
print(s.utf8.count)  // 8 code units, 8 bytes
print(s.utf16.count) // 4 code units, 8 bytes
print(s.unicodeScalars.count) // 2
print(s.count)       // 1 character

5. NSString uses UTF-16

Whenever you use Foundation, Objective-C interoperability comes into play. NSString encodes text using UTF-16, and its API operate at the UTF-16 code-unit level. This leads to:

• .length returning number of UTF-16 code units, not characters

• Indexing based on those UTF-16 code units

Example:

let flag = "🇫🇷" as NSString 
// 2 code points: F(U+1F1EB) R(U+1F1F7)
// 4 UTF-16 code units: F - (D83C) (DDEB) R - (D83C) (DDF7)
// 8 Bytes in total
print(flag.length) // 4 UTF-16 code units

6. Swift is a wrapper around NSString when Foundation is imported

When you write:

import Foundation

String gains automatic bridging to NSString. This has several consequences:

• When using the String API, it becomes difficult to know whether autocomplete suggestions come from String or from NSString.

• It is possible to break a Swift String by using certain NSString APIs, because they operate on UTF-16 code units rather than Swift’s grapheme-cluster–safe model.

7. How NSString APIs can break a Swift String

Take a flag emoji. It’s composed of two Unicode Regional Indicator symbols.

Swift counts this as one extended grapheme cluster.

NSString.length, however, counts UTF-16 code units, so the same flag becomes four UTF-16 units.

NSString methods such as substring(with:) operate on UTF-16 code units, not grapheme clusters.

If you request a substring of length 1, you slice half of a surrogate pair of the first Unicode Regional Indicator symbol , producing an invalid string.

var s = "🇵🇱"
let ns = s as NSString
let broken = ns.substring(with: NSRange(location: 0, length: 1)) // half of the regional letter P
prints nothing

var s = “🇵🇱”
let ns = s as NSString
let ok = ns.substring(with: NSRange(location: 0, length: 2))
prints full regional letter 🇵

Most developers never encounter these issues, but when working with emoji, flags, or ZWJ sequences, careless use of NSString APIs can corrupt text because they operate on UTF-16 code units, not Swift’s grapheme-cluster-safe model.

8. Character limits in TextFields: stay aligned with your backend

User-input character limits only work if the application and backend count text the same way. If the backend API documentation does not specify what is being counted, extended grapheme clusters, Unicode code points, UTF-8 bytes, or UTF-16 code units, you must either determine the method empirically or ask the backend team directly.

8. Key facts

• Swift’s String stores data in UTF-8.

• NSString stores data in UTF-16.

• Importing Foundation makes Swift.String transparently bridge to NSString.

• Many NSString APIs operate on UTF-16 code units, not Unicode characters.

• NSString’s UTF-16 APIs can easily break complex Unicode sequences (flags, emojis, ZWJ).

• Use native Swift String methods whenever possible.

• If someone asks, “What encoding should I use for String or Data?” → Default answer: UTF-8.

Related post:

Useful links:

https://www.compart.com/

https://codepoints.net/

https://emojipedia.org

https://forums.swift.org/t/can-encoding-string-to-data-with-utf8-fail/22437/5

https://www.swift.org/blog/utf8-string/

https://en.wikipedia.org/wiki/UTF-8

https://en.wikipedia.org/wiki/UTF-16

https://en.wikipedia.org/wiki/Unicode

Unicode is a character-encoding standard maintained by the Unicode Consortium. It provides a universal foundation for processing, storing, and exchanging text in any language across modern software systems. Before Unicode existed, computers used a long chain of incompatible encodings: ASCII, then ISO-8859 variants, and earlier systems such as ITA2 (Baudot–Murray), ITA1, and even Morse code.

Short history of Unicode

Creation and founders

The Unicode Consortium was created in 1987 by engineers from Xerox and Apple, including Joe Becker, Lee Collins, and Mark Davis. Their goal was to design a single universal character set that could replace the dozens of regional encodings used around the world.

Why Unicode was needed

The growth of global software made national encodings impossible to maintain. Each region used its own system—ISO-8859-1 for Western Europe, Windows-1250 for Central Europe, Shift-JIS for Japan, GB for China, KOI8-R for Russia, and many others. These encodings were incompatible: the same byte could represent different letters depending on the system, which made text exchange unreliable. Developers often had to build multiple “locale-specific” versions of the same software. Unicode eliminated this fragmentation by defining one code point for every character—Latin, Cyrillic, Arabic, Chinese ideographs, Korean Hangul, Japanese kana, and eventually emojis. With one unified set, global software finally became practical.

Draft proposal of Unicode88 — August, 1988

Joseph D. Becker (Xerox) described the core problem clearly: people need to compute in their native languages, not just in English. ASCII was too small for that. Future systems needed a single multilingual standard covering Latin alphabets, major non-Latin scripts, and thousands of CJK ideographs. https://www.unicode.org/history/unicode88.pdf

ISO 10646 drafts — 1988–1990

ISO proposed a 31-bit design, not aligned with ASCII, and driven by national-body processes. The approach was bureaucratic and technically difficult to implement on 1980s hardware.

Unicode version 1 — October, 1991

Unicode initially rejected ISO’s proposal. The Consortium believed a 16-bit space was enough to encode all necessary characters, and keeping ASCII compatibility was essential. ISO disagreed, and Version 1.0 received no international approval.

Unicode Version 1.1 and ISO/IEC 10646-1:1993 — June, 1993

A compromise was reached: ISO adopted Unicode’s code charts, and Unicode adopted ISO’s plane structure. Both standards were synchronized to define the same characters at the same code points, with guaranteed ASCII compatibility.

Unicode Version 2 — July, 1996

Real-world requirements showed that 16 bits were not enough. China and Japan requested thousands of additional ideographs used in legal names and government documents. China later required all software sold in the country to support its complete repertoire. This pushed Unicode and ISO to expand beyond the original 65,536-code-point limit. Unicode 2.0 introduced surrogate pairs and expanded the design to a 21-bit code space. UCS-2 became UTF-16, enabling characters outside the Basic Multilingual Plane. This expansion was strongly influenced by Chinese national standards such as GB 18030.

Relationship between Unicode and ISO

Unicode and ISO now work jointly, but they began with different roles. ISO, as an international standards body, has political authority—governments depend on it for regulation and language policy. Unicode, founded by private-sector engineers, moved faster and focused on solving technical problems. Over time both organizations aligned: ISO provides global legitimacy, while Unicode defines the technical rules—encoding behavior, normalization, bidirectional text, and emoji specifications. Today they share a synchronized repertoire.

Why ASCII tables still matter?

Unicode kept ASCII as its foundation. The first 128 code points are identical to ASCII, so modern systems inherently support ASCII. Developers still consult ASCII tables because many low-level protocols—HTTP, email, URLs, shells, programming languages—continue to rely on ASCII byte values. Unicode didn’t replace ASCII; it extended it.

Are modern languages affected by Unicode?

Yes. Each language integrates Unicode differently based on its historical string model.

Swift has been strongly influenced by Unicode, especially since Swift 5 switched String to native UTF-8 storage. It treats Unicode correctly at a high level, supporting grapheme clusters, ZWJ emoji, flags, combining characters, and normalization. Indexing operates on extended grapheme clusters rather than UTF-16 units, although bridging to NSString reintroduces UTF-16 semantics when older APIs are involved. As a result, Swift is one of the most Unicode-correct mainstream languages.

Objective-C, through NSString and CFString, uses UTF-16 internally. Its length and indexing operations work at the level of UTF-16 code units rather than Unicode scalars or grapheme clusters. Modern Unicode constructs such as surrogate pairs, flags, ZWJ sequences, and emoji with modifiers break the assumptions behind its basic APIs, and it provides no native way to iterate grapheme clusters without relying on higher-level functions. Objective-C can represent the full Unicode repertoire, but it cannot interpret many modern features correctly at the raw API level.

Java is similarly affected because it also stores String as UTF-16, inheriting the same limitations as Objective-C. Its length() method counts 16-bit code units rather than characters, and any character above the Basic Multilingual Plane requires explicit surrogate handling. Later versions added improved Unicode support in regular expressions and utility classes, but the underlying string model remains firmly tied to the older UTF-16/UCS-2 style. In practice, Java supports Unicode but remains constrained by decisions made in the 1990s.

Kotlin, when running on the JVM, inherits Java’s UTF-16 representation. Its String.length property counts UTF-16 units, and surrogate pairs, emojis, and ZWJ sequences behave exactly as they do in Java. Even Kotlin Multiplatform aligns with UTF-16 for compatibility reasons. As a result, Kotlin’s Unicode behavior is limited by the JVM’s architecture and is not as correct or flexible as more modern approaches like Swift’s.

Which encoding do modern operating system kernels actually use for filenames, system calls, and process arguments? Do macOS, Linux, and Windows rely on UTF-8, UTF-16, or something else internally?

macOS follows UNIX conventions and uses UTF-8 for almost all system-level interfaces exposed to userland. The kernel itself treats filenames as byte sequences but the entire Apple ecosystem assumes UTF-8 as the canonical encoding. Linux kernels do not enforce Unicode at all: they store filenames and arguments as raw bytes and leave interpretation to userland, which today standardizes on UTF-8 through glibc and desktop environments. Windows is the outlier: the NT kernel and the Win32 API are built around UTF-16, and APIs that accept UTF-8 are thin compatibility layers added later. As a result, the behavior of text at the OS boundary still differs significantly across platforms.

Are UI frameworks on iOS and Android aware of modern Unicode features such as emojis, ZWJ sequences, flag pairs, and other complex grapheme clusters?

Yes, but the awareness comes from the text-rendering stack, not the UI frameworks themselves. On iOS, both UIKit and SwiftUI rely on Core Text, Core Graphics, and Apple’s system fonts. These layers fully support emojis, ZWJ sequences, flag pairs, skin-tone modifiers, and other grapheme clusters defined by modern Unicode. On Android, both the View system and Jetpack Compose depend on HarfBuzz, Minikin, and system fonts, which implement the same modern Unicode rules. The frameworks do not parse or interpret complex characters on their own; they delegate rendering, shaping, and cluster boundaries to lower-level text engines that track the evolving Unicode standard.

Why is there a difference between how Foundation handles Unicode features and how UI frameworks on iOS and Android display them? Shouldn’t both layers support the same modern Unicode behavior?

Foundation is an older API layer whose string behavior is shaped by historical constraints such as UTF-16 storage, legacy Objective-C design, and APIs that operate on code units rather than grapheme clusters. As a result, certain modern Unicode constructs—ZWJ sequences, complex emojis, multi-scalar clusters—cannot be interpreted correctly by its low-level methods. UI frameworks, on the other hand, do not parse Unicode themselves. They delegate all shaping, rendering, and grapheme-boundary decisions to system text engines like Core Text and HarfBuzz, which track the latest Unicode specifications. This separation means the rendering layer keeps up with modern Unicode evolution, while older string APIs in Foundation or the JVM may lag behind because they were designed around simpler character models.

What is the difference between UCS-2, UCS-4, UTF-8, UTF-16, and UTF-32?

UCS-2 was the original fixed-width encoding of Unicode 1.0 in 1991. It stored every character in exactly sixteen bits and reflected the early belief that 65,536 positions would be sufficient for all writing systems. Once the standard began to incorporate larger repertoires—especially after CJK countries highlighted the vast number of ideographs in real use—it became clear that UCS-2 could not scale beyond the Basic Multilingual Plane, and it became obsolete once Unicode adopted surrogate pairs.

UCS-4 emerged from the early ISO/IEC 10646 work between 1989 and 1993. ISO originally proposed a massive 31-bit code space. The final ISO 10646-1:1993 edition reduced this to a fixed 32-bit representation, still far larger than practical Unicode needs. After Unicode and ISO unified their repertoires, UCS-4 remained simply a 32-bit encoding form capable of representing the same 21-bit Unicode range, mainly used in specialized systems where simplicity mattered more than memory.

UTF-8 was invented in 1992 by Ken Thompson and Rob Pike and became part of Unicode 1.1 in 1993. It stores characters in a variable number of bytes from one to four and keeps ASCII as a one-byte identity mapping. UTF-8 quickly became the dominant encoding on Unix systems, the web, and almost all modern text protocols because of its compactness and compatibility with existing ASCII-based tools.

UTF-16 was introduced with Unicode 2.0 in 1996. It replaced UCS-2 by extending the original 16-bit model with surrogate pairs that represent characters above U+FFFF. This allowed Unicode to expand to a 21-bit code space without breaking software built around 16-bit code units. UTF-16 became the internal string representation for Windows, Java, .NET, and Apple’s NSString/CFString.

UTF-32 appeared in the late 1990s as a simplified version of UCS-4 restricted to the actual Unicode range. It stores every code point in exactly four bytes. Although easy to process, it is space-inefficient, so it is rarely used for storage and instead appears mainly in internal structures of compilers, font engines, or low-level text tools.

In summary, UCS-2 and UCS-4 were early fixed-width forms tied to the initial Unicode and ISO designs; UTF-8, UTF-16, and UTF-32 are modern encoding forms introduced throughout the 1990s to reconcile practicality, compatibility, and the need for a larger code space as Unicode matured.

Which Unicode encoding is the most widely used today, and why?

The most widely used Unicode encoding today is UTF-8, by a very large margin. It dominates the modern computing world because it preserves ASCII as a one-byte identity mapping, works smoothly with legacy Unix tools, and compresses Western languages extremely well. Almost all major platforms and technologies—Linux, macOS, iOS, Android, web browsers, servers, JSON, HTML, XML, email, and modern programming languages—standardize on UTF-8 for storage, communication, and file formats. Large-scale measurements confirm this dominance: well over 95% of all web pages are now encoded in UTF-8, and new protocols are designed around it by default.

UTF-16 and UTF-32 remain in use, but mainly as internal representations inside specific programming ecosystems. UTF-16 persists inside Java, Kotlin (JVM and Native), .NET, and Objective-C’s NSString, while UTF-32 appears occasionally in low-level text engines. However, when it comes to actual text exchange, files, services, and the internet as a whole, UTF-8 is by far the most popular encoding in the world today.

If UTF-8 is the most widely used encoding today, why did China push for Unicode to expand beyond the original 16-bit limit?

China’s push to expand Unicode beyond 16 bits had nothing to do with UTF-8’s popularity. It was about the size of the Unicode repertoire itself, not about how Unicode was encoded.

In the early 1990s, Unicode was based on a 16-bit model (UCS-2), which allowed only 65,536 code points. The designers believed this would cover all writing systems. Once China, Japan, and Korea examined the standard more closely, they discovered that the number of ideographs needed for real-world use—especially for names, publications, government documents, and variant forms—far exceeded that limit. Many of these characters are rarely used in ordinary text, but they are legally and administratively essential. If a standard cannot encode the characters in a citizen’s name, a place name, or an official document, it is not viable for national use.

China therefore required Unicode to support all ideographs in national standards, including less common ones, and eventually introduced GB 18030, which made full coverage mandatory for software sold in China. Because the BMP was too small for this expanded repertoire, Unicode had to move from the fixed 16-bit UCS-2 model to the 21-bit model introduced in Unicode 2.0. That transition brought surrogate pairs and UTF-16, enabling more than one million possible code points.

This expansion was a repertoire problem, not an encoding problem. UTF-8 could already encode far more than 65,536 characters from the start, so its popularity is unrelated. Unicode needed more than 16 bits because the world’s scripts genuinely required more characters—not because of how those characters were encoded.

When converting raw data into a string in Swift, Objective-C, Java, or Kotlin on Android, which text encoding should be used?

Across all these languages and platforms, the correct encoding to use when decoding external data is UTF-8. Modern systems—Apple platforms, Android, web services, JSON, XML, SQLite, network protocols, and almost every contemporary file format—standardize on UTF-8 for text interchange.

Swift internally stores strings as UTF-8, and Objective-C uses UTF-16 internally, but both expect incoming data to be UTF-8 and convert it automatically after decoding. Android’s Java and Kotlin also store strings as UTF-16, yet the entire Android ecosystem assumes UTF-8 for external data, from HTTP clients to JSON libraries and resource files.

You should only choose another encoding when dealing with legacy data created in old regional code pages (Windows-125x, ISO-8859-x, Shift-JIS, GBK, etc.). For modern applications and APIs, UTF-8 is the universal and correct choicefor decoding raw bytes into text.

To print “Hello World!“ in macOS Terminal using the default zsh shell, just type echo

echo “Hello World!“

but hey, you can do it as well with printf

printf “Hello World!“

and even with print

print “Hello World!”

What it the difference between these three commands?

Each command appeared at the different moment and for different reasons.

1. echo — the oldest (early 1970s)

Origin: UNIX Version 1 (AT&T Bell Labs)
Creators: Ken Thompson & Dennis Ritchie (UNIX authors)
First appearance: 1971

echo was one of the original commands in early Unix.
Its only job: write text to standard output.
That’s why it’s primitive, inconsistent, and full of historical quirks — it predates portability standards, POSIX, and even ANSI C.

It existed long before shells became programmable languages.

2. printf — much later (1980s → 1992 standardization)

Origin: C programming language’s printf (Brian Kernighan & Dennis Ritchie) around 1972–1974
Shell version introduced: AT&T System V shell (/usr/bin/printf), mid-1980s
POSIX standardization: IEEE POSIX.2 (1992)

Shell printf did not exist in early Unix.

It was added when shell scripting became more serious and the community needed a precise, predictable formatter — something echo could never be.

POSIX essentially forced every shell to ship a compatible printf implementation.

3. print — invented by David Korn for the Korn shell (mid-1980s)

Origin: KornShell (ksh)
Creator: David Korn, AT&T Bell Labs
First appearance: ksh88, released 1988

print was created because:

• echo was unreliable

• printf didn’t yet exist as a shell command

• Korn wanted a consistent, user-friendly output builtin

Later, zsh (1990, Paul Falstad) adopted and extended print because it fit their philosophy of improving shell ergonomics.

When should I use print versus printf in the shell, and in which situations is it appropriate for an iOS developer to rely on echo?

1. print — use it only in zsh (interactive use)

print is a zsh/ksh-specific convenience command.

Use print when:

• you are typing commands interactively in zsh

• you want cleaner, predictable behavior than echo

• you want features like print -r (raw), print -f (formatting), or automatic newline

Do NOT use print in scripts unless the script is explicitly for zsh (#!/bin/zsh).

If the script must run everywhere → never touch print.

2. printf — use it in scripts (portable, predictable)

printf is the correct command when you want:

• reliability

• cross-platform compatibility

• consistent escaping

• no random behavior with -e, -n, backslashes, or options

• portable shell scripts (#!/bin/sh, #!/bin/bash, #!/bin/zsh, #!/bin/dash, etc.)

printf is guaranteed by POSIX.
It behaves the same everywhere.
It never surprises you.

Typical use:

printf “Hello World\n”

3. echo — use for quick and dirty output, interactive only

echo is fine for:

• quick interactive use

• debugging while typing commands

• humans reading output where precision doesn’t matter

But it is NOT reliable in scripts, because:

• some echo interpret \n

• some don’t

• some treat -e specially

• some don’t

• some print -n literally

• some treat it as option

• behavior differs between BSD, GNU, POSIX shells, and builtins

Example of “fun” portability issues:

echo “\n”     # may print one newline, two, or the characters “\”, “n”
echo -e “\n”  # may work, may not
echo -n hi    # may print “hi” or “-n hi”

If you care about correctness → don’t use echo.

Should an iOS developer use echo?

Yes for interactive debugging, no for scripting.

As an iOS developer you are using the shell mostly for:

• printing messages in simple scripts

• build scripts

• CI scripts (Fastlane, GitHub Actions, Bitrise, Jenkins)

• Xcode Run Script phases

In these contexts, you should prefer printf, because:

• output must be predictable

• logs must be stable

• CI machines may run different shells

• macOS (BSD), Linux (GNU), and Alpine (Busybox) all differ

echo is fine when:

echo “building...”
echo “done”

But for anything involving escaping, newlines, or control characters → use printf.

Your simple rule (practical):

Interactive zsh (Terminal typing)

• Use print or echo

• They’re fast, convenient, and safe enough

Scripts (shell, CI, build steps, automation)

• Always use printf

• Never use print

• Avoid echo unless it’s trivial text

You ask your passenger: ‘Hey Max, take the bottle, open it, and put it in my right hand.’

That’s procedural programming.

But when you simply say: ‘I’m thirsty,’ you expect the passenger to know what to do and handle it in the best way to satisfy your need.

That’s declarative programming.

UIKit and SwiftUI are perfect examples of these two styles.

The Quick Actions panel, introduced in Xcode 15, is Apple’s new feature inspired by tools like Spotlight and Visual Studio Code’s Command Palette.
It centralizes access to Xcode menu items, Automator workflows, and Shortcuts app actions — all from one place, without ever leaving the editor.

Think of it as Xcode’s built-in command line, where you can search, discover, and execute actions instantly. It’s not just about running menu items — it’s a productivity hub that reveals what Xcode can do, and lets you trigger it all with a few keystrokes.

Quick Actions can also serve as a finder for keyboard shortcuts of menu items.

You can access it from the menu Editor → Quick Actions or with ⌃⇧⌘A (Control–Shift–Command–A). Once you open it, search for an action by typing it’s name or just single letter to find the action or just to get ideas what is accessible. Xcode 26 contains more actions than Xcode 15 and 16, so it’s worth checking what’s new in each version.

Wait — I saw my macOS Shortcuts App actions there. Why?

Because Quick Actions are tightly integrated with the Shortcuts app.

You can create a shortcut in the Shortcuts App and have it appear directly in Xcode’s Quick Actions panel.

Does it work with Automator too?

Yes.

Can it run my own shell scripts or commands like xcodegen generate?

Yes — just wrap your script with an Automator workflow or Shortcuts App custom action.

What are your favourite Quick Actions commands?

Here are some of my favorite built-in Xcode’s Quick Actions:

• Discard changes in the current file

• Discard all changes in the project

• Clean build folder

• Clear consol

• Find and replace in the current file

• Commit

And my custom ones:

• Execute xcodegen generate command

• Switch between my project’s white-labels environments

📬 Coming Next (for subscribers):

“How to Build a Shortcut App, Custom Shortcut for Xcode”

Learn how to turn your everyday build scripts into one-click actions inside Xcode.
Subscribe now to get the tutorial as soon as it’s published.