struct ContentView: View {
	var input: Int
	var unrelated: Int
	
	var expensive: Int {
		input * 2 // let’s pretend that multiplication is super slow
	}
	
	var body: some View {
		Text("Expensive: \(expensive)")
		Text("Unrelated: \(unrelated)")
	}
}

Sure, whenever input changed, that expensive multiplication had to be recalculated; after all, I was using expensive in the view body. But if only unrelated had a new value? The view really ought to skip the expensive computation, and reuse the previous result.

You’d think there was a built-in way to perform this sort of caching, this memoization; or a ready-to-use code snippet online; but I couldn’t find any. So here’s my take!

Using @Memoize

After copying the source (see below) into your codebase, using it only requires two changes:

1. Add a @Memoize property, with the computed value’s type. This stores the cache.
2. In the expensive getter, wrap the computation with a call to the newly-added property wrapper, passing all the input values as arguments.

struct ContentView: View {
	var input: Int
	var unrelated: Int
	
	@Memoize() private var expensiveCache: Int // 1. Add this
	
	var expensive: Int {
		_expensiveCache(input) { // 2. Wrap in that
			input * 2
		}
	}
	
	var body: some View {
		Text("Expensive: \(expensive)")
		Text("Unrelated: \(unrelated)")
	}
}

That’s it! Now, whenever the expensive property is accessed, it’ll first check the cache for an up-to-date value, skipping the closure execution if none of the inputs changed. If there are expensive calculations in some of your views, this can make quite the difference.

Do make sure you list all the input values (here, just the input variable, but you can pass as many as needed). Otherwise, the output value won’t update when it should. The only requirement for these inputs is Hashable conformance.

For types that can’t conform to Hashable, or hash too slowly, you can pass a single Equatable value instead. To enable this, you’ll first need to tell the property wrapper about the key type: @Memoize(key: SomeInput.self). The downside is increased memory usage, as the full input value will be stored as a cache key, instead of just a tiny hash.

The source

Download the ready-to-use Memoize.swift file, or read the code and implementation notes below if you’re curious.

Memoize.swift

@propertyWrapper
struct Memoize<Key: Equatable, Value>: DynamicProperty {
	var wrappedValue: Value {
		fatalError("To use @Memoize, call it as a function, passing the input value(s), and a closure to produce the value")
	}
	
	@State @Boxed private var cache: (key: Key, value: Value)?
	
	init(key keyType: Key.Type = Int.self) {}
	
	private func getMemoized(key: Key, produceValue: () throws -> Value) rethrows -> Value {
		if let cache, cache.key == key {
			return cache.value
		}
		
		let newValue = try produceValue()
		cache = (key: key, value: newValue)
		return newValue
	}
	
	func callAsFunction(_ key: Key, produceValue: () throws -> Value) rethrows -> Value {
		return try getMemoized(key: key, produceValue: produceValue)
	}
	
	func callAsFunction(
		_ key: any Hashable...,
		produceValue: () throws -> Value
	) rethrows -> Value where Key == Int {
		var keyHasher = Hasher()
		
		for keyPart in key {
			keyHasher.combine(keyPart)
		}
		
		return try getMemoized(key: keyHasher.finalize(), produceValue: produceValue)
	}
}

@propertyWrapper
fileprivate class Boxed<Wrapped> {
	var wrappedValue: Wrapped
	
	init(wrappedValue: Wrapped) {
		self.wrappedValue = wrappedValue
	}
}

Implementation notes

• Yes, that’s a box in a state. The state is necessary because we want the cache to persist across renders—it’d be pointless otherwise. But, we need to update that state during view updates, which isn’t supported by SwiftUI. To get around this, we wrap the cache in a reference type—that’s the box—enabling us to update it at any time, without ever modifying the actual contents of the state itself.
• Memoize is a DynamicProperty: this allows it to use SwiftUI property wrappers, such as @State.
• The unusually-implemented wrappedValue is only there to help set the value type. It lets us type @Memoize() private var expensiveCache: Int instead of @Memoize(value: Int.type) private var expensiveCache. Arguably nicer.
• Those empty parens in the @Memoize() call are necessary: it seems that without them, Swift doesn’t use our explicit init, and therefore skips the default key type.
• To make calls to the memoization function more concise, we’re using callAsFunction, and an any Hashable... variadic parameter. Also, the wrapper takes care of hashing these input values, so you can have more than one input without needing to group them yourself, like you would for instance with onChange(of:).

Hopefully you find this bit of code useful. If you do try it, I’d love to hear your feedback!

Updating Retcon’s icon for macOS 26 Tahoe involved a lot of trial and error, a lot of resolving (and creating) problems. So I recorded this short tour of some of the versions the icon went through, and the reasoning for everything. Give it a watch!

