Like many power-user apps these days, Nova has an “open quickly” palette:

Type a few letters, and you’re able to jump to any file, or symbol (an important element within a file):

Through buttons right below its text field, the bar also lets you filter results: only show files, only show symbols, or only show symbols in current tabs. Here’s the thing, though: each one of these buttons has four distinct purposes. They’re not just for clicking.

First, they indicate that you can filter at all! If filtering was done through an app menu instead, it’d be a lot harder to discover. You wouldn’t go looking for a feature you don’t even know exists. So before you’ve even clicked one of the buttons, they’re already doing a useful job; their presence itself is documentation.

Second and most obvious, the buttons let you act. Click one and its filter is enabled:

Straightforward, except for an unassuming side-effect: a # was inserted into the text field. That’s right: the third purpose of the button is to teach you how to stop using it, how to graduate to a faster interaction.

You can enable a filter just by typing the corresponding magic prefix, which is especially handy since your hands will be on the keyboard anyway. But once again, you first need to learn that this is possible at all. By inserting the prefix whenever you enable a filter, the buttons tell you that the two are inextricably linked; they suggest that you could have typed the prefix yourself. No tutorial text, no need to go read a manual; just by using the app, you’re being taught not only what it’s capable of, but how to become faster at using it.

Finally, the button’s fourth and final purpose is what comes after all that. You’ve been taught about filters; taught about the magic prefixes; the button’s only job from now on will be acting as a cheat sheet. Each button displays the correct magic prefix in its label, acting as a reminder of what it is you must type, conveniently displayed exactly when you need it (and only then). Once you’ve learned all of the app’s tricks, the buttons won’t ever see another click, and yet they remain useful; they supplement your memory, lowering the cognitive load of going through the interface.

I sat my mom — a tech-savvy Mac user, but one who’d never used Git in her life — in front of the same beta, and tasked her with bringing some specific commit to some specific branch. Just minutes later, with little effort, she had done so.

A feature that baffles experienced users, and comes naturally to novices. How did I mess up that bad?

Embracing the GUI

So, what did that misguided cherry picking interface look like?

There’s an obvious answer for what it could have looked like. A small modal window, in which you can type a commit hash or name, or maybe choose from a list. Click OK, and the commit is inserted.

With Retcon however, I try to never settle for the obvious and conventional, in the hope of finding new, better solutions. The app’s whole schtick is that of improvement through reinvention.

(Sometimes, the obvious and conventional is perfectly good, and therefore makes it into Retcon, of course.)

In the case of cherry picking, it turns out there’s an existing metaphor in the vocabulary of GUI interactions; a perfect fit, that both feels natural to use and is widely understood: copy and paste! Copy something from somewhere, paste a copy of it elsewhere: that’s exactly what cherry picking is. So that would be the model: just copy and paste commits.

The elegance of that solution, however, is also its weak point. It requires absolutely no new buttons or menus or anything — the Copy and Paste commands are already available in the Edit menu — making the feature invisible. How will users discover that they can copy-and-paste commits? There’s no precedent of a Git client letting you do that.

Surfacing commit copy-and-paste would require adding something. I decided on a somewhat awkward solution:

Placing a copy of the clipboard commands in the Commit menu, while unusual, sends a clear message: these operations apply to commits. With this, Retcon’s first cherry pick interface was complete. As you read at the start, though, it did not fare well with experienced users. Why not?

Trapped in domain knowledge

My developer friends, tasked with cherry picking, scanned the menus for the words “cherry pick”. It’s that simple: they knew the terminology, and so that’s what they looked for¹, and did not find. Interestingly, one of them did find the copy/paste commands once I gave them a clue (“have another look in the Commit menu!”), while the other, with the same indication, still found nothing. That’s how strongly they associated the domain-specific term with the action.

On the other hand, my mom, equipped with no Git-specific knowledge, was free to think more flexibly. Need to copy something from A to B, while not being able to see source and destination at the same time? That’s what the clipboard is for. There, done. The answer came perfectly naturally.

By choosing a less specialized, more widely understandable metaphor for the action, I both made the feature more accessible to people without any domain knowledge, and less intuitive to those with domain knowledge. What I expected to be a pure improvement to usability, wasn’t².

Dumbing it up

