I wrote this a while back when I was working at one of the larger social networks. I’ve stripped out all the internal bits, but the core message holds up: memory is a resource worth understanding and using well. The goal was to help teams stop treating it as an afterthought.

This article covers app terminations and the unintended consequences of the code we write. In most cases, there’s a trace that leads directly to the cause. A task is filed, the issue is fixed and we move on; sometimes we even build tools to ensure types of issues don’t happen again. Other cases are more complicated, all we have are breadcrumbs we decided to leave behind. One of these is Foreground Out-of-Memory App Deaths (a.k.a. FOOM or OOM). This note covers how these occur, why you should track what leads to them, and how to do that. The topic: memory.

The persistence of memory issues brings to mind a quote:

“…nothing can be said to be certain, except death and taxes.”

— Benjamin Franklin (and 2 others before him).

Death comes in the simplest form, a SIGKILL signal; you can put it off, but no doubt it’s waiting at the next opportunity. Death keeps a prioritized list of targets, so there are things you can do to stay off its radar.

Taxes are the cost paid to stay up and kicking; trade-offs. This is usually seen by the user as performance regressions, animation hitches, longer loads, UI stalls and more annoyances like that.

Why Should You Care

OOMs make up a significant share of all foreground app deaths. But here’s the thing: OOMs are simply a symptom of extreme memory consumption. They are mostly preventable.

Users can often sense when an app is struggling — slowness creeps in, something feels off. They develop coping habits: force-quitting from the app switcher, avoiding certain flows. You don’t want that. It doesn’t have to be this way.

Limits and Pressure

There are two areas to be mindful of when it comes to memory: limits and pressure. The former is under your complete control and affects both foreground and background execution. The latter not so much, and is much more relevant in the background. Limits revolve around your use of memory through allocations. There are undocumented hard limits, getting too close to them is not recommended. Pressure relates to how other apps handle their limits.

The orchestration between the limits and pressure is what allows the OS to ensure the foreground app will survive as long as possible in order to give users the best experience with their Apple device. It does this by sending memory warning notifications. Apps respond by reducing their memory consumption. If that is not enough, and the OS still needs to reclaim memory in order to keep chugging along, it will start terminating apps.

Dirty, Compressed and Clean

There are 3 important kinds of memory: dirty, compressed and clean.

┌─────────────────────────────────┐
│           Footprint             │
│  ┌───────────────────────────┐  │
│  │                           │  │
│  │          Dirty            │  │
│  │                           │  │
│  ├───────────────────────────┤  │
│  │        Compressed         │  │
│  └───────────────────────────┘  │
└─────────────────────────────────┘
┌─────────────────────────────────┐
│            Clean                │
└─────────────────────────────────┘

Dirty and compressed can be combined into what’s called the app’s memory footprint. These go hand-in-hand. The OS will take dirty memory that has not been used in a while, squeeze it and move it to compressed memory (basically in-memory swap). This will in turn reduce the memory footprint. Apple is on your side and will do its damndest to never intervene in a way that is unfavorable to your app.

Dirty memory is accumulated through allocations and object creation (class instances, large arrays, image buffers, etc.). It is the memory you can control. Dirty memory is what Apple is most interested in when an app is in the foreground and it is what counts towards the memory limit; get close or exceed that limit and the app is terminated, no questions asked. This is how the OS purges dirty memory. These are FOOMs.

Before this termination occurs the OS will notify the app that it’s getting close to the limit by way of memory warnings. It is your duty to ensure that when this occurs you take action. Here are a few simple things you can do:

• Compact caches.
• Clean up strongly referenced objects that can easily be recreated.
• Sometimes you might even take a cue from the warnings and change strategies used for choosing video bitrates, network requests, image sizes and prefetching.

Just as there are go-to things you should do, there are also things that you don’t want to do when a memory warning comes in. Here are a few of them:

• Don’t run code that will have any side-effects. This can include any UI work, dispatching to other queues and/or calling out into functions that might have unknown repercussions.
• Definitely don’t DispatchQueue.async or Task { }. The OS wants action now, not later.
• Never iterate collections (Array, Set, Dictionary, ...) during a memory warning. The OS compresses unused memory—including collection contents. Iterating forces decompression, which increases memory use at the worst possible time.

Clean memory is pretty interesting. It’s basically memory the OS can drop and reload later without consequences. Paging in libraries has a huge effect on clean memory. As soon as you write to that memory (swizzling is one way), that memory is dirtied and it can’t be purged anymore, the best that can be done is compression.

