I own a MacBook. I use it. I will never love it, and it will never touch my desktop or my pocket as anything more than a tool I tolerate for professional reasons.

Before going further, a clarification: this isn’t an attack on Apple specifically. It’s a broader stance about proprietary, walled-garden computing, and Apple simply happens to be the most polished, most successful example of that model on the market today. The same reasoning is exactly why I no longer tolerate Windows anywhere I can avoid it — not at home, and not professionally when I have a say in the matter. Apple and Microsoft occupy the same category in my mind: vendors who’ve decided what “optimal” looks like on your behalf and built the walls to keep you inside that definition. This piece happens to be about Apple because I recently picked up a MacBook Neo, and it got me thinking about just how much of what Apple sells as an in-house achievement was actually built by other people first.

A Debt Apple Rarely Acknowledges Out Loud

Apple Silicon exists because of ARM, and ARM exists because of Acorn Computers and the open engineering culture of 1980s Cambridge — not because Apple built a chip architecture from scratch in Cupertino. Acorn began designing its own RISC processor in 1983 on a shoestring budget, after touring a rival lab and realizing that a much smaller, simpler design could outperform the CISC chips of the day. That processor became the Acorn RISC Machine.

Apple’s relationship with that architecture goes back further than most people realize. Apple partnered with Acorn on an experimental ARM-based prototype as early as 1985, and when Apple needed a low-power chip for the Newton PDA, it partnered with Acorn again. In 1990, Apple, Acorn, and VLSI Technology spun the processor group out into a new joint venture, Advanced RISC Machines Ltd — with Apple putting up roughly $3 million for a stake in the company. The Newton itself was a commercial failure, but the licensing model that came out of that venture — designing an instruction set once and letting anyone build silicon against it — is the entire reason ARM went on to power essentially the whole mobile industry, and eventually Apple’s own devices.

Apple didn’t get its own custom ARM cores by building them alone, either. The turning point was the 2008 acquisition of P.A. Semi, whose engineering talent and IP let Apple sign a rare architecture license with ARM Holdings, permitting Apple to design its own cores using the ARM instruction set rather than just licensing pre-built ones. The first fruit of that was the A4 in 2010. Everything since — A-series, then the M-series, then the chip inside a MacBook Neo — is a descendant of that licensed foundation, not a clean-room Apple invention.

None of this is a secret. It’s Apple’s own well-documented history. But it’s conspicuously absent from the marketing, which frames Apple Silicon as though Apple invented the concept of an efficient low-power processor. Apple has always been better at branding an inheritance as an innovation than crediting the open, cooperative engineering culture — Acorn’s included — that made the inheritance possible in the first place.

The Open-Source Debt Runs Even Deeper

It’s not just the silicon. macOS itself is a thin, tightly-controlled shell wrapped around Darwin — an open-source, BSD-derived core, built on decades of Unix engineering that Apple did not originate. The compiler toolchain most Mac and iOS developers rely on is built on LLVM and Clang, projects born and matured in the open-source community, not invented whole-cloth inside Apple. Even the Unix philosophy of small composable tools, pipes, and a real filesystem — the parts of macOS power users actually like — are inherited from the free software and open-source world, then locked back behind a walled garden and a proprietary UI.

So when Apple ships a MacBook and calls the experience uniquely “theirs,” it’s worth remembering how much of the foundation was engineered outside Apple, by Acorn’s small Cambridge team and by the open-source and free-software communities, and merely licensed, acquired, or absorbed by Apple along the way. Understanding that debt is exactly what keeps me from being impressed by the closed box it now ships in.

Necessity Is Not Endorsement

My current workflow runs across three machines, each doing a specific job:

• A CachyOS/Arch workstation (AMD, Ryzen, RDNA-class GPU) for primary engineering work
• An Ubuntu-based laptop for corporate obligations
• A MacBook, kept specifically to validate Apple-ecosystem compatibility

