After upgrading from Mojave to Ventura, I noticed that Apple had changed QuickLook.

QuickLook is one of my favourite pieces of software. You just select a file in the Finder, press space, and the file pops up on your screen. Then you press space again and it goes away.

Focus stays in the Finder, so you can use the arrow keys to select different files, and the QuickLook window updates to show them to you.

It's simple, well-designed, fast, tasteful and just all around excellent.

Until now.

For whatever reason, QuickLook will now remove the corners of your images before showing them to you.

It doesn't matter if they're photos, game assets, or UI elements you're designing. Everything will be rounded off before you see it.

Naturally, I searched around for the secret switch to make it stop. Apple is usually pretty good about letting us opt out of their latest improvements, so there has to be something, right? An accessibility setting? A cheeky defaults.write? As far as I can tell, there isn't.

So, I guess we're out of luck?

No. Don't think like that. It might be a Mac but it's still your computer. Let's fix this.

QuickLook headers

If we want to mess with how QuickLook displays things, we need to get at its window. Then we can hopefully poke around in the views and change how they draw.

The QuickLook API is public and documented, and if you look through the docs you'll see that this window is called QLPreviewPanel, there's one instance of it per app, and you retrieve it with [QLPreviewPanel sharedPreviewPanel].

Debugging Finder

I'd only ever used QuickLook from Finder, so that was where I thought to start. Let's bust out the debugger and see what Finder's up to:

Actually, first, let's deal with SIP. SIP is a new Apple technology that helps you out by stopping you from reading and writing memory on your own computer. In order to fix problems in system processes like this, we have to turn it off and reboot.

Alright, let's try that again:

<hacker-voice>We're in</hacker-voice> to our own machine.

Let's try setting a breakpoint on sharedPreviewPanel.

Navigate to an image file, press space, and:

LLDB has stopped the Finder process in the sharedPreviewPanel function. Let's get the return value, which should be the preview panel instance:

Alright! We're getting somewhere. Let's see what's in this panel:

This is pretty juicy. We can probably ignore QPreviewTitleBarView and its children, so let's focus on the other branch of the tree. There's a QLPreviewBackgroundView, then a bunch of NSViews, and then a QLPanelPreviewView, a QLPreviewContainerView, and right at the very top, an NSRemoteView.

NSRemote­View

I haven't come across NSRemoteView before and I'm not really sure what it is. There doesn't seem to be a public header for it. I wonder how it works?

Well, we might be getting ahead of ourselves here. We still don't know if the NSRemoteView has anything to do with our image. Let's hide it and see if our image disappears.

Indeed it does. So it's this NSRemoteView that's actually displaying our image. The “remote” makes me think it's communicating with another process which is doing the actual rendering, so we'll probably have to look inside the remote process to see what it's doing. But which process is that? Perhaps the NSRemoteView can tell us? Let's see what it can do:

A lot!

Searching for “process” in that list of methods yields _serviceProcessIdentifier so let's call it.

What's that process?

This has to be it. Debugging Finder isn't what we want. We need to be debugging QuickLookUIService.

Debugging QuickLookUI­Service

So, the other side of that NSRemoteView is... somewhere... in this process.

If we could iterate through all the views in the process, we could see if any of them looked like the other end of an NSRemoteViewDelegate.

I searched the internet for a function that would get all views, but I couldn't find anything except for the odd person saying to just use Xcode.¹

Well, why don't we just use Xcode?

After opening Xcode, creating a project, choosing where to save the project, entering a team name, choosing a template, entering a bundle identifier, creating a scheme, and setting the scheme target so it'll let me use the debugger, I attached it to QuickLookUIService, pressed “Show View Hierarchy”, and:

Well, that was easy! We can click through these views and get info about them, including their addresses so we can mess with them in the debugger. And we can see straight away that the frontmost view, which Xcode tells us is a QLBorderView, is a border with rounded corners!

Wait, there's a border?

The Border

There is. I hadn't noticed it at first, but if you zoom in, you can see that as well as rounding the corners, QuickLook also superimposes a slightly-too-small border:

The QLBorderView turns out to be very simple; it's just a view whose layer has a borderWidth and a borderColor. Let's get its address from Xcode and tell it to cut it out:

Unclipping

So, the border is gone, but the corners are still rounded. We can see in the view debugger that the image view's corners are not rounded, so something must be clipping it.

Let's have a look through all of the parent views' layers and see if any of them have a nonzero cornerRadius.

You could probably write some code to do this but I just clicked through each one and copied its layer's address into the debugger to check:

Well, that didn't take long. Let's try...

Keeping it that way

So, we've now fixed our view. We can see all of our pixels.

But we're not done yet, because when you click on a different file, you get a new view, and the new view is rounded. It looks like QL creates one view per previewed file, and reuses the old view only for the same file.

So, we need to intercept it when it makes new views and stop it from screwing them up.

Let's start with that border view. When is it created? We'll break on its init method, which its method list tells us is initWithFrame:.

This does indeed trigger when you select a new image:

Let's see who's calling us:

Interesting. The border view is being called from something called enableBorder. What if we disabled enableBorder?

There are no docs for the QLDisplayBundleViewController, of course, but there's always a method list:

As well as enableBorder, there's a disableBorder. If we're lucky it might disable the border.

It does! So, to fix our QuickLook process, we'll have to arrange for disableBorder to be called instead of enableBorder.²

Now, what about the rounded corners? We can set a breakpoint to see where the corners get rounded:

When this breakpoint is hit, we can see that it's being called from a method called updateCornerRadius.

So, our strategy for making our fix persist will be to:

1. Patch updateCornerRadius to return immediately without doing anything.
2. Patch enableBorder to just call disableBorder and return.

Aside: Method Swizzling

In Objective-C, classes have methods and methods have implementations. As a holdover from the bicycle-for-the-mind days, the Objective-C runtime is hacker-friendly and provides functions to help us monkey around with things:

In theory, you should be able to use these functions to switch out the implementations of enableBorder and updateCornerRadius.

But, try as I might, I couldn't get it to work reliably. Maybe I was holding it wrong, but instead of spending time figuring out why, I just went straight to no-nonsense instruction patching.

Patching the corner radius

Let's patch updateCornerRadius to return immediately without doing anything. We'll write a ret instruction over the first instruction in the function.

As documented in this 76MB PDF, the encoding of ret in ARM64 is 0xd65f03c0.

We can write a simple Python script that will find the function in memory and patch it:

Check it worked:

Success!

Patching enableBorder

Patching enableBorder is a little tricker, since we don't just want to have it ret, we want to have it jump to disableBorder.

The ARM64 instruction for performing an unconditional jump is b, and is encoded as follows:

• The instruction is 4 bytes long, like all ARM64 instructions.
• The high 6 bits are 00101.
• The low 26 bits are the number of instructions to jump, relative to the current instruction.

Each instruction is 4 bytes, so we just need to subtract the destination address from the source address, sign-extend to 26 bits, and set the high 6 bits to 00101.

Here's the Python code to do that:

Check it worked:

Nice! ³

Putting it all together

We now have all the building blocks we need to make a nice script that attaches to all running QuickLook processes and patches them. This article is long enough already, so instead of reproducing it here I'll just link to the repo. That way you'll get any fixes that have been made since I wrote this article, too.

You can find the latest version of the script here.

Conclusion

I am reminded of the words of the late, great Douglas Adams:

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.

Well, perhaps not impossible. But that was rather involved!

The bit where I try and sell you something

Thanks for reading. If you'd like to read more from me, I've got this article from last year about how I ported a Flash game to C++. My website has a bunch of free games I've made over the years, and I've also got two games out on Steam:

Firstly, Blackshift, an epic puzzle game which you can think of as Chip's Challenge in space.

And more recently, Hapland Trilogy, a smaller point-and-click game.

I am currently looking for my next career move. If you are hiring, please feel free to send me an email at r@foon.uk.

And if you have comments about the article, or just want to say hi, please also feel free to drop me an email.

Oh, and if you want to keep up to date with anything else I write, there's an RSS feed. RSS is coming back!

See you next time!

Robin Allen

2023