This article is relevant for iOS 18 and uses the latest SwiftUI API for alerts. If you are supporting older versions or using UIKit, some details may differ, but the general principles remain the same.

Alert vs ActionSheet

Before we dive into alerts, let’s talk about ActionSheet and where to use it instead of Alert. An action sheet is a UI element that presents a set of choices related to an action the user has started. According to the Human Interface Guidelines (HIG):

Use an action sheet — not an alert — to offer choices related to an intentional action. For example, when people cancel the Mail message they’re editing, an action sheet provides three choices: delete the edits (or the entire draft), save the draft, or return to editing. Although an alert can also help people confirm or cancel an action that has destructive consequences, it doesn’t provide additional choices related to the action. More importantly, an alert is usually unexpected, generally telling people about a problem or a change in the current situation that might require them to act.

It seems obvious, but even Apple is not always consistent. For example, when you delete a note in the Notes app, you see an action sheet, but when you delete a reminder in the Reminders app, you see an alert. Why?

According to HIG, in this case, an alert would be more appropriate, because the user is being warned about a destructive action that cannot be undone. This highlights the importance of understanding the intent behind each component and choosing the right one for your scenario.

Diving into Alert

Since we decided that an alert is the right choice in the previous example, let’s see how to use it correctly and what options we have. We will not talk about the title and message, as they are straightforward. Instead, let’s focus on the buttons, their placement, and style.

In the example above, the destructive button “Delete” is on the right, and the cancel button is on the left. This is the current HIG recommendation:

Place buttons where people expect. In general, place the button people are most likely to choose on the trailing side in a row of buttons. Always place the default button on the trailing side of a row. Cancel buttons are typically on the leading side of a row.

You don’t need to worry about the button order — just assign the correct role (such as .cancel or .destructive) to each button, and SwiftUI will automatically arrange them according to the latest HIG. This not only simplifies your code, but also guarantees a consistent and native experience for your users.

.alert("Delete Reminder") {
    Button("Cancel", role: .cancel) {}
    Button("Delete", role: .destructive) {}
} message: {
    Text("This action can't be undone.")
}

Even better, you do not need to add the cancel button explicitly. The system will add it for you, making your code even cleaner:

.alert("Delete Reminder") {
    Button("Delete", role: .destructive) {}
} message: {
    Text("This action can't be undone.")
}

But it was not always like this. In the past, HIG said the opposite:

In a two-button alert that proposes a potentially risky action, the button that cancels the action should be on the right and light-colored. In a two-button alert that proposes a benign action that people are likely to want, the button that cancels the action should be on the left and dark-colored.

I think this is why you can still find alerts in iOS where the button order is different.

Apple made it easier for developers, and forgot about themself.

Should the Destructive Button Always Be Red?

Use the destructive style to identify a button that performs a destructive action people didn’t deliberately choose. For example, when people deliberately choose a destructive action — such as Empty Trash — the resulting alert doesn’t apply the destructive style to the Empty Trash button because the button performs the person’s original intent. In this scenario, the convenience of pressing Return to confirm the deliberately chosen Empty Trash action outweighs the benefit of reaffirming that the button is destructive. In contrast, people appreciate an alert that draws their attention to a button that can perform a destructive action they didn’t originally intend.

In simple words: If the user already chose a destructive action (for example, pressed a red “Sign Out” button in a list), the confirmation button in the alert does not need to be red again. It can be blue, because the user already made a conscious choice.

But if the alert is warning about a destructive action that the user did not choose directly, the destructive button should be red to draw attention. This subtle distinction helps prevent accidental data loss while keeping the interface clean.

If I understand HIG correctly, in these scenarios the button should be blue. Always consider the user’s intent and the context of the action when choosing button styles.

The Cancel Button is Bold?

You may have noticed that the “Cancel” button above is bold. Apple made this change in iOS 8.3. HIG recommends making the “Cancel” button the bold button in an alert with a destructive action. This makes the safe option more visible and reduces the risk of accidentally choosing the destructive action.

However, it’s worth noting that even in Apple’s own examples (again), the Cancel button is not always bolded. This inconsistency can be confusing, and it shows that even Apple sometimes deviates from its own guidelines.

Sometimes (I hope never), you may want to do the opposite — not just remove the bold emphasis from “Cancel”, but actually make the destructive button stand out even more. For example, if you want to draw extra attention to a destructive action, you can use .keyboardShortcut(.defaultAction) on the destructive button.

Button("Delete Reminder", role: .destructive) {}
    .keyboardShortcut(.defaultAction)

Button("Cancel", role: .cancel) {}

This will make the destructive button bold, increasing its prominence in the alert. Cancel button will not be bold anymore:

‼️ Use this carefully, as making the destructive action more noticeable can increase the risk of accidental data loss.

But What Does Default Action Mean?