If you enjoy this walkthrough, you’ll also like reading about the making of the original icon.

Well, there’s no single thing. Months of work resulted in numerous, surprisingly diverse optimizations; some expected, some eyebrow-raising. Despite that variety, however, one kind of optimization ended up the most common by far: caches.

Many values, many caches

Retcon now has numerous in-memory caches. Anything that’s slightly expensive to compute is stored in memory, to be reused the next time it’s needed. To make sure these cached values don’t go out of date, they’re either discarded whenever the input data changes, or are stored alongside a fingerprint of the input data, to allow checking validity on retrieval.

One of Retcon’s most important classes is VirtualizedRepository. VR objects mediate access to Git repositories, while transparently layering Retcon’s own data on top. They’re core to allowing Retcon to display and manipulate states that Git itself can’t represent, such as a commit histories with a conflict midway through.

Because of this, a VR exposes many different properties, most derived from on-disk data, that get accessed quite heavily. And so these properties are cached: the head commit list is cached as an array, allowing for random access, instead of requiring walking the history one commit at a time through parent lookups. The repository’s tags are cached in a purpose-made map, cachedTagsBySHA1, that makes it very fast to look up a given commit’s tags, instead of needing to filter through the repository’s complete tag list every time. There’s the precisely-named cachedPhysicalSecondaryHeadAncestorsByMergeCommitLineage—a map of the commits that were merged into the current branch, keyed by the identity¹ of their merge commit. Purpose-made, once again. And there’s even a cache of the behind/ahead counts, that are eventually displayed on the pull/push buttons—if your branch has significantly diverged from its upstream, finding the closest shared parent can take a while.

Many of the VR caches are regenerated from scratch whenever any repository data changes, so that they’re always up to date. But some are handled with more granularity, for performance.

The head commit list cache is updated, not discarded. When a repo changes, the vast majority of the history usually stays the same; so Retcon holds onto the current cache’s tail of unchanged commits, and prepends new and modified commits².

The merged commit map is never proactively built, but instead gets populated as data is requested. This is because in Retcon, merge commits are initially displayed collapsed: their child list is only needed once the user toggles them open.

Rigorously not measuring text

Caches are useful for more than abstract, internal state. Computing the layout of UI elements can also be expensive, once again inviting caches; Retcon’s best example is the measuring of diff hunk heights.

Now, while generating diff hunks is fast, computing their on-screen height is not. Retcon doesn’t let the text scroll horizontally, instead wrapping it at the window edge; this means that to know the total pixel height of a hunk, the layout system must scan through the entirety of its text, determining line wrapping points, and therefore the number of lines the hunk actually spans³. This is a very, very slow process for large amounts of text.

Which brings us back to caches. It’s a no-brainer to cache the output of this expensive measuring process, as a given hunk will often stay the exact same when the diff view is refreshed. Here’s the tricky part, though: what does it mean to be the exact same? If the hunk’s text remains unchanged, but the window becomes wider, then we should redo the measurement—more horizontal space means less wrapping. If one of the hunk’s neighbors changes in content, we ostensibly don’t need to reflow the unchanged hunk itself—unless the neighbor’s line numbers are now different, since these dictate the width of the line number gutter, which is shared by all of a file’s hunks. So many variables to take into account, coming from such distinct sources!

So we need to invalidate our cache based on these diverse factors, and do so with precision: while the height must never go out of date, we also want to avoid costly superfluous invalidations. To achieve this granularity, Retcon makes use of a supporting method, that fetches all the relevant inputs for a given hunk, and mixes them into a single integer:

\showLineNumbersStartingFrom: 624
/// A hash of all the properties that have an impact on this hunk's view height.
func heightDependenciesHash(
	forHunkAtIndex index: Int,
	withParentWidth parentWidth: CGFloat
) -> Int? {
	guard let viewHunk = viewHunks[safeIndex: index]
		else { assertionFailure(); return nil }
	
	var hasher = Hasher()
	hasher.combine(parentWidth)
	hasher.combine(contextIsDough)
	hasher.combine(effectiveForceDisplayingHunks)
	viewHunk.hunk.combineText(into: &hasher)
	hasher.combine(hunkGutterWidth)
	return hasher.finalize()
}

The method essentially captures the complete context in which a hunk is measured, and represents it as a hash. This allows us to store the hash alongside the cached height, and use it as the cache key: whenever the cache is read back, we first check if the stored hash matches the current output of the method. If the two differ, it means the cached height is stale, and we need to take a fresh measurement.

The nice thing about this approach is that it neatly encapsulates all knowledge about hunk height calculation. While this listing of factors is itself duplication (after all, the window width will affect hunk height regardless of what we hash in the method), it does prevent duplicating and scattering that information any further. It’s the one, canonical way of representing hunk cache freshness.

