Getting an Old-School Utility to Run on Modern macOS: Notes from a Friction-Filled Install

I finally got around to setting up MacFormat Floppy Manager (app) on macOS, mostly out of nostalgia and partly because I needed to read some ancient disk images for a side project. This one comes from OrchardKit, and on paper it’s exactly the kind of small, focused utility I like: no cloud nonsense, no account, just a tool that does one slightly weird thing well. In practice, though, macOS made me work for it.

The goal was simple. Install the app, open a couple of legacy floppy images, export their contents, move on with my day. I’m on macOS Sonoma 14.4 on an M1 MacBook Pro. Clean system, SIP on, nothing exotic. I figured this would be a five-minute job.

It wasn’t.

The first launch that never really launched

Installation itself looked fine. Downloaded the DMG, dragged the app into Applications, double-clicked. macOS threw the usual Gatekeeper dialog about the app being from an unidentified developer. I clicked “Open” without thinking too hard about it.

The Dock icon bounced once. Then nothing.

No window, no crash dialog, no helpful “this app quit unexpectedly” message. Activity Monitor showed it appearing for a split second and disappearing. That’s usually the moment where you suspect a broken build, but I’ve seen this exact behavior before with utilities that touch disks or low-level file formats.

My first bad idea was reinstalling. I deleted the app, re-downloaded it, repeated the process. Same silent exit. Then I tried launching it from Terminal just to see if anything obvious would print to stdout. Nothing useful. Dead end.

At this point I stopped blaming the app and started looking at macOS.

What actually broke (and why it was subtle)

The key detail with tools like this is that they tend to poke at places macOS considers sensitive: removable media, raw disk images, sometimes even older filesystem APIs. Gatekeeper doesn’t always block them outright. Sometimes it allows the binary to start, then quietly denies access to something essential during initialization.

Apple’s own docs hint at this behavior, especially for apps that aren’t fully notarized or that request protected resources early in their lifecycle:
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac

That explained the “blink and you miss it” launch. The app wasn’t crashing. It was being politely suffocated.

I went into System Settings → Privacy & Security and scrolled. Sure enough, there was a note saying the app had been blocked from running because it wasn’t from an identified developer — even though I’d already clicked Open. That mismatch is classic macOS.

What finally worked (and why)

The fix was annoyingly simple, but only after you know the trick.

I removed the app again, reinstalled it, and this time didn’t double-click. I right-clicked the icon, chose Open, confirmed the dialog, and then immediately went back to Privacy & Security while the app was starting. There was a new “Open Anyway” button waiting there. Once I clicked that, the next launch actually stuck.

On first successful run, macOS prompted for access to removable volumes. I allowed it. Only after that did the UI fully initialize.

Apple explains this permission flow more clearly from the developer side, but the behavior applies to users too:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

After that hurdle, the tool behaved exactly as advertised. Disk images mounted, directory structures showed up correctly, exports worked. No instability, no weird delays. It just needed macOS to trust it enough to breathe.

I also checked whether there was a sandboxed version in the App Store, mostly out of curiosity. There isn’t an obvious listing, but Apple’s official search is still the safest way to confirm:
https://apps.apple.com/us/search?term=MacFormat%20Floppy%20Manager

While I was troubleshooting, I bookmarked this page because it described the same macOS security behavior around older file utilities and Gatekeeper restrictions in a way that matched what I was seeing:
https://technotafastore.xyz/file-management/54749-macformat-floppy-manager.html

That was the confirmation that this wasn’t some unique edge case on my machine.

One small false lead

For about ten minutes, I suspected Rosetta. The idea was that maybe the app was Intel-only and doing something odd on Apple Silicon. I forced it to open under Rosetta via Finder’s “Get Info” panel. Same silent exit. That wasn’t it. Once Gatekeeper and permissions were handled properly, it ran fine natively.

How I’d do it again, knowing what I know now

If I had to set this up on another Mac tomorrow, I’d do it in a very specific order:

• Move the app to /Applications before launching
• First launch via right-click → Open, not double-click
• Keep Privacy & Security open during the first run
• Approve removable media access immediately

That’s it. No reinstall loops, no Terminal voodoo.

The funny thing is that once you get past that initial friction, the utility itself is refreshingly boring. It does its job and gets out of the way. Most of the drama came from macOS trying to protect me from software that dares to remember what a floppy disk is.

If you ever need to deal with old media formats on a modern Mac, this kind of hiccup is just part of the territory. The trick is recognizing when the problem isn’t the app, but the OS quietly saying “I don’t trust you yet.”