SwiftUI provides three main controllers you can use to capture input text:

• TextField, which is generally used to capture a single line of text, as input ( name, e-mail address etc.). It can be used to capture large amounts of text, but it will turn the input text into one single line (it would drop all newline characters, list markers, text decorations, links etc.).

• SecureField, which is generally used to capture confidential and private information. This field takes your unmodified input, but displayed a redacted version, by replacing characters with circles or stars. You should use SecureField to capture passwords, Card Verification Values etc.

• TextEditor, used to capture paragraphs of data. You would typically use this control to capture notes in a notes application. With iOS26, the TextEditor control received a lot of extra functionality, allowing it to work with AttributedStrings. Unless you need to support older OS versions, you can use this control for a full Rich Text Editor, in native SwiftUI code.

• UIKit/AppKit views wrapped in a UIViewRepresentable, such as UITextView and NSTextView, used to capture rich text data. Prior to iOS26 and MacOS26, you would use these controls to create rich text editors in SwiftUI.

All SwiftUI text input controls require a binding to a state property. The controls themselves provide the mechanisms your end-users need, in order to interact with that state property. As a result of this implementation detail, these controls provide you with the ability to easily validate and\or process the input, on the fly (for example, using the .onChange modifier). Additionally, the text controls provide enough customization options, to make them fit into most designs.

For context, login screens or user registration forms both use text input controls, grouped and styled appropriately, to take user information, such as user name and password, and pass it to some other component or service. Another very common use case is the payment details form, where users provide credit card information.

When connected to a debugger, both in the simulator and on a connected device, all text input controls can display errors and they can block the interface when they load. In general, these issues are safe to ignore, since they will not occur when the application runs in standard mode (when the debugger is not attached to the process). If you encounter general slowness with text input controls, before investing time to debug, try running the application by directly loading it from the device interface, instead of pushing it from Xcode (so that the debugger does not connect).

To showcase some of the customization possibilities, as well as the way they interact with the rest of the interface you would build, some views in this section are going to be displayed in a ZStack, on top of an animated background view. We are going to explore this in far more detail later but, for now, it’s useful to know that, in SwiftUI, you can animate a vast majority of the views’ properties, including their scale and color. SwiftUI provides several tools you can use to create animations, such as the withAnimation function, the .animation view modifier or the .animation Binding method. Apple also hosted a few presentations regarding SwiftUI’s Animation APIs, such as Explore SwiftUI animations and Wind your way through advanced animations in SwiftUI. Apple’s SwiftUI team also maintains a brief SwiftUI animation tutorial.

The animated background view provided below creates a set of randomly colored circles, scales them up and down automatically and moves them on the screen. To animate each circle’s color and position, we tie them to a scale @Stateproperty. Using the onAppear modifier, we force SwiftUI to transition between the initial value of the scale property, assigned on initialization, and the new value, provided in the modifier’s closure. To keep the animation running indefinitely, we can simply use the repeatForever method. The blur effect is used to create the illusion of a thick material between the screen and the underlying animated circles and it was very commonly used to give the impression of translucent glass or plastic, before iOS26 and Apple’s Liquid Glass.

To be useful, the animated background view needs to create and moves circles in an area that is visible. You can use compiler directives to condition the area in which the colored circles can move, based on the Operating System. There are other, more precise mechanisms (such as the GeometryReader container), but this will suffice for our current requirements.

struct AnimatedBackground: View {
    @State private var scale : CGFloat = 1
    @State private var nbOfCircles: Int = 25
    let bubbleColors:[Color] = [.red,.mint,.purple,.pink,.purple,.blue,.cyan,.orange,.red,.teal]

    var body: some View {
        
        ZStack {
            ForEach (0...nbOfCircles, id:\.self) { index in
                Circle ()
                    .foregroundColor(scale < 2 ? bubbleColors[index < bubbleColors.count - 1 ? index : bubbleColors.count - 1] : bubbleColors[index < bubbleColors.count - 1 ? index % bubbleColors.count : index % (bubbleColors.count-2)])
                    .animation (Animation.easeInOut(duration: 1)
                        .repeatForever(autoreverses: true)
                        .speed (.random(in: 0.05...0.5))
                        .delay(.random (in: 0...1)), value: scale
                    )
                    .scaleEffect(self.scale * .random(in: 0.5...3))
                    .frame(width: .random(in: 50...100),
                           height: CGFloat.random (in:50...100),
                           alignment: .center)
#if os(iOS)
                    .position(CGPoint(x: scale < 2 ? .random(in: 50...200) + index : .random(in: 100...300) - index,
                                      y: scale < 2 ? .random(in:50...980) + index : .random(in: 100...800) - index))
#else
                    .position(CGPoint(x: scale < 2 ? .random(in: 10...2000) + index : .random(in: 100...1300) - index,
                                      y: scale < 2 ? .random(in:10...600) + index : .random(in: 100...800) - index))
#endif
                    .animation (Animation.easeInOut(duration: 1)
                        .repeatForever(autoreverses: true)
                        .speed (.random(in: 0.05...0.5))
                        .delay(.random (in: 0...1)), value: scale
                    )
                    .blendMode(.destinationOver)
            }
        }
        .onAppear {
            self.scale = 2
        }
        .background(
            Rectangle()
                .foregroundColor(.gray))
        .blur(radius: 60)
        .ignoresSafeArea()


    }
}

The TextInputControls view below acts as the main test view, used to showcase the text input controls and their customization options. The input controls are going to be added in the VStack.

struct TextInputControls: View {
    @State private var input = ""
    var body: some View {
        ZStack{
            AnimatedBackground()
            VStack{
                Text("The **raw** input value is: \(input)")
            }
        }
    }
}

The TextField Control

The TextField control is used to capture a single, unformatted line of text. It is an expansive view, unlike the fixed-sizeText primitive. The image below showcases some common use cases for the TextField control (or its UIKit equivalent, UITextField), in Apple’s first party applications.

The snippet below exemplifies a TextField control in its most basic form. It takes a localized string as a label and a binding to a State property as the text parameter. It is, therefore, common to surround the TextField control with some padding, to create some space between the edges of the screen and the control.

TextField("Card Title", text:$input).padding()

The screenshots below represent the same view, but rendered on various platforms. Notice how, on iOS and on visionOS, the TextField controls do not provide, in their default styling, any background. There are multiple mechanisms you can use to add a background, depending on the OS version your application targets, and we are going to explore some of them shortly. It’s also useful to note that the animated background may make sense on some devices and in some contexts, but not on others.

Depending on your particular use case, you may want to change the visual style of the control. For example, you may want to make it more visible on compact platforms, like the iPhone and Vision Pro. With iOS26, on the iPhone, you can use the glassEffect modifier, to quickly apply LiquidGlass. If you feel LiquidGlass doesn’t match your application, you could use the textFieldStyle modifier, or you could simply add a background modifier, directly. The snippet below showcases a few examples, both with and without Liquid Glass and using various initializers.

TextField("Card Title", text:$input).padding().glassEffect().padding()
TextField("Card Title", text:$input).padding().textFieldStyle(.roundedBorder)
TextField("Card Title", text:$input).padding()
    .background{
Capsule(style: .circular).foregroundStyle(.ultraThinMaterial)
    }
    .tint(.red)
    .foregroundColor(.red)
    .padding()
TextField(text: $input){
    Text("Card Title").foregroundStyle(.red)
}.padding()
    .background{
Capsule(style: .circular).foregroundStyle(.ultraThinMaterial)
    }.padding()
TextField("Card Title", text: $input, prompt: Text("Card Title").foregroundStyle(.white), axis: .vertical).padding().glassEffect(.regular.tint(.mint)).padding()

The image below showcases the resulting interface, both on iOS and on macOS.

Note that Vision Pro does not currently support Liquid Glass (at least not with VisionOS 26). If your multi platform application uses Liquid Glass, you should ensure there is a style to fall back onto. Otherwise, the application will not build for the VisionOS target.

Customizing the Virtual Keyboard, the Quick Type Bar the Keyboard Toolbar

A distinct characteristic of text input controls is that, on compact platforms such as iOS, iPadOS, visionOS, watchOS and tvOS, when the control is in focus (active, selected) you also get a pop-up or a modal keyboard. Using the .keyboardType modifier, you can change the default keyboard to a style that better matches the type of information the text field is meant to capture. The snippet and image below showcase an example you would use when the input you request from your end-users is a phone number. There are other styles, which suit other types of input better (.numbersAndPunctuation, .emailAddress etc).

You could use the default keyboard, but the dedicated style provides a much better experience and many Apple users expect this type of care from their apps.

Since macOS does not support the keyboardType modifier, we can simply condition the addition of the modifier with a compiler directive.

When working on Multiplatform applications, there will often be cases where specific interface elements will need their own implementation. Sometimes, it’s sufficient to keep a single struct and condition modifiers based on the OS, as shown in this example. In more complex cases, though, you will be a lot better off by simply creating individual structs (in the same file, or in dedicated files) and use compiler conditional directives to choose which view to render.

import SwiftUI

struct TextInputControls: View {
    @State private var input = ""
    var body: some View {
        ZStack{
            AnimatedBackground()
            VStack{
                TextField("Phone Number", text: $input, prompt: Text("Phone Number").foregroundStyle(.black))
                    .padding(20)

#if (os(iOS) || os(macOS))
                .glassEffect()
                .padding(20)
#endif

#if os(visionOS)
                    .background{
                        Capsule(style: .circular)
                            .stroke(lineWidth: 5)
                            .foregroundStyle(.ultraThinMaterial)
                    }
                    .padding(50)
#endif // os(visionOS)

#if !os(macOS)
                    .keyboardType(.phonePad)
#endif
                
                Text("The **raw** input value is: \(input)").padding()
            }
        }
    }
}

#Preview {
    TextInputControls()
}

You can also further improve the experience you provide to your end-users, by specifying the type of data associated to the text field. For example, by using the .textContentType modifier, you can control the options your end-users receive in the quick type bar (the autocomplete area above the keyboard). You can also modify the way the Submit (return) key looks, on the keyboard, using the .submitLabel modifier. Apple provides a set of SubmitLabels you can use, but you cannot easily add your own. Using the .toolbar modifier, you can also add custom buttons right above the keyboard. That is where you would add custom buttons, or other types of custom views. In the image below, you can see some of the common use cases of each modifier (although they are not necessarily combined this way in practice).

Adding custom behavior on updates

As an input control, the main purpose of the TextField is to effect a change in your application’s state. In the previous example, it updates the input state property. In some interfaces, you may want to verify the input your end-user provides (for example, your input property should contain no more than 10 characters, similar to a normal phone number), or you may want to reformat or modify the input ( for example, reformat the text as a phone number, as seen in the Contacts application). There are multiple mechanisms you can use, but the easiest ones to use are the .onChange (updated with iOS17) and .onSubmitmodifiers.

Limiting the length of the input to 10 characters

When used strictly for formatting purposes, the formatting logic can be maintained inside the view modifier. For example, the snippet below simply ensures that your end user would not be able to insert an 11th character. Note that the key presses are still registered. In the simulator, you can cause this closure to stop executing, if you use a physical keyboard and spam keys.

TextField("Name", text: $input, prompt: Text("Name").foregroundStyle(.black))
    .padding(20)
    .submitLabel(.send)
    .onChange(of: input){ new, old in
        guard new.count <= 10 else { return }
        input = new
         }
    }

As a reminder, the guard statement is typically used as an early return mechanism. Its purpose is to return from the current scope, if a set of conditions are not met. The onChange closure above can also be written as :

onChange(of: input) { new, old in

if new.count <= 10 { input = new }

}

In general, with very few exceptions, logic that controls or affects the input (limiting the number of characters, adding or removing characters etc.) should be placed in onChange closures and not in onSubmit closures. Otherwise, you may hide the effects of the closure away from your end user. This is especially true if you interface jumps to another text field on submit, because your end user may miss the changes your application made to their input. For example, your end user may type 11 or more characters, but their input would get truncated after the value is submitted.

Using TextField validation to enable and disable Buttons (e-mail validation)

Another common requirement in interfaces is to condition the interactivity of a button (whether it’s active or not) to the validity of the TextField’s input. For example, if a TextField takes in an e-mail address, you may want to allow the end user to save the input only if the value contains the @ sign and, at least one character after it, a . symbol. With version 5.7, Swift introduced dedicated types forregular expressions, or regexes. They also added a framework you can use to build regexes in a more human readable way. In prior Swift versions, the String struct’s range() instance method. Regardless of the approach you choose, the mechanism remains the same. You would build a regular expression using one of the rules in the table below and you would then try to match the input in the TextField to the regex.

In the example below, the isEmailValid computed property returns true if input matches the regex, or false if it does not. The commented regexes are equivalent to the uncommented one. Then, we use the .disabled modifier to determine if the button is active. Since isEmailValid returns true for a valid e-mail, we use the negation operator ! to reverse the value (.disabled is true when isEmailValid is false).

Alternatively, the value of isEmailValid could have been re-evaluated in a .onChange modifier closure.

import SwiftUI
import RegexBuilder