As the name suggests, you can trigger the action using a keyboard shortcut. defaultAction means this is the default button in your OS. Since SwiftUI works on different platforms, the system will decide what this means. On iOS, keyboard shortcuts are not very useful, unless you use an iPad with a keyboard. It can also be helpful for developers to use the keyboard in the simulator.

By default, the system treats destructive buttons as default actions in alerts with two buttons, so you usually don’t need to add .keyboardShortcut(.defaultAction) explicitly:

However, in alerts with three or more buttons (one of which is destructive), no button is set as the default. In such cases, you can assign .keyboardShortcut(.defaultAction), this approach encourages users to pay closer attention before making a choice.

If you want to encourage people to read an alert and not just automatically press ↩ to dismiss it, avoid making any button the default button.

Button("Delete", role: .destructive) {}
    .keyboardShortcut(.defaultAction)
Button("Cancel", role: .cancel) {}
Button("Info") {}

In alerts with a single button — regardless of its role — pressing the default key (↩) will dismiss the alert and trigger that button’s action:

alert {
    Button("OK") {} // default action
}

alert {
    Button("Delete", role: .destructive) {} // default action
}

alert {
    Button("Cancel", role: .cancel) {} // default action
}

In the context of alert example, this modifier also makes the button text bold. This visual cue helps users quickly identify the primary action, but use it thoughtfully to avoid confusion.

Conclusion

• Always use the correct component: Alert for unexpected warnings, ActionSheet for intentional choices.
• Assign proper roles to buttons (.cancel, .destructive) and let the system handle their order and style.
• Destructive buttons do not always need to be red — consider the user’s intent.
• Follow the Human Interface Guidelines, but remember that even Apple sometimes makes exceptions — strive for clarity and user safety in your own apps.

By paying attention to these details, you can create alerts that are not only functional but also intuitive and safe for your users. Thoughtful design and thorough testing will help your app stand out and provide a better experience for everyone.

References

• Apple Human Interface Guidelines: Alerts
• SwiftUI .alert documentation

Many of us have encountered loader indicators in our work, making it a familiar starting point. We’ll begin with the most basic component and progressively enhance its flexibility.

Imagine a basic circle that fills up as the progress increases. This is our starting point:

struct LoaderView: View {

    let progress: Double
    @State private var degree: Double = 0

    var body: some View {
        Circle()
            .trim(from: 0.0, to: progress)
            .stroke(Color.red, style: StrokeStyle(lineWidth: 8.0, lineCap: .round))
            .rotationEffect(.degrees(degree))
            .animation(Animation.linear(duration: 1).repeatForever(autoreverses: false), value: degree)
            .onAppear {
                degree = 360
            }
            .frame(width: 80, height: 80)
    }
}

It spins and spins all the time, nothing more.

Progress color

Let’s start the improvements by making the progress color adjustable. Initially, you might consider passing a tint color directly into the initializer:

LoaderView(progress: 0.6, tintColor: .purple)

However, having numerous configuration parameters can get messy eventually, so I’d suggest to use a more SwiftUI approach - using the tint modifier:

LoaderView(progress: 0.6)
    .tint(.purple)

If you are used to using environments, you may want to consider using @Environment(\.tint).
But the problem it doesn’t exist (technically it’s internal), so we can’t access it directly.

struct LoaderView_Env: View {
    // Error: 'tint' is inaccessible due to 'internal' protection level
    @Environment(\.tint) var tint
}

By looking at the stroke signature we can see it accepts ShapeStyle protocol as a first argument, not a specific color as we might though:

func stroke<S>(_ content: S, style: StrokeStyle, antialiased: Bool) -> ... where S : ShapeStyle

The nice thing for us is that SwiftUI provides TintShapeStyle that conforms that protocol and has an underlying access to the passed tint color. Thus, we don’t need an environment at all, just pass .tint as an argument:

.stroke(.tint, style: StrokeStyle(lineWidth: 8.0, lineCap: .round))

NOTE: the similar approach can be achieved for .foreground by using ForegroundStyle.

Loader size

Now the color is configured, let’s make the loader view flexible in size.

With the current implementation it has a fixed size 80x80. To adjust this, we set the ideal size - similar to intrinsicContentSize in UIKit:

Circle()
    ...
    .frame(idealWidth: 80, idealHeight: 80)

By default our loader grows as long as a parent allows, but if we want to have a default size - we apply fixedSize modifier:

struct ContentView: View {
    var body: some View {
        HStack(spacing: 20) {
            LoaderView(progress: 0.6)
                .fixedSize()

            LoaderView(progress: 0.6)
        }
    }
}

You can experiment with the Color the same way - it expands as much as possible and the fixedSize makes tiny.

If you’re not familiar with these modifiers, I’d recommend to read this article about SwiftUI Layout.

So far so good:

struct LoaderView: View {

    let progress: Double
    @State private var degree: Double = 0