Unrigorously measuring text?

In a slightly different world, we could actually skip measuring most hunks. If a hunk isn’t in view, all we need is an approximation of its height, so that we can properly size the scroll bar’s thumb.

Retcon has a way of producing such an estimate: it maintains estimatedRowHeightToLineCountRatio, a cache of the average ratio between the pixel height of a hunk, and the number of line break characters it contains, based on hunks measured so far. We always know how many line breaks a hunk has, so it’s extremely cheap to get an idea of its height using this value.

However, this technique turns out to be unusable. AppKit’s NSTableView class, that Retcon uses to display the list of hunks, requires us to provide exact heights, not estimates, when enumerating our hunks⁴. If the values we provide are off by even a few pixels, the view will constantly stutter and jump when scrolled, making for a terrible experience. Oh well.

The long tail

There’s many more caches in Retcon. They all bring welcome performance boosts, but most aren’t especially interesting. Here’s one last story for the road.

The welcome window, with its list of recently-opened repositories, could be slow to appear, sometimes stalling for more than a second. The view code would read the system-provided recentDocumentURLs list many times per refresh, with the assumption that the access would be instant; it was not. One cachedRecentDocumentURLs later, and the window now shows up without delay. A welcome improvement!

There’s a lot more to Retcon 1.4 than caches, though; we’ll look at the many other optimizations in future blog posts. Follow along on Mastodon, Bluesky or Atom, and get Retcon now to see firsthand how fast it’s become.

The obvious

• Text swapping becomes easy. Copy A, copy B; paste B over A, then recall A and paste it over B.
• Peace of mind. When your clipboard holds an important item you mustn’t discard, you no longer need to consciously stop yourself from copying anything. It’s OK if you forget and override that item; it’s OK to switch to a quick side-task that requires the clipboard, or to reboot your computer, or let someone else use it. Your clipboard is no longer fragile. To some people, this makes a world of difference; it’s one less thing to actively keep in mind.

The creative

That was the expected. Leaning on your clipboard manager, though, you can start using your computer differently.

• Long recall. If you can remember manipulating some piece of text, there’s a chance you copied it. So if you can recall just a few unique letters from it, that clip can be instantly recalled, using the clipboard manager’s search feature.
  An email address you copied? Often, just type the person’s name. A URL you recently shared on a chat? The website name. That Terminal command to clear a file’s quarantine flag that you keep looking up online¹? Try “quarantine” and it should be there.
  The list goes on! Without any upfront effort of your part, so much of the interesting text you manipulate can later be recalled in just a few keystrokes. The longer your clipboard history, the better, too; I’ve configured my clipboard manager to keep items for months, so if I remember something, it’s in there for sure.
• Instant backup. Ever lost text to a flaky Web form after spending half an hour composing it? Well, you now have the means to instantly backup any piece of text: ⌘A, ⌘C. That’s it! It’s so fast, you can do it all the time. And now you won’t ever again lose anything you’ve written. ⌘A, ⌘C. Your own instant, ubiquitous backup system.
• Regret-proof delete. This builds up on the previous item. Now, whenever I delete any piece of text that’s longer than a couple words, I do so using ⌘X. That goes for code, or unsent chat messages, or Web searches. Most of the time this is pointless; but often enough, I’ll be happy to save some thinking and typing, when I realize that actually, that first draft was in the right direction. Anything you delete by cutting can be undeleted, and there’s no cost to doing it.
• Photographic memory. And it’s not just about text: I’ll often take a screenshot of a settings windows right before I tweak something. ⇧⌘4, Space, then Control-click: I instantly captured a reference of how things were configured, before I went and messed them up. My future self often thanks me.

So many uses out of that single simple system! I think that’s really cool. I hope you find these ideas useful; and if you have your own schemes, please do share them with me on Mastodon or Bluesky. I’ll be happy to use my clipboard manager even more.

Appendix: What clipboard manager to use?

The app I personally use does the job brilliantly; however, it stores all of its data unencrypted on the file system, and the developers have stated they didn’t intend on fixing the issue, so I’m really not comfortable recommending it.

Fortunately, there’s plenty of clipboard managers out there! Find one that’s got very fast search, and a large maximum history size, and you’ll be set.

I also really like telling people all about the things I’m making. There’s a lot of pleasure in describing, in great detail, the goals, the obstacles, the breakthroughs, even the vexing compromises.

Up until now, though, it’s mostly been my friends’ ears that I’ve been talking off. With this blog now online, it can finally be yours too!

This is the icon for Retcon, the macOS app for rewriting git history at the speed of thought. My first Mac icon! Rendered in Sketch, with reference renders in Blender.