Being a Better Memory Citizen

What can you do to keep your app’s memory footprint hovering in the sweet spot? Here are a few pointers that might help.

• Don’t cheat, let the OS do its thing. Follow its guidance and you’ll be OK. Don’t optimize because you think it’s right — profile first.
• Allocate on the stack as much as possible and keep the stack short. In Swift, prefer value types (struct, enum) when you can.
• If you’re still using C or Objective-C: use const, always use const. It's not magic but will help you write better code down the line.
• Profile often. Apple Instruments is your best friend.
• Use the Xcode Memory Graph. Pause in it once in a while to see what objects are in memory. It will surprise you and you’ll save yourself a lot of grief if you take this simple step.
• Override didReceiveMemoryWarning() on view controllers and/or observe UIApplication.didReceiveMemoryWarningNotification to manage your memory usage when the OS asks you to. Keep it to larger objects and make sure you do it fast.
• Make meticulous use of caching. Use NSCache with objects that conform to NSDiscardableContent for a thread-safe way of keeping heavier, often used objects in memory. NSCache will purge objects when needed, so make sure they're not mission critical or can be recreated.
• Be careful of image size when loading up large images. Use CGImageSource, buffer caching properties and thumbnail creation to keep this under control.
• Track your memory consumption with metrics and dashboards.

Tracking Memory Consumption

When tracking memory consumption, there are two key metrics to consider: Peak Consumption and Product Accumulation.

Peak Consumption is the maximum memory footprint attained throughout the lifetime of a session. It’s best to keep this as low as possible — the higher it goes, the more likely the app will be terminated.

Product Accumulation is the amount of memory footprint left behind by a surface after a user navigates away from it. This includes leaks, but also objects that have a clear strongly held code path but aren’t accessed anymore. This is summed up throughout the session and tells you what surfaces are not cleaning up after themselves. Keep this as low as possible.

Related

• The Case for Another Cache
• Reducing Memory Terminations in iOS Apps
• Footprint — memory tracking library

References

• iOS Memory Deep Dive (WWDC 2018)
• Image and Graphics Best Practices (WWDC 2018)
• Improving Battery Life and Performance (WWDC 2019)
• Getting Started with Instruments (WWDC 2019)
• Why is my app getting killed? (WWDC 2020)
• Detect and diagnose memory issues (WWDC 2021)
• Explore Swift performance (WWDC 2024)
• Reducing the Memory Footprint of Metal Apps
• Stack and Heap Objects in Objective-C (Mike Ash)
• NSCache and NSDiscardableContent documentation

For the past month or so, I’ve been working with one of the best observability platforms out there — Embrace. The team has been absolutely fantastic, and I’ve been having a blast collaborating with them. They gave me an interesting challenge: figure out how to automatically instrument SwiftUI views without all the usual boilerplate and manual work.

Liner notes: This article discusses unreleased feature of the Embrace SDK. They may, or may not make it into a final release. The SDK Is open source, so you’re free to peruse the code.

As any iOS developer knows, adding performance monitoring, analytics tracking, or debugging instrumentation to SwiftUI views can quickly become a maintenance nightmare. You start with good intentions, but before you know it, you’re drowning in repetitive code and constantly forgetting to add instrumentation to new views.

Here’s the solution I came up with using Swift macros. It’s cleaner than I expected, and honestly, I wish I’d figured this out years ago.

Manual is Hard

Usually when we want to trace SwiftUI views, we end up with one of these approaches:

Wrapping everything:

TraceView("MyView") {
  Text("Hello World")
}

Or adding view modifiers:

Text("Hello World")
  .onAppear { startTrace("MyView") }
  .onDisappear { endTrace("MyView") }

Both work, but they’re a lot of work and pretty cumbersome if you ask me (you did, right?). Your view code gets mixed up with tracing code, you forget to add it half the time, and refactoring becomes a disaster due to past you.

Our Solution

A macro. Boring things should be easy. Hard things should be made easy. So we figured a macro should do it. Simply add the @embraceTrace macro to your views and you’re good to go.

@EmbraceTrace
struct MyView: View {
    var body: some View {
        Text("Hello World")
            .foregroundColor(.blue)
            .padding()
    }
}

That’s it. One attribute, and your view gets automatic performance tracing without any of the usual mess.

