If you look after Macs, you’ve probably already asked yourself (or perhaps your print provider) whether your print management client runs natively on Apple Silicon. That’s a good question. But there’s more to the situation than first appears.
Apple’s transition to its own silicon is entering its final phase, and macOS 27 AKA “Golden Gate” (expected mid-September), is the milestone that matters. When a Mac upgrades to macOS 27, Rosetta 2 is uninstalled. Rosetta (I’m dropping the ‘2’ from now on) is the translation layer that’s quietly kept Intel-only software running on Apple Silicon Macs for the past few years. You can manually reinstall Rosetta with macOS 27, but that’s a temporary fix that will fail with the installation of macOS 28 in 2027.
Most teams will check their print application, see a green tick, and move on. But printing isn’t one piece of software. It’s a chain of applications, print queues and the printer drivers they use, and every link in it has to run on the same architecture as everything else.
So here’s the thing: your print-management software may be ready for Rosetta’s end of life. Your printer driver might not be.
Apple’s transition is entering its final phase
None of this should feel like an ambush. Apple Silicon was a deliberate architectural break, and Rosetta was always described as a bridge rather than a destination; a way to keep the old world running while developers caught up. And it turns out macOS 27 is where that bridge is dismantled for most Macs.
The useful thing about a known milestone is that you can plan around it. You have a rough date, a published direction of travel, and a fleet you can inventory before anyone clicks “Upgrade”. Treated that way, macOS 27 is a deadline. Treated as a surprise in October, when a site full of Macs stops producing stapled duplex output and nobody can explain why, it becomes an incident.
The difference between those two outcomes is almost entirely about what you check between now and September (assuming that’s macOS 27 release month).
The risk is bigger than the print application
The instinctive question “is our print client native?” is necessary and nowhere near sufficient. A single print job touches more of your estate than most software you own:
Printer drivers and vendor utilities: Manufacturer driver packages, configuration tools, scan utilities and helper processes, some of which haven’t been rebuilt in years.
The one most likely to trip you up is the printer manufacturer’s driver. In macOS, the basis of a printer driver is a plain-text file called PostScript Printer Description, or simply PPD. It is a blueprint of the printer’s capabilities. On its own, it will cause no issues running on Intel or Apple Silicon Macs. Where the problem comes in is when the PPD links to a custom:
- Filter, used to transform the printer language to a language the printer supports.
- Print Dialog Extensions (PDEs), used to inject custom menus (like stapling, booklet creation, or accounting codes) directly into the macOS print dialog box.
Some printer manufacturers also install custom back-ends, which are used for custom submission to the printer.
If any of these three were built only for Intel, then the user will receive a “This printer software is not compatible with this device”
Print queues and deployment packages: The MDM payloads, scripts and installers that put those queues on a Mac in the first place.
Older hardware: Devices still working perfectly well, sold by vendors who may never ship an Apple Silicon-native update for them.
An Apple Silicon-native application sits inside that environment. It doesn’t convert it. You can have a fully native print client and still have a user who can’t print to the finisher on level three, because one Intel-only component in the path never got rebuilt.
This is the part worth slowing down on, because it’s the part that tends to get skipped.
Printing exposes hidden dependencies
Print environments accumulate dependencies the way garages accumulate boxes. At least at my place anyway. Most of them are invisible until something moves.
The trigger is rarely dramatic. A new Mac gets deployed. A user upgrades over the weekend. An MDM push lands. Someone selects a finishing option nobody has used since the last hardware refresh, and a legacy driver tries to run Intel-only code that has nowhere left to run.
What you get isn’t a clean, fleet-wide outage. It’s worse than that: inconsistent failure. Printing works at one site and not another, on one Mac model and not its neighbour, for most documents but not the ones going to the production device. That pattern is far harder to diagnose than total failure, and far harder to support.
Apple’s error handling doesn’t help you here. When a background component can’t run, macOS tends to surface something generic:
- A message saying software is not compatible with this device
It won’t tell you which component, and it won’t point at the driver. Which is exactly why admins facing macOS 27 print software ‘not compatible’ messages may not realise the actual cause is an unrelated legacy driver deeper in the stack.
One genuine mitigation: driverless printing. AirPrint and standards-based IPP shift the work into the OS and cut your exposure to legacy Intel-only driver packages considerably. If you can print driverlessly, do. But plenty of organisations still depend on manufacturer drivers for secure release, accounting, finishing or especially older fleet devices, so “just use AirPrint” isn’t a universal answer. It reduces risk. It doesn’t eliminate it.
A 6-step readiness plan for preparing your print stack in macOS 27
Here’s the sequence worth working through before macOS 27 lands on real desks. It’s not complicated. It just has to actually happen before you break printing.
1. Discover Intel-only components
Inventory applications, printer drivers, vendor utilities, and helper processes across your Mac fleet and flag anything that isn’t native or universal.
2. Identify where each one is deployed
A single unsupported driver matters very differently at one site with one device than across four campuses.
3. Test representative workflows on Apple Silicon hardware
Not “does the app open” — print to the devices people actually use, with the finishing options they actually select, through the authentication method they actually have.
4. Update software and MDM packages first
Deployment payloads, installers, and scripts need to be current before the OS moves, not after.
5. Phase the rollout
Start with a defined group, watch what breaks, then widen. Fleet-wide on day one gives you no signal and no rollback.
6. Plan for exceptions
Some devices will never get updated vendor software. Decide now what happens to those workflows (driverless queue, alternative device, replacement schedule) and write it down.
Note that where there are exceptions, such as no native Apple Silicon driver is available, Rosetta can be reinstalled manually and used until macOS 28 comes out.
Steps one to three can start today and don’t depend on anyone else’s release timing.
Where PaperCut fits
By the time you’re reading this, most of PaperCut’s Mac components already run natively on Apple Silicon. We’re on track for full native support in September, when the last remaining pieces are due to ship, completing our own transition ahead of or alongside the wider shift, rather than behind it.
We’re also testing end-to-end print workflows as we go, and talking to printer manufacturers to understand the wider driver landscape, because being native ourselves is only half of your picture.
To be straight about the limits: we can’t make every manufacturer’s driver Apple Silicon-ready. Nobody can do that on your behalf. What we can do is help you work out where your dependencies sit, what to test, and which questions to put to your vendors while there’s still time to act on the answers.
The best migration is the one nobody notices
It’s easy to turn this into an architecture story. It isn’t one. It’s a continuity story.
Nobody in your organisation should need to know what Rosetta was, which processor is in their Mac, or how a driver package is compiled, in order to print a document on the morning after an OS upgrade. If they never think about any of it, you’ve done the job properly. Technical compliance is the floor here; an uneventful Monday is the actual goal.
For the full technical detail including compatibility guidance and our driver compatibility tool, see the PaperCut Knowledge Base article. It’s a living document, updated as the transition progresses and as vendors confirm their own plans, so it’s worth checking back rather than reading once.
FAQ
Q What's the difference between Intel-only, universal, and Apple Silicon-native software?
Intel-only software was built for Intel processors and needed Rosetta to run on Apple Silicon. Native software is built for Apple Silicon directly. Universal binaries contain both, so they run on either without translation.
Q Will my Mac stop printing the day I upgrade to macOS 27?
Probably not entirely — but specific things may stop working, and the failures tend to be partial and inconsistent rather than total. That unpredictability is the real risk to plan for.
Q Is there a temporary workaround if my printer driver isn't ready?
Yes. With macOS 27, you can manually reinstall Rosetta. However, it’ll stop working permanently with the release of macOS 28 in 2027.
Also, driverless printing via AirPrint or standards-based IPP will cover basic output for many devices. It won't necessarily cover secure release, accounting or finishing features, so treat it as a bridge and keep pressure on the vendor.
Q What's the real deadline — macOS 27 or macOS 28?
Plan for macOS 27. Even where narrow exceptions exist, the practical deadline is the point at which your users can upgrade — and they will.