That third machine earns its place for reasons well beyond browser testing. Yes, Safari and WebKit still render differently enough from Chromium and Gecko that any web-facing project needs a real pass against them, and LINUXexpert.org’s tools get tested there before anything ships. But the actual justification runs wider than that: a meaningful share of readers, consulting clients, and collaborators are on macOS or iOS day to day, and validating that a script, a web app, a document, or a piece of guidance actually behaves correctly on real Apple hardware and real Apple software versions is part of doing the job properly. Font rendering, filesystem quirks, permission prompts, Gatekeeper behavior, how a terminal command actually behaves in zsh on macOS versus bash on Linux — all of it needs to be verified firsthand rather than assumed. That’s a professional obligation, not a preference. The MacBook sits on my desk the way a multimeter sits in an electrician’s bag — necessary, not beloved.

The Silicon Isn’t Even the Problem

People assume the objection to Apple is about performance. It isn’t. Apple Silicon is legitimately good engineering — efficient, fast, well-integrated with the OS scheduler. That was never the complaint.

The complaint is what surrounds the silicon: an operating system and hardware ecosystem built on the premise that Apple, not the user, gets to define “optimal.” Optimal font rendering. Optimal window management. Optimal peripheral compatibility. Optimal cloud sync. In every case, “optimal” quietly means “the one path Apple has decided to support,” and every other path is treated as user error rather than legitimate preference.

Compare that to a CLI-first, GPLv3-oriented stack: nothing is hidden, nothing is arbitrarily disallowed, and when you disagree with a default, you change it — at the config file, the kernel module, or the source level if you have to. Freedom of choice isn’t a marketing slide; it’s the literal architecture.

Lock-In Is a Business Model, Not a Side Effect

iMessage, AirDrop, Handoff, the connector ecosystem, the App Store toll — none of this is incidental. Each one is a deliberate seam that makes leaving expensive and staying convenient, right up until the moment you want to do something Apple hasn’t blessed. Then the convenience evaporates and you’re negotiating with a walled garden for permission to use your own hardware the way you want.

On Linux, the “lock-in” is your own decision to standardize — on a distro, a package manager, a config format. You can walk away from any of it without asking anyone’s permission. That’s the difference between a fence you built and a fence built around you.

Same Complaint, Different Vendor

None of this reasoning is unique to Apple, which is why I want to be clear about the actual target here. Windows earns the identical objection: a proprietary kernel, a forced-update cadence dictated by Microsoft’s calendar rather than mine, telemetry defaults that assume consent, and an increasingly aggressive push toward bundled services I never asked for. I’ve made the same call there that I’ve made with Apple — I don’t run it at home, and I avoid it professionally in every case where I actually have the choice. The common thread isn’t “Apple bad” or “Microsoft bad.” It’s that any vendor asking me to trade configurability and transparency for a smoother default experience is asking for something I’m not willing to give up, regardless of how good their industrial design or their silicon happens to be, looking at you Broadcom.

The Pricing Reflects the Toll, Not Just the Hardware

Apple’s margins aren’t a mystery. Part of what you’re paying for is silicon and build quality. A meaningful part of it is the toll for staying inside the ecosystem — the tax on convenience, on “it just works,” on not having to think about how any of it works. For a lot of people that trade is worth it. For those of us who default to owning the stack top to bottom — kernel, drivers, package manager, init system — it’s a trade we’d rather not make, because we’re not buying magic, we’re buying dependency.

The Line I’ve Drawn

So here’s where I’ve landed, plainly:

Apple hardware and software are things I use where the job genuinely requires it — validating ecosystem and browser compatibility being the clearest example — and nowhere else. Not as a desktop daily driver. Not as a phone. Not by default, not by convenience, not by “well, everyone else already has one.” Windows gets the same treatment, for the same reasons.

My daily driver is, and will remain, AMD hardware running Linux — CachyOS on the workstation, Ubuntu where corporate policy requires it, open tooling everywhere I have a say. That’s not nostalgia for the command line; it’s a considered position that the freedom to configure, inspect, and replace every layer of your stack is worth more than a marginally smoother out-of-box experience.

Tolerating a tool professionally and choosing it personally are two different acts. I do the first with Apple products, and with Windows where I absolutely must. I will not do the second with either.

Have thoughts on ecosystem lock-in, right-to-repair, or building a CLI-first, vendor-neutral workflow? Reach out — LINUXexpert.org exists to make the case for open, user-controlled computing, one workflow at a time.