    var body: some View {
        Circle()
            .trim(from: 0.0, to: progress)
            .stroke(.tint, style: StrokeStyle(lineWidth: 8.0, lineCap: .round))
            .rotationEffect(.degrees(degree))
            .animation(Animation.linear(duration: 1).repeatForever(autoreverses: false), value: degree)
            .onAppear {
                degree = 360
            }
            .frame(idealWidth: 80, idealHeight: 80)
    }
}

Styling

It’s time to add different styling options - for simplicity, we’ll consider two variants:

• Primary (80x80 size, purple progress color, and progress value inside)
• Secondary (40x40, pink, without any progress text)

In a simple scenario you’d just pass a style directly to an initializer:

LoaderView(style: .primary)

and applied different configurations for each style by having many switch and if conditions. Probably in most cases it’s not a big deal and doesn’t look messy, but sometimes it complicates the code a lot that it’s better to use the approach SwiftUI uses a lot (style protocol).

First step is creating a LoaderStyle and LoaderStyleConfiguration. Different styles should implement this protocol and use the provided values by configuration:

protocol LoaderStyle: DynamicProperty {
    typealias Configuration = LoaderStyleConfiguration
    associatedtype Body: View

    @ViewBuilder func makeBody(configuration: Configuration) -> Body
}

It’s up to you how many information your configuration’s needed. For simplicity the progress and the loader bar will be enough for us:

struct LoaderStyleConfiguration {
    struct Indicator: View {
        public let body: AnyView
    }

    let progress: Double
    let loadingIndicator: Indicator

    init(progress: Double, @ViewBuilder loadingIndicator: @escaping () -> some View) {
        self.progress = progress
        self.loadingIndicator = Indicator(body: AnyView(loadingIndicator()))
    }
}

Then we need to define a custom EnvironmentKey with the default primary option for passing a needed style to our component:

struct LoaderStyleEnvironmentKey: EnvironmentKey {
    static var defaultValue: any LoaderStyle = PrimaryLoaderStyle()
}

extension EnvironmentValues {
    var loaderStyle: any LoaderStyle {
        get { self[LoaderStyleEnvironmentKey.self] }
        set { self[LoaderStyleEnvironmentKey.self] = newValue }
    }
}

extension View {
    func loaderStyle(_ style: any LoaderStyle) -> some View {
        environment(\.loaderStyle, style)
    }
}

Finally, two implementations of our styles:

struct PrimaryLoaderStyle: LoaderStyle {
    func makeBody(configuration: Configuration) -> some View {
        configuration.loadingIndicator
            .tint(Color.purple)                        
            .frame(width: 80, height: 80)
            .overlay {
                Text(String(Int(configuration.progress * 100)) + "%")
                    .font(.subheadline)
                    .foregroundStyle(Color.secondary)
            }
    }
}

struct SecondaryLoaderStyle: LoaderStyle {
    func makeBody(configuration: Configuration) -> some View {
        configuration.loadingIndicator
            .tint(Color.red)
            .frame(width: 40, height: 40)
    }
}

I also highly recommend to add some readability improvements by adding convenience getters for our styles:

extension LoaderStyle where Self == PrimaryLoaderStyle {
    static var primary: Self {
        PrimaryLoaderStyle()
    }
}

extension LoaderStyle where Self == SecondaryLoaderStyle {
    static var secondary: Self {
        SecondaryLoaderStyle()
    }
}

To make it all works we need to adjust our main component as well. Create a configuration with a progress and loading indicator and pass it to the loader style:

struct LoaderView: View {

    let progress: Double

    @State private var degree: Double = 0
    @Environment(\.loaderStyle) private var loaderStyle

    var body: some View {
        let configuration = LoaderStyleConfiguration(
            progress: progress,
            loadingIndicator: {
                Circle()
                    .trim(from: 0.0, to: progress)
                    .stroke(.tint, style: StrokeStyle(lineWidth: 8.0, lineCap: .round))
                    .rotationEffect(.degrees(degree))
                    .animation(Animation.linear(duration: 1).repeatForever(autoreverses: false), value: degree)
                    .frame(idealWidth: 80, idealHeight: 80)
                    .onAppear {
                        degree = 360
                    }
            }
        )
        let resolvedView = loaderStyle.makeBody(configuration: configuration)
        AnyView(resolvedView)
    }
}

For a more detailed guide into custom view styles I recommend to read this article.

Finally we can use it as follows:

VStack(spacing: 40) {
    LoaderView(progress: 0.6)
        .loaderStyle(.secondary)
    
    LoaderView(progress: 0.6)
        .loaderStyle(.primary)
}

Sure, you don’t have to stick to all the rules for every single component. So, just use this know-how wisely and don’t make your code more complicated than it needs to be. 😉

enum Visa {
    case tourist
    case business
    case student
}

However, considering the possibility of new visa types being introduced in the future, we need a fallback a case that can accommodate any unrecognized visa types. This is where the other case comes into play:

enum Visa {
    // ...
    case other(String)
}

Now, here comes the problem: how do we store this enum in a persistence storage solution like Core Data? Unfortunately, Core Data doesn’t provide built-in support for enums with associated values. One approach that comes to mind is making the Visa enum conform to RawRepresentable and save an underlying value. However, since enums with associated values don’t offer a default implementation for RawRepresentable, we need to manually implement it ourselves:

enum Visa: RawRepresentable {
    var rawValue: String {
        switch self {
        case .tourist:
            return "tourist"
        case .business:
            return "business"
        case .student:
            return "student"
        case .other(let value):
            return value
        }
    }

    init?(rawValue: String) {
        switch rawValue {
        case "tourist":
            self = .tourist
        case "business":
            self = .business
        case "student":
            self = .student
        default:
            self = .other(rawValue)
        }
    }
}

With this implementation, we can now store and retrieve visa types seamlessly using Core Data or any other persistence storage mechanism.

We all know developers are clever at finding shortcuts. But what happens when we need to duplicate the same logic for different types? That’s why Swift has introduced a feature called Macros. It automates the whole process, saving us lazy developers tons of time and effort. If you’re not familiar with Macros, I suggest checking out this WWDC session or this introduction article by Antoine before diving into the rest of this article.

Today we’ll discuss the attached macros:

Attached macros provide a way to extend Swift by creating and extending declarations based on arbitrary syntactic transformations on their arguments. They make it possible to extend Swift in ways that were only previously possible by introducing new language features, helping developers build more expressive libraries and eliminate extraneous boilerplate.

Before we dive into the implementation details, let’s start by adding the Macro itself:

public enum StringRepresentationMacro {}

With that in place, we can move on to the first step, which is adding protocol conformance to our type. To accomplish this, we’ll utilize the ConformanceMacro protocol. This protocol describes a macro that can add conformance to the declaration it’s attached to.

In the following code snippet, we’ll use the expansion function to add the RawRepresentable conformance to our type. We keep it simple and only specify a single conformance to RawRepresentable, omitting any additional constraints (where clause) by returning nil.

extension StringRepresentationMacro: ConformanceMacro {
    static func expansion<Declaration, Context>(...) throws -> [(TypeSyntax, GenericWhereClauseSyntax?)] where (...) {
        return [
            (TypeSyntax("RawRepresentable"), nil)
        ]
    }
}

To make our macro accessible, we need to add the @attached(conformance) attribute to the public declaration:

@attached(conformance)
public macro StringRawRepresentation() = #externalMacro(module: "MyMacros", type: "StringRepresentationMacro")

If we try to expand our Macro in Xcode using Expand Macro option we’ll see the following generated code:

extension Visa : RawRepresentable  {}

Now that we’ve added the conformance, the next step is to implement the RawRepresentable protocol itself. To achieve this, we’ll utilize the MemberMacro protocol, which defines new members for the declaration it’s attached to. Similar to the ConformanceMacro, there’s a single function for implementing:

extension StringRepresentationMacro: MemberMacro {
    public static func expansion<Declaration, Context>(of node: AttributeSyntax,
                                                       providingMembersOf declaration: Declaration,
                                                       in context: Context) throws -> [DeclSyntax]
    where Declaration : DeclGroupSyntax, Context : MacroExpansionContext {
        ...
    }
}

First, we must ensure that the type we’re adding the macro to is an enum. If it’s not, we need to throw an error about the unsupported declaration:

enum MacroError: Error, CustomStringConvertible {
    case message(String)

    var description: String {
        switch self {
        case .message(let text):
            return text
        }
    }
}

guard let enumDeclaration = declaration.as(EnumDeclSyntax.self) else {    
    throw MacroError.message("@StringRawRepresentation only works with Enums")
}

Next, we obtain all the enum cases to iterate through:

let cases = enumDeclaration.memberBlock.members
    .compactMap {
        $0.decl.as(EnumCaseDeclSyntax.self)
    }
    .flatMap {
        $0.elements
    }

To generate an initializer conformance, we need to iterate through each case, and add a mapping to a string representation. To keep things simple for this article, we’ll assume that there’s only a single case with a String associated type. However, it’s important to note that you can customize and handle different edge cases and present a validation error for a developer as we did before:

let initializer = try InitializerDeclSyntax("init?(rawValue: String)") {
    try SwitchExprSyntax("switch rawValue") {
        for element in cases {
            if element.associatedValue == nil {
                SwitchCaseSyntax(
                    """
                    case "\(element.identifier)":
                        self = .\(element.identifier)
                    """
                )
            } else {
                SwitchCaseSyntax(
                    """
                    default:
                        self = .\(element.identifier)(rawValue)
                    """
                )
            }
        }

    }
}

Using the similar techniques we’ll generate a variable conformance:

