There is a machine in most mature Mac test labs that nobody defends in a planning meeting and nobody quite turns off. It is an Intel MacBook Pro, probably from 2019 or 2020, running an operating system it can no longer upgrade past. It is slower than everything around it, it costs money to maintain, and every quarter someone proposes retiring it. For the last two years, Ishak Badanga has been the person arguing that it stays.
The argument is about to expire on its own terms. In September 2025, Apple shipped macOS 26 Tahoe as the final version of macOS that will run on Intel hardware at all. macOS 27, arriving this month, will not boot on an Intel Mac under any circumstance, and it is the last release in which Rosetta 2 the translation layer that has quietly executed Intel-compiled code on Apple silicon since 2020 remains a fully supported, general-purpose tool. After that, in autumn 2027, Apple retains only a narrow subset of Rosetta aimed at unmaintained gaming titles that depend on Intel-based frameworks. Everything else stops. Apple announced this at its Platforms State of the Union in June 2025 with unusual precision for a company that rarely commits to deprecation windows publicly. It gave developers a two-release runway and named the end of it. That runway has now been consumed, and, according to Badanga, the industry’s response has largely been to file it away.
Badanga spent close to four years as a Quality Assurance Engineer at Sora Union, where one of the products he owned test coverage for was Airtime, which ships a macOS desktop client alongside its web application. Desktop distribution on the Mac is not a large surface compared with the web, but it is an unforgiving one: a bad build is not a rollback, it is an installed artefact on a user’s machine that has to be replaced.
His test matrices for the 2.5.0 release cycle split coverage explicitly by silicon — one column for Apple silicon, one for Intel rather than treating architecture as an environment variable folded into a single pass. That distinction sounds procedural. In practice it is the difference between having a regression suite and having a regression suite that means anything during a transition.
The reason is that the interesting failures in a dual-architecture period are almost never in application logic. They are in the seams. A universal binary is two slices of compiled code in one container, and the slices can diverge in ways that a functional test written against user-visible behaviour will never touch. A native dependency gets pulled at install time and resolves to the wrong architecture. A helper process, a background launch agent, or a codesigned plugin ships as x86_64 while the host application ships universal, and the whole thing runs correctly on an Apple silicon Mac purely because Rosetta translated the odd one out without telling anyone. The application worked. The test passed. The build was, in a way that nothing in the pipeline reported, broken.
Then there is concurrency. Intel processors implement a strong memory ordering model; ARM64 implements a weaker one, where a compiler or processor has more freedom to reorder memory operations unless the code explicitly says otherwise. Rosetta 2 handles this by running translated code in a mode that preserves the stricter Intel ordering guarantees. Code that natively contains a latent race, a missing barrier, an unsynchronised shared structure — can therefore run for years under translation and only surface once the same logic is compiled and executed natively on Apple silicon. The bug was always there. Translation was holding it still.
Page size behaves similarly. Intel Macs use 4KB memory pages; Apple silicon uses 16KB. Anything that assumed page alignment, mapped file behaviour, or buffer sizing derived from the page constant has a different runtime reality on each side, and the assumption is usually buried in a dependency rather than in code anyone on the team wrote. None of this is exotic. It is precisely the category of defect that becomes visible only when you deliberately test both architectures natively and invisible the moment you allow a translation layer to sit in the path.
What distinguishes Badanga’s approach is less any single technique than the sequencing. He treated architecture as a first-class test dimension while the compatibility layer was still there to catch mistakes, rather than after it was withdrawn. That meant maintaining structured test-case libraries where the architecture of the machine under test was recorded as part of the case, not the run notes, so that a defect could be attributed to a slice rather than to a build. It meant keeping the web regression suite and the desktop suite deliberately separate, because the two answer different questions and collapsing them lets desktop-specific packaging failures hide behind an all-green web pass. And it meant retaining Intel hardware in the estate long after the finance case for it had weakened, because once the last Intel Mac leaves the lab, the ability to reproduce a customer’s environment leaves with it, and there is a long tail of users who will stay on Tahoe for years rather than replace working machines.
The infrastructure question is the one most teams underestimate. Continuous integration providers are retiring Intel capacity on their own schedules, and those schedules are tighter than Apple’s. GitHub retired its macOS 13 runner image in December 2025, introduced a ‘macos-15-intel’ label as the migration path, and has stated that this is the final x86_64 image it will offer, available until August 2027, after which the architecture is not supported on GitHub Actions at all. A team that has not audited which of its pipeline steps still resolve to an x86_64 binary a build script, a packaging tool, a signing utility, a Homebrew formula pulled in three layers deep discovers the dependency when the runner disappears, not before.
Apple has done this before. The original Rosetta, which translated PowerPC code during the move to Intel, was removed in Mac OS X Lion in 2011, roughly five years after that transition began. The Apple silicon transition began in 2020, and the general-purpose translation layer ends in 2027. The interval is almost identical, and so, by most accounts, is the industry’s preparedness. The difference this time is the scale of the installed base and the quiet efficiency of Rosetta 2 itself. It worked well enough that a large number of applications never needed to be recompiled to remain usable, which removed the commercial pressure that normally drives migration. Apple has been applying that pressure artificially instead: from macOS 26.4, users launching an Intel-only application see a system notification warning that support is ending, reissued after each restart rather than shown once. macOS 27 goes further, removing Rosetta during the upgrade and requiring users to reinstall it deliberately the first time they need it. The friction is the message.
For a QA function, the implication is specific. Every one of those prompts is a support ticket waiting to be filed by a user who cannot tell the difference between an operating system warning and an application defect. Test plans that cover only whether the software works have nothing to say about whether the software is about to generate a support load. Badanga argues that this belongs in the coverage too – that the environment a build lands in is part of the surface under test and that a QA engineer who reads deprecation notices is doing the job, not straying from it.
Badanga’s work has not been confined to one product. He has held a Senior Quality Assurance Engineer role at Prunny Technologies, whose portfolio includes CTMFB, a CBN-licensed digital microfinance bank, and EFactory, an electricity vending platform — environments where a defect is a financial event rather than an inconvenience and where staging audits and structured test-case discipline carry regulatory weight rather than merely engineering weight. Alongside that, he has built and delivered a three-month QA training curriculum, and served as a volunteer mentor and coach to software engineering and QA students at Crescent University, a position he was selected for as one of five candidates from a field of more than five hundred.
The through-line is a view of quality assurance that is unfashionable in an industry that has spent a decade trying to automate the discipline into a pipeline stage. Badanga’s position is that automation tells you whether the thing you thought to check is still true, and that the value of a QA engineer is in the checks nobody thought of, which requires understanding the platform underneath the product, including the parts of it that are scheduled to be removed.
The last Intel Mac in the lab has perhaps a year of usefulness left. After that, the machines it was there to reproduce will run an operating system frozen in September 2025, and the code that used to run under translation will either have been recompiled or will have stopped. Badanga’s case is that the interval between now and then is not a countdown to be waited out. It is the last period in which a team can find out what it got wrong while the safety net is still up.
About the Author: Ishak Badanga is a Quality Assurance Engineer specialising in cross-platform regression testing and release quality for consumer and financial software.