Why it matters

Our app’s launch is our user’s first experience with our app, and as such it should be delightful. It is also important to test on older devices, to make sure the experience holds up across a broad set of users with different device capabilities. A launch that feels fast on the latest hardware can feel sluggish on a device that is a few years old.

Launch types

There are three kinds of launch, and they differ by how much of our app is already resident in memory.

• Cold:
  • Happens after a reboot.
  • The app is not in memory.
  • No process exists. Basically, the app was not launched in a very long time.
• Warm: after a cold launch has happened, every kill and relaunch of the app is a warm launch.
  • The app was recently terminated.
  • The app is partially in memory.
  • No process exists.
• Resume: this is when the app is in the background and the user re-enters it from the home screen or the app switcher.
  • The app is suspended.
  • The app is fully in memory.
  • The process exists.

The 400ms target

Apple says that to achieve a responsive cold launch, we should aim for roughly 400ms to render the first frame. That way we have pixels displayed to the user during the launch animation, and by the time that launch animation completes, the app is interactive and responsive.

I believe that is a very optimistic case, and it depends on the size of the app and other factors. But of course we can still find ways to reduce app launch time and aim for the lowest possible value.

To reduce app launch time, it is important to understand what happens during launch.

Launch generally starts when the user taps our icon on the home screen. Then, over the next 100 or so milliseconds, iOS does the necessary system-side work to initialize our app. That leaves us developers about 300 milliseconds to create our views, load our content, and generate the first frame.

The phases of an app launch

The launch flows through these phases:

1. System Interface

DYLD, the dynamic linker, loads our shared libraries and frameworks. For an in-depth analysis, watch this presentation: A tale of dyld, and how iOS launches your app.

This is a section we can hardly influence, because it is system work. But we can influence it by avoiding dynamic library loading so we can make use of dyld3, which caches runtime dependencies and warm launches, which improves app launch performance.

2. Runtime Init

This is when the system initializes the Objective-C and Swift runtimes.

We cannot do much here either, except avoid static initializations and frameworks that use static initialization. But if we must use static initialization, we should consider moving code out of class load, which is invoked every time during launch, into class initialize, which is lazily invoked the first time we use a method within our class.

3. UIKit Init

This is when the system instantiates our UIApplication and our UIApplicationDelegate. For the most part, this is system-side work: setting up event processing and integration with the system. But we can still affect this phase if we subclass UIApplication or do any work in UIApplicationDelegate initializers.

4. Application Init

This is where we can have the most impact on our app launch time. Nowadays everyone is using UIScenes, so it is important to create our view controllers only in scene(_:willConnectTo:options:) and not also in application(_:didFinishLaunchingWithOptions:). Doing both leads to a common pitfall that results in performance losses and, likely, unpredictable bugs in our code base.

5. Frame Render

This one is relatively straightforward. This is when we create our views, perform layout, and then draw them: loadView, viewDidLoad, layoutSubviews.

We can affect this phase by reducing the number of views in our hierarchy. We can do that by flattening our views to use fewer of them, or by lazily loading views that are not shown during launch. We should also take a look at our Auto Layout and see if we can reduce the number of constraints we are using.

6. Extended

This is the app-specific period from our first commit until we show our final frame to the user. This is when we load the asynchronous data. Not every app has this phase. During it, the app should be interactive and responsive.

How do we know we need improvements?

How do we know we need to make our app launch faster? We of course need to measure first the app launch under certain conditions and in a certain states. I will leave that topic for another article, because I wanted to keep this one short and concise.

Thanks for reading. If you found it helpful, you can share it with others.

Useful link

• WWDC19 - Optimizing App Launch

This is a case where method swizzling is the right tool.

What swizzling is

Swizzling is a runtime technique from the Objective-C world. Every Objective-C method is just an entry in a method table, a mapping from selector to function pointer. The runtime exposes method_exchangeImplementations, which swaps two entries in that table.

After the swap, calling the original selector runs your replacement function. Calling the replacement selector runs the original function. This is the core trick that makes swizzling work.

In Swift, you can only swizzle methods that are visible to the Objective-C runtime. That means methods on NSObject subclasses, or methods annotated with @objc.

