The key issue is that hardware drivers aren't there, and that requires a massive amount of reverse engineering work.
Apple could release documentation for the hardware, making things easier, but from apples point of view that opens them up to patent litigation (you can be sure trolls will scour the documentation for evidence of violated patents), and most internal documentation isn't of sufficient quality to release without at least someone reading it all over and removing swearwords...
Collecting the documentation together will be hard - it is probably scattered amongst hundreds of git repos, wikis, documents, spreadsheets, photos of whiteboards, on some engineers laptop, and mixed in with code and secrets.
Even then, without a lot of people putting a lot of effort in, you wouldn't see desktop linux running...
Overall, I can see why Apple doesn't help these guys - the disadvantages outweigh the advantages.
I know Apple drops open source blobs for iOS. Do the kernels not include drivers? Especially as Apple takes over more of the BOM through vertical integration, there's less stuff they would need to suppress because of contracts (but of course that doesn't mean they do include other things).
This might be semantics, but the fact that unlocking the bootloader or running code with the highest level of privilege on an iPhone requires exploits in the first place is a pretty big sign that these platforms are pretty closed. Checkra1n is very nice but this is an oversight that Apple is unlikely to make again (the only way Checkra1n was found in the first place was Apple fixing the underlying issue on Apple A12 devices anyway).
Unfortunately I think the existence of Apple's Security Researcher Device program squashes any hopes that Apple would consider opening up store bought devices any further. The only real way I see Apple opening iDevices if some regulation to that effect would be enforced, but I don't see that happening any time soon either.
I mean I get why one would want unrestricted access to hardware, custom software, etc, but at the same time I understand the resistance to allowing it. In Apple's case, security is really high up in their priorities.
So in theory, you get the best of both worlds. I don't think there's anything really stopping Apple from doing this, but as many others have said, it's not really their jam ;)
So when you got your second hand device you just need to check the bootloader while booting. If it warns then you need to flash a stock iamge.
It just shows that this is possible, but we are talking about Apple here.
And here I thought the cliche was Macbook in IT == SDE.
Or maybe it's just me.
By all available stats, Macs are only used by about 25% of programmers. Windows is 50% and Linux is 25%.
This developer has purchased a (used) Macbook Pro but only touches it to build into iOS-land. The rest of my time is spent on Linux where I'm in charge and where I can get proper basic facilities like sane window and file management without the hassle.
In your average light tech sv-inspired web startup you will see them, but it drops off as you start moving into actual engineering.
But in my case, I’m not buying the internal components. I’m buying the “I won’t have to angrily kick myself later” promise.
So far that promise has held and not felt overpriced.
I am excited to start evaluating the m* macs once they get docker sorted though.
I had a fellow dev whose camera was below the screen, so when we'd videoconference I'd be pointed at his chest, for example.
Every time he'd plug in his headphones and then unplug them his microphone would stop working.
It was death by a thousand cuts. Tiny inconveniences that stack up.
Although speaking of cuts, I'll admit I sliced my finger open (on the exhaust vent) when pulling my 2018 MBP out of my laptop bag. Talk about inconvenient design flaws. And yet, here I am recommending them. That's how good the other stuff is in comparison.