Writing ARM64 Code for Apple Platforms(developer.apple.com)
developer.apple.com
Writing ARM64 Code for Apple Platforms
https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
1 comments
I wonder to what extent the M1 has been designed with thoughts towards vendor lock-in?
To exactly the same extent as everything Apple does. If they genuinely believe that they can create a custom X that works better than all the other options, and that compatibility with the rest of the world would hold back the user experience, then they go for it and don’t worry about compatibility.
Whether you, as a user, agree with their decisions, is a different story. Apple doesn’t care about making products for everyone, so to them if 70% of the market doesn’t like their design but 30% absolutely loves it - and they can make sustainable profits selling to that 30% - then that’s fine.
Apple thinks of it’s products like game consoles. We don’t get mad at Sony that PlayStation games don’t run on Windows… we understand that Sony has designed a complete package offering and then we either like it and buy it… or we don’t. And that’s fine.
People get confused about Apple’s choices because they make Macs, which are a lot like PCs and partially compatible. But Apple doesn’t see the Mac as part of the PC ecosystem, it sees the Mac and all its products as the distinct, standalone, Apple platform, which is a complete package offering. And Apple expects users to either like that and buy it, or not.
Whether you, as a user, agree with their decisions, is a different story. Apple doesn’t care about making products for everyone, so to them if 70% of the market doesn’t like their design but 30% absolutely loves it - and they can make sustainable profits selling to that 30% - then that’s fine.
Apple thinks of it’s products like game consoles. We don’t get mad at Sony that PlayStation games don’t run on Windows… we understand that Sony has designed a complete package offering and then we either like it and buy it… or we don’t. And that’s fine.
People get confused about Apple’s choices because they make Macs, which are a lot like PCs and partially compatible. But Apple doesn’t see the Mac as part of the PC ecosystem, it sees the Mac and all its products as the distinct, standalone, Apple platform, which is a complete package offering. And Apple expects users to either like that and buy it, or not.
It's also important to remember that Apple doesn't want to be like a PC or Android phone. They've said so in court filings. They view themselves as separate, and they also say that if you want sideloading, you have that choice by joining the other side.
In Apple's view, they are encouraging customer choice because customers have the ability to choose an open experience, or a closed experience, and the desire to force all experiences to be open removes choice. It's an argument very contrary to us on Hacker News but that's what Apple tries to get at.
In Apple's view, they are encouraging customer choice because customers have the ability to choose an open experience, or a closed experience, and the desire to force all experiences to be open removes choice. It's an argument very contrary to us on Hacker News but that's what Apple tries to get at.
> they also say that if you want sideloading, you have that choice by joining the other side.
That's a bit of a stretch of what they said - they were specifically referring to iOS there, and pointing out that there are other choices (including macOS) that offer side-loading or direct installs.
Taking that one comment to imply that Apple doesn't want to build any platforms that aren't completely locked down is, imho, a step too far.
That's a bit of a stretch of what they said - they were specifically referring to iOS there, and pointing out that there are other choices (including macOS) that offer side-loading or direct installs.
Taking that one comment to imply that Apple doesn't want to build any platforms that aren't completely locked down is, imho, a step too far.
That argument would work a little better if they did not market their phones as a computer replacement in the first place...
Apart from that, I think with only two companies on the mobile market, even them can't really argue against the obvious lack of competition.
Apart from that, I think with only two companies on the mobile market, even them can't really argue against the obvious lack of competition.
This is subtle, but they’re not advertising the iPad as a replacement for a PC or Mac.
They’re advertising an iPad as a replacement for the things most people use a PC or Mac for.
An iPad is certainly not a viable PC replacement for me, nor most of HN I would guess. But for a lot of “casual users,” who really just surf the web, watch videos, etc, it’s great.
What’s way more interesting is how iPad has become appealing to a lot of “semi-power users,” like photographers and videographers. These are people who, twenty years ago, really needed to be computer savvy to do their work, but didn’t (and still don’t) think of themselves as “computer people.” Or to put that a different way, they “use a computer for work,” but they don’t “work on computers.” That audience has been greatly expanded as iOS devices have lowered the cost and skill barriers to entry making a lot of content creation possible.
For those of us who actually “work on computers,” I don’t see iOS devices ever being a great fit… or at least not any time soon. But for others, an iPad might do everything the user wants from a computer, and maybe do it faster and easier as well. That’s what Apple is advertising.
They’re advertising an iPad as a replacement for the things most people use a PC or Mac for.
An iPad is certainly not a viable PC replacement for me, nor most of HN I would guess. But for a lot of “casual users,” who really just surf the web, watch videos, etc, it’s great.
What’s way more interesting is how iPad has become appealing to a lot of “semi-power users,” like photographers and videographers. These are people who, twenty years ago, really needed to be computer savvy to do their work, but didn’t (and still don’t) think of themselves as “computer people.” Or to put that a different way, they “use a computer for work,” but they don’t “work on computers.” That audience has been greatly expanded as iOS devices have lowered the cost and skill barriers to entry making a lot of content creation possible.
For those of us who actually “work on computers,” I don’t see iOS devices ever being a great fit… or at least not any time soon. But for others, an iPad might do everything the user wants from a computer, and maybe do it faster and easier as well. That’s what Apple is advertising.
> This is subtle, but they’re not advertising the iPad as a replacement for a PC or Mac.
> They’re advertising an iPad as a replacement for the things most people use a PC or Mac for.
To me that sounds pretty similar, they advertise it with similar features, functions and in practice it's also used similarly.
> They’re advertising an iPad as a replacement for the things most people use a PC or Mac for.
To me that sounds pretty similar, they advertise it with similar features, functions and in practice it's also used similarly.
I kind of like how Apple's advertising went from "the computer for the rest of us" to "what's a computer?"
Well, uh, kid, it's a bit like that iPad you're using, but you can run any software you want on it.
Well, uh, kid, it's a bit like that iPad you're using, but you can run any software you want on it.
> That argument would work a little better if they did not market their phones as a computer replacement in the first place...
It's a very effective alternative model. Steve jobs said no stylus and no separate keyboard and it did quite effectively replace PCs at a lot of boring office tasks that any manager would need.
It's a very effective alternative model. Steve jobs said no stylus and no separate keyboard and it did quite effectively replace PCs at a lot of boring office tasks that any manager would need.
I believe many people use a smartphone as their only computer.
Smartphones have useful features that many laptops don't have, including: subsidized pricing, long battery life, small size that fits in your pocket, mobile data, and the ability to make phone calls.
Smartphones have useful features that many laptops don't have, including: subsidized pricing, long battery life, small size that fits in your pocket, mobile data, and the ability to make phone calls.
I’ve seen the iPad marketed as such but never the iPhone.
Just have a look at the difference between an Iphone ad and a PS4 ad. On one side you have screen, processor, new apps & all the productive things you can do with the phone, on the PS4 side you have games games and more games. The marketing difference is obvious.
Sure but that doesn’t mean that Apple markets the iPhone explicitly as one and it’s not like Apple is shy to not market one of their devices as such i.e the iPad. I think everyone is trying to fit these items in categories when they already have categories they’re marketed in. The iPhone is a Smartphone and has always (as far as I’m aware) has been marketed as a Smartphone. Just as the PS4 is market as a Game console because it IS a game console.
In the end what separates these are not by what they can do , cause in reality if someone really really really wanted to ALL these devices can run a OS that makes it function like a desktop/laptop. It’s about what they’re meant to do. We’ve seen Apple market something as a computer before and it was never the iPhone.
In the end what separates these are not by what they can do , cause in reality if someone really really really wanted to ALL these devices can run a OS that makes it function like a desktop/laptop. It’s about what they’re meant to do. We’ve seen Apple market something as a computer before and it was never the iPhone.
What separates them is how they are used in practice and they are used in practice as computer replacement (it's especially visible in developing countries). Apple themselves marketing them as multi-purpose computers in their ads is further proof but not needed for my argument.
And I’m telling you that’s not the case since we have an actual case of Apple marketing one of their products as computer replacements and it was never the iPhone. The iPhone was always market as “An iPod, a phone, an internet mobile communicator... these are NOT three separate devices” m. There’s a difference between a computing device and a computer. All devices with a chip are computing devices hut jot all computing devices are computers.
To each their own, I don't see a big difference between the marketing of an Iphone and the marketing of any laptop out there. Apple might claim whatever suits them for their defense but even themselves have realized internally how their product is used.
There's an app for that.
I have been an Apple ecosystem developer for the past 19 years and this is the best, most succinct explanation of Apple’s outlook re: openness for the HN crowd that I’ve seen. I don’t always agree with the stance, more so in recent years, but understanding that it is what governs things, not a nascent PC market world view, is important to factor in when making hardware, lifestyle, and career choices.
Thanks for that comment, it’s very kind. :)
> Apple thinks of it’s products like game consoles.
And at the same time Apple expects me to build my business on those products.
And at the same time Apple expects me to build my business on those products.
Plenty of games run on multiple consoles, despite having completely different operating systems, graphics APIs, etc.
It's certainly a pain, but cross-platform development has always been a thing so it's not a unique pain to Apple platforms.
It's certainly a pain, but cross-platform development has always been a thing so it's not a unique pain to Apple platforms.
It's not just the development. It's the fact the Apple takes control over the distribution of software on their platform.
“Expects” is a stretch. “Encourages”, “wants”, “likes to” more like.
They call their products "Pro".
Linux devs giving money to Apple instead of GNU/Linux OEMs are the ones that got mixed up what Apple eco-system is supposed to be.
Most of them never used the old Mac OS, GUI based, with Object Pascal/C++ tooling, and zero POSIX.
Most of them never used the old Mac OS, GUI based, with Object Pascal/C++ tooling, and zero POSIX.
>We don’t get mad at Sony that PlayStation games don’t run on Windows…
Actually there was much rejoicing when the Playstation moved to x86_64.
Actually there was much rejoicing when the Playstation moved to x86_64.
That was due to how horrible it was to program an app for the cell processor.
[deleted]
> Apple doesn’t care about making products for everyone
Can you give me a quote from the company or an otherwise official statement that supports this?
Can you give me a quote from the company or an otherwise official statement that supports this?
They’ve certainly said on multiple occasions they won’t make cheap computers, which by definition excludes a big percentage of the potential market.
https://www.huffpost.com/entry/apple-ceo-tim-cook-expensive-...
https://www.huffpost.com/entry/apple-ceo-tim-cook-expensive-...
It doesn't require a statement from Apple for someone to ascribe intent from a company's actions. It's of course just speculation and may not align with what the company officially states or what the intent is internally. It's simply an opinion.
Anyone that has been around long enough to remember the days of Atari, Amiga, PC, Archimedes, PC.
This isn’t the kind of thing a company generally externalises in quotes and official statements. This comment is pushing the HN “provide sources” meme to it’s limits.
The Apple ABI was burnt into physical hardware while ARM was still finalizing some of the 64-bit details, which is why there are minor differences.
X18 is very specifically called out as “for the platform: do not use”, though, so things like GNU MP [1] moaning that Apple hasn’t specified how they use x18, and them using it anyway are just ridiculous.
‘While we added support for Apple's new Arm based computers, our support has a problem. The problem is that Apple reserves CPU register x18, but GMP's mpn/arm64 assembly code uses that register. While GMP runs fine in our tests, we expect things to go awry in some execution situation. (Apple has not been kind enough to specify how they use x18. Therefore, we don't know what the consequences of using x18 might be.)’
[1] https://gmplib.org/
X18 is very specifically called out as “for the platform: do not use”, though, so things like GNU MP [1] moaning that Apple hasn’t specified how they use x18, and them using it anyway are just ridiculous.
‘While we added support for Apple's new Arm based computers, our support has a problem. The problem is that Apple reserves CPU register x18, but GMP's mpn/arm64 assembly code uses that register. While GMP runs fine in our tests, we expect things to go awry in some execution situation. (Apple has not been kind enough to specify how they use x18. Therefore, we don't know what the consequences of using x18 might be.)’
[1] https://gmplib.org/
I think it was fixed 2 weeks after the announcement: https://gmplib.org/repo/gmp/rev/5f32dbc41afc
I am more reading this as 'we just enabled compilation for Apple M1 but it is highly experimental, use at your own risk until it is properly fixed'.
I think you misinterpreted their stance.
I am more reading this as 'we just enabled compilation for Apple M1 but it is highly experimental, use at your own risk until it is properly fixed'.
I think you misinterpreted their stance.
Now that these differences are documented, are they going to have to be maintained forever? Or is there any chance that the Apple ABI could converge to the AArch64 ABI over time?
Probably forever. AFAIK IANAE (I am not an engineer), to change this would require breaking compatibility with all iOS and macOS ARM binaries and telling developers that for optimal performance without using Rosetta 3, they need to compile toward "(new) Apple Silicon." It's probably not going to happen.
You don't need a translator. The ABI is a software construct, not an hardware one.
What would be needed though is to have two copies of the system libraries in such a case, targeting different ABIs. That's of course very unlikely to happen.
What would be needed though is to have two copies of the system libraries in such a case, targeting different ABIs. That's of course very unlikely to happen.
There are already two different ABIs for Apple silicon, although one (arm64e) is mostly reserved for Apple’s use at the moment. Apple could choose to finalize the ABI for that with x18 being available to applications, although this is quite unlikely.
No there aren’t and you know that.
Arm64e has the exact same abi as arm64, but in arm64 mode the pac instructions are no ops.
Otherwise as the parent says apple would need multiple copies of the system libraries.
Arm64e has the exact same abi as arm64, but in arm64 mode the pac instructions are no ops.
Otherwise as the parent says apple would need multiple copies of the system libraries.
Yeah, I understand that they are currently the same, I'm just saying that as Apple hasn't locked down the ABI yet so they could in the future choose to ship a new copy of all the libraries (as they do with x86_64h) for arm64e (well, split out arm64 slices) and for that ABI allow the use of x18. It would be pretty dumb, but it's possible.
[deleted]
Are they not able to stop using the register? Why keep touching a rail that you've been told might be electrified?
Their code is older than M1. That rail, when supplied by other vendors, was not live.
But younger than Apple’s arm64 ABI, and younger than ARM’s ABI docs which reserve it for platform use. Any software intended to target multiple platforms should never have been using it.
Yeah I get that... but that doesn't meet the current ABI so change it.
It is already fixed https://gmplib.org/repo/gmp/rev/5f32dbc41afc
Unless Apple can produce a sufficient explanation of why you wouldn't use that register, I see no reason why developers wouldn't.
Here is ARM's explanation in the AAPCS64 (ARM 64-bit Architecture Procedure Call Standard):
> Software developers creating platform-independent code are advised to avoid using r18 if at all possible. Most compilers provide a mechanism to prevent specific registers from being used for general allocation; portable hand-coded assembler should avoid it entirely. It should not be assumed that treating the register as callee-saved will be sufficient to satisfy the requirements of the platform. Virtualization code must, of course, treat the register as they would any other resource provided to the virtual machine.
From: https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d5517...
> Software developers creating platform-independent code are advised to avoid using r18 if at all possible. Most compilers provide a mechanism to prevent specific registers from being used for general allocation; portable hand-coded assembler should avoid it entirely. It should not be assumed that treating the register as callee-saved will be sufficient to satisfy the requirements of the platform. Virtualization code must, of course, treat the register as they would any other resource provided to the virtual machine.
From: https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d5517...
To elaborate:
On Darwin, x18 is used as a scratch register in context switches on hardware where Meltdown mitigations are needed.
As such, it is cleaned on each ctx switch on that hardware.
On M1, it's currently usable by applications, but that is not part of the ABI contract and might change at any time without notice.
On Windows, x18 is the TEB (thread environment block) register. It must as such _not_ be touched by apps either.
On Darwin, x18 is used as a scratch register in context switches on hardware where Meltdown mitigations are needed.
As such, it is cleaned on each ctx switch on that hardware.
On M1, it's currently usable by applications, but that is not part of the ABI contract and might change at any time without notice.
On Windows, x18 is the TEB (thread environment block) register. It must as such _not_ be touched by apps either.
> On Darwin, x18 is used [...] on hardware where Meltdown mitigations are needed. [...] On M1, it's currently usable by applications
I’m confused. x18 is an ARM register, but I thought Meltdown only affected x86 chips. Were iOS devices vulnerable to Meltdown too? Or did you mean not x18 specifically but some equivalent OS-reserved x86 register?
I’m confused. x18 is an ARM register, but I thought Meltdown only affected x86 chips. Were iOS devices vulnerable to Meltdown too? Or did you mean not x18 specifically but some equivalent OS-reserved x86 register?
Yeah, Meltdown did affect quite some Arm CPUs, including the Cortex-A75 too.
However, due to specific features of the Arm architecture, it was patchable without a significant performance hit.
(see this section: https://siguza.github.io/KTRR/#meltdownspectre-mitigations-1..., which made the need for actually doing a page table switch avoidable)
However, due to specific features of the Arm architecture, it was patchable without a significant performance hit.
(see this section: https://siguza.github.io/KTRR/#meltdownspectre-mitigations-1..., which made the need for actually doing a page table switch avoidable)
Interesting, thanks for the link!
x18 happens to also be used by Rosetta, and is restored in those cases.
I'm in the market for a new laptop, but can't get myself to buy an Apple laptop despite some nice innovation on the CPU front. The lock-in, the dragging their feed and outright stalling web innovation with Safari, the “Sideloading in this case is eliminating choice” newspeak. It's just not something I want to support.
> outright stalling web innovation with Safari
Not adopting technologies at the rate of the market leader who is pushing for more and more control over the web might be "stalling web innovation" but the alternative universe is one where Chrome has no meaningful check against its hegemony of the web and can freely create new technology in support of Google's mission to harvest private information and serve advertisements to its users.
> Sideloading in this case is eliminating choice
There is nothing on MacOS that is preventing installing and running arbitrary code on your machine. Elevation of privileges is required for some of that code, but it is there for those that need or want it and a sane default exists for everyone else. This is the case with every modern operating system, including free ones.
Not adopting technologies at the rate of the market leader who is pushing for more and more control over the web might be "stalling web innovation" but the alternative universe is one where Chrome has no meaningful check against its hegemony of the web and can freely create new technology in support of Google's mission to harvest private information and serve advertisements to its users.
> Sideloading in this case is eliminating choice
There is nothing on MacOS that is preventing installing and running arbitrary code on your machine. Elevation of privileges is required for some of that code, but it is there for those that need or want it and a sane default exists for everyone else. This is the case with every modern operating system, including free ones.
> There is nothing on MacOS that is preventing installing and running arbitrary code on your machine. Elevation of privileges is required for some of that code, but it is there for those that need or want it and a sane default exists for everyone else. This is the case with every modern operating system, including free one
Actually, there is but not In the way you expect. When the M1 Mac’s we’re released, you could sideline iOS and iPadOS apps but that was blocked by Apple in a later update. On the surface this is a means of clamping down on app piracy and unauthorized use of an app but also a a blockage all the same.
Actually, there is but not In the way you expect. When the M1 Mac’s we’re released, you could sideline iOS and iPadOS apps but that was blocked by Apple in a later update. On the surface this is a means of clamping down on app piracy and unauthorized use of an app but also a a blockage all the same.
Any app creator can release their iOS / iPadOS app for Apple Silicon Macs if they choose to, I'm not sure I'd paint Apple as the bad guy here if a vendor doesn't want their iOS app running on macOS.
I’m not taking about Availability of iOS App in the MacOS App Store that devs can opt in and out of. I’m talking explicitly about side loading iOS/iPadOS apps to MacOS. This was possible when M1 apps were released and then explicitly blocked by Apple after an update.
That's a good point and it's something I did overlook, despite complaining about it when they changed this. I would argue though that this is DRM just like Denuvo is for video games or widevine for a lot of streaming content and wouldn't really consider it the same thing as Apple restricting running arbitrary code in the traditional sense. If something like Gatekeeper made things unsigned by Apple impossible to run rather than simply being annoying (which I mean, is kind of the point of it) then I'd be more inclined to agree with the sentiment.
Personally I don’t see the difference between a local MacOS system doing it and a system phoned by MacOS doing it
The difference is that Apple runs the App Store and agreed to allow app developers to opt out of publishing their apps to the Mac App Store. In order to facilitate that they had to implement DRM.
Being able to run arbitrary code doesn't really mean you get to run other people's code without their permission, which is essentially what running those applications on a mac was. You can argue the merits of DRM and copyright of course, but ultimately that's not the same thing as "running arbitrary code." You can run the code and that code includes a check to make sure the platform is one that the developer approved of. If you find a way to remove that check it probably still runs.
Being able to run arbitrary code doesn't really mean you get to run other people's code without their permission, which is essentially what running those applications on a mac was. You can argue the merits of DRM and copyright of course, but ultimately that's not the same thing as "running arbitrary code." You can run the code and that code includes a check to make sure the platform is one that the developer approved of. If you find a way to remove that check it probably still runs.
> ...dragging their feed and outright stalling web innovation with Safari...
You aren't entirely wrong here, but we are one thin plank from the web being whatever Google says it is.
I know we don't live in an ideal web development world, but we are awfully close to something much worse.
You aren't entirely wrong here, but we are one thin plank from the web being whatever Google says it is.
I know we don't live in an ideal web development world, but we are awfully close to something much worse.
Why would Apple want to join the Chrome arms race that Google is pushing for their own benefit?
I feel you. I'm at a point where I can't go on and support that ecosystem with my money, as they envision a future of the whole IT/CE industry which I increasingly disagree with.
But it's hard to explain the implications of Apple's business model to someone who is just happy how well his AirPods are integrating with all his other Apple stuff, and offended how other companies simply don't make anything equally well integrated with his iPhone...
But it's hard to explain the implications of Apple's business model to someone who is just happy how well his AirPods are integrating with all his other Apple stuff, and offended how other companies simply don't make anything equally well integrated with his iPhone...
I believe side-loading on Mac OS is not a problem. It is only restricted in iOS.
Sideloading on the M1 is fairly easy. @marcan42, who is developing Linux for M1, is very clear that Apple actively went out of their way to make sideloading possible in a secure manner.
Also, for everyone who says Apple is going to lock MacOS down, that's not going to happen with the M1 at least. The ability to run older versions of MacOS, alongside Linux support coming, means it's not happening. Despite what the conspiracy theorists say.
Also, for everyone who says Apple is going to lock MacOS down, that's not going to happen with the M1 at least. The ability to run older versions of MacOS, alongside Linux support coming, means it's not happening. Despite what the conspiracy theorists say.
Linux on M1 and sideloading OSX apps are fairly orthogonal. Bootloader/sideloading term mixup maybe?
They are not orthogonal. If you can install Linux, then you can sideload apps on macOS. It might involve invasive XNU patching with a hex editor, but it can be done.
It's not that involved, by the way. There's a command that you run to turn off gatekeeper [1].
[1]: https://disable-gatekeeper.github.io/
It's not that involved, by the way. There's a command that you run to turn off gatekeeper [1].
[1]: https://disable-gatekeeper.github.io/
Exactly, and this goes beyond mere self-signed code (Gatekeeper) and into things like SIP and private entitlements. As long as the user controls the bootloader, the user can also patch the OS to do whatever they want.
I think the OP is pointing out that installing Mac apps from places other than the App Store is not what most (if any) Mac users would call "sideloading". We just call it "installing." :)
It's 2 separate points, Apple explicitly said they allow sideloading (I wouldn't even call it side loading, it's just "install from outside the app store" and "allow unsigned applications if you want") and booting any other OS is allowed, there is even some amount of Apple documentation on how to do it, and success with both BSD and linux. Drivers are of course an issue.
Have you given much thought to the opposite idea - that web innovation is ultimately bad for users?
I think having an open, equal opportunity platform not policed by any specific vendor is a good thing. It could pave the way for a mobile OS like Mozilla envisioned with the discontinued Firefox OS. There is of course this massive influence of Google which could steer web innovation in the wrong direction.
I've been talking about this a lot lately, so maybe I'm repeating myself, but Ellen Ullman's (very good) book Life in Code she writes about Whitfield Diffie's (of Diffie-Hellman fame) speech at the 2000 Computers, Freedom, and Privacy conference in Toronto.
> "We were slaves to the mainframe! he said. Dumb terminals! That's all we had. We were powerless under the big machine's unyielding central control. Then we escaped to the personal computer, autonomous, powerful. Then networks. The PC was soon rendered to be nothing but a "thin client," just a browser with very little software residing on our personal machines, the code being on network servers, which are under the control of administrators. Now to the web, nothing but a thin, thin browser for us. All the intelligence out there, on the net, our machines having become dumb terminals again."
I think yielding control back to remote administrators is ultimately a mistake if you care about freedom and privacy. It's why I've come to believe the web, as a platform, is in some ways a giant step backwards (and I do realize that's not a popular opinion here).
I like that Apple is slowing things down. Users are better served by well written native apps IMHO. It makes life more difficult for those of us who write software but also for those who want to sell to, spy on, or control users.
> "We were slaves to the mainframe! he said. Dumb terminals! That's all we had. We were powerless under the big machine's unyielding central control. Then we escaped to the personal computer, autonomous, powerful. Then networks. The PC was soon rendered to be nothing but a "thin client," just a browser with very little software residing on our personal machines, the code being on network servers, which are under the control of administrators. Now to the web, nothing but a thin, thin browser for us. All the intelligence out there, on the net, our machines having become dumb terminals again."
I think yielding control back to remote administrators is ultimately a mistake if you care about freedom and privacy. It's why I've come to believe the web, as a platform, is in some ways a giant step backwards (and I do realize that's not a popular opinion here).
I like that Apple is slowing things down. Users are better served by well written native apps IMHO. It makes life more difficult for those of us who write software but also for those who want to sell to, spy on, or control users.
I'm in a (similar) boat. I'd probably be a lot more interested if Apple gave me more control over the hardware.
What control are you lacking? Are you positive you are lacking control or just espousing a knee jerk opinion?
Indeed, a comment in this thread points out that others have reported Apple went out of their way to allow secure access to the hardware on peer with what apple does with macOS - your generic concerns seem utterly without merit.
Indeed, a comment in this thread points out that others have reported Apple went out of their way to allow secure access to the hardware on peer with what apple does with macOS - your generic concerns seem utterly without merit.
I'm mostly a big fan of my Macbook Air, first Mac I've owned in 15 years. But I'd jump for joy if they'd just let me control the auto-open feature of Music.app that forces it to the front every time I take my headphone off and put them back on. I'm in a damn meeting. How on earth did they ever come to the decision that they should assume everyone using headphones is listening to music?
I scoured the Internet and this has apparently been a problem for at least six years, and Apple keeps breaking all the workarounds people find to disable the behavior.
I scoured the Internet and this has apparently been a problem for at least six years, and Apple keeps breaking all the workarounds people find to disable the behavior.
Perhaps you're not sure what kinds of controls you're missing because you haven't often left the Apple bubble? Here are the types of control that I enjoy as a Linux/Windows PC user:
- All of my non-Mac PCs have a BIOS interface that lets me control very low level behaviors of my motherboard and CPU. Macs expose just the bare minimum.
- Windows, and to a much greater extent Linux both offer vastly more API hooks to customize things that I want about the OS. Apple does things like making NSScreen.visibleRect readonly so that only their Dock program can change it and nobody else. Meanwhile, on Windows/Linux I can programatically do just about anything I choose to, so I can replace the taskbar (and even app window chrome/menus) with something else if I want.
- Macs have extremely limited GUI configuration options. You can't even change the color of your mouse pointer from black to white if you wish to! You can't have "themes" that change anything significant. You can only put the Dock left/right/bottom. You can't move the menu bar. For a long, long time you could only resize app windows by the lower right corner until they finally implemented that. It's very often Apple's way or the highway - and there's a reason why that phrase is often associated directed towards Apple; because they just don't offer nearly as much control to users...
- Even if you try to customize these things by using third party hacks, there's no guarantee that your hack will continue to work after an update - and that's a loss of control. My Macs have broken many times from updates, way more than any of my real PCs. Even if I do hack Windows to do something that I want, Microsoft bends over backwards to stay compatible. Obviously Linux offers even more control, i.e. you can get right into the source code of almost anything on your desktop.
- I can only run macOS on Apple hardware. This is a severe loss of control for users. If Apple decided to stop making Intel machines tomorrow, I'd be screwed.
- If I'm running a cloud business, I can't even rent out a cloud Mac for an hour at a time. I have to rent it out for 24 hours at a time. That's a loss of control.
I'm sure I missed some things because I wrote this pretty quickly. I thought at some point that I should keep a running list of things that Macs just can't do, but that would be a waste of time - better to just accept things and relegate my Macs for doing iOS/Mac things only. So that's exactly what I did.
- All of my non-Mac PCs have a BIOS interface that lets me control very low level behaviors of my motherboard and CPU. Macs expose just the bare minimum.
- Windows, and to a much greater extent Linux both offer vastly more API hooks to customize things that I want about the OS. Apple does things like making NSScreen.visibleRect readonly so that only their Dock program can change it and nobody else. Meanwhile, on Windows/Linux I can programatically do just about anything I choose to, so I can replace the taskbar (and even app window chrome/menus) with something else if I want.
- Macs have extremely limited GUI configuration options. You can't even change the color of your mouse pointer from black to white if you wish to! You can't have "themes" that change anything significant. You can only put the Dock left/right/bottom. You can't move the menu bar. For a long, long time you could only resize app windows by the lower right corner until they finally implemented that. It's very often Apple's way or the highway - and there's a reason why that phrase is often associated directed towards Apple; because they just don't offer nearly as much control to users...
- Even if you try to customize these things by using third party hacks, there's no guarantee that your hack will continue to work after an update - and that's a loss of control. My Macs have broken many times from updates, way more than any of my real PCs. Even if I do hack Windows to do something that I want, Microsoft bends over backwards to stay compatible. Obviously Linux offers even more control, i.e. you can get right into the source code of almost anything on your desktop.
- I can only run macOS on Apple hardware. This is a severe loss of control for users. If Apple decided to stop making Intel machines tomorrow, I'd be screwed.
- If I'm running a cloud business, I can't even rent out a cloud Mac for an hour at a time. I have to rent it out for 24 hours at a time. That's a loss of control.
I'm sure I missed some things because I wrote this pretty quickly. I thought at some point that I should keep a running list of things that Macs just can't do, but that would be a waste of time - better to just accept things and relegate my Macs for doing iOS/Mac things only. So that's exactly what I did.
A whole lot of what you're describing -- not all, obviously, but a good chunk -- have to do with not being able to significantly affect the aesthetics of the operating system, or in some cases, the functionality of the widgets. This is fair, but I think people who haven't really gotten deep into "the Apple bubble" don't really understand how much control Apple does, in fact, give you over the functionality of the operating system, whether through OS-level features or hooks third-party applications can latch onto. When I think of "customizing my environment," I think of running things like Alfred and Keyboard Maestro. I think of using Automator (and soon, Shortcuts) to control applications and create system-wide services like "select any Markdown text in any application and convert it to BBCode, HTML, or Rich Text". I think of editing the default keyboard finding file to add ^W as "select word" in every application that uses standard system input. None of these are "hacks" that are going to go away tomorrow. Personally, I don't care whether I can "move the menu bar" (where the hell would I move it?) or turn window chrome purple, and I don't really care that I can only put the dock in one of three places. :)
As for some of the others, well, again, yes and no. I mean, in the history of computing, "I can only run FooCo's OS on FooCo's hardware" was the norm"; I don't think it's Apple's fault if you can't rent out a cloud Mac for an hour at a time; I think it's debatable whether the lack of fine-grained editing of BIOS settings is a material loss on the Mac platform.
Also,
> If Apple decided to stop making Intel machines tomorrow, I'd be screwed.
I have bad news. :)
As for some of the others, well, again, yes and no. I mean, in the history of computing, "I can only run FooCo's OS on FooCo's hardware" was the norm"; I don't think it's Apple's fault if you can't rent out a cloud Mac for an hour at a time; I think it's debatable whether the lack of fine-grained editing of BIOS settings is a material loss on the Mac platform.
Also,
> If Apple decided to stop making Intel machines tomorrow, I'd be screwed.
I have bad news. :)
> Apple does things like making NSScreen.visibleRect readonly so that only their Dock program can change it and nobody else. Meanwhile, on Windows/Linux I can programatically do just about anything I choose to, so I can replace the taskbar (and even app window chrome/menus) with something else if I want.
If you turn SIP off, you should be able to swizzle those methods with your own implementations. I admittedly haven't tried with NSScreen.visibleRect specifically, but I've swizzled plenty of other low-level objective-c stuff. When I need to go even deeper, there's dyld interposing.
You just need to turn off SIP. It's the magic switch that lets you do whatever you want. Some people argue "letting the user do whatever they want" is poor security, and perhaps it is, but you can't have it both ways—either grant yourself control and accept the security consequences, or leave Apple in control and accept the restrictions.
If you turn SIP off, you should be able to swizzle those methods with your own implementations. I admittedly haven't tried with NSScreen.visibleRect specifically, but I've swizzled plenty of other low-level objective-c stuff. When I need to go even deeper, there's dyld interposing.
You just need to turn off SIP. It's the magic switch that lets you do whatever you want. Some people argue "letting the user do whatever they want" is poor security, and perhaps it is, but you can't have it both ways—either grant yourself control and accept the security consequences, or leave Apple in control and accept the restrictions.
Probably to the same level of everything else they do - "We are doing what we want, so get on board if you are interested"
If that leads to lock-in, it's a happy accident.
If that leads to lock-in, it's a happy accident.
I think many will interpret this as sarcasm, but it’s actually spot-on. If you watch Apple’s history, they’re strongly opinionated and they always do what they believe is best for users, regardless of what developers or critics think.
This usually works out well. I think the one big conflict is that Apple is also very diligent about it’s profit margins, and while this usually doesn’t conflict with “what’s best for the user,” where Apple gets in trouble is when it does.
One prominent example: there’s really no reason to think that the 5GB of free iCloud storage is sufficient anymore. Maintaining cloud storage isn’t free, so I understand why they don’t want to offer more than a “free trial” so to speak, but I would guess this hurts a lot of users who have a degraded user experience on their phone because they don’t have enough storage for iCloud backups, for example. It would make more sense to me if they would offer something like “system backups don’t count against your storage cap” and then include two years of iCloud 50GB with the purchase of the phone. That conflicts with the profit margins, though, so the 5GB teaser stays around.
This usually works out well. I think the one big conflict is that Apple is also very diligent about it’s profit margins, and while this usually doesn’t conflict with “what’s best for the user,” where Apple gets in trouble is when it does.
One prominent example: there’s really no reason to think that the 5GB of free iCloud storage is sufficient anymore. Maintaining cloud storage isn’t free, so I understand why they don’t want to offer more than a “free trial” so to speak, but I would guess this hurts a lot of users who have a degraded user experience on their phone because they don’t have enough storage for iCloud backups, for example. It would make more sense to me if they would offer something like “system backups don’t count against your storage cap” and then include two years of iCloud 50GB with the purchase of the phone. That conflicts with the profit margins, though, so the 5GB teaser stays around.
I think it's part of an onboarding strategy, because remember that the next tier is $1/mo., or $12 a year. Peanuts. It could easily be rolled into the purchase price of the device for a year or two. Apple TV+ which come with a year free with purchasing an iPhone would be $60 a year, or 5 years of iCloud 50GB.
However, by charging peanuts, you got the user into a subscription, which is the important bit. A person in a subscription who jumped the hurdle of not paying vs paying a little is much more likely to upgrade later.
It also plays into a Steve Jobs strategy, for better or worse. Many people don't hear about this, but Steve Jobs had a view that people don't value things that are free. He made the Cafe at Apple HQ subsidized but require payment, not that Apple couldn't afford it, but because he knew people wouldn't respect free food. This view of Apple's, that people don't value things they didn't pay for, seems to permeate many of their business decisions.
However, by charging peanuts, you got the user into a subscription, which is the important bit. A person in a subscription who jumped the hurdle of not paying vs paying a little is much more likely to upgrade later.
It also plays into a Steve Jobs strategy, for better or worse. Many people don't hear about this, but Steve Jobs had a view that people don't value things that are free. He made the Cafe at Apple HQ subsidized but require payment, not that Apple couldn't afford it, but because he knew people wouldn't respect free food. This view of Apple's, that people don't value things they didn't pay for, seems to permeate many of their business decisions.
Yes, I think you’re exactly right. Overall it’s a good business strategy. I just personally think that in this case, it’s an example of “what’s best for profit margins” conflicting with “the best user experience for most users,” and the awkward place they’ve landed today is how they’ve split that difference.
> This view of Apple's, that people don't value things they didn't pay for, seems to permeate many of their business decisions.
This would explain why their users are so quick to defend the 30% cut, with sunken cost taken into account.
This would explain why their users are so quick to defend the 30% cut, with sunken cost taken into account.
Accident, yeah
Can anyone else name an industry where this would be allowed?
Imagine if John Deere decided to switch all of their tractors to a proprietary gasoline formula, and said "We're doing what we want, so get on board if you're interested".
They would be sued before the sun went down.
Imagine if John Deere decided to switch all of their tractors to a proprietary gasoline formula, and said "We're doing what we want, so get on board if you're interested".
They would be sued before the sun went down.
John Deere unfortunately does do this. To the court's credit, at least they keep losing right to repair lawsuits. To law enforcement's discredit, they don't change the behavior and suffer no punishment.
Except here's the twist: Imagine if John Deere made their tractors from day one with the proprietary gasoline formula. And that people liked their tractors from day one and grew them into the behemoth they are today despite the formula.
That's more like what the current situation is.
That's more like what the current situation is.
A better analogy would be if Deere required a new fuel formulation that all the industry players had access to but no one else had sufficient clout/“courage” to use.
Do Apple devices use special Apple Electricity? No? Then your analogy is nonsensical, as analogies always are.
John Deer tractors are locked down... just go talk to a real farmer and see what he says.
I don't think it matters, since MacOS itself is a compilation target that differs completely from others. If they made the CPU different, that would just make its differences yet another aspect of MacOS as a target.
In other words I don't think it would be any more of a special snowflake than it is.
If they dropped ARM64 compatibility (in other words stopped making Apple Silicon a superset of ARM64), this would be stupid in that it would make the platform less useful. It would make it impossible to e.g. run ARM64 Linux or Windows in a VM which is a fundamental use case of the machine for developers. I doubt they'd do this.
In other words I don't think it would be any more of a special snowflake than it is.
If they dropped ARM64 compatibility (in other words stopped making Apple Silicon a superset of ARM64), this would be stupid in that it would make the platform less useful. It would make it impossible to e.g. run ARM64 Linux or Windows in a VM which is a fundamental use case of the machine for developers. I doubt they'd do this.
Why not?
As long as Swift and Objective-C development is the same as always, that is their public, not people that should be giving money to Linux or Windows OEMs.
As long as Swift and Objective-C development is the same as always, that is their public, not people that should be giving money to Linux or Windows OEMs.
People write C and C++ for those platforms too. And a lot of programming languages that Apple doesn’t ship compilers for.
They do, to the extent that they fullfill Apple platforms, like Metal shaders, IO and DriverKit, Network extensions, POSIX, macOS is after all a certified UNIX.
I never seen Mac OS X as something to use to target GNU/Linux.
The computer I use for GNU/Linux development was bought from Asus, with Ubuntu pre-installed.
I never seen Mac OS X as something to use to target GNU/Linux.
The computer I use for GNU/Linux development was bought from Asus, with Ubuntu pre-installed.
I write plenty of POSIX code on my Mac. Sometimes I send it to people to run on Linux without once running it on anything but my machine!
Luckily for you GNU/Linux implements most of the POSIX stuff, although as UNIX developers know, POSIX isn't 100% portable across UNIX implementations.
It was for sure designed to bring the locked architecture and tight value-chain control from iOS into the macOS space, in a slow transition which doesn't alienate the existing userbase (like the frog in a pot analogy).
For example, I don't expect them to address the situation with the Hackintosh market (people running macOS on custom PCs). They will simply fade-out OS-support for Intel CPU's, AMD GPUs and so on at one point, and then basically close the door behind all the M1/Mx users...
For example, I don't expect them to address the situation with the Hackintosh market (people running macOS on custom PCs). They will simply fade-out OS-support for Intel CPU's, AMD GPUs and so on at one point, and then basically close the door behind all the M1/Mx users...
They never supported Hackintoshes, and you need to remember there was a 20-year period before Intel where hackintoshes weren't possible. Apple is closing something they never supported and that wasn't there for the two decades prior, so I can hardly fault them.
For how well-known "hackintoshing" is, remember that the Mac has spent the majority of its existence without this ability.
For how well-known "hackintoshing" is, remember that the Mac has spent the majority of its existence without this ability.
The description of Hackintosh as a “market” is pretty amusing
To clarify: I didn't mean that they would/should "help" the Hackintosh community. Quite the opposite, when looking into it they don't seem to take a significant effort to shut it down for several years now.
It probably also helped them at times, especially when they didn't offer powerful desktop machines and were at risk to have customers transition to another OS.
But with the introduction of M1 I suspect that this is the solution for that Hackintosh "grey-market".
It probably also helped them at times, especially when they didn't offer powerful desktop machines and were at risk to have customers transition to another OS.
But with the introduction of M1 I suspect that this is the solution for that Hackintosh "grey-market".