That initial approach had turned out to be too subtle, and needed fixing. I very much wanted to keep the flexibility and approachability of the copy-paste model, but needed to also make its presence clear to experienced users. My first attempt was tragically inelegant, if effective:

This works — anyone looking for the term of art will indeed find it — but the Paste command now looks way, way too conspicuous. It’s extremely rare for menu items to have a suffix that looks like that, which raises questions. Is this menu special? Does it have some sort of secondary action that can be invoked somehow? Or is cherry picking currently disabled for some reason? That solution felt like it would indeed achieve its goal of calling attention to the command, but that it’d cause confusion in the process.

Having run out of ideas, I had resigned to ship this problematic-but-better-than-nothing implementation, until finally, it struck. A way to label a group of menus? That’s a submenu!

A submenu! Of course! I sent excited, celebratory messages to many friends at that point.

The submenu approach has it all. There’s no attention-grabbing suffix; on the contrary, the three options are tucked away, which appropriately de-emphasizes them (I don’t expect people to ever use the menus to cherry pick; they’re just here to teach about the feature³). The nesting reinforces the message that these actions work together. And, most importantly, the submenu’s name does a perfect job of both explaining what the options are for, and of guiding those who look for that specific term. Hurray!

This submenu is what shipped in Retcon 1.6, and so far, no one’s asked where the cherry picking button was.

Despite this simplicity, the first implementation of that list was shockingly badly-behaved. It was:

1. Extremely slow (scrolling would cause multi-second freezes!)
2. Visually broken in multiple ways (you’ll see)

The implementation was naive but reasonable. The output, anything but. How come?

Using images in Picker options

Look, I like colors. So if my app has a whole menu of them, I want to show cute little swatches:

That didn’t work at first, though. For its options, Picker only accepts some text, plus an image; anything else seems to get ignored. So this sensible-looking piece of code plain doesn’t work:

struct AccentColorPicker: View {
	@Binding var selection: AccentColor
	
	var body: some View {
		Picker("Accent color", selection: $selection) {
			ForEach(AccentColor.allCases) { accentColor in
				HStack {
					Circle()
						.fill(accentColor.color)
						.strokeBorder(.tertiary)
					
					Text(accentColor.name)
				}
			}
		}
	}
}

Well, if an image is what it takes, we can make one. Dye’s solution is to make use of SwiftUI’s ImageRenderer, a class for rendering a view into an image. We create our own Rasterize view, which draws into content view into an image; then we wrap the circle with it. This works!

// Defining Rasterize
struct Rasterize<Content: View>: View {
	@ViewBuilder var content: Content
	
	var body: some View {
		if let nsImage = ImageRenderer(content: content).nsImage {
			Image(nsImage: nsImage)
		}
	}
}

// Using it
struct AccentColorPicker: View {
	@Binding var selection: AccentColor
	
	var body: some View {
		Picker("Accent color", selection: $selection) {
			ForEach(AccentColor.allCases) { accentColor in
				HStack {
					Rasterize { // here!
						Circle()
							.fill(accentColor.color)
							.strokeBorder(.tertiary)
					}
					
					Text(accentColor.name)
				}
			}
		}
	}
}

The main drawback here is that the ImageRenderer’s view tree is disconnected from the main view tree; as a result, the environment must be bridged over explicitly (as seen in the full source to Rasterize), which breaks dependency tracking, making the user responsible for keeping the environment up-to-date. It works, though!

Fixing the spacing inconsistency

Look at the screenshot above again, though. There’s something wrong with the space between swatches and text: it’s inconsistent between in the popup button at the very top, and the menu items below! Yikes.

I tried a few variations—using a Label instead of an HStack, for instance—but the output was always the same. It looks like that’s just how Picker looks on macOS.

So let’s roll up our sleeves, and reimplement the popup button’s appearance. It’s not that much code, and the double arrow is conveniently available as a SF symbol. What you see in the app, then, is a totally fake button; but overlaid on top is the real Picker button, set to near-zero opacity.

That’s an absurd amount of work for a basic piece of UI, but it works!

Making Picker fast (in two parts)

Okay, the Picker looks good, now. But, surprise surprise, scrolling the list is extremely choppy. Like stop motion, without the motion. What gives?

Turns out, computing the width of the popup button is very slow. That requires measuring the width of every option in the menu, to make the button fit the widest one¹. It seems that doing these measurements in SwiftUI is very slow; this was the case both for the native Picker view, and our own fake recreation, which goes through the same process². What to do?

