Retroactive: an unsigned compatibility shim for Apple's abandoned Mac apps

No licence file, and two README promises that depend on one

Retroactive's README makes an open source argument twice, and the repository does not support it.

The first instance is in the Gatekeeper section. The alert is expected because Retroactive is not notarized, and the reassurance that follows is that Retroactive will not harm your Mac and that this alert only shows up because Retroactive is not notarized, followed by: Retroactive is open source, so you can always examine its source code to make sure it's safe.

The second is in the authentication section, where the tool asks for your macOS login password and states that your password is never stored or sent anywhere. To verify this, you can view Retroactive's source code.

Both claims reduce to the same instruction: check the code. And the repository listing at the top level is .gitignore, README.md, Retroactive.xcodeproj/, Retroactive/, TRANSITION.md, genstrings/ and screenshots/. There is no LICENSE file, and the repository's licence field reads as unknown.

The distinction matters, and it is a legal one rather than a technical one, so it is worth stating plainly rather than leaving implied. Source code that is published is not automatically open source. Publishing lets you read. Open source requires a licence granting the right to use, copy, modify and redistribute, and its absence leaves you with the default position under copyright, where the author retains all rights and you have none beyond reading. So the instruction to verify the password handling by reading the source is available to you, and so is the right to build a fixed version yourself, because the code is there to read either way. What you do not have is a grant.

For a utility that writes into your Applications folder using an administrator credential, that gap is the first thing to resolve. If you need a modified build, an internal distribution, or any assurance beyond your own reading, you have to ask the author, not infer permission from a GitHub page.

An unsigned binary that asks for your admin password

The trust surface of Retroactive is the part of the design that deserves the most attention, and the README describes it accurately rather than deflecting.

You download the release archive straight from the GitHub releases page, extract it and double-click the app to open it. The 3.0 download is a single zip:

https://github.com/cormiertyshawn895/Retroactive/releases/download/3.0/Retroactive.3.0.zip

macOS will say Retroactive cannot be opened because it is from an unidentified developer, and the README says that this is expected. The documented path is System Settings, then Privacy & Security, then scroll down and click Open Anyway, which it links to Apple's own support article. That is the standard manual override for an unnotarized developer, and it is a bypass you perform deliberately on a binary with no signing identity behind it.

The next step is the one with actual consequence. To install or modify the app you chose, you authenticate with your login password: click Authenticate and enter your login password. That is a real administrator credential handed to an unsigned application, and the password is not a sandboxed, scoped token that the tool could abuse for one operation. It is the account that can write to /Applications.

Later, and for iTunes specifically, there is a second privilege escalation. After installing iTunes, Retroactive asks about iPod syncing, and if you need to sync with iPod devices you click Enable Full Disk Access. Full Disk Access on a modern macOS is one of the broadest permissions a process can hold, and it is granted through the same click-to-confirm pattern as the password.

The mitigations the project offers are all of the same kind: the source is available, the password is not stored or sent, and the behaviour is limited to modifying the app you picked. That is a coherent position for a personal utility and an uncomfortable one in an enterprise context, where the same three facts are usually insufficient. If you deploy this on a work machine, the unnotarized signature and the full-disk grant are the two things your security team will ask about, and neither has an answer in the documentation.

Rosetta 2 leaves macOS 28, and this is the last macOS for Aperture

Retroactive has a stated expiry date, and the project says so before you install it rather than after.

Because Rosetta 2 will be removed from macOS 28, macOS Golden Gate is likely to be the final version of macOS to support running Aperture, iPhoto and iTunes through Retroactive. The word doing the work there is likely. The author is not promising Golden Gate works, only that it is the last candidate.

The escape hatch is described in a footnote, and it is worth reading at the right level of confidence. It may theoretically be possible to modify Aperture, iPhoto and iTunes in a way that makes macOS 28 treat them as older, unmaintained games, which would continue to run under a subset of Rosetta functionality. And because those applications likely depend on frameworks beyond that remaining subset, they may need to be augmented with x86_64 frameworks extracted from the dyld shared cache from macOS Golden Gate using dsce.

Two hedges, two different mechanisms. The first, the game-classification trick, is presented as theoretical. The second, the dyld shared cache extraction, is presented as a likely requirement if you pursue it, and it points at a separate tool rather than anything Retroactive does itself. Nothing in the repository listing suggests Retroactive contains that capability; dsce lives in its own repository and the reference is a pointer, not a feature.