What Did We Actually Solve?

The macro does some clever stuff behind the scenes. Check it out.

First, it makes sure you’re using it on a View, otherwise you get errors flagged directly in Xcode.

This catches mistakes at compile time, which is nice.

Next, instead of modifying your body implementation, the macro creates a private copy and adds it to the same View, this way anything it refers to will still work as usual:

private var _embraceOriginalBody: some View {
    // Exact copy of your original body
    \(raw: declaration.description)
}

TBH, I couldn’t find a way to directly reference the original body implementation, so copying it seemed like the best option.

This body duplication is obviously a small hiccup; it causes a binary size impact. It’s negligible, so we run with it. And I’m sure we’ll find a way around that soon enough. Worried, I am not.

Next is the meat of the macro. SwiftUI views have their body type defined, so you can’t just return something different from the same view. I got a lot of help from the community figuring this part out.

The first solution was to redefine the Body to AnyView. But, AnyView causes performance issues with SwiftUI's layout system due to type erasure and other things I haven’t explored too much, so I tried to stay away from that.

Instead, the macro creates a container view:

struct _EmbraceBodyContainer: View {
    let view: MyView
    
    var body: some View {
        view._embraceOriginalBody
    }
}

This container holds a reference to your view and returns your original body. It avoids circular references and keeps the type system happy.

Then we redefine your view’s body type:

typealias Body = EmbraceTraceView<_EmbraceBodyContainer>

@_implements(View, body)
@inline(never)
@ViewBuilder
var _embraceTracedBody: Self.Body {
    EmbraceTraceView("MyView") {
        _EmbraceBodyContainer(view: self)
    }
}

More interesting details. The @_implements attribute tells the compiler that this new body satisfies the View protocol's body requirement instead of the original one.

By using the container approach instead of AnyView, we keep all the original type information intact. SwiftUI can still optimize your view hierarchy the same way, so you get the performance benefits plus automatic instrumentation.

Beyond Instrumentation

This idea isn’t limited to performance monitoring. You could use the same technique for a bunch of other things, like…

• @AnalyticsTrack - automatic user interaction tracking
• @ErrorBoundary - error catching with fallback UI
• @AccessibilityAudit - automatic accessibility improvements
• @MemoryWatch - memory usage monitoring

Anytime you’re adding the same boilerplate across multiple views, you could potentially build a macro for it.

Why This Approach Works

The main benefit is that your view code stays focused on what it’s supposed to do. All the monitoring happens automatically.

Once you add the @embraceTrace attribute, you're done. No more futzing around. No more hard coded span names.

Since everything happens locally, before you even hit run, you catch mistakes immediately. And because kicked AnyView to the curb, your views perform exactly the same as before.

You can always expand the macro to see what code is being generated, and it won’t mess with your dSYMs or debugging metadata like some runtime instrumentation systems do.

Wrapping Up

The @embraceTrace macro solves a real problem in a clean way. For those of us who've spent way too much time adding (and forgetting to add) tracing code throughout our apps, this is a major improvement.

The real value lies in keeping your code focused and maintainable. With this approach, instrumentation becomes a one-time annotation rather than an ongoing maintenance burden. Your views stay clean, your monitoring stays consistent, and your development workflow becomes more efficient.

The Embrace SDK’s implementation of this technique is available as open source, so you can explore the full implementation details and adapt the approach for your own use cases.

I hope you enjoy it and find new and useful ways to use and improve it.

Cheers!

When I say “another cache,” I’m not suggesting we create one. Instead, I’m proposing we acknowledge that another cache likely already exists, and we should account for it rather than ignore it.

This “other cache” can be any type of reusable object container. For instance, consider the trusty UIImageView. It has an .image property that, when set, strongly retains the image—usually an instance of UIImage that's also cached in-memory or on-disk.

The Problem

A user interacts with an app, loading, caching, and displaying images repeatedly. The developer diligently follows best practices to minimize memory usage while maintaining performance. Over time, memory usage grows until the OS flags the app with warnings. At this point, the app trims its caches, often by removing items based on a least recently used (LRU) pattern.

The twist? Views may still hold onto data that has been evicted from the cache. If the app survives subsequent memory warnings, it eventually needs to reload resources that are no longer in the cache but are still retained by views or containers.

This is especially common with media objects like images or videos, though it can happen with any type of object.

As a result, the same object exists in memory twice:

• One instance in a container (like a view).
• Another instance in the cache (if reloaded).

This duplication, occurring repeatedly, is a major cause of excessive memory consumption in applications.

How Do We Fix It?

The solution is simpler than it might seem. There are two approaches:

1. From the Container’s Perspective
   We could ensure containers properly release their data when no longer needed. However, this approach is error-prone and doesn’t scale well across complex systems.
2. From the Cache’s Perspective
   A better approach is to clean up unreferenced objects before compacting the cache. This ensures we’re not holding onto anything unnecessary.

The Weak/Strong Round-Trip Solution

To handle this, I recommend a weak/strong round-trip.

Here’s the basic idea:

1. Take your cached object.
2. Create a weak reference to it.
3. Clear the strong reference.
4. Reassign the weak reference back to a strong reference.

If the object is no longer needed, it will be cleared. If it’s still in use, it remains. Then, proceed with your LRU trimming.

Here’s an example implementation:

// A structure that holds a weak reference to an object.
struct WeakReference {
    weak var value: AnyObject?
}

// Start with an array of objects.
var items: [AnyObject] = [UIImage(), UIImage(), UIImage()]

// Create weak references for all objects.
var weaks = items.map { WeakReference(value: $0) }

// Clear the original container.
items.removeAll()

// Rebuild the array by removing nil objects.
// The result contains only objects still in use.
items = weaks.compactMap(\.value)

Results and Benefits

This technique can significantly lower your app’s memory footprint and reduce the risk of termination due to high memory usage. It ensures your cache stays efficient and prevents objects from being duplicated unnecessarily.

If you’d like to see this approach in action, check out the open-source caching library Arsenal. And if you found this useful, don’t forget to clap, follow, and subscribe!

What is important to users

Today, we know more. We know that users care about more than what is foreground. For example, you might be using the phone app in the background while you sift through something in the foreground. If it came down to it, which should be terminated first: the phone App or the foreground app? I’ll go for the foreground app every time. So the OS has priorities, and the foreground app is not always at the top.

There’s another small particularity about foreground that is kind of interesting. Most apps are considered foreground when their state is active, which makes total sense. Consider what the app state is when the user taps the icon on the SpringBoard — it’s in background until the open animation is complete. This means that most products don’t consider the user interaction of opening an app (or the act of opening/foregrounding an App) to be a foreground issue and simply disregard it. We need to come up with a new way to discuss the state of an app, or how the user perceives its state, which is much more important. So let’s call that User Perceptible.

User Perceptible is a binary state; did the user know about it or not (tbd if we need a care level to go with this switch — let’s not complicate things yet). This works for all sorts of different kinds of situations, from traditional crashes, to terminations all the way to much more complex functional issues. From an observability standpoint, any logged span could include an extra flag specifying the perceptibility of the event being logged. A really simple example is the span from when the user starts the action of foregrounding an App to when they begin the action of changing to something else (backgrounding the App). Anything that happens within that span is important and should be considered User Perceptible. To add to that example, let’s start playing a live podcast in an App, that should begin a span that is important to the user. That span completes when the podcast ends or when the user stops listening to it, not necessarily when the app is sent to the background. In other words, the user perceives our App as important to them for as long as it’s in the foreground or that podcast is playing. Any issues that occur within a User Perceptible span are considered important to the user and should be reported so teams can address them.

I hear you. I just expanded the scope of where you need to collect issues in your product. Your users will be happier and will love your app more for it. You’ll also be able to prioritize issues much more effectively and spend time in areas with a much larger ROI.

OOMs

Many issues occur during transitions from one state to another, which led to the concept of User Perceptible. It just so happens that these areas are known to be prone to OOMs, at least we thought they were. What is actually going on, is the major flaw in Reducing FOOMs in the Facebook iOS app. I say this with all the love in the world because without that article reliability of iOS apps would be far from what it is today.

That article makes OOMs the falloff, the default in a switch, the one who always gets the blame, the scapegoat. Truth is, they aren’t. We need to examine various factors during startup to understand why the app is starting, such as why the previous session was terminated. That’s all for another post (or partly that Facebook post), today it’s all about Memory Terminations.

Memory Limit and Memory Pressure

There’s a reason an OOM was the falloff case, we didn’t have tools to know if they were actually the real reason for a termination. So instead of just saying we didn’t know, we blamed memory, it was a good bet and worked most times, but also led to many days and nights of trying to solve an issue that was just not going to be solved in that specific way. I’ve been there, I know. My Wife Sarah knows, my dogs know. So let’s fix that.