UIResponder is an NSObject subclass, so every method on it, including becomeFirstResponder and resignFirstResponder, is swizzleable.

The strange behaviour

I was investigating some unexpected focus behaviour in an app that embeds a WKWebView. Things were not working as expected: focus was moving in a way that did not match what the code was doing, and I could not tell which part of the hierarchy was actually first responder at any given moment.

The tricky part with WKWebView is that it manages its own internal view hierarchy, including WKContentView, a private WebKit view that actually holds the first responder when the web content is focused. You cannot inspect this easily, and there is no delegate or notification that tells you when it takes or releases focus.

I needed to see the full sequence of responder transitions across the entire app, including those private views.

The swizzle

I added an extension on UIResponder:

extension UIResponder {

    static func swizzleBecomeFirstResponder() {
        let originalBecome = class_getInstanceMethod(UIResponder.self, #selector(becomeFirstResponder))
        let swizzledBecome = class_getInstanceMethod(UIResponder.self, #selector(swizzled_becomeFirstResponder))
        if let original = originalBecome, let swizzled = swizzledBecome {
            method_exchangeImplementations(original, swizzled)
        }
    }

    @objc func swizzled_becomeFirstResponder() -> Bool {
        print("---> becomeFirstResponder: \(type(of: self))")
        return swizzled_becomeFirstResponder()
    }
}

The key detail is the recursive-looking call inside swizzled_becomeFirstResponder. After method_exchangeImplementations runs, the selector swizzled_becomeFirstResponder points to the original becomeFirstResponder implementation. So calling swizzled_becomeFirstResponder() from within the replacement is not infinite recursion. It is the call to the original method. This is the standard swizzling pattern.

I activated it in AppDelegate, before the window is shown:

func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    UIResponder.swizzleBecomeFirstResponder()
    return true
}

I added an equivalent swizzle for resignFirstResponder to get the full picture.

What the output revealed

With the swizzle in place, the console printed every responder transition in order:

---> becomeFirstResponder: RootNavigationController
---> becomeFirstResponder: BrowserWindow
---> becomeFirstResponder: LaunchScreenViewController
---> resignFirstResponder: LocationView
---> resignFirstResponder: LocationView
---> becomeFirstResponder: BrowserViewController
---> becomeFirstResponder: WKContentView

This immediately gave me a complete picture of the hierarchy and the sequence of events, something that would have been impossible to reconstruct from breakpoints alone.

One thing this technique is particularly useful for with WKWebView is confirming whether WKContentView is becoming first responder or not. WKContentView is a private class, so you cannot reference it directly in code or set a targeted breakpoint on it. But because the swizzle is on UIResponder, the base class for the entire responder chain, it catches everything, including private UIKit internals. If WKContentView takes focus, it shows up in the log like any other class.

Without the swizzle, none of this sequence was visible. The log turned an opaque focus problem into a readable timeline.

When to reach for this

Swizzling is not a tool you leave in production code. It changes global behaviour for every instance of a class, in every part of the app, for the lifetime of the process. That is too broad for anything except a debugging session.

The right workflow:

1. Add the swizzle behind a #if DEBUG block, or simply in a debug branch
2. Reproduce the bug and read the log
3. Fix the root cause
4. Remove the swizzle entirely before shipping

There is also a correctness requirement: swizzling must happen exactly once per method. Calling method_exchangeImplementations twice on the same pair restores the original state, effectively a no-op. If you call it from multiple places or inside code that runs more than once, you will get unpredictable results. Using AppDelegate.application(_:didFinishLaunchingWithOptions:) is a safe call site because it runs exactly once.

What to reach for first

Before swizzling, check the cheaper options:

• UIApplication.shared.keyWindow?.perform(#selector(UIResponder.resignFirstResponder)) to manually clear focus
• A recursive walk of the view hierarchy that checks isFirstResponder
• Breakpoint on becomeFirstResponder in Xcode’s symbolic breakpoint list.

Swizzling is the right choice when the problem spans multiple classes, involves a sequence of events, or is too fast to catch with a debugger. For a first responder bug that crosses view controllers and windows, it was the right call.

This article walks through a concrete implementation, explains what happens at the ARC level, and backs every claim with benchmark data.

The problem with heap-heavy structs

Consider a struct with 10 fields, all heap-allocated:

public struct HeavyStruct {
    public var name: String           // heap buffer + ARC
    public var description: String
    public var identifier: String
    public var category: String
    public var tags: [String]         // heap array + ARC retain per element
    public var keywords: [String]
    public var authors: [String]
    public var relatedIDs: [String]
    public var scores: [Int]          // heap array
    public var metadata: [Int]
}

When you copy this struct, Swift retains every reference individually. That’s roughly 10+ ARC retain calls per copy. One for each String, one for each Array buffer.

The retains are cheap individually, but they add up.

What CoW actually does

Copy-on-Write moves all fields into a single class instance (_Storage) and wraps it in the struct. Basically, it is a struct, backed by a class:

public struct HeavyCOWStruct {

    final class Storage {
        var name: String
        var description: String
        var identifier: String
        var category: String
        var tags: [String]
        var keywords: [String]
        var authors: [String]
        var relatedIDs: [String]
        var scores: [Int]
        var metadata: [Int]

        func copy() -> Storage { ... }
    }

    private var _storage: Storage
}

Now copying the struct is 1 ARC retain on _storage, regardless of how many fields it contains. The actual buffer duplication is deferred to the first mutation and only if another owner of the same storage exists:

public var name: String {
    get { _storage.name }
    set {
        // Only allocates if someone else holds a reference to _storage.
        if !isKnownUniquelyReferenced(&_storage) {
            _storage = _storage.copy()
        }
        _storage.name = newValue
    }
}

isKnownUniquelyReferenced is an O(1) check on the ARC reference count. If the count is 1, meaning no other variable holds this storage, the mutation happens in place with zero allocation.

This is about semantics, not struct vs class

The struct still has value semantics. Two variables holding the same HeavyCOWStruct are independent values. Mutating one does not affect the other:

var a = HeavyCOWStruct(name: "Swift", ...)
let b = a                 // b._storage === a._storage — shared, 1 ARC retain
a.name = "Performance"    // new Storage only if b is still alive
// a.name == "Performance", b.name == "Swift"

If you used a plain class instead, b would reflect the mutation. CoW gives you the copy safety of a struct with the copy efficiency of a class, but it is not free. Every mutating property setter pays the isKnownUniquelyReferenced check, and when storage is shared, it pays a full allocation.

The benchmark

To measure the difference, I ran two tests, a copy followed by a mutation on both versions. Each test was run with -c release to get optimized builds.

Results:

CoW was ~27% faster.

The mutation makes the difference clear. The plain struct is fully copied at assignment (all 10 ARC retains), then mutated in place. The CoW struct pays only 1 ARC retain at assignment. The mutation checks isKnownUniquelyReferenced and because original is no longer in use at that point, the reference count is 1, so no Storage.copy() is needed. The mutation happens in place.

CoW wins both steps: cheaper copy, free mutation.

When CoW does not help

CoW is not always the right choice. It adds overhead when:

Mutations are frequent with shared owners. If two variables hold the same CoW struct and you mutate through one of them, Storage.copy() runs a full heap allocation of all fields. This is more expensive than a plain struct mutation.

Fields are small scalars. A struct with Bool, Int, and Float fields has nothing to gain. There are no heap references to consolidate. The struct copies by value directly.

Instances are always freshly constructed. CoW shares storage between copies of the same instance. If every use of the struct calls init, there is never a shared storage to benefit from.

Property access is in a tight loop. Every read goes through _storage.field an extra pointer indirection compared to a plain struct. For a type accessed thousands of times per frame, this adds up.

Advice

Use CoW when a struct has many reference-type fields, is frequently copied, and mutations either don’t happen or happen while the copy is the sole owner. Skip it for small structs, scalar-heavy types, or anything mutated in a tight loop with shared owners.

The data, not the pattern should drive the decision.

Further reading

• CoW in practice: swift-nio-examples: A real-world example from Apple’s SwiftNIO team showing how CoW-backed value types are used in production networking code.
• High-Performance Systems In Swift: Apple engineer, Johannes Weiss from the SwiftNIO team, walks through the performance model for value types, reference types and the gradual steps to a high performant system. Essential context for every decision covered in this article.