What this means practically is that Retroactive's long-term value is a migration clock rather than a permanent solution. The README's TRANSITION.md is the same message at document length, and the alternative-app lists in the README are organised by exactly the three apps that have a deadline: Music, TV, Podcasts, Books and Finder for iTunes, with Windows via Parallels Desktop or VMware Fusion as the path for the App Store and device-sync parts that have no macOS equivalent; Photos, Darktable and RawTherapee as the free options for Aperture and iPhoto, with AfterShot Pro, Capture One Pro, Darkroom, DxO PhotoLab, Lightroom, Lightroom Classic, Luminar Neo and Photomator as the paid ones; and XML export into DaVinci Resolve, Media Composer or Premiere Pro for Final Cut Pro 7, with SendToX as a route into a current Final Cut Pro.

Note the asymmetry in that iTunes line. A Windows VM genuinely preserves the old iTunes, while Aperture and iPhoto have no such option because there is no Windows version to run.

The app matrix inverts as your macOS gets newer

Retroactive's capability set runs backwards from how most software behaves, and reading the two lists side by side is the fastest way to understand it.

On macOS Golden Gate, Tahoe, Sequoia, Sonoma, Ventura, Monterey, Big Sur and Catalina, Retroactive can unlock Aperture and iPhoto, or install iTunes. On macOS Mojave and High Sierra, it can also unlock Final Cut Pro 7, Logic Pro 9, Xcode 11.7 and fix iWork 09. Xcode 11.7 additionally requires Mojave, and Logic Pro 9 is labelled experimental.

So the newest macOS gets the fewest apps, and the oldest supported macOS gets the most. That is not an arbitrary design choice. The older the applications, the more of their dependencies have been dropped from the OS, and the deeper the patch has to reach. A 2009 iWork and a 2013 Final Cut Pro 7 need substantially more surgery than a 2015 iPhoto, and a version of macOS old enough to still carry the frameworks those apps need is itself old enough to be hard to run.

Two practical consequences. If you are on a current Mac and have an Aperture or iPhoto library, Retroactive is your route and the app list is the whole of it. If you are trying to rescue Final Cut Pro 7, Xcode 11.7 or iWork 09, you are being pointed at Mojave or High Sierra, and the honest reading of the documentation is that you need that machine to exist, not that you need to buy that machine. A separate Mac you own, an AirDrop or a Time Machine restore is how the README expects you to source an app that was never on the computer in front of you.

The single-app rule is also explicit. Pick the app you want to run, and if you want to run multiple apps from here, pick any one of them, because you will always be able to get back to this screen later. Retroactive is a one-target-at-a-time tool, not a bulk rebuilder.

Which iTunes, and what to do when 12.9.5 will not install

iTunes is the one application where Retroactive makes a compatibility decision for you, and it is the only place in the flow where choosing wrong costs an hour.

If you chose iTunes, Retroactive asks which version to install and then downloads and installs it automatically. The four options are separated by what they can do rather than by date alone. iTunes 12.9.5 supports Dark Mode and most DJ apps. iTunes 12.6.5 supports Ringtones and iTunes U. iTunes 11.4 has a classic look. iTunes 10.7 supports CoverFlow. If you do not know which version you want, the advice is to keep the default and click Continue.

The default is therefore 12.9.5, and that is the version with the reported failure mode. The modifying step, which takes about two minutes for Aperture, iPhoto, Final Cut Pro 7, Logic Pro 9, Xcode 11.7 and iWork 09, can take between ten minutes and an hour for iTunes. The fans spinning up during that time is normal, so is being asked for your login password a second time. And if iTunes 12.9.5 cannot be installed, the documented fallback is to try 12.6.5.

That last line is the most useful sentence in the section, and the reason to read the version list before you start rather than after an hour of waiting. 12.6.5 is not a strictly worse fallback, because it is the version that supports Ringtones and iTunes U, which 12.9.5 is not listed as supporting. If you have old ringtones or a library of iTunes U content, 12.6.5 is the version you wanted and the default was the wrong one from the start.

For device work the README points elsewhere entirely. Archiving iPhone and iPad apps is listed under tools including Asspp, IPATool, iMazing and Apple Configurator, with a tutorial video for Configurator hosted in the repository under Retroactive/Support/. Retroactive's own scope is the iTunes application, and the archive-and-restore tooling is somebody else's job.