struct Regexes: View {
    @State var input:String = ""
    var isEmailValid: Bool {
        // ^ = starts with, $ = ends with, + after ] or } = one or more, * fter ] or } = zero or more
//        input.range(of: "^[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}$", options: .regularExpression) != nil
//        input.firstMatch(of: /^[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}$/) != nil
        input.firstMatch(of: Regex {/^/
            OneOrMore {
                CharacterClass(
                    .anyOf("._%+-"),
                    ("A"..."Z"),
                    ("0"..."9"),
                    ("a"..."z")
                )}
            "@"
            OneOrMore {CharacterClass(
                .anyOf(".-"),("A"..."Z"),("a"..."z"),("0"..."9"))}
            /./
            Repeat(2...) {CharacterClass(("A"..."Z"),("a"..."z"))}
            /$/
        }) != nil
        
    var body: some View {
        
        TextField("e-mail address", text: $input)
        Button("Submit"){
            
        }.disabled(!isEmailValid)
        
        
    }
}

Although RegexBuilder seems more human readable at first, especially when spaced properly on new lines, I would strongly recommend you become familiar with the C-style Unicode version. RegexBuilder is unique to Apple, whereas Unicode regexes are almost universal. In other words, Unicode regexes are transferrable. Additionally, Unicode regexes are a lot more succinct.

Changing input using Formatters

There may be cases where, for aesthetic or clarity reasons, you need to modify your end-users’ input for display. For example, if the input represents a phone number, you may want to surround the first three digits with rounded braces, to represent the Area Code, then surround the next three digits with a space or - symbol to represent the central office code. This would be work your application should do, not the user. In other words, your end user would type 1231231234, but the phone number would be displayed as (123) - 123 - 1234. There are other similar examples, such as credit card numbers, dates, numbers with various decimal places and so on.

Apple provides several tools you can use to rearrange data to be displayed in text form. One of the older such tools is the Formatter class, with its many subclasses, included in the Foundation package with iOS 2.0. Since it’s a legacy component, it has both an Objective-C and a Swift version, and you can use either of the two. With iOS 15, Apple introduced a redesigned, Swift-native replacement for the Formatter class, in the form of the FormatStyle, ParseableFormatStyle and ParseStrategy protocols.

Both the old and the new formatting tools function on similar principles. They provide a way for you to describe how to transform text input to a different concrete type and vice versa. They can also be passed as arguments to the TextField control initializer. You can pass a Formatter class as an argument to TextField(\_ titleKey:LocalizedStringKey,value: Binding<V>,formatter: Formatter) , or a FormatStyle as an argument to TextField(\_ titleKey: LocalizedStringKey, value: Binding<F.FormatInput>,format: Format).

Although tutorials often demonstrate the functionality by converting between string formats, their purpose is more complex. Formatters, together with FormatStyles, represent a mechanism to convert (or format) any type of data (ranging from currency, dates, textual sentences or complex objects) into a localized string for presentation, and to parse user-entered text back into those concrete types. Their main advantage is that, under the hood, they interact with other APIs on Apple devices. As Apple introduces new capabilities in localization and formatting capabilities, they would be available to your application, with no additional effort on your part.

To exemplify both approaches, in a SwiftUI TextField control, we are going to assume our application runs on a device set to the US region and that the phone numbers we are going to store are typed by a user in the US, in the domestic format (123) 123 - 1234. We are not going to handle the + symbol.

If formatting the phone numbers is a core function of your application, it would be useful to choose the formatting rules based on the device’s settings. This way, you make sure the formatting is aligned to your end user’s customs. To do so, you would create a more complex data model and you could, for example, base your formatting decision on the value of Locale.current.region. For example:

if Locale.current.region == .unitedStates { // add formatting logic }

Correct and complete localization in general is a complex topic and is out of scope for now, even when it comes to the format of a phone number.

The “legacy” approach relies on subclassing (inheriting) the Formatter class and on overriding a set of methods that get called when SwiftUI performs specific actions (when loading the view or when the bound value changes). You would essentially define how the data should be showed (by overriding the string method) and how the underlying data should be saved (by overriding the getObjectValue method).

A common approach consists of the use of a mask. First, you would choose a placeholder (or control) symbol, to represent a phone digit (for example, X), then lay out the structure of the formatted result. For a phone number, you could use (###) ### - #### as the mask. You can then write a simple method that parses the mask and replaces the placeholder with the appropriate values from your end-user’s input. The snippet below represents the starting point.

class PhoneFormatter: Formatter {
    let mask = "(###) ### - ####"
    

    override func string(for obj: Any?) -> String? {
    // Converts the raw digits to the formatted version (for display)
    }
    

    override func getObjectValue(_ obj: AutoreleasingUnsafeMutablePointer<AnyObject?>?, for string: String, errorDescription error: AutoreleasingUnsafeMutablePointer<NSString?>?) -> Bool {
    // Converts the formatted string to raw digits (for the Binding)
    }
    
    func format(numbers: String) -> String {
    // Altough you could put the formatting code inside the string function, it is customary to put this in a dedicated method.    
    }
}

Since it’s straight-forward, we can start with the getObjectValue method. As shown in the comment, its purpose is to take whatever input the end-user provides and convert to raw digits. The string parameter will represent the input that needs to be converted (the text displayed in the TextField), and the obj parameter is a reference to the destination object (in this case, it will be the TextField’s Binding). This is required because the end user can paste an already formatter phone number, so we need to be able to convert it to the underlying storage format (in this case, digits). The snippet below represents the updated method. Note that the commented version uses methods supported in older Swift versions, which did not support regexes. If you need to support iOS15 or earlier, you would use the string.components method.

class PhoneFormatter: Formatter {
    //...
    

    override func getObjectValue(_ obj: AutoreleasingUnsafeMutablePointer<AnyObject?>?, for string: String, errorDescription error: AutoreleasingUnsafeMutablePointer<NSString?>?) -> Bool {
    //    obj?.pointee = string.components(separatedBy: CharacterSet.decimalDigits.inverted).joined() as AnyObject
        obj?.pointee = string.replacingOccurrences(of: "[^0-9]", with: "", options: .regularExpression) as AnyObject
        return true
    }
    //...
}

The string method’s purpose is the opposite of getObjectValue. It’s meant to take the raw value (digits stored in the TextField binding) and convert them to the formatted value, matching the mask we had defined previously. First, we need to get a String from the obj parameter. To do so, we could cast it using a type cast operator (as? if the cast may fail or as! if the cast will surely succeed). This would change the type of the obj parameter, from the existential type Any to a concrete type, without making changes to the underlying data. It generally faster and, if you use the optional cast operator as?, it is safe in Swift, but may not be so in other languages. Since the TextField’s Binding is a String, and we are going to use the formatter to work with that binding, this mechanism would suffice. Alternatively, we could convert obj to a String, for example using a String initializer (String(data:, encoding:)). This would actually perform a conversion, making it generally safer to use if there’s no way to predict the type of the value passed to the Formatter.

Then, we can use a separate method ( in this example, we can call it format) to do the actual processing. In the end, this method needs to return the converted value (the formatted phone number).

class PhoneFormatter: Formatter {
    //...
    
    override func string(for obj: Any?) -> String? {
        guard let string = obj as? String else { return nil }
//        guard let string = String(data: obj as! Data, encoding: .utf8)  else { return nil }

        return format(numbers: string)
    }
    //...
}

Due to the way the String struct is implemented, you can iterate through the characters of String variables just as you would a Swift Array. Because of this detail, the formatting mask problem is, essentially, a problem of operations over arrays:

• The mask String is, in essence, the array ['(', 'X', 'X', 'X', ')', ' ', 'X', 'X', 'X', ' ', '-', ' ', 'X', 'X', 'X', 'X']

• A full phone number entered in the input field is represented by the array ['1', '2', '3', '1', '2', '3', '1', '2', '3', '4']

To apply the mask, you would iterate through its elements and, when a control character is encountered, you would replace it with the appropriate element in the phone number array. Note that, because the mask contains additional characters compared to the , the indexes of the corresponding elements in each array will not match. Therefore, you would need to iterate through the mask String. The snippet below represents the format function.

class PhoneFormatter: Formatter {
    //...
    func format(numbers: String) -> String {
       var result = ""
        var index = numbers.startIndex
        for char in mask {
            if index >= numbers.endIndex { break }
            if char == "#" {
                result.append(numbers[index])
                index = numbers.index(after: index)
            } else {
                result.append(char)
            }
        }
        return result
    }
    //...
}

The index(after: ) method is used for variety. You could just as easily use index += 1. The out of bounds check is performed in the conditional if index >= numbers.endIndex { break }.

You can then use the PhoneNumber formatter in a regular TextField SwiftUI control, as shown in the snippet below.

import SwiftUI

struct SampleWithFormatter: View {
    @State var input: String = ""
    var body: some View {
        TextField("Phone Number", value: $input, formatter: PhoneFormatter()).padding().glassEffect().padding(30)
        Text(input).padding().glassEffect()
    }
}

#Preview {
    SampleWithFormatter()
}

If you test this out, you will quickly discover that the text is not reformatted as you type. This is because SwiftUI does not call the formatter’s string method until the view goes out of focus. This means your end-user can input a lot more than 10 characters and they have no visual feedback until they either submit the new value or they select another control. In the section Changing input through an intermediate binding, we are going to explore a potential workaround for this.

As you find new ways to accomplish specific tasks, you may find it valuable to properly test the implementation’s limitations, if you have the time and energy. Even though I am trying to outline the main limitations of each approach, you may encounter limitations in use cases I may not have considered. This is why, in software development, experience is still more valuable than pure syntactic knowledge.

More examples of format functions

To expand on the idea of the formatting functions presented in the previous section, for more complex types of input, you could also use more control characters. For example, you could use a control character to indicate an uppercase letter (C), and another one to indicate lowercase letters (c). In that case, a switch statement would likely be more feasible. The snippet below represents an example. It would take the input abcdef and turn it to abc-DEF.

func format(input: String) -> String {
    var result = ""
    var index = input.startIndex
    final mask = "ccc-CCC"
    for char in mask {
        if index >= input.endIndex { break }
        switch char {
        case "c":
            result.append(input[index].lowercased())
            index = input.index(after: index)
        case "C":
            result.append(input[index].uppercased())
            index = input.index(after: index)
        default:
            result.append(char)
        }
    }
    return result
}

A less flexible (but perhaps more concise) option would be to use regexes. Instead of using a mask, you would capture groups of digits, then use them to construct the number. The snippet below represents one such implementation. Notice how, as a fallback, if the regex fails, you should return the unmodified input.

class PhoneFormatter: Formatter {
    //...
    func format(numbers: String) -> String {
        var result = ""
        guard let matched = numbers.firstMatch(of: /(\d{0,3})(\d{0,3})(\d{0,4})$/) else {
            return numbers
        }
        print(matched)
        return "(\(matched.1)) \(matched.2) - \(matched.3)"
    }
    //...
}

You would often use regexes in the pattern showed above when you need to operate with specific portions of a string. For example, you may want to capture the domain of an e-mail and capitalize it. In that case, the function would become similar to the snippet below.

func format(input: String) -> String {
    var result = ""
    guard let matched = input.firstMatch(of: /^.*@(\w+).*$/) else {
        return input
    }
    return "\(matched.1.uppercased())"
}
//print(format(input: "josh.tea@prudent.leap.com"))
//PRUDENT
//print(format(input: "josh.tea@prudentleap.com"))
//PRUDENTLEAP

As seen above, regular expressions are powerful. However, they have also been the source of numerous service outages throughout the years. You should always validate regexes carefully, and you should make them as restrictive as you possibly can.

Changing input using FormatStyle, ParseStrategy and ParseableFormatStyle

Apple’s more modern formatting APIs rely on a set of protocols, instead of the Formatter class, to accomplish the same functionality in a more modern and concise way. A SwiftUI TextField using this approach will have the same limitations as one using a Formatter, as the view lifecycle does not change.

• FormatStyle, which ensures that conforming types take an input of an underlying type and convert it to a formatted output. Conforming types implement a format(\_ value: InputType) -> OutputType method, which is the equivalent of the string method in the Formatter class.

• ParseStrategy, which ensures that conforming types take a formatted value and convert to an underlying input data type . Conforming types implement a parse(_ value: OutputType) throws -> InputType method, which is the equivalent of the getObjectValue method in the Formatter class.

• ParseableFormatStyle , which acts as a wrapper over FormatStyle and ParseStrategy. Conforming types implement a parseStrategy read-only computed property that instantiates a ParseStrategy, as well as a formatmethod.

• To make it easier to use, you can extend the FormatStyle base protocol with a static accessor. This is known as static member lookup over generics, and it has been introduced in Swift 5.5.

The snippet below provides the same formatting capabilities as the previous Formatter-based example, but in a more modern way. For modern code bases, it should be the preferred implementation.

struct PhoneNumberStyle: ParseableFormatStyle {
    var parseStrategy: PhoneParseStrategy {
        PhoneParseStrategy()
    }
    
    func format(_ value: String) -> String {
        let mask = "(###) ### - ####"
        var result = ""
        var index = value.startIndex
        for char in mask {
            if index >= value.endIndex { break }
            if char == "#" {
                result.append(value[index])
                index = value.index(after: index)
            } else {
                result.append(char)
            }
        }
        return result
   }   
}


struct PhoneParseStrategy: ParseStrategy {
    func parse(_ value: String) throws -> String {
        return value.replacingOccurrences(of: "[^0-9]", with: "", options: .regularExpression)
    }    
}

extension FormatStyle where Self == PhoneNumberStyle {
    static var phoneNumber: PhoneNumberStyle { PhoneNumberStyle() }
}


struct SampleWithFormatter: View {
    @State var input: String = ""
    var body: some View {
        TextField("Phone Number", value: $input, format: .phoneNumber).padding().glassEffect().padding(30)
        TextField("Sample", text:$input).padding().glassEffect().padding(30)
        Text(input).padding().glassEffect()
    }
}

Changing input through an intermediate binding

There are other ways you can obtain a similar effect to formatters. As an example, you could also use a computed property wrapped in a binding to handle the translation logic. This would, essentially, act as a proxy between the TextField and the State Property it should control. The mechanisms remain, essentially, the same:

• A mechanism to take the input and change it to an underlying, cleaned up format. In the case of a computed property, we could use the set method

• A mechanism to provide the formatted value, when SwiftUI needs to display the updated view. In a computed property, this is the function of the get method.

The snippet below showcases this type of implementation. Notice how the phoneFilterBinding computed property itself is a read-only property and it implicitly returns a Binding via the Binding(get:() -> Value , set: (Value) -> Void)initializer.

struct SampleWithFormatter: View {
    @State var input: String = ""
    private var phoneFilterBinding : Binding<String> {
        Binding(
            get: {
                let mask = "(###) ### - ####"
                var result = ""
                var index = input.startIndex
                for char in mask {
                    if index >= input.endIndex { break }
                    if char == "#" {
                        result.append(input[index])
                        index = input.index(after: index) 
                    } else {
                        result.append(char)
                    }
                }
                return result},
            set: { newValue in
                input = newValue.replacingOccurrences(of: "[^0-9]", with: "", options: .regularExpression)
            }
        )
    }
    var body: some View {
        TextField("Phone Number", text: phoneFilterBinding, prompt: Text("(###) ### - ####").foregroundStyle(.background))
        .padding().glassEffect().padding(30)
    }
}

This approach has the same limitations as all of the previous ones, but it adds an additional bug. The mask is applied to the computed property, rather than directly to the state property. This means the state property will temporarily hold one or two additional characters, until you either submit the value or another view comes into focus.

However, this can be fixed. The TextField view automatically updates when its text binding changes. Since the TextFieldis bound to a computed property instead of the actual state property, any updates done to the input state property will force the TextField view to update.

As a reminder, when a view displays a computed property, any update to the value it’s based on will invalidate the view, forcing a view update. When the view updates, it re-evaluates the computed property.

We can leverage this behavior, by using the .onChange(of:) modifier to react to changes to the input state property’s value. Any assignment to input would invalidate the view, which will cause the computed property to be re-evaluated. The most obvious operation to perform there is to limit the number of characters input can take, via a String.prefix method, as shown in the snippet below.

TextField("Phone Number", text: phoneFilterBinding, prompt: Text("(###) ### - ####").foregroundStyle(.background))
    .onChange(of: input){ new, old in // this could have been "new _ in" instead 
        input = String(new.prefix(10))
    }
.padding().glassEffect().padding(30)

To clarify, the reason this works here and it does not work if you bind the TextField directly to the State property is that the value of input is only changed on value submission. The value submission operations occurs implicitly when the view goes out of focus, or when the Submit operation is explicitly called (for example, by touching the submit button on the phone’s keyboard, or the return key on a Mac keyboard).

The SecureField Control and its limitations

Sometimes, your application needs to accept an end-user’s password, which is highly sensitive. It’s common practice to replace the characters your users type with * or with other symbols. Although you could apply one of the techniques we explored previously, Apple already provides a control you can use. In addition to masking characters and providing a quick link to Passwords as auto-fill options, the SecureField control also completely blanks out its content when you take screenshots or screen recordings and it blocks the ability to copy its contents , among other security measures. The snippet below and the adjoining screen shots exemplify a typical use case. Notice how the SecureField redacted characters are visible in normal use (left) but are hidden when a phone screen grab is taken(right).

struct SecureFieldSample: View {
    @State private var password = ""
    var body: some View {
        Text("Login Form")
        SecureField("Password", text: $password)
            .textContentType(.newPassword)
            .padding()
            .glassEffect()
            .padding()
    }
}

The control does have its own limitations, though:

• At the time of writing, there is no built-in mechanism to show the password.

• You cannot customize the redaction characters, from the default *

• If the control loses focus, it no longer supports in-place edits. In other words, any attempted changes will overwrite the existing text entirely.

If needed, you could implement a variant of the show/hide function using a state variable to signify whether the password should be visible. If true, you would display a TextField and, if false, you would display a SecureField. The snippet below represents such an example.

struct SecureField_ShowPassword: View {
    @State var showPassword = false
    @State var password = ""
    var body: some View {
        HStack{
            if showPassword == true {
                TextField("Password",text: $password)
                    .padding()
            } else {
                SecureField("Password",text: $password)
                    .padding()
            }
            
            Button(action: {
                showPassword.toggle()
            }, label: {
                Image(systemName: showPassword == false ? "eye" : "eye.slash")
                    .foregroundStyle(showPassword == true ? .gray : .accentColor )
            })
        }
        .padding(.horizontal)
        .glassEffect()
        .padding(.horizontal,40)
    }
}

However, this implementation brings its own limitations:

• Pressing the show/hide password button will cause the SecureField to re-render. As mentioned previously, the control loses in-place edit capabilities when it loses focus

• The TextField control is not blocked for broadcast. Its content will be picked up by screenshots and screen recordings

The images below showcase the difference.

If the first issue is more of a nuisance, the second is a security concern. We can mitigate both by using UIKIt controls wrapped in a SwiftUI view, and we are going to explore this next. However, just because a solution is technically possible or even feasible, doesn’t mean it should be implemented. If a control misses the type of functionality you have in mind, you should always consider why.

In the case of UIKit’s UITextField, the same control is used both for normal text and for passwords. The security features are all linked to the instance property isSecureTextEntry. If you were to implement the same show/hide functionality, you would set that property to false, in order to show the password in plain text.

In the case of SwiftUI, Apple specifically chose to create two distinct controls. You would use SecureField for things you need to protect and TextField for anything else.

From a security standpoint, if the user can see the password, so can any potential bystanders.This type of threat is commonly known as shoulder surfing. Most likely, Apple specifically did not implement a show/hide password functionality for SecureField controls for this reason. With this constraint, in-place edits can cause potential issues with password mismatches, when you can’t visually confirm the edits.

A counter-argument to the shoulder surfing scenario is that the input mechanism itself (a keyboard on the screen) would pose a similar threat. This, however, is a false equivalence. A password displayed in plain text, even a moment, is immediately and passively readable. Conversely, deciphering what someone is typing requires active, sustained effort. Having said that, this potential threat is likely one of the reasons Apple introduced Keychain and Password Manager integration for secure fields. By eliminating the need to physically type in the password you remove the entire threat. Accessing secure features on the device using biometric authentication serves the same purpose. Not having to type or see the password ultimately makes it harder to leak information, even if the phone screen is accidentally captured by a CCTV camera. Ultimately, security is not a binary property, but rather a spectrum, and these features collectively push the experience towards the more secure end of that range, without sacrificing usability.

1. Your application performs some setup activities, either in a serial, synchronous manner - or asynchronously, concurrently

2. Once the setup process is complete, the final instruction in the application’s entry point creates an infinite loop, with some very clear (and mandatory) exit/return/continue conditions. To see this in action, simply replace the content of the cli-example main.swift file with the snippet below:

print("Enter some text and I will repeat it, or enter 'q' to quit\n")

while true {
        print("what should I repeat?: ", terminator: "")
        
        guard let input = readLine()?.trimmingCharacters(in: .whitespacesAndNewlines) else {
            continue
        }
        
        // Check if user wants to quit
        if input.lowercased() == "q" {
            print("Goodbye!")
            break
        }
        
        // Skip empty input
        if input.isEmpty {
            print("Please enter some text or 'q' to quit\n")
            continue
        }
        
        print("Input was: \(input)")

}
print("Enter some text and I will repeat it, or enter 'q' to quit\n")

while true {
        print("what should I repeat?: ", terminator: "")
        
        guard let input = readLine()?.trimmingCharacters(in: .whitespacesAndNewlines) else {
            continue
        }
        
        // Check if user wants to quit
        if input.lowercased() == "q" {
            print("Goodbye!")
            break
        }
        
        // Skip empty input
        if input.isEmpty {
            print("Please enter some text or 'q' to quit\n")
            continue
        }
        
        print("Input was: \(input)")

}

If you would run the new executable, you would essentially have a process with an event loop ( in an overly simplified manner, this is mimics very well how more complex applications work).

$\> swift run cli-example
Building for debugging...
[7/7] Applying cli-example
Build of product 'cli-example' complete! (0.81s)
Enter some text and I will repeat it, or enter 'q' to quit

what should I repeat?: Something
Input was: Something
what should I repeat?: Something else
Input was: Something else
what should I repeat?: 
Please enter some text or 'q' to quit

what should I repeat?: q
Goodbye!

A Swift Program - from source code to executable file

When developing applications for Apple’s ecosystem, you would spend a good portion of your time writing Swift source code files. Sometimes, you may need to use Objective-C, C or C++, but even then, you would mostly write source code. While writing Swift source code, you use components (libraries) included in the Swift versions of Apple’s numerous frameworks - one of which being SwiftUI - and you ensure your code respects the requirements of Apple’s frameworks, into which your code would need to integrate.

Since Swift is a compiled language, when your program’s code is ready, you need to compile it. So far, we have seen how a simple Swift program is created by writing text into files - and then how Swift’s toolset transforms that text into another set of files, such as object files, dynamic library files and, importantly, the executable file. We have explored the main mechanisms you can use to describe an application, using concepts (symbols and abstractions) you find in the Swift programming language. We have then looked at the build process and how it translates those source files into binary object files, then bundles everything together into one, Mach-O executable file you can use to execute the program.

Between the source code files and the final executable files, the LLVM toolset (Compiler, Assembler, Linker) performs various other, intermediary tasks:

• Perform Lexical and Syntactic Analysis (this is where compilation due to syntax errors would fail);

• Perform Semantic Analysis (for type checking);

• Generate intermediary LLVM IR files (LLVM Intermediate Representation files, which are target-independent files written in the LLVM Assembly Language)

• Generate platform-specific assembly language files

• Generate the Binary Object files, from the platform specific assembly language files

• Bundle everything into an executable file, usable by the Operating System’s kernel ( in this particular case, theMach-O executable file for the XNU kernel )

More complex projects (such as an application with a GUI) would also include many other components, which are used while the application is running (from icons to pre-rendered sprites to interface builder files)

The diagram below represents a simplified overview of the numerous transformations your Swift Code will go through.

Once your program is bundled into a Mach-O executable file, it can be started by the Operating System.

Although it’s easy to pick up and become productive, mastering Swift is a process that takes time and effort. For this reason, it's usually a good idea to become familiar with the official documentation. You can take a Swift Language Tour or further consult the Language's Reference and, eventually, read the API Design Guidelines. These are all bundled under Swift’s Documentation section.

You can conceivably be very successful in your work without consulting these resources periodically, but it's useful to know they exist. The Swift project team also manages a Blog, where you can stay up to date with newer developments, including some that didn't yet make it to WWDC talks.

If you would like to understand how Swift evolves as a language - and to understand how the Language team decides which features to add and which not to add, you can check the Swift Evolution GitHub repository. You can also see what’s in store for upcoming versions of Swift by checking the Swift Evolution Page directly, as well. Both sources contain highly technical information, but you have the opportunity to see why Swift works the way it does. There are many gems hidden in the answers to proposal, not just the proposals themselves, so they are all great resources if you want to understand Swift’s language design philosophy straight from the language team.

Out of the box, Swift supports C/Objective-C interoperability (as Apple had/has a lot of Objective-C legacy code) and, since Swift 5.9, opt-in C++ interoperability.

Similar to many other programming languages, you can use Swift to create anything from simple cli tools (like the one in this section), to locally executed desktop applications, all the way to complex web servers.

Throughout this post, we are going to create a very simple cli tool which takes a list of numbers separated by the “,” (comma) symbol, and then returns those numbers in ascending order. The tools itself is not particularly useful, but it’s going to help us explore Swift a bit more closely, from the ground up.

Problem Decomposition

In order to capture the arguments of the cli application, we can use Apple’s swift-argument-parser module.

The main steps required to obtain the output are going to be:

• In a dedicated struct entity, we are going to save the argument provided to the cli on call time, as a String variable named input. For brevity, we are not going to perform any input validation (which is a very bad practice in real world applications. You should always validate user input, even for offline applications. Validating user input is required not just for security reasons - but also to ensure that your application does not end up in an undefined state);

• Using the split function associated to the String types, we are going to divide the input string into individual elements, based on the separator “,”;

• Using the configMap function associated to Arrays , we are going to convert every element obtained from the split function into an Int

• Finally, using the sorted function associated to Arrays, we can store a copy of the sorted array, in a temporary variable, which can then be printed to the console.

Before you start solving a problem, it’s usually a good idea to break it down to smaller, more manageable pieces. This helps you (and, if you work in a team, your colleagues) set up a common understanding. It’s not always possible to design an application (especially a complex one) unless you already built it once. Similarly, it’s not always possible to tackle complex problems, unless you break them down into smaller pieces first. As you solve more problems, it becomes a lot easier to find the smaller chunks - and this steps becomes less important, if you work alone.

Creating a new Package

In Swift, code is organized in Modules. Unlike other languages (eg Java, C# or Go), you do not explicitly define modulenames at the beginning of a Swift file, nor do you explicitly define the namespace.

One or more modules, together with a single manifest file, make up a Swift Package. Within the Package’s manifest file, you can define the Package Dependencies (functionality that is defined in other, external packages) and one or more Targetsfor your application to be compiled for. Finally, each target builds a Product, which is either a library (to be used in other projects) or an executable (and actual file).

To standardize the structure of Swift Project, but also to support the creation of various tools (such as build and CI/CD tools), all Swift projects are maintained as a Swift Bundle.

To start a new project, you can use a Swift utility to bootstrap a package for you. The utility would initialize your package, by creating the main directories and files for you. For example, in a dedicated directory called cli-example, you can run the command below (in the terminal):

$> swift package init --name cli-example --type executable

This command would return the following output, in the terminal’s standard output stream:

Creating executable package: cli-example

Creating Package.swift

Creating Sources/

Creating Sources/main.swift

The tool created a file for package management, named Package.swift, as well as a directory for source files, named Sources. Within the Sources directory, you can find a swift file named main.swift. By convention, the main.swift file is the only file that can contain top-level instruction.

Alternatively, you could designate a class as the top-level entry point for the program by using the @main attribute, in a file that is not called main.swift. The two options are mutually exclusive: you cannot declare a @main class in a file named main.swift.

A tree representation of the directory structure would be:

.
└── Package.swift
└── Sources
    └── main.swift

Adding Dependencies

Using the Package.swift file, you can also add external dependencies to your project. For example, Apple already provides a package you can use to capture and use command-line arguments, named swift-argument-parser. We can add this package as a dependency to cli-example, by modifying the Swift Package Manifest:

// swift-tools-version: 6.0
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "cli-example",
    dependencies: [
        .package(url: "https://github.com/apple/swift-argument-parser", from: "1.0.2"),
    ],
    targets: [
        // Targets are the basic building blocks of a package, defining a module or a test suite.
        // Targets can depend on other targets in this package and products from dependencies.
        .executableTarget(
            name: "cli-example",
            dependencies: [
               .product(name: "ArgumentParser", package: "swift-argument-parser"),
        	]
       )
    ]
)

Throughout this example, we used Swift’s Package Manager, but you don’t necessarily have to. You can also use external package managers and their repositories, such as CocoaPods - which is industry standard for Apple development.

For reference, this is what the CocoaPods manifest (known as specification or spec) would look like:

// Example
platform :ios, '8.0'
use_frameworks!

target 'MyApp' do
  pod 'AFNetworking', '~> 2.6'
  pod 'ORStackView', '~> 3.0'
  pod 'SwiftyJSON', '~> 2.3'
end

Alternatively, you can simply use Xcode to manage dependencies, as shown in Apple’s Xcode documentation

Implementing the CLI Tool

Before proceeding with the actual implementation, it would be useful to be aware of a few rules and conventions (enforced by Swift’s tooling, but not always well documented in literature):

1. In a Swift Package, source code files must end with the .swift extension.

2. Swift source code needs to be placed in a directory named Sources or Src (or variants of these directory names, such as Source or src), or in one of its subdirectories (eg Sources/MainApplication or Sources/Services).

3. Within the Swift Package Description Manifest, you can specify custom source directories for individual targets, using the path key in the executableTarget dictionary.

4. In Swift, directories act as helpers for you, the developer. They don’t really hold much meaning (unlike other languages where directories are effectively namespaces or packages), unless you attribute meaning in the Swift Package Description manifest, as mentioned previously. On compilation, all Swift files are loaded in a flat structure. For this reason, you cannot have two files with the same name in a single Swift project (unless they are part of different modules).

5. The entry point of an application is, by convention, the main.swift file. There are two main exceptions to this rule:

   • The package contains only one source file, in which case the name doesn’t matter

   • The package does not contain a main.swift file and, instead, it has a class or structure marked with the @main attribute. In this case, the entry point is the main function belonging to the marked type(functions associated to the type and not an instance of the type are identified by the static keyword). This is the more common pattern, if you work on developing regular applications in Xcode. The snippet below is an example of such an implementation.

@main
struct TestStruct {
    var sample = ""
    //This is the Instance Function
    func run() {
        print("The sample is: \(sample)")
    }
    //This is the entry point. It is a static function with no input and no returns (() -> Void, but Void can be omitted)
    static func main() {
        let s = TestStruct(sample: "A String provided within the static main function")
        s.run()
    }
}

With these conventions and rules in mind, we can now work on our simple Command Line Tool implementation. Although the exact structure of your project will likely vary, it’s a good idea to separate the main sections of your application into their areas of responsibility. For example, you would use an App directory to keep the application’s entry point, while the rest of the business logic would be maintained in separate directories (such as Services, Networking, Shaders etc.). Since the directory structure is more important to you than it is to the Swift tools, these conventions are mainly meant to help you organize your code.

To start, add two new directories inside the Sources directory - and name them App and Services, respectively (though you could use any other names, instead). Within the Services directory, add a new swift file, with the name CLIService.swift. Then, move the original main.swift file, from Sources to Sources/App. Your project structure should now resemble the tree below:

.
└── Package.swift
└── Sources
    └── App
        └── main.swift
    └── Services
        └── CLIService.swift

In the App/main.swift file, we would typically define instructions that are relevant to the application’s life cycle. For example, this is where you would execute the function that captures input from the user. For now, a set of print instructions would suffice. Replace the content of the main.swift file with the following print instructions:

print("Welcome to our simple CLI!")
print("We have finished the execution, I will close now")

Within the Services/CLIService.swift file, use the import keyword to add the ArgumentParser module to this file. This allows the compiler to recognize and use the functions, protocols, and types provided by that module within the file where it's imported. Then, define a struct to act as a wrapper for our CLI functionality. It should be called CLIService and it should conform to the ParsableCommand protocol (we are going to look closely into protocols later in the book. For now, know that the protocol is part of the ArgumentParser module).

import ArgumentParser

struct CLIService: ParsableCommand {
}

First, we would need to store the user input. Structs can contain properties (the equivalent of fields in other languages) and functions. Therefore, you can declare a public variable input, of type String, as the first property of the CLIService struct. To mark the variable as the storage of the user’s input, we can use the @Option property wrapper (more on this later)

import ArgumentParser

struct CLIService: ParsableCommand {

  @Option(help: "Specify the input")
  public var input: String

}

The ParsableCommand protocol includes a main function, which can be executed by your application’s entry point. It captures the arguments passed in the command line and, using them, it executes the instance function named run. We can, therefore, write our sorting logic within the run function - or in a separate function, which is executed (called) by the runfunction.

There are benefits and drawbacks to both approaches. If you keep the sorting functionality inside the run function, the code is easier to read, but slightly harder to extend. Conversely, if you use a dedicated function for sorting, you could add more functionality (such as removing an element), at the potential cost of resource consumption (function calls require resources) and a slight decrease in readability (how easy a human can understand the code and its purpose), especially if the functionality extends over a larger number of files.

Here is an example where the sorting logic is performed directly in the run function:

import ArgumentParser

struct CLIService: ParsableCommand {

  @Option(help: "Specify the input")
  public var input: String

  //This function is called by CLIExample.main()
  public func run() throws {
    let result = input
      .split(separator:",")
      .compactMap{
          Int($0)
      }
      .sorted()
    print("The array of sorted numbers is: \(result)")
  }
}

Alternatively, here is the same logic, but with the sorting performed by another, dedicated function, named sortInput:

import ArgumentParser

struct CLIService: ParsableCommand {

  @Option(help: "Specify the input")
  public var input: String
  //This function is called by run()
  private func sortInput() -> [Int]{
    input
      .split(separator:",")
      .compactMap{
          Int($0)
      }
      .sorted()
  }
  //This function is called by CLIExample.main()
  public func run() throws {
    print("The array of sorted numbers is: \(sortInput())")
  }
}

You may keep either of the two examples. Since we separated the project in two files, each with their own purpose, you can easily replace or modify each of the two pieces, independently - and revert your decisions easily. You can also add more functionality in either of the two, without affecting the other. Just as importantly, you can test the two components individually.

Going forward, you can keep either of the two examples used for CLIService. They will both work just as well, because the struct is named CLIService in both examples, and the function is named run in both examples.

Update the main.swift file and, between the two print instructions, call the main() function of the CLIService struct.

print("Welcome to a simple CLI tool!")
CLIService.main()
print("Finished the execution, closing the process...")

When the cli-example project will be executed, the main.swift file will act as the entry point - and execute the staticfunction main() associated to the CLIService struct.

You can test out the example using the swift run command, as shown below.

$> swift run cli-example --input 3,1,5,7,6,4,90,78,45,32,15

Running that command would result in the following output (together with some other messages related to building and debugging, recorded by the run tool itself):

Fetching https://github.com/apple/swift-argument-parser from cache
Fetched https://github.com/apple/swift-argument-parser from cache (1.29s)
Computing version for https://github.com/apple/swift-argument-parser
Computed https://github.com/apple/swift-argument-parser at 1.5.0 (1.82s)
Computed https://github.com/apple/swift-argument-parser at 1.5.0 (0.00s)
Creating working copy for https://github.com/apple/swift-argument-parser
Working copy of https://github.com/apple/swift-argument-parser resolved at 1.5.0
Building for debugging...
56/56 Applying cli-example
Build of product 'cli-example' complete! (6.24s)
Welcome to a simple CLI tool!
The array of sorted numbers is: [1, 3, 4, 5, 6, 7, 15, 32, 45, 78, 90]
Finished the execution, closing the process...

If you would try running the same command again, you would still get the build output - indicating that the project builds again. However, it would take a lot less.

$> swift run cli-example --input 3,1,5,7,6,4,90,78,45,32,15
[1/1] Planning build
Building for debugging...
[1/1] Write swift-version--58304C5D6DBC2206.txt
Build of product 'cli-example' complete! (0.20s)
Welcome to our simple CLI!
The array of sorted numbers is: [1, 3, 4, 5, 6, 7, 15, 32, 45, 78, 90]
We have finished the execution, I will close now

This is because, when we executed the initial swift run command, Swift’s toolset also built the project. When this occurs, the toolset creates a hidden directory (with a “.” in front of its name). In order to see hidden directories in the terminal, you would need to use ls -a. For example:

$> ls -la

A truncated representation of the directory tree would look something like this:

.
└── .build
    └── artifacts
    └── checkouts
        └── swift-argument-parser
            └── ....
     └── repositories
        └── swift-argument-parser-54a11a8d
            └── ...
    └── arm64-apple-macosx
        └── debug
            └── ...
    └── debug  # // This is where the build clie binary resides. 
└── Package.resolved
└── Package.swift
└── Sources
    └── app
        └── main.swift
    └── services
        └── CLIService.swift

From the project’s directory, you can also run the built binary, as well. This time, it runs directly, as it’s the final, built executable.

$> ./.build/debug/cli-example --input 3,1,5,7,6,4,90,78,45,32,15
Welcome to our simple CLI!
The array of sorted numbers is: [1, 3, 4, 5, 6, 7, 15, 32, 45, 78, 90]
We have finished the execution, I will close now

You can also see the file type, to confirm that it is, indeed, a Mach-O executable:

$> file ./.build/debug/cli-example
./.build/debug/cli-example: Mach-O 64-bit executable arm64

Notice that the build is, at this point, a debug build. As shown in the Swift Build System Guide, though, you can also build a release version, directly:

$> swift build -c release            
[1/1] Planning build
Building for production...
[10/10] Linking cli-example
Build complete! (11.58s)

Once you run this command, your released binary can be found in .build/release. You can also run the release binary.

$> .build/release/cli-example --input 3,1,5,7,6,4,90,9,8,2,3,3,5,6
Welcome to our simple CLI!
The array of sorted numbers is: [1, 2, 3, 3, 3, 4, 5, 5, 6, 6, 7, 8, 9, 90]
We have finished the execution, I will close now

If you check the contents of the release directory, though, you would find many other items. All of these files were generated when the Swift toolset (including the compiler) analyzed the source code files - and built the entire project.

.
└── ArgumentParser-tool.build
    └── ...
└── ArgumentParserToolInfo-tool.build
    └── ...
└── cli-example.dSYM --> debug symbols
    └── ...
└── cli-example.product
    └── Objects.LinkFileList --> text reference to other binary object files
└── cli_example.build
    └── CLIService.swift.o --> binary object files
    └── cli_example.d --> text reference to make dependency files
    └── main.swift.o
    └── sources 
    └── output-file-map.json
    └── master.swiftdeps
└── swift-version--58304C5D6DBC2206.txt
└── ...
└── ...
└── ArgumentParserToolInfo.build
    └── ToolInfo.swift.o
    └── ArgumentParserToolInfo.d
    └── ArgumentParserToolInfo-Swift.h
    └── sources
    └── output-file-map.json
    └── module.modulemap
    └── master.swiftdeps
└── ArgumentParser.build
    └── ...
└── ...
└── Modules 
    ...
    └── cli_example.abi.json
    └── ArgumentParserToolInfo.abi.json

Surfacing the touch event, from Kernel Space to User Space

For security reasons, direct access to hardware, ranging from memory to peripherals, is only allowed in the kernel space. To access hardware, a process has to either be running in the kernel space (as it’s the case with the drivers as kernel extensions) or have a kernel delegate, which does have access to hardware ( such as driver extensions in DriverKit).

Since IOKit drivers and their WorkLoops all execute in the kernel, in various contexts and with various restrictions, the events they work with are still within the kernel’s boundary. For those events to be visible to end-user facing applications, they need to be surfaced to the user space. In other words, they need to cross the kernel boundaries. Surfacing these events is a complex, carefully coordinated process.

After the IOKit driver consumes the processed touch information from the Ping-Pong buffers, using the structures described in the post Exploring Apple’s drivers ecosystem, it persists the message in a dedicated shared memory ring buffer, implemented as an IOSharedDataQueue. When data is added to this buffer, registered clients (particularly the backboardddaemon) receive a Mach notification, which in turn wakes the daemon’s event dispatcher thread. Backboardd then dequeuesevents from the shared memory buffer and further processes them.

The mach notification model, with gated access to shared memory, ensures the lowest possible latency for high-throughput scenarios, as it’s the case with device-generated events. It works well because it’s carefully synchronized by Apple, using low-level synchronization mechanisms, such as IOCommandGates. And yet, as seen in CVE-2017-7162, even with Apple’s careful design, mistakes can happen.

In higher level programming, communicating through shared memory is often discouraged. Even though it’s less common, it is still useful to understand this model, especially when optimizing for performance.

Next, backboardd forwards the event to multiple subsystems. First, it assumes System Gestures (such as minimizing an application, lowering the status bar etc.) are possible, so it sends the event to the SpringBoard process, which manages the Home Screen and System UI (also via Mach Ports). If it needs to, SpringBoard assumes control and handles the system events.

Secondly, since it keeps a record of all application frames, together with the state of these applications (whether they are running, whether they are in the foreground or background etc.), backboardd also locates the application it should send the event to, by determining if the touch coordinates fall within the frame of an active application in the foreground. Once the hit tests find the frame that contains the touch point, backboardd identifies the process that owns the frame and forwards the touch event information to its associated listening Mach Port.

Handling the Touch Events

When any application starts up, it is encapsulated within a process running on the operating system. This process spans an initial thread which, on Apple systems, is named Thread 1, and it’s known as the Main Thread. It executes the instructions found in the executable top level code (the entry point of the application, or the main function, in most languages) and, since a process ends when its main thread completes, the main thread usually runs in a loop. More accurately, it starts a CFRunLoop, executes its setup instructions, then blocks (sleeps), waiting for various events. Unlike the example in “From a CLI task to a run (main) loop”, though, SwiftUI (or most other UI frameworks designed for efficiency) does not trigger timer events (or any events) unless it needs to. Instead, when an application starts up, it executes an initial setup process, to load the data it requires to display the first scene (a lot more on this in the SwiftUI sections) and then, if the application is well written, it blocks quickly, waiting for new events.

As shown in the previous section, when backboardd identifies the application that should receive the event, it sends the touch information, serialized into a mach message, to its dedicated mach port. This, in turn, marks the application thread listening on the port as runnable and, in a mechanism similar to the one explored previously, the application’s event handling thread drains the port. Each event is dequeued in sequence and it is then processed by the UI Framework.

First, it performs hit tests, to determine which UI Responder should receive the touch event ( similar to how backboarddidentified the application to route the event towards). Then, the touch information (packaged as a UITouch Event in UIKit or a Gesture in SwiftUI) triggers the execution of a few functions. The exact implementation is not particularly relevant at this point, but the general idea can serve as inspiration for your own implementations.

Of the numerous events a control can react to, there are two types of touch events that are particularly relevant for a buttoncontrol. First, the touchDown event, which indicates that the control has been touched, triggers the execution of an activation animation (usually, this highlights the button). Additionally, the touchUpInside or touchUpOutside events, which indicate that the button has been released, trigger the execution of a deactivation animation and, at the same time, signal the framework to execute the instructions found in the closure of the SwiftUI Button control view.

You can easily check this separation (and how SwiftUI handles these events) by touching the “Please press the button” button in the example application at the start of this post and holding it pressed. You should notice how the button lights up (activates), but you would also notice how the message underneath the button remains “The button has been pressed 0 times ”. This indicates that the Button’s action closure did not execute yet. Once you release the button, the control’s deactivation animation plays and the text updates to reflect the change.

In our example, since the end-user just touched then released the button, the first event sent by backboardd is translated to a touchDown event. Since the touch occurred within the frame of a button, the UI framework runs the code associated with the control’s activation animation. Typically, this animation extends over several frames, depending on the way the animation is configured. To prepare the first frame in the animation, the Application (more specifically the code that handles the UI, such as SwiftUI or UIKit) updates the characteristics of the Button control. For example, it changes a the color to a different, lighter shade, to act as a highlight, while also scaling the shape down and perhaps adding some changes to the button’s shadows and outlines. After all changes required for the first frame of the animation are processed, they result in an update to the underlying CALayer construct (within the CoreAnimation framework). Whenever a view needs to change its aspect, the underlying CoreAnimation CALayer structure triggers a setNeedsLayout layout call. The function invalidates the view (more on this in the SwiftUI sections), which results in an update in the Application’s CALayer Tree. The diagram below outlines this process.

The next event sent by backboardd is translated to a touchUpInside event, which marks the beginning of the button deactivation animation, as well as the execution of the action closure’s instructions (in this case, counter += 1).

Reacting to UI Update Events

When the visual content of an application needs to be updated, the UI framework schedules rendering updates as part of a mechanism commonly referred to as the Render Loop. This process is typically synchronized with the device’s display (or, if more than one display is connected, the fastest display) using a CADisplayLink object.

Internally, the CADisplayLink is tied to the system’s V-SYNC (Vertical Synchronization) events, which occur during the display’s vertical blanking interval ( VBLANK). VBLANK is the brief moment where the screen is refreshed and not actively drawing. On a standard 60Hz display, this interval occurs roughly translates to 16.67 milliseconds (the system needs to render 60 frames per second, or one frame every 16 milliseconds). For a 120Hz Pro Motion display, the V-Sync interval is even shorter, around 8.33 milliseconds.

To prevent screen tearing and other potential issues, the application is required to receive and process the event, then update the underlying CALayer Tree

(Apple calls this the event phase), all within a V-Sync Interval. Once this synchronous, blocking process is complete, the application moves to the commit phase, where it sends the new CALayer Tree information to another process, known as the Render Server. Since it’s an inter-process communication flow, it’s also implemented through Mach Ports.

On iOS, the Render Server functionality is implemented in the backboardd process, which is why it’s marked as the Render Server in the Instruments application.

On every V-Sync interval, the backboardd process needs to complete its own tasks, split in two phases: the rendering preparation phase, followed by the render execution phase. In the rendering preparation phase, which runs on the CPU portion of the SoC, backboardd collects the information submitted by all applications in the foreground, then composes a final image data structure, in the form of GPU Render instructions (for the Metal framework). Then, the SoC portion of the render loop forwards the frame information to the GPU, which in turn draws the final image and saves it into a frame buffer.

By default, the render loop uses two frame buffers, in a setup known as double buffering. One buffer contains the image that is visible on the display (the front buffer), while the other contains the image that is being rendered (the back buffer). On every screen refresh, the two buffers are swapped. Whatever image is presented in the front buffer at the time of the Display’s VBLANK would be displayed on the screen. This is why the GPU never renders directly in the front buffer ( if the image is not complete, the display would simply display the incomplete image).

As a safety mechanism, if the image in the back buffer is not completely drawn, the system falls back to a triple buffering mechanism, where it uses two back buffers, instead of the one. It loads the image currently present in the front buffer into the a second back buffer (which is usually called the spare buffer), while also continuing to render the image in the initial back buffer. When the V-Sync event is triggered, the system swaps the front buffer with the spare buffer.

At the next V-Sync event, the front buffer should be swapped with the back buffer, and the spare buffer is usually destroyed. Any deviation from this process would cause a hitch, or an issue with the animations. Apple describes this process in great detail in their Tech Talks such as Explore UI animation hitches and the render loop. The linked talk contains detailed explanations and troubleshooting details that would become valuable to you later, so I am purposefully not diving into more details here. Instead, I strongly recommend you would watch that talk. Together with the information presented in this section, you should have a detailed understanding of how events are captured, processed and rendered on your device.

For each type of device they designed, Apple selected the most fitting operating system and the best suited input and output mechanisms, to deliver unique experiences, appropriate for the host device’s form factor. On iPhone, you use iOS and you interact with applications through touch gestures. On a Mac, with macOS, you typically use a combination of keyboard and mouse/trackpad, as well as various other peripherals (decks, drawing tablets etc.). On an Apple Watch, you use a combination between the Digital Crown and touch gestures to interact with applications running on WatchOS. On a newer Vision Pro, with visionOS, you use a combination of eye tracking and hand gestures and, at times, various buttons. And finally, on an Apple TV, you use a remote control with a built in trackpad, to interact with TvOS. On top of those, you have a wide variety of additional accessories you can connect to your device, as well as voice commands.

Regardless of the OS and the exact input technology, the main mechanisms involved are generally the same:

• An input device, which captures input and translates it into a binary data packet. Then, the binary data is transmitted to the device’s SoC, through dedicated lines on a dedicated bus;

• A driver running on the host device’s operating system kernel, which manages the communication between the input component and the operating system. It instructs the operating system how to interact with the device and how to control it. It also converts the device specific data intro a more generic Human Interface Device (HID) package(the IOKit IOHIDEvent);

• An IO Manager, which aggregates and routes IO events from various connected devices to other software components. On iOS, this is the backboardd;

• An Application and Window Manager/Server, which receives IOHIDEvents from the IO Manager and routes them to the relevant application. The relevant application is generally determined by keeping a record of which applications are in the foreground and/or in focus, as well as the frames of their windows (their coordinates). This work divided between the the SpringBoard and backboardd processes on iOS, or the WindowServer process, on macOS;

• Applications and Frameworks, which ultimately receive the input event and effect some change in their own state, based on the input. Here, the IOKit IOHIDEvent is converted to application framework specific formats, such as UITouch (UIKit) or an appropriate Gesture type (SwiftUI);

• A Window Compositor and a Render Server, which renders the images to be displayed on the screen(s), with the frequency dictated by the display with the highest refresh rate;

• Optionally, depending on the design and technology, there can be various buffers and/or shared memory locations, on any of the previously mentioned components. Their purpose may vary, from ensuring that events are not lost in case of failures to various memory, speed or power consumption optimizations.

Throughout this article, we are going to follow the entire journey of a touch event, from the moment an end-user presses on a button in an application’s UI, to the moment the button’s effects are visible on the screen.

For reference, the application will render a single view, as shown in the screenshot below.

The following snippet represents the view’s code. We are going to explore SwiftUI in detail in the following sections. For now, the code is just for support, in case you would like to explore it further.

//   JourneyOfATouch.swift
//===================
//   Created by Samwise Prudent on 23.06.2025
//   Copyright (c) 2025 Prudent Leap Software SRL. All rights reserved.
//   


import SwiftUI

struct JourneyOfATouch: View {
    @State var counter = 0
    var body: some View {
        Spacer()
            .frame(maxHeight:40)
        Text("The journey of a touch")
            .font(.largeTitle)
        Spacer()
        Button(action: {
            counter += 1
        }, label: {
            Text("Please press the button")
        })
        .buttonStyle(.borderedProminent)
        Text("The button has been pressed \(counter) times")
        Spacer()
    }
}

#Preview {
    JourneyOfATouch()
}

The diagram below represents a very high level overview of the main elements that work together in order to capture, interpret and transform the act of touching an area on your screen into an action that effects change in an application.

Note how, in the diagram above, some elements exceed the outlines of their parent structures. This is intentional, because those elements (for example, the controllers) are used as interfaces with external components.

Understanding the devices

The announcement of the first generation iPhone, at MacWorld 2007, is still considered one of the most impactful keynote presentations in recent history. With the original iPhone, Apple entered the mobile phone market in a landscape dominated by two telecommunications giants, Nokia (Finland) and Motorola (United States of America). At the time, Nokia dominated the market by a large margin. Their flagship multimedia computer, the Nokia N95, was also looking to deliver a rich experience. Their design, however, was still heavily rooted in the classic, time-tested and resilient button based form factor.

Apple’s original iPhone marked several shifts in the mobile phone market. First, it encouraged the release and adoption of a new generation of Operating Systems, primarily focused on touch-based mobile devices. At the time, the main Operating Systems were Nokia’s Symbian and Microsoft’s Windows Phone, together with various proprietary Operating Systems, such as BlackBerry OS. Secondly, it solidified a design language around the modern smartphone, with a large screen and only a few hardware buttons. The latter was also made possible by the manufacturers’ move away from resistive touchscreens (pressure sensitive), to a different technology, the capacitive touch screen. This technology is described in Apple’s patents, US8243027 - Touch Screen Liquid Display, US7479949 - Touch Screen Device, Method, and Graphical User Interface for determining commands by applying heuristics, US8432371 - Touch Screen Liquid Display and US7663607 - Multipoint Touchscreen. The development of capacitive touch screen technology, combined with a dedicated, touch-focused User Interface, sparked a new generation of devices. This combination enabled a stylus-free experience, enriched by multitouch capabilities. If you experienced the transition, you may recall that some Android devices either didn’t support multitouch, or implemented inconsistently. Apple’s multitouch was leaps and bounds ahead.

On an iPhone, iPad or an Apple Watch, the screen assembly is, simultaneously, both an input and an output device. Underneath the screen’s glass, you would find a conductive layer (usually consisting of Indium Tin Oxide - ITO) and the screen’s digitizer. These components make up the main assembly that acts as the input side of the phone’s screen. Underneath those, you would find the LCD or OLED assembly, or the output part of the screen.

The screen’s input assembly, the Touch Application Specific Integrated Circuit (or, in short, the digitizer), consists of an array of sensors and a touch controller. As seen in Apple’s Patents US8243027B2 and US8432371B2, (in the patent material, sheet 17, Fig. 25), Apple may have preferred digitizers that are compliant to the SPI specification, but this is not necessarily indicative of the actual implementation. SPI is slightly more complex than other similar specs (such as I2C), but it does ensure higher bandwidth.

The Touch IC itself usually resides on the phone’s main logic board and it connects to the sensors array via a flat flexible cable. The main logic board consists of a multi-layered PCB assembly and it also hosts the SoC, Modem and GSM modules, the Input/Output connectors, the main memory modules, the T1/T2 security chips and various other modules.

In 2014, Apple submitted a new patent, for an in-cell touch technology. As a result, the old technology became known as on-cell touch. In essence, in-cell technology eliminates the need to overlay the display and the sensing layers, by interweaving the touch sensors with the pixel cells of the display. Apple holds a patent for an implementation of the technology, under US20140225838A1 - In-Cell Touch for LED.

The iPhone hardware is controlled by its dedicated firmware and by the Apple iOS Operating System, which is based on macOS X.

Apple does not typically publish too much information about the internal components of their devices, nor do the manufacturers of these components. For this reason, the sections discussing the digitizer and its connection to the SoC are speculative. It is likely that Apple is using some variant of SPI for the bus between the digitizer and the SoC, it’s likely they are using DMA, and it’s possible that they use out of band hardware interrupts.

Capturing a touch event and generating an Interrupt (in a hypothetical SPI-based flow)

When it comes to events directly initiated by end users’ interaction with any device, from any manufacturer, the trigger is always some form of change in the state of an input device. In most cases, end users interact with smartphones by touching a region of the screen. Because the human body is a relatively good conductor, the touch disrupts the electrostatic field of the capacitive screen’s digitizer, causing a change in the state of the its sensors array ( affecting the mutual capacitance between the sensors). This change is detected by the touch controller, which eventually sends the change information to the SoC, for processing. The diagram below depicts a general implementation of the touch section of a touchscreen, as an input device. It abstracts away the data bus used for communication between the Peripheral Touch Controller (which controls the sensors array) and the Host Touch Controller (which orchestrates other similar peripheral controllers, on the same bus but with different purposes). You can find schematics for various devices online or in dedicated software and, with enough experience, you can infer some of the design choices, but this is out of scope for now.

To conserve power while also maintaining the overall responsiveness of the device, the digitizer’s touch controller polls the sensors array at a fixed frequency of 120 Hz, regardless of the display’s refresh rate (as opposed to constantly reading the array). Older displays polled the touch controller at 60Hz. This means that, in modern devices, a Pro Motion digitizer’s controller would cycle through its detection routine (draw power from the battery, power up the sensors array, read the mutual capacitance of the array then power off) 120 times every second. In other words, the controller takes a snapshot of the sensors array once every 8.33 milliseconds.

For comparison, Apple Pencil devices poll their controller at a frequency of 240 Hz, while gaming mice poll their controllers at much higher frequencies, up to 4000-8000 Hz. This variance in poll rates is handled by Apple’s Operating Systems and UI Frameworks, for example by use of Coalesced UITouch events.

When the touch controller detects a change in characteristics (a signal), it performs an initial analysis, to determine if the change represents a valid touch event. It performs noise filtering, to ensure that the detected signal is not triggered by electrical noise (such as interference with other devices) and, in some cases, it may also periodically perform various calibration tasks(for example, to account for changes in temperature, which may also affect the characteristics of the sensors array).

If the signal matches the parameters of a valid touch event, the digitizer converts and serializes the event’s characteristics into a special data structure, which would later be processed by other components of the host device (in our case, an iPhone).

The serialized touch data structure, which includes the coordinates of the touched points, as well as whether the touch gesture started or ended, together with some other potentially useful information, is then persisted into a First-In First-Out Queue, located in the controller’s memory. This allows the controller to queue up multiple touch events until they are processed by the host device, keeping the entire system responsive and ensuring no events are lost.

With its limited processing capabilities and focus on power efficiency, the digitizer can’t do much more (nor should it). Therefore, after the touch information is persisted, the touch information needs to be transferred to the SoC, for further processing.

There are many mechanisms Apple could use to transfer the touch information from the Touch Integrated Circuit to the SoC. Their initial patents mention I2C and SPI as possible buses to use for the touch screen assembly - and the schematics available online do indicate that Apple SoCs support both I2C and SPI. However, Apple is likely using a modified variant of an existing bus or a proprietary bus altogether.

As a hypothetical example, we are going to assume Apple uses an SPI bus with an out of band interrupt mechanism. While Apple didn’t publicly share the exact implementation details, it’s a plausible scenario, considering MacBook trackpads do use an SPI bus. Apple may prefer Message Signaled Interrupts, but it’s not necessarily the case. Both approaches have advantages and disadvantages and Apple can optimize the entire stack, from hardware to software and everything in-between.

Regardless of the exact implementation, though, the general mechanisms remain unchanged. The peripheral touch controller needs to communicate with its host controller on the SoC via some data bus and the SoC’s CPU requires a signal to stop its current execution and focus on processing the touch event.

The SPI Specification, originally developed by Motorola, includes a dedicated data bus used for synchronous, bi-directional (full-duplex) communication between a Main Node (the Host Controller) and one or multiple Peripheral Nodes.This data bus consists of four lines types (wires):

• CS (Chip Select) Line(s), used by the Main Node to select the peripheral it talks to. In the old specification, this was called the Slave Select line. Usually, there is a dedicated line for each peripheral.

• SCLK (Serial Clock) Line, used by the Main Node to synchronize clocks with the peripheral it selects using the CS Line

• PICO (Peripheral In, Controller Out) Line, used by the Main Node to communicate with its selected Peripheral. In the old nomenclature, this line was MISO

• POCI (Peripheral Out, Controller In) Line, used by the peripheral to send data to the Main Node. In the old nomenclature, this line was MOSI

In SPI, there is no dedicated message or packet format. Instead, the communication is governed by a command-response pattern, where the Host controller indicates what it needs to read (eg. a status register to know how many bytes are present in a buffer, or the content of the buffer) and the Peripheral controller provides the response.

By design, SPI is slightly more secure than I2C, another commonly used peripheral bus. SPI Hosts select a specific peripheral by pulling the dedicated Chip Select (CS) line (each peripheral has a dedicated pin on the host). While the data lines (PICO, POCI and SCLK) are still shared among devices, a peripheral only listens if its CS line is active, reducing the risk of unintended data exposure.

In contrast, I2C Hosts broadcast packets that include the address of the intended peripheral. By convention, only the controller that has the transmitted address would act on the message. Since the two I2C wires (Clock and Data) are shared across all peripherals on the bus, it’s much easier to eavesdrop on I2C traffic or spoof peripherals.

Regardless of interface, it’s good practice to secure the transmission, with various protection mechanisms. Some common approaches are encrypted packets, peripheral authentication via dedicated security chips and/or bus zone isolation.

Although SPI does not specifically include an Interrupt Line, it is commonly used when designing responsive, power-efficient devices. In most cases, it is a dedicated out-of-band line (not part of the standard SPI Bus specifications).

As an example scenario, let us assume an end-user touches the "Please press the button" button in the interface presented at the start of this post. As long as the user touches the screen for slightly more than 8 milliseconds, the Touch ICwill detect a change in the mutual capacitance values of its sensors array. Having confirmed the readings indicate a valid touch, it will convert the analog readings into digital information and then store the details in its local memory.

Having persisted the touch information into its buffer, the peripheral host controller sends a signal on its interrupt line output pin. The interrupt signal is characterized by the presence of a higher voltage (relative to the ground). In slightly more technical terms, the digitizer asserts the interrupt line, signaling that it encountered a scenario that needs to be handled (serviced) by the circuit on the other end of the interrupt line. This line is connected to a dedicatedGeneral Purpose Input/Output connector (GPIO), which carries the signal further to the Generic Interrupt Controller (Apple Interrupt Controller in our case).

When the AIC receives the interrupt signal, it generates a request known as the Hardware Interrupt Request (IRQ). The purpose of an IRQ is to halt any task the processor may be currently doing and trigger the Interrupt Response process.

Based on system load and other criteria, the AIC then assigns a CPU Core to process the IRQ. At this moment, the AIC creates an interrupt mask, to ensure that subsequent IRQs are only directed to that core in specific circumstances (for example, higher priority IRQs of a different class). Otherwise, the Core is allowed to process the interrupt until it completes the task. This process has two main advantages:

• It helps prevent possible data corruption and it ensures that Kernel panics, for example, which would have a very high priority, would still be processed by a core that is currently engaged in an IRQ process, avoiding deadlocks;

• It allows other cores to potentially pick up other interrupts from the same digitizer, increasing the system’s responsiveness

During this time, other cores may handle other interrupts from the same digitizer and/or perform other tasks. For this reason, access to shared memory areas is controlled through a very carefully set up system of mutually exclusive locks and semaphores. This guarantees events are handled in order and it ensures one core doesn’t accidentally overwrite the data another core needs.

Handling the (primary) interrupt

Compared to the previous model, where the digitizer polls its sensors at a set frequency, interrupts are handled as they occur. When a peripheral controller asserts its interrupt line, it maintains the voltage until its host controller signals it to de-assert the line. Since this signal is the initial trigger of any action on the CPU side, it is referred to as the primary interrupt. Since it’s also a physical signal (not software), it’s a primary hardware interrupt.

The host controller is configured to instruct peripherals to clear the interrupt after the events are dequeued. This model allows the CPU Cores (which end up servicing the interrupts) to go into a deep sleep state. Requiring the CPU to poll every peripheral to determine if it should do anything would be highly inefficient.

During normal operation, any given CPU Core is either in a deep sleep state or it’s executing instructions from one of the many programs that might be running on the device. When an interrupt signal arrives, the core needs to temporarily suspend this work (or if it’s sleeping, it would wake up) and handle the interrupt request. This process is known as Exception Handling(IRQs are a subtype of Exception) and it generally follows a clear pattern. First, the core switches from Exception Level 0 (EL0, for Application execution) to Exception Level 1 (EL1, for Rich OS or Kernel execution), to gain access to privileged Kernel instructions. After it gains the elevated privileges, it also automatically saves the Current Program Status Register, as well as the Program Counter (the next instruction it should execute when it resumes the interrupted task) and other special registries, in a dedicated memory location. Next, the core jumps to a special area of Kernel Memory, known as the Interrupt Vector Table(or, on x84, Interrupt Descriptor Table). The IVT stores short branching instructions, generally known as trampolines or redirects, which instruct the CPU to jump to another area in memory, where the appropriate long form interrupt-specific Interrupt Service Routine is stored. It runs in a highly restricted kernel space, in an interrupt context and its purpose is to identify the type of device that raised the interrupt, then schedule the more complex operations required to actually servicing the interrupt to a device-specific handler. Code that is executed in an interrupt context can only use specific memory addresses, cannot acquire locks, cannot create new memory structures and it completely blocks the CPU Core while it runs.

The ISR is also known as the top half of a driver, while the device-specific handler is known as the bottom half of the driver. The top half of the driver handles the primary (or direct) hardware interrupt.

In their Kernel Programming Guide and Handling Interrupts in IOKit guides, Apple describes how, in OS X and, by extension, in iOS, this ISR is a generic low level interrupt handling routine, which Apple programs and maintains. Its purpose is to hand off the direct interrupt to a device handler (in this case, the digitizer’s handler), then schedule an indirect interrupt ( an interrupt handler written as an IO Kit Work Loop Kernel Extension (kext)) and then immediately clear the interrupt bit in the Apple Interrupt Controller. By doing so, the Operating System Kernel (specifically the Mach Scheduler) gets the chance to further arrange the execution of other tasks (other IRQs or perhaps some other urgent work). As a result, the CPU Core can reload its previous state and continue the execution, in a reasonably low timeframe.

Handling the indirect (secondary) interrupt

Shortly after handling the primary interrupt, the system proceeds to execute the scheduled touch driver event handler’s IOKit WorkLoop. In the hypothetical case of a SPI bus, the driver could issue a request to the Main SPI Controller (this is the controller on the SoC), to retrieve events from the appropriate Subnode (Peripheral) Controller. The Peripheral SPI Controllerwould then dequeue the messages it has stored and transmit the binary (serialized) representation of every touch event it currently holds in its buffer, potentially in a batched touch events report.

As Apple describes them and as shown in “Exploring Apple’s drivers ecosystem”, IOKit WorkLoops are essentially gating mechanisms that ensure single-threaded access to data structures used by the hardware. This is especially useful with driver constructs, which can be accessed concurrently by multiple threads for a variety of reasons (primary interrupts, timeout events and others). Device driver design and implementation are complex topics, which we are not going to explore further. For now, it’s useful to know that IOKit WorkLoops run on dedicated kernel threads and they run in the normal kernel space, which allows them to allocate memory, acquire locks and perform more complex logic. When the event assigned to an IOKit Workloop is processed by the system, a more comprehensive analysis of the touch data is performed. The final task of the driver is to package the processed information into a standard IOHIDEvent, which represents the processed touch input in Apple’s HID Event System ( you can find some examples here).

The mechanism could be slightly different on a Mac, where Kernel Extensions are no longer supported and have been replaced with the DriverKit System Extensions. System and Driver extensions were announced in WWDC19, in a dedicated set of talks.

Improving the hypothetical SPI model

Another, more complex (and arguably more likely) model , still within the hypothetical SPI scenario, involves the use of DMA (Direct Memory Access) enabled SPI flows. In this scenario, the CPU handles two interrupt sources, the SPI Peripheral and the DMA Controller. The driver initialization phase, which occurs when the Operating System starts up, is slightly more complex, because it involves configuring the DMA context. This process requires loading the DMA controller’s drivers, setting up the controller configuration and initializing its memory-mapped registers, among other tasks.

The trade-off is that DMA enables the transfer of data from the SPI peripheral to the system memory (to be processed and encoded as an IOHIDEvent) with minimal CPU intervention. In contrast to the previous model, which requires the CPU to constantly read data from the controller’s dedicated MMIO register, DMA offloads most of this work by coordinating the transfer of data from the host controller to the dedicated system memory area. This allows the CPU to work on other tasks in the meantime.

In DMA-enabled flows, the CPU is responsible for initiating the DMA-supervised data transfer, and later for reading the data from the appropriate system memory buffer, once the DMA controller signals that the transfer is complete.

When the SPI Peripheral detects a valid touch event, it still buffers the data - and it still asserts an interrupt to the CPU. The generic ISR executes, but instead of issuing a read command to the SPI Host controller, the driver’s IOKit WorkLoopinstructs the DMA controller to perform the transfer. After doing so, the WorkLoop waits for the DMA to signal completion.

Next, the SPI Host controller retrieves data from the peripheral controller and store it in a dedicated RX_FIFO memory area.

The DMA controller then transfers data from the SPI Host controller’s RX_FIFO to a dedicated System Memory Buffer. Many Audio and Touch Screen implementations rely on ping-pong buffers. In these implementations, the DMA controller reads data from the peripheral, then writes to a buffer, usually named the Ping buffer. When the transfer for the Ping buffer is complete, the DMA controller raises an interrupt, signaling the CPU to read from that buffer. The driver’s interrupt handler responds by waking up the previously blocked WorkLoop, which had been put to sleep when the DMA transfer process was initiated.

The driver then reads the data from the system memory, processes it through a Driver Interface, then encodes it into an IOHIDEvent structure, which is then processed as a Human Interface Device Event.

While the CPU processes the Ping buffer, the DMA controller continues reading packets from the peripheral and writes them to another area in system memory, usually known as the Pong buffer.

When the transfer is ready, it raises an interrupt, to signal the CPU that the Pong buffer is ready for processing. The IOKit WorkLoop wakes up, consumes and processes the message, then blocks again. This alternating process repeats as long there is data to be transferred.

To Be Continued…

Exploring Apple’s drivers ecosystem

When an Apple Operating System starts up, it loads the drivers required to interact with hardware components, such as connected displays, keyboards, headsets and various integrated hardware devices, such as an iPhone’s screen and its digitizer, or a macbook’s trackpad.

At first, Apple represented physical devices using a complex set of system frameworks, libraries and tools, known as I/O Kit. Later, Apple chose to extend the set of tools, by introducing DriverKit. With MacOS 15, Apple further enriched the toolset, with CoreHID. Each new addition made the creation and maintenance of device drivers slightly more accessible and safe. IOKit components are, in their vast majority, entities running in the kernel space, as Kernel Extensions (kext). They have the potential to bring the entire operating system down, if bugs occur. With macOS 10, DriverKit introduced System Extensions and Driver Extensions (dext), which run in the user space. Unlike kernel extensions, when a driver extension crashes, the operating system (launchd) simply restarts its process, with limited impact to the overall system. Both frameworks are primarily written in C++ and Objective-C. CoreHID, introduced with macOS 15, is a Swift-based framework.

As mentioned in the post “About (Swift) Applications and (Apple) Operating Systems”, it’s generally a good idea to analyze complex systems in a layered approach, especially if they are unfamiliar. In the context of device driver components, the highest level framework is (currently) CoreHID, followed DriverKit and ending with IOKit, the latter actually controlling the interactions with hardware devices.

At the lowest level, Apple built IOKit by extending the base C, Objective-C and C++ foundation of kernel modules, libkern. They consist of low level OS classes, which you can find in the XNU repository. These classes provide implementations for base ring buffers, meta classes (classes which define the behavior and structure of other classes and their instances) , mach port interfaces and so on.

On a slightly higher level, Apple abstracts devices as IOKit classes. They represent drivers as elements in a driver registry, they categorize components as services and clients, define IOKit abstractions on top of OS Classes (for example, the OS Class IOSharedDataQueue is abstracted as IOHIDEventQueue and IOHIDEventServiceQueue) and so on. The classes we’re interested in, in the context of Human Interface Devices, can be found in the IOHIDFamily and IOKitUserrepositories.

With DriverKit and later CoreHID, Apple further abstracts these lower level components, by providing user space accessible counterparts, via DriverKit base classes, representing Services, Dispatch Queues, Servers and Clients.

CoreHID provides Swift-based abstractions on top of Apple’s lower level Human Interface Device Classes, with its own Swift actors, enums, structs and protocols.

To see these systems in action, you can use ioreg -l to explore the Kernel IO Registry. You can also use hidutil list to see the HID Event System services and devices running on your Mac, as well. You can extract a tree of the known drivers on your computer (similar to Windows’ device manager, but in the terminal), allowing you to take a structured approach to understanding the ecosystem.

The diagram below showcases the elements used by the operating system to interact with a mouse connected to the system. You could start by identifying the IOHIDUserDevice element for which the Product field matches the name of your mouse ( look for "Product" = , under a IOHIDUserDevice <class IOHIDUserDevice...> entry. You can then find related classes by going up and down the tree. This is also a useful technique to add to your tool belt.

For comparison, the MacBook Trackpad, which is an integrated device connected to the SoC via an SPI bus, appears in the IORegistry as shown in the diagram below.

Keep in mind that IORegistry expands the inheritance chain of both IOKit and DriverKit classes. Not everything you see there is a producer or consumer of events, or even a standalone service. It essentially presents a suggestive view of object-oriented design, with deep dependency chains operating at low levels of the system.

The main purpose of a driver is to manage the flow of data to and from a connected device. In its most basic form, a device driver needs a few basic components to accomplish its purpose:

• a way to describe a hardware device and the mechanisms by which the driver can interact with it (Device Service)

• a memory area where it can store data it receives from the device, until the higher order components can use the data (Memory Buffers)

• a way to describe higher order operating system elements, which would consume data from the device, as well as mechanisms to interact with those higher order components. (Operating System Services)

• a mechanism to signal when the Device or OS services to consume data from the memory buffers

• a mechanism to properly orchestrate access to memory, in very tightly synchronized order. Otherwise, the OS could read the wrong data at the wrong time, or the device could try to overwrite the data the OS only partly read.

With these basic components, you can manage the process of collecting data from the device, storing it into a memory buffer, then passing it to the operating system clients. You can also manage the reverse process, of writing instructions from the OS Services to a memory buffer, then forwarding those commands to the device. All of this relatively safely, in the context of a very busy parallel and concurrent system.

Modern Operating Systems rely on a large variety of devices and connections, to deliver the functionality we’re accustomed to, as end users. All operating systems rely on some form of a Device Tree, to discover and manage devices connected to the system.

The diagram below showcases the main base classes used by IOKit, with the exception of low level work handling classes (IOWorkLoop, IOCommandGate, OSAction etc). IOKit is a pure object oriented framework, based on the conventions and language features provided by the C-class family (C, C++ and, more notably, Objective-C). It relies heavily on inheritance and composition, where objects are structured as descendants of parent classes, while their functionality is composed through the integration with other classes.

In IOKit, both drivers and services that interact with drivers inherit from the IOService class, which is a subclass of IORegistryEntry. Together, these two classes define how an object fits into the IOKit device tree, as well as the resources it requires in order to deliver its functionality. Device drivers are all grouped into Driver Families, which offer abstractions common to specific types of hardware devices. Typically, drivers are clients of the abstractions that describe their underlying bus (for example, USB) and they inherit from abstractions that describe their purpose (for example, HID).

Using Driver Interfaces, IOKit describes the flow of data, from transport level drivers (such as AppleUSBHIDDriver) to higher order EventServices. In IOKit jargon, driver interfaces decode device reports and bundle their components into IOElement or IOHIDElement objects, to be further processed by IOHIDDevice objects. With IOUserHIDEventService (a service based on IOHIDEventService), drivers gain the ability to process the device-specific report messages, into generic, IOKit native IOHIDEvents.

Finally, leveraging IOHIDEventQueues and IOUserClients, drivers gain the ability to efficiently surface those IOHIDEvents to higher order services.

Both iOS and macOS rely on processes running in the user space to act as a bridge between the kernel and various end-user facing applications. On macOS, this process is the WindowServer. On iOS, it’s the backboardd daemon. Both WindowServer and backboardd use the system-wide singleton IOHIDUserClient (a subclass of IOUserClient) to register as clients that consume IOHIDEvents.

For every Human Interface Device, backboardd and WindowServer also have associated IOHIDEventServiceUserClient instances, which set up a shared memory area, implemented as a ring buffer.

Traces captured in Instruments also expose part of this model. They indicate that backboardd receives input events via IOHIDEventServicePlugin, as shown in the screenshot below.

To transfer data from the kernel space to the user space, Apple relies heavily on Mach Messages and Mach Ports (provided by the Mach Kernel). In Apple’s ecosystem, this is the preferred Inter-Process Communication mechanism. This is especially true for cross-boundary scenarios (user space to kernel or vice-versa). Apple chose these constructs for their lower level and foundational architecture, because they enable asynchronous information delivery with built-in security and flow control. Because it’s a pattern you would encounter often in Apple’s ecosystem, especially while debugging, it’s useful to know how it works.

You will likely never use Mach Ports in applications you would release on the App Store, because Apple provides dedicated, higher level abstractions (such as CFMachPort and XPC).

There are two main models for using Mach ports for inter process communication. The first is a notification-based model, where a client process sends a notification (an empty message) to a server process listening on a dedicated port, as a signal that data is available or that a specific event has occurred. This was also the very first mechanism supported by the operating system. These notifications do not carry any payload; instead, they prompt the receiver to take further action, typically involving reading from the memory area associated with the port.

The second model is message-based, resembling higher level communication patterns. In this case, a Mach port client communicates with a Mach port server through a full message, with a payload. This mechanism is more commonly used for higher order components, such as user space process-to-process communication.

Access to Mach ports is controlled through integer-based flags known as Mach Port Rights, indicating operations that a process may perform over the port.

If you are familiar with Linux constructs, Mach Ports essentially work as Unix Pipes.

Apple also provides a higher level framework, which it recommends when developing modern software requiring Inter Process Communication. This is the XPC Services framework, which leverages the orchestration capabilities of the launchd daemon and the Mach Kernel’s Mach Ports.

Regardless of the model used for communication (notification or message), the kernel manages interactions via Mach Ports in the same fundamental way. When a port is registered, the thread that will use it performs its setup, then eventually blocks on the port. In other words, it enters a waiting, SUSPENDED state, until the kernel reactivates it to resume the execution of its loop. Only a single task can listen on a given Mach port at a time, so only a single thread is ever blocked on it.

When data is written into a Mach port, the kernel marks the associated listener thread as RUNNABLE. Then, the Mach Scheduler assigns the thread to a CPU Core. When the core is ready to take new work and change contexts, it picks up the runnable thread and executes its instructions. Generally, the thread dequeues data structures, in an operation is known as draining the port. Apple also describes this process in the Kernel Programming Guide.

To Be Continued…

Exploring the User Space in MacOS X

Before diving into how a SwiftUI application runs on an Apple operating system, it would be useful to become familiar with some of the main entities that constantly run on a Mac (simply because it’s easier to see, compared to an iPhone or iPad).

When you turn your computer on, it has no concept of files, memory, operating system or applications. However, as it boots up, more and more services start working in concert, to provide the logical support for those concepts. The exact steps are different between Apple Silicon based Macs and Intel based Macs, but the general approach is the same: the System On A Chip (as there is no CPU or GPU per se, in ARM) executes the instructions it finds on the Boot Read Only Memory ( known as the ROM. If you remember the old days of custom jailbroken Android ROMs, this is the concept). Generally, one of the first operations is to verify the signature of the Bootloader (as a security mechanism), and, if the signature is valid, it starts it. This, in turn, executes a series of exchanges to gradually verify and load various other pieces of low level software (firmware) from every connected piece of hardware that is relevant to the base boot process ( such as Security Chips, RAM, integrated Storage). Towards the end of this process, MacOS finally begins to start up. The very first MacOS process to execute in the user space is the System Manager, or launchd.

You can easily check this, if you open the Terminal app on your Mac. Thanks to its BSD roots, MacOS supports BSD commands, many of which are very similar to Linux commands. You can run the ps -eaf (process status) command in your terminal. The output is going to be ordered nicely, so you can even get a rough idea of which processes start the first. You would see many lines similar to the one below:

 UID   PID  PPID   C STIME   TTY           TIME CMD
    0     1     0   ...  ... ...        ... /sbin/launchd

The first row in the output represents the output header. There, UID represents the User ID (0 is root, the user with full rights in the OS), PID represents the process ID, PPID is the process’ parent’s PID. CMD represents the command issued to start the process. This shows that launchd, which is the system process manger for MacOS is one of the very first processes that start, on your Mac. It is started directly by the kernel_task process, which is the only process that has PID 0 (which is why the PPID of launchd is 0) - and it starts as a privileged process (as root). It does so because it needs to be able to issue requests to the Kernel (which is not allowed from a non-root level, which is why you are sometimes asked to input your “root” password for very specific tasks).

If you analyze the full output of the command, you will start seeing that many of the processes running on the system (particularly the first part of the output) are started by launchd (they have PPID 1). Eventually, after the group os processes that started from PPID 1, you will start seeing processes that are started with another PPID. These are typically processes that other applications started. For example, you would likely see the terminal process.

	...  1468     1   ...  ... ...         0:00.33 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
	...  1469  1468   ...  ... ...    0:00.01 login -pf <...>
	...  1471  1469   ...  ... ...    0:00.02 -zsh
	...  1477  1471   ...  ... ...    0:00.01 ps -eaf

It’s useful to know that PIDs are assigned by the operating system, to processes that are launched, in consecutive order. The OS has a special PID counter, which is incremented every time a new process is started. In the example above, you can see that, between -zsh and ps -eaf there are 6 missing PIDs. This indicates that, in the meantime, 6 processes likely executed and finished their execution.

It is common, when troubleshooting applications on a computer, to check the list of running processes, then walk back up the PID -> PPID chain, to identify relationships between processes. For example, ps -eaf was started by -zsh (Unix Z-Shell), which was started by the login command which was itself issued by the Terminal application.

If you open any application (for example, the Music Player), you would see a set of dedicated entries (you can use ps -eaf | grep -i music). For reference, you would use the pipe symbol (“|”) to take the output of one command and pass it as the input of another command. You can use grep to filter, -i is the flag to make the filtering case insensitive and, in this case, music is the argument. In other words, the command lists the processes that are currently running on your Mac, but only shows you the filtered ones. This is very similar to a Swift filter on a collection (let b = try a.filter { $0.contains(try Regex("m|Music")) } ):

  ...  4357     1   ...  ... ...         0:02.02 /System/Applications/Music.app/Contents/MacOS/Music
  ...  4358     1   ...  ... ...         0:00.66 /System/Applications/Music.app/Contents/XPCServices/VisualizerService_x86.xpc/Contents/MacOS/VisualizerService_x86
  ...  4359     1   ...  ... ...         0:00.05 /System/Applications/Music.app/Contents/XPCServices/VisualizerService.xpc/Contents/MacOS/VisualizerService

The PID for the Music application is 4357. We can confirm it was indeed started by the launchd daemon, because its PPIDis 1 (which is the PID for launchd). Additionally, right after launchd started Music, it also started two other processes: the VisualizerService (PID 4358) and the VisualizerService_x86 (PID 4359).

This is another very good example of how Operating System design philosophies, together with Kernel functionality, can influence the way we write applications. When running in an Operating System, each application is sandboxed. It receives its own area of memory and, as we’ve already seen, it receives its own OS Process with a dedicated Process ID. This means that, in general, one application cannot directly (willingly or accidentally) access another application’s internal memory space. However, there are cases where you need one application to have multiple isolated components. They remain sandboxed one from the other, but still function as one application and, just as importantly, they are bundled together. They are installed, updated and uninstalled together and the separation into isolated components is not relevant to the end-user.

In this case, the Music application, which is the main music playback application on the Mac, also comes bundled with two music visualizer components (which you can bring to the foreground when the Music Application is in focus, by going to the Window menu and clicking on Visualizer). This is a common application design pattern, where developers can break down complex applications into separate components, which can then be managed independently, by the OS System Manager (launchd in this case). The Music process starts as the main executable of the Music App. The two Visualizers are implemented as XPC Services, and they each receive their own OS process. Besides increased security, this also ensures that, if the visualizers encounter issues ( they are more prone to crashes due to potential decoding issues or memory problems), it can crash without bringing down the Music Player with it. It can also be managed independently by launchd, which can then restart it.

When it needs to, the Music process can then communicate with the Visualizer XPC Service, via XPC messages (which are wrapped over Mach Kernel IPC Abstractions). Essentially, as it streams the music information, the Music process bundles a copy (or some subset) of the binary data into Codable struct - and then sends it to the Visualizer. The visualizer then processes the data it receives and generates the animations it needs to.

Of the numerous processes and subsystems that start up with the Operating System, many work in concert to support the underlying functionality required for Application Graphical User Interfaces. One of those is the WindowServer process (the SpringBoard process in iOS). After launchd starts this process, there are others which follow shortly - such as the loginwindowprocess (which starts the login procedure) and then, some time later, the UserEventAgent process for MacOSX’s higher level system events. Shortly after, Apple’s WindowManager (often referred to as the Stage Manager) process starts up. The WindowManager process is responsible for arranging windows in various workspaces (desktop windows).

As described in Apple’s manual (in the terminal app, run the command man WindowServer), the WindowServer process is in charge of “window management, content compositing, and event routing”. It is a process that runs on multiple threads. All of these services are important and no application would function without any of those services - but the event routing service is perhaps the least obvious, so it merits a dedicated discussion.

Device drivers react to events in real time. To put this in perspective, the screen of an iPad could potentially send one event every 8.33 milliseconds (if its refresh rate is 120Hz). An Apple Pencil device has a polling rate of 240Hz (sending one event each 4.16 ms). A mouse could potentially send an event once every 0.4 ms (if the controller’s polling rate is 2.5 GHz). To prevent applications from being flooded with events, the WindowServer also coalesces and buffers these events. Applications can still use the entire array of events, for high fidelity applications (such as drawing applications), by leveraging the coalescedTouches(for:) API. Generally, however, they retrieve the last touch event recorded at the beginning of the V-Sync cycle (more on this later).

Another important part of the ecosystem consists of the device drivers. On MacOS, you can see the status of the Drivers Registry, by opening the terminal and running the command ioreg. If you would like to research further, you can check the main classes (such as IORegistryEntry or IOSurfaceRoot or ) and build a more detailed understanding, based on the elements that run on your computer.

Finally, you can also check the connected Human Input Devices your OS recognizes at any given time, by running the command hidutil list. Apple provides a guide on how to analyze this information in their “Discovering HID Devices in the Terminal” guide.

The Activity Monitor is another particularly useful tool for exploration and troubleshooting. You can call it from the Launchpad as a generic Task Manager (similar to Windows’ Task Manger) or from the Menu Bar (<Application Name> -> Services -> Activity Monitor), as a Development Instrument. Depending on the way you call the Activity Monitor, the interface will likely look slightly different.

If you run the Activity Monitor as a Task Manager, you can also sample any running process. As shown in the screenshot below, you would select the process you’re interested in (WindowServer in this case).

Then, using the System Diagnostics Menu, you can sample the process. When doing so, the OS takes a snapshot of the running threads and calls - as well as a Stack Snapshot (similar to what you see when reaching a breakpoint when debugging your application).

Once the sampling process is complete, Activity Monitor opens up a dedicated Sample Window. You can then choose from multiple Display Options and analyze the process call graph. You can then cross-reference the calls with Apple’s documentation, to determine what each call does. Notice how, for example, 2220 represents the amount of times the thread/call was found during the sample period - and it does not represent a Process ID.

You can later use these tools to further explore how other processes and applications work (to some extent). You would not see implementation details and, in many cases, the method calls are intentionally not documented. However, with time, you would become proficient at interpreting call graphs and stack traces.

Using Instruments to explore the User Space on an iPhone

You can also explore the main processes running on iPhone and iPad devices, as well as the way the Operating System interacts with the applications you create. It is, however, a slightly more involved process, since you need to connect the devices to a Mac, then use Xcode’s Instruments suite.

For example, you could use the Logging Instrument to capture the log entries created by various processes running on the phone, grouped by the subsystem (framework) that creates them. To make the initial experience easier, it would be a good idea to switch the iPhone to airplane mode, to minimize the amount of messages the logger instrument would intercept. As you gain more and more knowledge and become more comfortable with the toolset, this step would become unnecessary.

There are other Instruments you may want to use, such as:

• Runloops instrument, to explore the execution details of running processes’ various input processing threads, known as runloops

• Virtual Memory Trace instrument, to explore various structures in memory, as your application changes

• GPU and/or CPU Profiler instruments, to analyze various activities performed by the GPU and CPU sides of the SoC, respectively

Although you can add multiple instruments to a single recording session and capture data from all processes, the bandwidth you can use is limited. Sometimes, events are dropped due to various rate limiters.

Therefore, it helps to create a simple test scenario (eg press a specific button in your application), then run the test scenario multiple times, with one instrument at a time, but for all processes. Or, with all instruments, but on one specific process at a time.

The purpose of this section is to show some of the main processes running on MacOS and iOS, to give you a general idea of where to look, given your specific needs.

To get started, in an Xcode project, go to Xcode -> Open Developer Tool -> Instruments. Then, select Logging as the initial instrument. You can add multiple other instruments. In fact, you can select a different set of instruments for each recording, to make the process easier to follow.

The Instruments application's User Interface is designed to streamline the viewing, organizing, and filtering of captured events while serving as a centralized repository for recording sessions across multiple test cases. The screenshot below demonstrates a scenario where logs were captured across various test cases, which are displayed in the Recorded Sessions section.

The Instruments UI also features a central Toolbar, similar to Xcode, allowing you to select your target device and specify which process to monitor during recording sessions. You can configure the recorder to capture all processes system-wide or focus on a specific application, system process, or app extension. The toolbar also displays currently running applications on the connected device, functioning similarly to the ps -eaf command in the macOS Terminal.

As shown in the screenshot below, you have several monitoring options to choose from. Like macOS, iOS assigns process IDs (PIDs) sequentially. In other words, lower PIDs indicate processes that started closer to system boot time. Note that certain processes cannot be monitored through Instruments due to security restrictions.

As an example, we could analyze the processes that are involved in starting the Music Application on an iPhone, in iOS26, when pressing its icon on the Dock (the area at the bottom of the Home Screen on an iOS device).

To make it easier to follow, switch the device to Airplane mode. Since Airplane Mode turns off all wireless services, make sure the device is paired with your Mac via a cable. Also, make sure the device is unlocked and that TrueTone is off ( also to minimize the amount of events the logger would capture). Finally, make sure you switch the Recording Mode to Deferred, to make sure the logger doesn’t drop events.

In the Instruments Application, start recording, then touch the Music Icon and, finally, stop the recording. The faster you execute this chain of events (start recording, start the music app, stop recording), the shorter the session would be and the easier it becomes to parse.

While your mouse cursor hovers over the timeline, you can zoom in and out, using the option (⎇) key + the mouse wheel up or down. Alternatively, you could use cmd (⌘) and +/-, to zoom in and out, respectively. Zooming in and out is particularly useful when, besides the logger, you have other instruments in the recording, because you can more clearly find correlations between events across processes and various CPU/GPU/Memory operations. In the screenshot below, the highlighted area represents an area of interest. It starts around the moment the Music Icon was touched and it ends around the moment the Music application starts up.

According to the log timestamps, the entire process, from the moment the touch was registered until the application fully loaded, took under 200 milliseconds (or a little under 12 frames).

Finally, the Instruments application supports Input Filters, to help quickly locate specific log entries. The filtering mechanism accepts two input fields, which can be combined for more precise results.

First, you can use the filter search box with the syntax <filter category>:<filter value> to isolate specific log entries. For example, process:SpringBoard would show SpringBoard related logs and nothing else. You can also search for any text strings across all categories, simply by typing it out, without a category identifier. For example, the string Welcome to MusicX would identify the event that signals the start of the Music Application.

Secondly, although not clearly marked as such, you can press the Input Filter button, to filter results by threads. Notice you can specify the filters independently. Contradicting filters ( runningboardd in the thread filter and process:Music in the search box) are valid selections, but they would display an empty list of results. The screenshot below showcases an example of these filters.

This section introduced you to some of the tools that will help you better understand the vast ecosystem Apple has put together over the years. These techniques do not replace perusing Apple’s documentation or their WWDC sessions. In fact, you will find references to many of them, scattered throughout this book. Instead, together with the Xcode Debugger, they will help you verify your assumptions and put the information in a more practical context.

To be Continued…

Some months ago, I had a conversation with a colleague of mine, about cloud applications and why Kubernetes workloads need to scale out (more individual pods, or horizontal scaling) and not just up (more powerful pods, or vertical scaling). This went on a tangent about distributed systems and, eventually, on why creating a large number of threads and even processes to be handled by a processor eventually hits a ceiling. Whether that ceiling is truly relevant, in the context of modern hardware and software is an entirely separate topic.

During our conversation, it became apparent just how disconnected modern software development is from the underlying hardware, or even from the Operating Systems the application processes run on. Coincidentally, I was getting ready to finish up my first SwiftUI introductory book. I decided to push the release of that book a bit farther, and capture the information I wanted to convey in that conversation, in a better articulated manner and through the lens of Apple’s systems.

In this post, I will cover the first two sections of that introductory chapter. The rest will be included in a few other posts.

About (Swift) Applications and (Apple) Operating Systems

Today, Software Development as a profession is often performed on very high level software frameworks, which usually hide away many of the more complex tasks.

Some frameworks are developed by large companies, such as Apple, Google or Microsoft, to help developers create software for their ecosystems, or to solve very specific problems they encounter in their business. Others are created by individual developers or small teams, to solve a problem they encounter ( such as Laravel, Ruby on Rails, Vue.js etc.). This model works very well because it allows framework users to focus on their application’s core logic, while framework developers handle the underlying technical challenges.

Applications work well when both sides understand their roles: users must grasp the framework's rules, and developers must understand the types of applications their users are building. However, this mutual understanding breaks down. Sometimes, the framework evolves in a direction that excludes specific types of applications. Other times, we use the wrong framework to solve a particular problem, influenced by hype or by the incomplete understanding of the framework’s purpose. More often still, framework creators lock users into their particular vision of how applications should function. The degree to which framework maintainers establish and enforce their own views (opinions) over how their users should build applications determines if a framework is opinionated or not. Apple’s Combine framework, together with the SwiftUI framework, for example, are opinionated frameworks. They expect applications to be constructed by declaring how data is transformed over time and howthe User Interface should use the data, without requiring the users of the frameworks to specifically call a render or an update function, for example. They are declarative, reactive frameworks which, by their very nature, require a specific structure.

Since frameworks hide complex lower-level interactions, developers often make assumptions that are partially or completely incorrect, leading to various issues. Meanwhile, framework maintainers, focused on their own development priorities, may create constraints that make certain application requirements difficult to implement. When these constraints are not properly documented, the resulting applications are more likely to behave incorrectly.

With experience and as frameworks evolve, users become experienced enough with architecture of the frameworks they use and form their thinking models in line with the framework maintainers’. In the same time, the framework documentation improves, leaving less room for incorrect assumptions.

Because this model generally works well and allows application developers to move faster, it also allows developers to become completely disconnected from mechanisms and notions that are not made visible (or usable) by their frameworks of choice.

Eventually, some developers (hopefully most of them) reach a point where they wonder what actually lies beneath the surface exposed by those frameworks. They may, for example, wonder how a touch on their screen (or click of their mouse) results in the actions they see on their screens - whether it’s their favorite application starting up or it’s they favorite game character moving. Or, perhaps, they would start wondering how macOS works and why it’s built the way it is. Not just in terms of design and polish, but the internal mechanisms.

As a developer, you can spend most of your career writing applications for the Apple platform without knowing what the Mach kernel is or ever seeing an IPC message. You can write fast and safe concurrent multithreaded applications, without knowing anything about POSIX Threads. In fact, since Swift 5.5, you may not even need to know what the Grand Central Dispatch is.

However, if and when you do, you suddenly start to understand why Operating Systems, Application Frameworks and Programming Languages work the way they do. You start understanding the techniques others used to solve problems - and you gain the ability to apply those notions independently. You begin to realize just how complex and vast the technology space is, even in areas that seem specialized, such as the development of applications for the iPhone.

The purpose of this section is to explore how the Swift source code we write fits into the wider and more complex context of Apple Operating Systems running on Apple devices. This will help form a mental model of the way your own application’s code fits within this entire ecosystem. Then, we are going to follow the events that take place when an end-user touches the screen of their phone (or clicks a button on their mouse) to activate a button in an application’s user interface.

I find this helpful, though not necessarily mandatory, for a few key reasons:

• You gain the vocabulary you need to express concepts and implementations. This is particularly useful when collaborating with other developers, or during your own research. Many technical terms carry specific implementation details, so a shared understanding between you and your interlocutors can go a long way. Additionally, the richer your vocabulary becomes, the more precisely you can ask the questions you need, to get the answers you seek;

• All Operating Systems essentially solve the same problem: they act as a bridge between the end-user, the applications they need to use and the hardware those applications run on. This is all orchestrated in a safe (relative to the system itself, not your data) and hopefully intuitive manner. The mechanisms they use to accomplish these tasks differ in certain implementation details, but the general ideas and concepts remain the same across all ecosystems (partly for convenience, partly because the ideas were that good to begin with). For example, all Operating Systems use drivers to describe devices (such as a mouse or printer) in ways that are useful to the software running on the operating system. However, each OS may (and usually does) have its own systems used to build those drivers.

• Generally, low level systems do not change in fundamental ways and if they do, they rarely change quickly and suddenly. Therefore, if you know how a specific kernel worked 5 years ago, it will likely work the same now and 5 years from now. The same goes for kernel extensions. As this section will show, there are portions of the macOS Operating System that were written in the 1980s and 1990s. They are still relevant and important, close to half a century later. This is why some of the references provided throughout this chapter are sourced from Apple’s archives website.

When referring to software components and concepts, we can generally use the terms “low level” and “high level”. For example, SwiftUI is the higher level framework, while UIKit is the lower level framework. Even lower level framework examples would be CoreAnimation or CoreGraphics. Regardless of the framework, the direction remains consistent. Lower level indicates that a concept is closer to the device’s hardware space, while higher level indicates that the concept is closer to the end-user space. This is a useful way to describe frameworks and programming languages because, the closer we get to the hardware, the less protection mechanisms we generally. As a result, the impact of potential programming errors is generally higher in lower level environments.

When analyzing complex software systems, it’s important to set a context or abstraction domain and then ground the analysis to that context. This is especially useful because a single term can mean multiple things, depending on the context.

For example, the diagram below presents a Button in various contexts. While “Button” conceptually means an interactive control, its technical definition and characteristics vary, based on the domain (or even frameworks of the same domain). Specifically:

• In SwiftUI, the button exists as a Button view built upon the UIControl class from UIKit, which itself derives from the UIResponder class.

• At a lower level, the button is expressed in the context of the screen ( display device) and it can be represented by a Touch Area and a CoreAnimation Layer

• In Memory, it simply becomes a block of data, representing its state and, potentially, references to other objects(such as the associated functions to be executed when touched)

All of these perspectives are valid and individually accurate, but no single one tells the whole story.

When referring to a button in UI Frameworks, you are referring to the control, which is a high level abstraction that contains a visual element (the rendered button) and a logical element (what should happen when the button’s action is called). These concepts exist entirely in the Application’s User Interface domain. In the context of the screen’s display component (the OLED), you have an area of pixels. In the context of the screen’s digitizer (the assembly that converts physical interactions to digital signals) , you have various signals from a sensor array (changes in the electrical/magnetic field, recorded for each sensor) which the Hardware Controller registers and processes to extract information about touched areas. In the context of Memory, you have the frame buffer, which contains the information related to the visual representation of the Button, so that it can be drawn on the screen - and so on.

The terms framework and library are sometimes used interchangeably, especially in front end development and in discussions about React. This is usually because they both provide code that you can reuse and because some developers have very specific expectations from frameworks.

However, the two terms describe different requirements - and it’s useful to clarify them here, even though you will likely also use the terms loosely.

Libraries, such as the ArgumentParser library, provide reusable code you can integrate into your application. Their purpose is to add additional functionality, by allowing you to import their files and use them directly, as an integral part of your code. In other words, libraries integrate into your project.

Frameworks, such as SwiftUI, UIKit and others also provide some reusable code you can integrate into your application, but with a different purpose. The code exposed by frameworks acts as a connection point between the framework and your own code. In the case of SwiftUI, you use the View protocol to define views. When SwiftUI builds or updates views, it looks at structures conforming to that protocol. When it needs to render a view, it checks the structure’s body property, which is required by the View protocol. In other words, your code provides specialized behavior, conforming to the framework’s requirements, which the framework uses in certain cases. This is known as inversion of control.

Put simply, libraries integrate into your code, whereas your code integrates into frameworks.

Brief introduction to Operating Systems

If you own a personal computer, it is likely running an operating system that is either Apple’s macOS, Microsoft’sWindows or a variant of Linux. Of the three, two use a kernel (a complex set or abstractions that bridge the hardware of the device with the ) that represents a variant of POSIX/Unix (Portable Operating System Interface/ UNIplexed Information and Computing Service) and the other uses the Windows NT kernel.

There are numerous criteria to classify Operating Systems - and one of them is the way they structure Input and Output abstractions. There are others, such as promises related to Response Times (Real Time Operating Systems vs Regular Operating Systems).

In POSIX, the core philosophy is that everything is a stream of bytes (or a file). In Windows NT, on the other hand, everything is a specialized, securable object. This may seem like a small difference, but it essentially dictated the path of the operating systems that used them. For example:

• As its name suggests, the POSIX approach is to ensure the conforming Kernels are portable. By abstracting everything as a stream of bytes, you can effectively configure anything in a file (in Apple’s case, two files, because you typically include a .plist file as well). With Windows, on the other hand, you use the Windows Registry. The kernel is not as easily ported to another operating system.

• On POSIX, you use Native, Lower Level Abstractions. You can write native C tools to interact with the POSIX APIs, or you can use Apple’s C-level Core APIs - all the way up to Objective-C or Swift code. On the NT Kernel, however, since it is proprietary from the ground up, you usually interact with Higher Level Abstractions provided by Microsoft (.NET Core, UWP/WPF) . This does not necessarily make one approach safer or easier to use than the other, they just require different mindsets.

Overall, both ecosystems encourage developers to use the highest-level APIs possible and have invested heavily in toolsets that help developers build more complex, stable, and safe applications faster.

Despite these differences in approach, every Operating System (macOS, iOS, watchOS etc. for Apple or Windows for Microsoft) comprises, among many other complex systems, the same main components: an OS Kernel, a Service Manager, one or several Event Manager(s) and a User Interface Manager:

• The OS Kernel is the piece of software that acts as the bridge between the Hardware and the Operating System’s higher order components (daemons, UI and end-user facing applications). It is a collection of services (often C functions, objects and data structures) that provide fundamental capabilities (assigning work to the CPU, allocating memory, reading from memory etc.) to higher level components. A key concept to grasp is that kernel services are loaded in memory when the operating system boots up and, unlike higher order constructs (like applications or web services), kernel services never stop. If an error is encountered in the kernel functions, it has the potential to bring the whole machine down, requiring a complete reboot and reload of the kernel. Apple, uses the XNU kernel, which is a combination of FreeBSD and Mach. Together with other core components in Apple’s ecosystem, the XNU kernel is part of the Darwin Operating System. Over the years, Apple developed numerous Kernel Extensions, to enhance the functionality and organized them in various ways, to be bundled with their various devices.

• The Service Manager is a process (a workload container in which a program’s code runs, identified by a process ID - PID, for short) which starts after the OS completes its loading process. For Apple’s ecosystem, it’s launchdand for Linux - it’s init. Sometimes, it’s called a System Manager and it starts with the Operating System, as the very first User Mode process created, which is why it receives the Process ID (PID) value of 1. It runs as a daemon process (a background process which runs in an infinite loop and performs tasks without user interaction) and it starts the applications that should load up after the Operating System boots. Finally, once the startup level applications are started, the system manager daemon process continues running and waiting for instructions, for as long as the Operating System runs.

• The Event Manager is responsible for handling various types of events. There are usually multiple event handlers, each handling specific types of interactions - and in various activity spaces ( file system events, system events, touch events and so on). For macOS, mouse clicks are registered via WindowServer, while on iOS, touches are handled by backboardd (which was introduced in iOS6, as a break-out daemon from SpringBoard. They all receive the the events from the low-level IOKit kernel extensions.

• The User Interface Server, is responsible for managing the User Interface elements. For MacOS, it is WindowServer, whose main function is to open CGXServer (Core Graphics X Server). For iOS, it’s SpringBoard. Additionally, there is a WindowManager component, as well - and it is responsible for grouping managing window positions in various configurations (for example, on multiple virtual desktops). There is also a RederServercomponent, which ensures that the correct data is processed by the GPU at the correct time, so that the connected displays can show the UI correctly.

In most scenarios, you will rarely (if at all) interact with these components directly - especially the OS Kernel. Instead, you would typically write code that integrates into Apple’s frameworks which, in turn, would interact with the OS Kernel on your behalf.

Since the Operating System is responsible for the management of hardware resources and all applications that try to use them, providing higher level frameworks for lower level interactions is not sufficient to ensure its integrity and performance. The OS is not inherently secure simply by following the distinction between high level or low level, nor is it secure by dividing work among more processes. For this reason, as a bare minimum, the software running on a device is divided into two main spaces:

• The User Space, where applications external to the OS, such as eBook Readers, browsers, games etc. run. Software running in this space needs to be protected from other software running in the same space. This is accomplished by ensuring that each application receives its own memory (memory address space) they can read into. Generally, one application cannot read another application’s memory directly.

• The Kernel Space, where the Kernel runs. The software running in this space can potentially access any location in memory, can run any operations and can control all input/output address spaces. Since it essentially has unrestricted control everywhere, this space needs to be separated from the User Space - and access to its resources is tightly controlled.

This separation ensures that an application running in the user space cannot take up more resources than the Operating System considers to be safe - and that an application crash does not take the whole operating system down. There are cases where these issues do still occur - but the separation between the User Space and the Kernel Space aims to lower the number of occurrences.

In general, User Space applications use System Calls (wrapper functions within the libSystem dynamic library) to prepare instructions to request from the the software running in the Kernel Space. The Kernel (in the case of XNU, either the BSD components or the Mach components) can then request the CPU to execute the commands. Lastly, The CPU executes kernel-issued commands only when it receives a specific trap, which signals its transition from the User Mode (Ring 3 on x86/64 architectures or EL0 - Exception Level 0 - on ARM) to the Kernel Mode (Ring 0 on x86/64 architecture or EL1 on ARM).

Besides the logical separation between the kernel and end-user-facing applications, the design of an operating system includes other concerns. To function effectively, applications need to interact with memory. From the application’s executable code, to dynamic libraries, to runtime variables, every useful piece of an application is stored somewhere in memory. As such, memory use, management and security are critical concerns for any operating system and its surrounding components.

When any application starts up, it goes through a Setup Phase, where the OS Kernel assigns a dedicated Virtual Memory Address Space for internal use. This serves as the application’s addressable memory space. During the application’s normal operation (or the Frequent Access Phase), its instructions access addresses from the Virtual Memory Address Space.

This system enables true multitasking and the parallel execution of processes. Since every process operates within its own virtual memory address space, two processes could store different data, at the same virtual address. When each of the two processes needs to access the address, the MMU converts the virtual address to a unique, real memory location. Since the physical locations are unique, the two processes can run without interfering with each other.

The access to physical memory is orchestrated through a separate hardware component known as the Memory Management Unit, which translates between virtual memory space and physical memory space, using a page table. By using a separate orchestrator for memory access, a given process cannot access the data of another process, unless the MMU itself becomes compromised.

The diagram below showcases the separation between Exception Levels, as well as the way memory is allocated on setup and used during the frequent access state of applications.

To further improve security, the Operating System (and the dynamic loader) use a mechanism called ASLR (Address Space Layout Randomization), which randomizes the virtual memory addresses where critical program components are loaded when a process starts up. Rather than always using the same address to load executables, libraries or other data, ASLR introduces controlled randomness to the memory layout. For example, the configuration data of a process may be loaded in address 0x01020304 during one program execution, but in address 0x0402301 during the next execution. Similarly, the stack could begin at 0x7ffdb9v3e0000 in one instance and in 0x8ffe123456789 in another one. This makes it exponentially difficult for attackers to predict where a specific piece of data is stored by a certain application. ASLR has a direct consequence on the compilers, because the Object files they generate need to be expressed into Position-Independent Machine Code. In most cases, addresses are expressed relative to the current position of the stack pointer.

Perhaps equally as important, because virtual memory abstracts away the physical memory layer, it can essentially create the illusion of an extended memory lane. For example, a 32 bit application can use up to 4GB of addressable space. A 64 bit application could use up to 18 ExaBytes (1,000,000 GB) of addressable space. This allows the operating systems to use various types of non-RAM memory (such as the Hard Disk) as extensions to RAM.

About Memory and Data Transfer over various mediums

Computers (and phones) function by processing electrical signals as data. Any piece of information is represented as a sequence of 1 and 0, or a Binary Sequence. To illustrate this concept, we can take the letter F as a simple example. To represent it in a way that can be expressed as a sequence of 1 and 0, we need to choose an encoding. This represents the protocol that both the sender and the receiver need to use, in order to understand the binary sequence. This protocol is used by the sender to encode the letter F into a binary sequence. Then, the sequence is decoded by the receiver using the same protocol. As long as the two parties use the same encoding, they can communicate with each other. There are several encodings for characters (String Runes):

• ASCII is the foundational character set for the English language. It uses 7 bits to represent 128 characters, but the data is almost always stored in a standard 8-bit byte.

• UTF-8 is the dominant encoding for the web. It's a variable-length encoding designed to represent every character in the Unicode standard. It is fully backward-compatible with ASCII.

• UTF-16 is another variable-length encoding for Unicode. Its basic unit is a 16-bit (2-byte) chunk.

• UTF-32 is another variable-length encoding for Unicode. Its basic unit is a 32-bit (4-byte) chunk.

Wherever an encoding uses more than 1 byte, we usually specify whether the sequence is read with the most significant byte first (Big Endian) or the least significant byte first (Little Endian). Essentially, endianness represents the order in which the sequence is read. Big Endian represents the “natural order”, whereas Little Endian represents the “reverse order”. Depending on endianness, the same sequence can mean two different things. For example, the UTF-16 character represented by the binary sequence 00000000 01000110, can be read as:

• The Uppercase English Letter ‘F’, when using Big Endian, because 00000000 01000110 is read as 0x0046 in Hexadecimal

• The CJK Unified Ideograph ‘䘀’, when using Little Endian, because 00000000 01000110 is read as 0x4600 in Hexadecimal

Because the order in which bytes are read matters, it’s useful to know that, in network protocols, Big Endian is the default. For file formats (especially text), we specify the endianness using a BOM (Byte Order Mark), U+FEFF (ZERO-WIDTH NO BREAK-SPACE) which is an invisible character at the beginning of the file. For example, if a UTF-16 starts with the byte sequence FE FF, the file was saved as Big Endian. If it starts with FF FE, it was saved as Little Endian.

Since any type of information can be expressed in binary, as long as both the sender and the receiver agree on the encoding ( or format, or protocol, or standard, depending on the context) and endianness , we can save information, for later use, in some type of memory - or we can transfer it to other systems.

Although encoding can slightly obfuscate the data being converted, it is not a security mechanism. For example, you can easily take a base64 encoded string and then decode it. To properly secure data, you would need to use encryption, which requires cryptographic algorithms.

In the context of storing data for later use, one of the simpler examples consists of the common Dynamic Random Access Memory (DRAM), which stores data by using billions of small constructs, known as memory cells. Each memory cell stores a single bit and it consists of a capacitor (which can store charge) and a transistor (which acts as a switch). In a nutshell, when a capacitor is charged, it represents the value 1 - and if it’s discharged, it represents the value 0. The diagram below represents a single DRAM memory cell. DRAM cells are arranged in a matrix. This type of memory is wiped when the system is powered off, since the capacitors are very small and they cannot hold a charged state for too long. For this reason this type of memory is known as Volatile Memory.

To read from DRAM, the system places a small electrical current on a specific Word Line, which closes the transistors connected to it. As a result, the circuit between each transistor’s capacitor and the associated Bit Line is closed, as well. This activates the cell. If the cell’s capacitor is full, the Sense Amplifier on the Bit Line detects a small increase in the Bit Line’s current, which signifies a 1. On the other hand, If the capacitor is empty, the Sense Amplifier detects a small decrease in the Bit Line’s electrical current, signifying a 0. When a capacitor is discharged, it needs to be recharged to show the same value on the next read operation. For this reason, read operations on the DRAM are destructive and they usually result in an immediate write operation (essentially, the controller reads the memory, then writes it again, while also sending the information to the requestor). Since DRAM is based on capacitors, which leak current, this type of memory needs to be periodically refreshed, by reading and rewriting the data. Most modern DRAM memory blocks refresh once every 64ms.

There are many other storage mechanisms, such as SRAM (Static RAM), based on a transistors feedback loop, which does not require a refresh ( hence, the name static), Magnetic Discs ( the normal HDD) , Flash memory and so on - each with their own requirements and implementations. At a high enough level, though, all memory storage mechanisms serve the same function: they store binary data, which can be retrieved, or modified.

All operations (reading, writing, refreshing) are highly dependent on a well synchronized clock signal. For example, it’s important to ensure that the data is read by the controller exactly when the sense amplifiers would detect the discharge. For this reason, everything in computing is, at the lowest possible level, completely synchronous. Clock speeds are measured in Hertz (Hz). 1 Hz is the equivalent of a tick per second. To put this in perspective, a 2GHz clock ( a modern processor) would “tick” 2 billion times every second.

Lastly, data can be transferred from one medium to another. This is accomplished by passing electrical current, either through independent (floating) wires or through traces of conductor, printed on Printed Circuit Board. Generally, the wires or traces that make up a bus are called lines. A grouping of these lines is known as a Bus. There are 3 main types of buses, conceptually (though at a very high level, the Bus represents the whole group). If the bus is used to transfer the address for which the read or write operation should be performed (Read from Address or Write to Address), it’s an Address Bus. If it’s used to send a clock signal, which acts as a synchronization mechanism (metronome) for the system, it’s a Clock Bus . Finally, if the bus is used to transfer the actual binary data, it’s a Data Bus.

Besides their purpose, buses are characterized by a width, or a number of lanes, which represent the number of wires the bus uses to transfer signals. Generally, Address Buses and Data Buses have a higher width, while the Clock Bus is usually 1 line wide (only has one wire).

Not all standards separate the address from the data lines. In many cases (I2C for example), both data and address information are sent on the same wire, but in different frames (a data frame and an address frame).

Data Buses can be serial (they transmit the value of one bit at a time) or parallel (they transmit the value of several bits at a time). The advantage with parallel buses is that they can send more data faster, because they can send more bits in a single clock cycle. However, when printed in a curve, the lines have different lengths, so it’s more difficult to ensure that all bits reach their destination at the same time.

The diagram below showcases the example of how the uppercase letter F is transmitted, in UTF-8 binary encoding, over a serial and over a parallel bus. As a reminder, the binary value for this character is 01000110.

Data can be transferred either in a Little Endian or in a Big Endian order (Least Significant Bit is transferred first or Most Significant Bit is transferred first). In this case, we are looking at a Little Endian system, so the least significant bit is transferred first. The example is simplified, as parallel buses usually transmit data through much wider data buses. For example, a parallel bus might use 32 wires, to transmit 32 bits per clock cycle, instead of the 4 bit wide data bus in the example.

Over long distances (more than the usual distance between components on a single circuit board), this mechanism with a dedicated clock line becomes less and less feasible. Due to the physical characteristics of the wires, the timing signals can drift slightly, between timed objects. This is known as the clock skew or timing skew. To address this, most hardware protocols used to transfer data outside the realm of a single computer board (such as SATA, USB, Ethernet etc.) use various mechanisms to transfer the clock information with the data signal itself. This is colloquially known as Clock Embedding or Self-Clocking. For example, the Ethernet protocol specifies that, at the beginning of each transferred frame (more specifically, in the Preamble of each frame, or the first 8 bytes of the frame) there must be a sequence of high and low bits (10101010101), which are used by the receiving Network Controller to synchronize its own internal clock. This mechanism is known as Clock and Data Recovery.

To be Continued…

I will focus on ideas through the lens of Apple’s ecosystem, but the underlying concepts would generally be transferrable to other platforms and technologies. No large ecosystem exists in a vacuum. Ideas, especially the good ones, often cross the boundaries of individual companies and their platforms.

Throughout my career, I have always documented my projects. I recorded what I did and why - and it all came in handy, sooner or later. When I wanted to take new challenges, I used my documentation to ramp up my replacements, so my managers and teams found it easier to support me. When I needed to explain why I designed a software system the way I did, I used my documents to show my process and gain trust. And when I needed to know why I didn’t apply one pattern over another, I had my documents to tell me why… I still document everything I do, some 18 years later - though now it’s also a more prevalent part of my day job. It is, therefore, only natural for me to continue to write, as I walk the journey of Prudent Leap Software, in my free time.

I don’t claim to know how technology will evolve and where it’s headed, but I believe accurate, structured information will always matter. As tools evolve, understanding the concepts, models and patterns behind modern software architecture will still remain just as important, if not more so. Although Large Language Models may change how we find information and even how we build production, enterprise applications, context (pun intended) does and will still matter. In a system where the inputs are words, sentences and paragraphs, often framed as questions, knowing what words to use and what questions to ask still feels foundational. I am not so sure that AI will fully replace software developers, or even that developers who use AI would. But I am convinced well trained, knowledgeable developers will replace those who are not, with or without AI.

Some posts will be full excerpts from the books I am or had been working on. Others will represent ideas I found interesting enough to explore, but did not really fit in a book (yet). I am not looking to cover every new feature Apple releases for their frameworks, nor every new evolution initiative in the Swift community. There already many creators who do - and I try to follow all of them, as my time permits. But, if I feel I can add to the conversation in some way, I will.

As for you, my dear reader, I hope you’ll enjoy your time here - and that you will allow others to enjoy their time here, as well. Be decent. Be humble. If you can, teach others. If you know you’re right, defend your point of view, with arguments and examples. Don’t be disrespectful. Become better every day, bit by bit. And in doing so, improve those around you, so we can all grow, together.