I followed a process described in an article from Marc Edward: start with concept sketches, create a 3D version of your icon as a reference, then render the final icon in vectors.
The 3D reference allows the icon to have realistic shapes and lighting—as seen on the pen—but the vector re-render means the icon’s look can be fully controlled; great for aesthetics, and legibility.

Concept

Retcon allows you to modify git history very fast, with the same ease you’d move a folder in the Finder, or rename a file. That’s what motivated many of the concepts: splicing a movie, tearing pages from a book, redacting a page, etc. The app’s all about fast editing.

Ultimately, the whiteboard felt like the clearest metaphor. A close second was the blackboard, but while that might have made for a more visually pleasant icon, it also felt less modern, which wasn’t the appropriate for the app.

Some of my favorite concepts are the whiteboard titled “Progress”, and the blackboard being erased; but, while they’re pretty compelling as rough sketches, these concepts would probably have been much too busy as actual icons.

Symbol

The whiteboard features a git “branch” icon, which feels like a rather obvious choice in retrospect. It immediately ties the icon to git, and slightly hints at history and branch manipulation.

I explored many symbols, though, before settling on this one. Most notably, I looked for a less direct depiction of a git history; something more concrete and relatable, like the tree-related symbols. I eventually decided that the absolute clarity of the actual symbol for a git branch worked perfectly, in the context of the icon. In Retcon, you’re literally erasing and rewriting branches!

Another very tempting choice was Apple’s “A” app symbol. It evokes development very clearly, and has strong (and hopefully positive) associations.
However, it evokes app development, rather than software development in general, which is too specific for Retcon; and it feels owned by Apple, at least in culture, if not as a trademark.

A vector previz, and a 3D render

These really helped nail down the icon’s layout, scale, and overall look. When then rendering the final icon, I heavily referenced the pen, for realism, but mostly made up the board, which wasn’t modeled very interestingly in the 3D model.

Final render

Balancing viewing scales

Although Mac icon files can contain many variations, that the system then selects from depending on icon display size, I decided to only create a single size. (or perhaps forgot that you could create these variations. events unclear!)

That meant the icon had to work both when displayed large (as a marketing asset, or when inspecting by the user using Quick Look) and small (in the Dock, in the Finder).

Of the two, the smaller size was definitely the more important one, being the icon’s usual display scale. That meant sacrificing good-looking small details, if they muddied the icon when viewed small.

You can see this tension in action in the two-up comparison below. A WIP shot is on the left, and the final icon is on the right.
The final icon is coarser, its various borders thicker, its shadows heavier. The end result is a lot less elegant when viewed up close, but vastly more legible when viewed at Dock size. The process of removing subtlety was painful, but ultimately made for a much better icon!

Objectives

Going in, I had objectives in mind; some essential, some optional. The icon definitely doesn’t fulfill them all, but compromises are core to design, no?

The essential goals are predictable:

• Be a functional icon: Be recognizable, legible at small sizes, and evocative of the app itself. ◆ That one’s a go! As the most important goal, it forced quite a few decisions, as described above.
• Look at home on macOS: The system has its own design language. It’s a rather strongly-defined one, although there’s still a lot of leeway for experimentation. ◆ I think the icon does just fine here. It’s realistic but not actual 3D, and respects the round rect while playing with it a little. The pen really helps, too—more on that below.

The optional goals were a bit more personal:

• Use varied materials: While assembling a board of reference material, I kept encountering app icons that felt nice, but… were somehow just short of great. Eventually, I realized that they often fell into the trap of having every component rendered the same way: the whole icon would look like a plastic model of a thing, instead of looking like the thing itself. To counter that effect, I really wanted the icon to feature different materials, of which the different properties would contrast in the final render. ◆ I don’t think I did an excellent job, here. There’s certainly diversity: slightly rough metal for the board frame, shiny white plastic for the pen’s body, and some variations of plastic and paper. However, especially when viewing the icon at a small scale, the material differences barely stand out; only the metal frame’s telltale shine makes it stand out from what otherwise looks all-rubber, or all-plastic.
• Include a tool: Some of my favorite Mac apps have a tool on their icon. It’s an old convention, that screams “this app will let you make things”. I love creation apps, and I love this association—so it was important to me for Retcon’s icon to feature a tool. ◆ I’m happy I got to do this one! Luckily, the best concepts for the icon all made including a tool natural, if not necessary. The most observant will notice that the pen is shifted right from the standard, Big Sur-style tool location, but the appropriate 24° angle is respected!
• Show ample color: It’s so nice to look at something colorful. I wanted the icon to have a well-defined dominant color, and feature it prominently, with a large portion of the icon being painted. ◆ Well, that one’s a wash—the icon does have a clearly-communicated tint, but it’s not used over large areas; instead, the most represented color by far is classic whiteboard white. Gotta pick your battles!