Getting the app in the first place is often the hard part

Retroactive patches an application you already have. It does not contain Aperture, and the README is direct about the ways you might not have it.

Retroactive will automatically scan your Mac to locate an existing Aperture, iPhoto, Final Cut Pro 7, Logic Pro 9, Xcode 11.7 or iWork 09 install, and if it finds the one you want you skip to the next step. If it cannot, you are either asked to download the app or to reinstall it from a DVD disc. Two more routes are named: find the app on another Mac you own and AirDrop it to this Mac, or restore the app from a Time Machine backup.

The DVD route is the one people forget exists. Aperture, iPhoto, Final Cut Pro 7 and iWork 09 all shipped on physical media, which means the most reliable source for a genuinely old copy is a disc rather than a download, and it means the app has to be on a machine that still has an optical drive or an external one. The AirDrop route has an obvious constraint in the phrase another Mac you own, and it requires that Mac to still have the application installed. The Time Machine route requires that the application was ever in a backup, which for a discontinued app on a machine that has since been reinstalled is often not true.

None of this is a criticism of Retroactive, which is doing the part it can do. It is a warning about the shape of the task. The compatibility problem and the licensing-archive problem are different problems, and this tool solves the first while depending entirely on you having already solved the second. Anyone whose iPhoto library exists only as an .aplibrary file on a disk they no longer have is not in Retroactive's reach at all, and the migration list, not the patcher, is the relevant document for them.

The repository also contains a genstrings directory, the macOS command-line tool for extracting and generating string catalogues, which tells you the app is localized rather than English-only, and a screenshots directory that the README references for its screenshots.

Two years between major versions, and a 3.0 that landed on the last push

The release history says something about how to treat this tool.

Version 2.0 was tagged 2022-09-02, version 2.1 on 2024-02-18, and version 3.0 on 2026-06-28. That is a major version roughly every two years, and the last push was on 2026-06-28, the same day as the 3.0 tag. There is no 3.1 and no development branch activity since.

For a utility whose entire reason to exist is a moving target, that is the right shape. Retroactive has to be revised when Apple ships a macOS, and macOS is what sets the schedule. A major bump per OS generation is a sensible response, and the 3.0 release landing in the same window as the Golden Gate support claim fits the pattern of a release prepared for the last macOS before Rosetta 2 goes away.

It also means the code you read today is the code that has to work on tomorrow's macOS until version 4.0 exists, and until then the failure mode is not a bug report but an app that stops launching. There is no compatibility matrix in the repository listing, no test suite visible from the top level, and no CI configuration in the entries. Retroactive.xcodeproj/ means you can build it in Xcode if you want to, which is the practical answer to the trust question from earlier, but building from source is only half of it: without a licence, a build you produce is yours alone, not something you can hand to a colleague or a colleague's team.

The practical reading is that Retroactive is best treated as a tool you use once, to extract what you need, and then move on from. The migration document in the repository, TRANSITION.md, is arguably the more valuable artifact for anyone starting today, because it describes where the data goes rather than how to keep the old app running.

Editorial conclusion

Use Retroactive if you own an Apple application that no longer launches on your Mac and you have read enough of the source to be comfortable with what it does, because the alternative for a 2013-era iPhoto library is a manual export you may not be able to do at all. Do not use it on a machine you cannot afford to restore, and do not rely on the README's open source framing as a licence, since no LICENSE file exists in the repository and the default position on undeclared copyright is that you may read the code and not modify or redistribute it. Verify four things. Confirm the app you need is still in the matrix for your macOS version, because Final Cut Pro 7, Logic Pro 9, Xcode 11.7 and iWork 09 are Mojave and High Sierra only. Decide which iTunes version you actually want before starting, since 12.9.5 and 12.6.5 support different features. Make sure you actually have the app to patch, from a DVD, an AirDrop or a Time Machine restore, because Retroactive cannot fabricate Aperture. And read TRANSITION.md, which is the document that matters if Rosetta 2's removal from macOS 28 becomes your problem rather than your neighbour's. The deciding factor is not whether the patch works, which it evidently does, but that you are running an unnotarized binary with administrator rights and no declared terms.

Frequently asked questions

Official sources

1. cormiertyshawn895/Retroactive on GitHub
2. Issues
3. README
4. Releases