Writing ARM64 Code for Apple Platforms
developer.apple.com
developer.apple.com
If that leads to lock-in, it's a happy accident.
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.
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.
This would explain why their users are so quick to defend the 30% cut, with sunken cost taken into account.
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.
That's more like what the current situation is.
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.)’
> 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...
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.
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?
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)
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.
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.
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.
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.
- 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.
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. :)
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.
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.
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...
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.
It's not that involved, by the way. There's a command that you run to turn off gatekeeper [1].
> "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.
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.
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.
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.
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.
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 how well-known "hackintoshing" is, remember that the Mac has spent the majority of its existence without this ability.
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".
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.
Can you give me a quote from the company or an otherwise official statement that supports this?
https://www.huffpost.com/entry/apple-ceo-tim-cook-expensive-...
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.
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.
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.
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.
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.
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.
To me that sounds pretty similar, they advertise it with similar features, functions and in practice it's also used similarly.
Well, uh, kid, it's a bit like that iPad you're using, but you can run any software you want on it.
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.
Actually there was much rejoicing when the Playstation moved to x86_64.
Most of them never used the old Mac OS, GUI based, with Object Pascal/C++ tooling, and zero POSIX.
And at the same time Apple expects me to build my business on those products.
It's certainly a pain, but cross-platform development has always been a thing so it's not a unique pain to Apple platforms.
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.
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.
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.