Part I: No hover, no picker

If Picker is slow, let’s avoid rendering it.

Now, when you scroll through the list in Dye, no picker is actually there; just the fake button, the appearance. Only once you hover the button does the Picker get created, before you have a chance to click it. In practice, the interaction works exactly the same, but scroll performance is dramatically improved, since we skip the repeated measurements. Simple and effective.

struct FakePicker<FakePickerContent: View, PickerContent: View>: View {
	@State private var shouldRenderPicker = false
	[...]
	
	var body: some View {
		fakePickerButton
			.onHover { isHovering in
				guard isHovering else { return }
				shouldRenderPicker = true
			}
			.overlay(alignment: .trailing) {
				if shouldRenderPicker {
					actualPicker
						.labelsHidden()
						.opacity(0.1)
						.opacity(0.1)
						.opacity(0.1)
				}
			}
			.accessibilityRepresentation {
				actualPicker
			}
	}
}

Part II: Designated sizer

Now, for the final trick.

Scrolling is still slow, because we still create our fake popup button for every rendered row, which means we’re repeatedly measuring all ten options. There’s no way around rendering that fake button, but! Its width is the same in every row; why do we keep recomputing it?

There’s plenty of ways of computing that width once, then using the cached result in every fake picker. You could even make the argument for a hardcoded value, since macOS doesn’t have a system-wide font size setting, and Dye is currently only available in a single language. Feel free to imagine your own, reasonable solution; or keep reading for an overkill one.

The idea here is that the fake pickers’ content views are still responsible for computing their width, except one of them is randomly selected to make the measurement, sharing the result with everyone else. To achieve this, there’s a new .minSizeWithSharedCache modifier on the fake picker content, and a .sharedMinSizeCache modifier at the root of the app. They look like this in practice:

// Using .sharedMinSizeCache: it coordinates everything
struct ContentView: View {
	var body: some View {
		[...]
		.sharedMinSizeCache()
	}
}

// Using .minSizeWithSharedCache: it communicates with the root cache
struct AccentColorPicker: View {
	@Binding var selection: AccentColor
	
	var body: some View {
		FakePicker {
			// The fake, visible picker button
			pickerOption(for: $selection.wrappedValue)
				.minSizeWithSharedCache(alignment: .leading) {
					ForEach(AccentColor.allCases) { accentColor in
						pickerOption(for: accentColor)
					}
				}
		} picker: {
			// The actual picker (invisible, but clickable)
			Picker("Accent color", selection: $selection) {
				[...]
			}
		}
	}
}

How do these work? It’s an easy 5-step process of mad back-and-forth.

1. Each .minSizeWithSharedCache chooses a random UUID for itself, and propagates it up through a preference.
2. The root .sharedMinSizeCache receives all the UIIDs, and picks one arbitrarily. It propagates the chosen UIID back down the tree through the environment.
3. The .minSizeWithSharedCache that got chosen computes the minimum size, by measuring its content view. It then sends that size back up the three through a preference.
4. At the root, .sharedMinSizeCache receives the measured size, caches it in its state, and sends it back down through the environment.
5. Finally, all .minSizeWithSharedCache read that value, and use it as their minimum size. Goal achieved: the size was computed just once, but enforced in every row.

This was honestly very entertaining code to write! I think it’s especially fascinating how it’s essentially imperative code, expressed through declarative modifiers. It’s an absolute mess to read, because on top of that mismatch between behavior and expression, respecting view tree constraints forced an unnatural order for everything. Glorious, and dismal.

In conclusion

I’m not sure how to convey this through words without sounding sarcastic. Doing all this work—reimplementing the picker appearance, creating a Rasterize view, lazy-rendering the actual control, and creating an over-the-top cache network—was a ton of fun! Engrossing engineering work, solving puzzles with unusual tools.

And at the same time, it’s a maddening amount of work for such a basic user interface. A naive AppKit implementation would have achieved excellent performance with little effort. SwiftUI, at the ripe old age of 6, just shouldn’t struggle with such basics. To me, the framework is built on remarkable foundations³, but is as a whole deeply immature, somehow starved for development resources. It’s delicious jam spread too thin.

Oh well; there’s always next WWDC.

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!