let variable = try VariableDeclSyntax("var rawValue: String") {
    try SwitchExprSyntax("switch self") {
        for element in cases {
            if element.associatedValue == nil {
                SwitchCaseSyntax(
                """
                case .\(element.identifier):
                    return "\(element.identifier)"
                """
                )
            } else {
                SwitchCaseSyntax(
                    """
                    case .\(element.identifier)(let value):
                        return value
                    """
                )
            }
        }
    }
}

Lastly, we can simply return these two declarations:

return [
    DeclSyntax(variable),
    DeclSyntax(initializer)
]

and add a second attached attribute:

@attached(member, names: named(rawValue), named(init))
@attached(conformance)
public macro StringRawRepresentation() = #externalMacro(module: "MyMacros", type: "StringRepresentationMacro")

That’s it! Take a moment to appreciate the beauty of this code:

@StringRawRepresentation
enum Visa {
    case tourist
    case business
    case student
    case other(String)
}

With the implementation of attached macros, all the tedious work is now handled seamlessly under the hood. As developers, we can truly appreciate the time and effort saved by leveraging these powerful features of Swift. Our code is now more elegant, concise, and maintainable, allowing us to focus on the core logic of our applications.

References

• Write Swift Macros, WWDC23
• Swift Macros: Extend Swift with New Kinds of Expressions
• Proposal: Attached Macros
• Awesome Swift Macros

In short, UIResponder is an abstract interface for responding and handling events. All known UIView, UIViewController, UIWindow, UIApplication and UIApplicationDelegate are UIResponders.

For touch events the system uses hit-testing to determine where touch events occur. Specifically, UIKit compares the touch location to the bounds of view objects in the view hierarchy. The hitTest method of UIView traverses the view hierarchy, looking for the deepest subview that contains the specified touch, which becomes the first responder for the touch event. Then the system creates a UITouchEvent object, associates it with a view and dispatch the event to the system event queue by calling UIApplication.sendEvent.

For a clear demonstration we’ll use a simple screen with two coloured views. By tapping on one of them we’ll explore the whole process of touching.

The investigation starts with tapping the screen, so let’s do that. As I mentioned earlier, the system uses hit-testing approach to determine who owns the touch. Thereby, by checking the stack trace of the starting point, we can see that system initiates a touch-test on the window layer, by enumerating each of them.

For every window we enumerate on we should find a deepest subview that contains (or not) the specified touch. Having the approximate implementation of hitTest following the documentation

func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {	
    guard isUserInteractionEnabled, !isHidden, alpha >= 0.01, point(inside: point, with: event) else { 
        return nil 
    }        	

    // First, checks the subviews with the highest Z-coordinate value. 
    for subview in subviews.reversed() {
        let convertedPoint = subview.convert(point, from: self)
        if let view = subview.hitTest(convertedPoint, with: event) {
            return view
        }
    }
    return self
}

we can see the iterating process over every subview to find the needed one:

Note. In some cases the hitTest maybe called twice - the system may tweak the point being hit tested between the calls. Since hitTest should be a pure function with no side-effects, this should be fine.

The first responder is found (green view), the next step is to detect a window to which the view is attached for. The system detects the view’s _responderWindow right before sending a touch event using UIApplication.sendEvent.

UIResponder chain comes here to the rescue. Starting with the green view, we’ll iterate through the responders up to the UIWindow using the next property.

ChildView -> RootView -> ViewController -> UIDropShadowView -> UITransitionView -> UIWindow

Having the window and first responder view, the system is ready to send an event:

SENT EVENT: 

<UITouchesEvent: 0x600002108180> 
timestamp: 37554.7 
touches: {(
    <UITouch: 0x7fe8ebb0be20> 
    phase: Began 
    tap count: 1 
    force: 0.000 
    window: (UIWindow (0.0, 0.0, 390.0, 844.0)) 
    view: (ChildView (150.0, 300.0, 80.0, 80.0)) 
    location in window: {188.33332824707031, 361} 
    previous location in window: {188.33332824707031, 361} 
    location in view: {38.333328247070312, 61} 
    previous location in view: {38.333328247070312, 61}
)}

later on the following method will be called in ChildView:

func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?)

Note. The hit-test view is linked with the UITouch object for all phases of the touch event (began, moved, ended and canceled). The system won’t start the hit-testing logic for further events again. It’ll take the associated view and send the events right in.

References

• Using Responders and the Responder Chain to Handle Events
• Hacking Hit Tests
• Increasing the tap area of a UIButton

As an idol we’ll use the ForEach from the SwiftUI library with the same protocol conformance for our own version.

public struct ForEach<Data, ID, Content> where Data : RandomAccessCollection, ID : Hashable {

    /// The collection of underlying identified data that SwiftUI uses to create
    /// views dynamically.
    public var data: Data

    /// A function to create content on demand using the underlying data.
    public var content: (Data.Element) -> Content
}