Memory Pressure. This has been around for a while and has undergone changes in its implementation by Apple. Today, it’s basically a mix of pressure put on the app by the OS and other Apps running (remember that music player that’s not foreground, that’s putting pressure on your foreground app). It is rarely going to be an issue for the foreground app, but when an app is in the background, watch out, memory pressure is what is going to cause your app to be jettisoned (terminated by the OS). Now keep in mind, this is normal and is a fact of life on iOS. Your app, if in the background and doesn’t have any priority enhancers (playing music for example), will be terminated, it’s how things work.

I always emphasize that an app should have a very small memory footprint when backgrounded. But if for any reason it is terminated, as long as it has an optimized and efficient startup, and handles app restoration flawlessly, then users won’t be aware of background terminations and you should be good to go. What comes next is what really counts.

Memory Limit. If there’s one thing you need to be aware of, and it’s likely you aren’t because Apple has yet to give us a way to handle this, it’s how close you are to being terminated in the foreground due to memory. A few years ago they provided a way to query how much memory is remaining, that was the start of something great. We finally knew the reality of when an app would be terminated.

The eureka moment comes when we realize that we can add that to the App footprint, which is the dirty memory used within the process, and determine the real memory limit. This changes everything. To clarify, this means we know the absolute limit of heap our apps can use before the OS simply sends a SIGKILL signal to our Apps. For those who don’t know, from within an App, you cannot intercept a SIGKILL signal, the app just dies and no one tells us why. Hence the falloff case in the Facebook article, it was just the last possible case… until now. This is HUGE.

I’m really excited in case you couldn’t tell. Furthermore, we can split up the memory limit into distinct levels and react to these levels at runtime. This allows us to act on user behavior as it happens instead of when it’s too late when Apple sends out memory issue notifications.

With this information, and many tests done over the last few years, I can say with almost certainty that when we’ve used up above 90–95 ish% of memory, if the app is terminated then we can say it was terminated due to hitting the memory limit.

Just do it

Swoosh. I want everyone to be able to use this information. Oftentimes, depending on what your role is, you either want to be able to make sure things are prioritized efficiently, or be able to prioritize them efficiently. Either way, it all comes down to having the right information in your issues, observability systems, or built into your apps so everything else works flawlessly.

To this effect, there are currently a few ways to go about it. I have worked with the KSCrash team to build OOM support directly into their crash reporting systems. KSCrash has been forked by many apps and products out there so this should be a huge step in reducing OOMs across the Apple ecosystem. If you use KSCrash, you’ll get this soon by default. I have proposed the same solution to Crashlytics and Sentry which are also leading error reporting systems. I hope they implement it sooner than later.

I admit I have no insight into what Apple is planning, but I expect that this WWDC (’24) will have have some sort of update to MetricKit that brings more memory observability than simply reporting how many sessions were killed due to memory. I have ideas that I’ve shared. Fingers crossed.

But most importantly, Footprint is my own Swift implementation of Memory Limit and Memory Pressure. You can add it to your app using Swift Package Manager and start reacting to memory changes at runtime today. Go forth and be a good memory citizen.

import Footprint

@main
struct SplashApp: App {

    /// Finds a good weightLimit for our memory caches base on the current memory state.
    func goodMemoryLimitFor(state: Footprint.Memory.State) -> UInt64 {
        
        // half the memory limit is a good start for the max usage
        let maxValue = Footprint.shared.memory.limit / 2
        
        let eachSlice = maxValue / Footprint.Memory.State.terminal.rawValue
        let currentSlice = Footprint.Memory.State.terminal.rawValue - state.rawValue
        return UInt64(currentSlice * eachSlice)
    }
    
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onFootprintMemoryStateDidChange { state, _ in
                    Task {
                        // Anytime the memory state changes, I update the weightLimit of the
                        // memory caches. This does 2 things:
                        // 1. Ensures any memory growth we might have in the cache never gets out of bounds
                        // by limiting how much the cache can contain based on user behavior.
                        // 2. Purges memory caches to newer limits making memory growth much slower than with
                        // usual `memory warnings`.
                        let byteLimit = goodMemoryLimitFor(state: state)
                        // set your cache max cost to _byteLimit_
                    }
                }
        }
    }
}