I Finally Got a Mac. Here's What It Taught Me About Only Building for One OS.

#ai #ios #html #javascript

I picked up a Mac recently. Nothing dramatic — no grand migration story, no "Windows finally broke me" moment. I just ended up with one, and it made me realize something a little embarrassing: as someone who's shipped a genuinely large number of Chrome extensions, a few desktop tools, and a browser arcade under the DHSeaDev name, I had put almost zero thought into the Apple ecosystem. Not out of dislike. It just never came up. My tools worked, my users were on what they were on, and I kept building.

So this is the post where I admit that, and talk about why "what operating system does this run on" deserves more of a developer's attention than it usually gets — even when, like me, you get lucky.

The lucky part first

Most of what I build lives in the browser. Chrome MV3 extensions are basically OS-agnostic by design — they run wherever Chrome runs, and Chrome runs everywhere that matters. So the honest first finding here is: nothing broke. I installed Chrome on the Mac, logged into my dev account, and every extension I've shipped just worked, sync and all. Same for the browser-based games and tools I've built for the DHSeaDev arcade — they're just web pages. A browser doesn't care what OS is under it, and that's a genuinely nice property to have accidentally built toward.

That's not nothing. A lot of developers find out the hard way that "cross-platform" was actually "cross-platform as long as everyone uses Windows." I got that for free because I picked a browser-first architecture years before I had a reason to care about portability. Worth remembering next time you're picking a stack for something new: the platform-independence payoff might not show up for a long time, and then one day you buy a laptop and it's already paid for itself.

Where it's not free: native desktop tools

The story changes the moment you leave the browser. I've got a handful of internal PySide6 desktop tools — things like an internal document utility suite and an analytics dashboard for my day job at a legal process-serving firm. PySide6 (Qt) is cross-platform in theory, and mostly in practice, but "runs on macOS" and "feels native on macOS" are two very different bars. Native window chrome, dark mode behavior, file dialogs, keyboard shortcuts that macOS users expect (Cmd instead of Ctrl being the least of it), and packaging are all places where a Windows-built Qt app can feel like a guest wearing someone else's coat on a Mac.

And packaging is its own adventure. On Windows I'm used to a PyInstaller build and maybe an Inno Setup installer, and I'm done. macOS wants a signed, notarized .app or .dmg if you want it to run without the user fighting Gatekeeper — that means an Apple Developer Program membership (still $99/year as of this writing), codesigning, and submitting the build to Apple's notarization service before it'll launch cleanly on someone else's machine. It's not hard, but it's a real extra step that doesn't exist in the Windows world, and skipping it means every user has to right-click-and-open their way past a scary warning dialog. That's a bad first impression for a tool that's supposed to make someone's day easier.

None of this is a complaint. It's the kind of gap you don't see until you're standing in it.

The upside: a whole platform I hadn't been building for

Here's the part I'm actually excited about. Having a Mac in hand isn't just "now I have to test on it" — it's a green light to start building for it on purpose. macOS has its own conventions, its own distribution paths (direct download and notarization, or the Mac App Store if a tool fits those rules), and its own audience that's historically underserved by a lot of indie/internal tooling that defaults to Windows-only. A menu bar utility, a proper native companion app, something built with SwiftUI instead of ported in from Qt — that's a new lane, not just a compatibility checkbox.

It also reframes how I think about my existing native tools. The PySide6 apps I've built were written Windows-first, which means "port to Mac" is really "go back and find every place I assumed Windows," and fix it properly instead of papering over it. That's worth doing even if I never ship a Mac build to anyone outside myself, because it's the kind of assumption-hunting that also quietly improves the Windows build.

The actual takeaway

If you build software and you've only ever developed on and for one operating system, it's worth asking yourself why — and whether the answer is "a deliberate architectural choice" or "I just never had a reason to check." Those are very different positions to be in. Mine turned out to be the second one, and I got lucky that my main body of work (browser-based tools and extensions) didn't care. My native desktop tools weren't so lucky, and now I know exactly where the assumptions are hiding.

Consider this your nudge, the same way mine came in a shipping box: if there's a whole ecosystem you've been building software for millions of people on without ever touching, go touch it. You'll either confirm your architecture was more portable than you gave it credit for, or you'll find the gaps while they're still cheap to fix.

DEV Community

I Finally Got a Mac. Here's What It Taught Me About Only Building for One OS.

The lucky part first

Where it's not free: native desktop tools

The upside: a whole platform I hadn't been building for

The actual takeaway

Top comments (0)