The first implementation is the following:

struct ForEachEnumerated<Data, Content>: View where Data: RandomAccessCollection, Data.Element: Hashable, Content: View {

    var data: Data
    var content: (Int, Data.Element) -> Content

    var body: some View {
        ForEach(Array(data.enumerated()), id: \.element) { index, element in
            content(index, element)
        }
    }
}

It does the desired behavior, but there’s something we need to be aware of.

When you enumerate a collection, the integer part of each pair is a counter for the enumeration, but is not necessarily the index of the paired value. These counters can be used as indices only in instances of zero-based, integer-indexed collections, such as Array and ContiguousArray. For other collections the counters may be out of range or of the wrong type to use as an index. To iterate over the elements of a collection with its indices, use the zip(::) function. (documentation)

• This version is only suitable for integer-indexed collections
• Furthermore, it can lead us to an out of range crash. Consider this example, it leads to crashing an app, since the index is not zero-based:

let array = [0, 1, 2, 3, 4]
let newArray = array[2...3]

// newArray[0] // -> CRASH
// newArray.indices // -> [2..<4]

With the above in mind, we should modify our version. Now the index type is the same as Data’s one and indices are not zero-based anymore.

struct ForEachEnumerated<Data, Content>: View where Data: RandomAccessCollection, Data.Element: Hashable, Content: View {

    var data: Data
    var content: (Data.Index, Data.Element) -> Content

    var body: some View {
        ForEach(Array(zip(data.indices, data)), id: \.1) { index, element in
            content(index, element)
        }
    }
}

It already looks as a production-ready, however there’s something that would be great to improve. What about this code id: \.1? This restricts Data.Element to be Hashable and what if I don’t want to use the entire object as a identifier?

To achieve this goal, we’ll add another property for storing a keypath and a small structure (Info) for enumerating using id.

struct ForEachEnumerated<Data, ID, Content>: View where Data: RandomAccessCollection, ID: Hashable, Content: View {

    // For the simplicity of type reading
    typealias Index = Data.Index
    typealias Element = Data.Element

    private struct Info {
        let index: Index
        let id: KeyPath<Element, ID>
        let element: Element

        var elementID: ID {
            element[keyPath: id]
        }
    }

    var data: Data
    var content: (Index, Element) -> Content
    let id: KeyPath<Element, ID>

    var body: some View {
        let enumeratedData = zip(data.indices, data).map { index, element in
            Info(index: index, id: id, element: element)
        }

        ForEach(enumeratedData, id: \.elementID) { indexInfo in
            content(indexInfo.index, indexInfo.element)
        }
    }
}

Following the rules of our idol, let’s extend our type with a handy initializer that’s really useful for Identifiable data objects:

extension ForEachEnumerated where Element: Identifiable, ID == Element.ID {
    init(_ data: Data, @ViewBuilder content: @escaping (Index, Element) -> Content) {
        self.init(data, content: content, id: \.id)
    }
}

In conclusion, a small example that demonstrates how it looks:

struct Article {
    let title: String
    let author: String
}

struct ArticlesView: View {
    let articles: [Article]

    var body: some View {
        List {
            ForEachEnumerated(articles, id: \.title) { index, article in
                HStack {
                    Text("\(index)" + article.title)
                    Text(article.author)
                }
            }
        }
    }
}

TextField("Multiline textfield", text: $text, axis: .vertical)

This argument controls the scroll direction when the text is large than the text field bounds. Using the vertical value we get a new-modern multiline text field, but by specifying the horizontal one we return to the behaviour we are all already get used to.

See how smooth it works. This text field is not only multiline now, but it automatically expands and shrinks itself on content changes. If endlessly expanded content is not what you expect to see, old lineLimit with new handy friends are for rescue!

Using this modifier a text field grows until it exceeds the limited number of lines. There’re a few ways to specify how many visible text lines you need. Using the old one you only configure the maximum number of lines that text can occupy in this view.

// iOS 13+

TextField("Multiline textfield", text: $text, axis: .vertical)
    .lineLimit(2)

Starting with iOS 16 there’re a few more with the configuration of a minimum and maximum number of lines as well.

// iOS 16+

TextField("Multiline textfield", text: $text, axis: .vertical)
    .lineLimit(...2) // It's identical to usual `lineLimit(2)`
    .lineLimit(2...) // min=2, max=Int.max
 
TextField("Multiline textfield", text: $text, axis: .vertical)
    .lineLimit(2...3) // min=2, max=3
 
TextField("Multiline textfield", text: $text, axis: .vertical)
    .lineLimit(2, reservesSpace: true)  // = `lineLimit(2...2)`
    .lineLimit(2, reservesSpace: false) // = `lineLimit(2)`

Although all these features sound cool, need to remember about iOS 16. So create yourself a reminder about this feature in a few years :)

Recently, I’ve had a wish to erase a type of my Subject outside of a class definition. To be clear what I mean I prepared a small class that observes the battery level of my bluetooth device and emits new values on time.

class BatteryObserver {

    let batterySubject = ReplaySubject<Int>.create(bufferSize: 1)

    func loadBatteryLevelEveryNSeconds() {
        // battery level is 55 now - emit this value
        batterySubject.onNext(55)
    }
}

I use ReplaySubject in my example, and it’d be great to erase this type (convert to Observable) for the outside definition. I don’t want to bother that someone else could send a battery level by mistake, who knows… Only this class is responsible for emitting new values.

Roger! One more property with the erased type for help:

class BatteryObserver {

    var batteryObservable: Observable<Int> {
        return batterySubject.asObservable()
    }

    private let batterySubject = ReplaySubject<Int>.create(bufferSize: 1)
}

Looks solid, does it? I’ve always done this before, but this time I decided to over-engineering a bit - I really tired of this approach by creating two properties every time.

Taking advantage of the relatively new feature - property wrappers, I incapsulated the subject type only for in-class use.

@propertyWrapper
struct SubjectEraser<Subject>: ObserverType where Subject: SubjectType {

    typealias Element = Subject.Observer.Element

    var wrappedValue: Observable<Subject.Element> {
        return subject.asObservable()
    }

    private let subject: Subject

    init(subject: Subject) {
        self.subject = subject
    }

    func on(_ event: Event<Element>) {
        subject.asObserver().on(event)
    }
}

class BatteryObserver {

    @SubjectEraser(subject: ReplaySubject<Int>.create(bufferSize: 1))
    var batteryObservable

    func loadBatteryLevelEveryNSeconds() {
        // ...
        // battery level is 55 now - emit this value
        _batteryObservable.onNext(55)
    }
}

With this solution we have a wrappedValue for outside use - the type is erased and using underscore for getting a property wrapper itself we send values for handling further.

The first step of my investigation was turning on verbose logging. Thereby Xcode’s console started to spam plenty of messages. Yep, it became a mess by far. And since my goal was finding a “key” inside this galaxy of logs, I became clicking the tiny icon “trash” on every lap of my investigation steps to start looking again. On the 25th lap, I opened the StackOverflow trying to find a programmable way to clear the console - without success. On that note, I took off the detective hat to find a way to simplifying the debug workflow a bit.

The first thought that visited me - my old friend Apple Script. So I wrote a script in minutes:

activate application "Xcode"

tell application "System Events" to tell process "Xcode"
	click menu item "Clear Console" of menu 1 of menu item "Debug Workflow" of menu 1 of menu bar item "Debug" of menu bar 1
end tell

The longest line of this code just invokes the “Clear Console” command from the Xcode’s menu: Debug > Debug Workflow > Clear Console.

Of course, it does look nicer using a shortcut invocation from the script, but I think it’s less safe.

keystroke "K" using {command down}

Now that we have the worked script, need to find a way to invoke it right from Xcode. The handy thing you may not have heard, it’s the ability to invoke an apple script right from a breakpoint: (Right-click on any breakpoint) > Edit breakpoint > Add Action > Chouse ‘Apple Script’ from dropdown > (paste our script):

At this step, I could get back to the initial problem, but the current solution doesn’t look elegant as could be. What if I decide to repeat this code for another breakpoint? You know for sure that developers are lazy people, so we don’t like to repeat code and maintain its consistency across many places in our codebase. Thus I went further!

Ideally is to have a simple LLDB command - clear for instance. From my experience, a developer is able to write a LLDB command on his own. So if you haven’t heard about this feature I recommend to read this simple article that covers the basics.

Steps:

• At first check the existence of the ~/.lldbinit file (create if doesn’t exist). It’s the file that LLDB looks for and loads each time a new session is started.
• Then we need to import our further Python script that clears the Xcode’s console. Paste this code inside the .lldbinit file:

command script import ~/.lldb/otbivnoe.py # you can choose any directory for your script

• Final part is finally to write the magic script:

#!/usr/bin/env python

from subprocess import Popen, PIPE

def clearXcodeConsole(debugger, command, result, internal_dict):
  applescript='''
    activate application "Xcode"
    tell application "System Events" to tell process "Xcode"
      click menu item "Clear Console" of menu 1 of menu item "Debug Workflow" of menu 1 of menu bar item "Debug" of menu bar 1
    end tell
  '''

  p = Popen(['osascript', '-'], stdin=PIPE, stdout=PIPE, stderr=PIPE, universal_newlines=True)
  stdout, stderr = p.communicate(applescript)

def __lldb_init_module(debugger, internal_dict):	
  debugger.HandleCommand('command script add -f otbivnoe.clearXcodeConsole clear')

Be aware I have the following version of python. Maybe you need to tune this script a bit by yourself.

3.8.2 (default, Dec 21 2020, 15:06:04)
[Clang 12.0.0 (clang-1200.0.32.29)]

• Restart your LLDB debugging session or just reload the current one:

command source ~/.lldbinit

That’s It! Now you’re able to write a simple command clear to flush the console. And I go back to detective duties :)

Additional Recourses:

• Chisel - a ton of useful LLDB commands by Facebook
• Lowmad - a command line tool for managing scripts and configurations in LLDB.

I would happy to hear a better way or even a native way of clearing a console if it exists. So let me know if you know anything about it.

If you haven’t heard about Property Wrappers so far, I recommend reading this article first.

@propertyWrapper
struct UserDefault<Value> {

    private let key: String
    private let defaultValue: Value
    private let storage: UserDefaults

    var wrappedValue: Value {
        get {
            return storage.object(forKey: key) as? Value ?? defaultValue
        }
        set {
            storage.set(newValue, forKey: key)
        }
    }

    init(defaultValue: Value, key: String, storage: UserDefaults = .standard) {
        self.defaultValue = defaultValue
        self.key = key
        self.storage = storage
    }
}

class Onboarding {

    @UserDefault(defaultValue: false, key: "isOnboardingCompleted")
    var isOnboardingCompleted: Bool
}

Done, looks as simple as possible. The second step is to cover this code by tests. In order to run tests safely - to have stable tests, I decided to pass different domains of User Defaults. So the first code I wrote was the following one:

class Onboarding {

    @UserDefault(defaultValue: false, key: "isOnboardingCompleted", storage: storage)
    var isOnboardingCompleted: Bool

    private let storage: UserDefaults

    init(storage: UserDefaults) {
        self.storage = storage
    }
}

Obviously it didn’t work. The red error was flashing to my eyes:

Cannot use instance member 'storage' within property initializer; property initializers run before 'self' is available

After that I used to try a few approaches to solve this issue without luck until I remembered one important thing: using an underscore within a class allowing to access a property wrapper class itself rather than a general property.

The final solution:

class Onboarding {

    @UserDefault
    var isOnboardingCompleted: Bool

    init(storage: UserDefaults) {
        _isOnboardingCompleted = UserDefault(defaultValue: false, key: "isOnboardingCompleted", storage: storage)
    }
}

This article doesn’t look like a long step-by-step tutorial, it’s just a quick tip for a problem I faced recently. So I decided to share a non-obvious solution for me, maybe it will save some time for someone. Let me know if the article was useful to you :)

Today I’m going to talk about another approach - using layout margins! We will configure a particular inset value for a root view only and then pin all subviews to this guide.

If you haven’t heard about layout margins in-depth before, I highly recommend this detailed article before reading further.

If we can agree, that 16pt is a lot for our app as a horizontal margin, then perpahs 10pt is a great value that we’re going to work with.

Our first step is disabling viewRespectsSystemMinimumLayoutMargins since 10pt is less than 16pt (the default system margin).

viewRespectsSystemMinimumLayoutMargins = false

When the value of this property is true (default), the root view’s layout margins are guaranteed to be no smaller than the values in the systemMinimumLayoutMargins property. Changing this property to false causes the view to obtain its margins solely from its directionalLayoutMargins property. Setting the margins in that property to 0 allows you to eliminate the view’s margins altogether.

Then we configure directionalLayoutMargins to correct and obtain our margin values:

view.directionalLayoutMargins = .init(top: 0, leading: 10, bottom: 0, trailing: 10)

I’ve prepared two screenshots to better understand the differences between these options:

Go over to the second step - configuring a table view. Since the table view has its own margins, it is necessary to preserve the root view’s margins. We need to set these properties:

tableView.preservesSuperviewLayoutMargins = true
tableView.directionalLayoutMargins = .zero

When the value of this property is true, the superview’s margins are also considered when laying out content. This margin affects layouts where the distance between the edge of a view and its superview is smaller than the corresponding margin. For example, you might have a content view whose frame precisely matches the bounds of its superview. When any of the superview’s margins is inside the area represented by the content view and its own margins, UIKit adjusts the content view’s layout to respect the superview’s margins. The amount of the adjustment is the smallest amount needed to ensure that content is also inside the superview’s margins.

The last step you need is to configure layout in conformity with cell’s margins:

label.leadingAnchor.constraint(equalTo: contentView.layoutMarginsGuide.leadingAnchor).isActive = true

That’s it! Now you only need to change the layout margins of the root’s view and all subviews will be in sync automatically in the case of correct configuration of course! I also prepared a demo project for fast cloning and playing at your side. Your welcome!

It is important to mention the layout margins approach is applicable for UIStackView and UICollectionView as well! For stack view, there’s a isLayoutMarginsRelativeArrangement for help with useful article and in a collection view, this can be achieved by adjusting section insets or using the similar way as described in the article.

I hope it was worth reading for you and you will consider this approach when you start coding a new screen :)