That particular "fact" does have some substance to it- In the past, Apple has switched as they feel that CPU horsepower is holding them back (keep in mind that they really want people to buy new every year) and they have already started moving their lineups over to ARM- their iPads have been ARM forever, and they have a pretty big knowledge base in it now.
EDIT: I think you may have been referring to the 9to5mac article- I'm going to leave this comment here, but the current article is way more specific.
Fair enough, I always associated PowerPC with Apple and assumed they were the driving force behind it's use.
Regardless, that makes the financial calculus even more suspect as they would have even fewer units to amortize the cost over. But I don't work for Apple, and quite frankly the CPU market could certain use the injection of some more competition.
They helped a little with the overarching design (the ISA of the vector unit was pretty much Apple designed) but they never made any chips themselves AFAIK.
Fewer units? They have arm processors in every iPhone, iPad and AppleTV. At least 70 million units a quarter. The Mac CPUs would need more cores/threads (perhaps octocore).
Apple and assumed they were the driving force behind it's use
Quite the opposite. Apple, according to the book The Race for a New Game Machine, was an unprofitable demanding customer. The scale of the XBox 360 and PS3 dwarfed Apple's usage and IBM made several decisions that were contrary to Apple's needs. PowerPC for the embedded market has been the primary driver of PowerPC development.
IBM made decisions about the Cell PowerPC that made it unsuitable for Apple (no out of order) and offered the 970 as compensation. We all got to see how those promises played out.
I think a lot has changed. Maybe not the ability to consistently lead Intel, but at least a larger portion of end users that would find an ARM laptop "good enough" exists now.
AMD is beating intel on price and performance and they have a fraction of the resources of Apple.
Intel is behind on process and has been for a couple of generations right as everyone hits a process wall.
For the first time since I got into computers in the late 80s Intel looks vulnerable.
As to whether Apple would go ARM on a MacBook who knows, I’d guess they wouldn’t but they could straight buy AMD in cash so it’s not beyond the realm they could tool up for desktop class ARM.
Indeed, AMD is finally in a good position after years wandering the desert. That said, this current strong performance is the result of years of R&D, something that would have to be built from the ground up if Apple was to try and replicate it.
I can't help but think there must be some secret benefit to make them pursue such a risky endeavour for something so tangential to their comparative advantage. Apple doesn't sell custom components, they sell consumer experiences. They must be planning on going a completely different direction with iOS to warrant custom processor technology.
I suppose hiring people like this (and this is he one we hear about they could have hired 20-30 people without anyone noticing) is a way to shortcut such R&D
Umm, you do realize that Apple has a large design team and outsources Fab to TSMC? Their iPhone/iPAD/AppleTV hardware platforms already run on their own ARM chip design. They SHIP over 70 MILLION units a quarter. They have the R&D teams already churning out new designs each year.
If Apple bought AMD, they'd lose out on all of the Intel-licensed IP because of the poison pull in the cross-patent licensing agreements between Intel/AMD in case of an AMD acquisition.
At least, that's according to what I've read about it.
The difference here is that the previous ISA changes have been accompanied with massive benefits. The 68k to ppc transition came with ppc being able to emulate 68k code faster than any 68k you could buy (in an interpreter, no JIT!!!), and the native ppc code was just ungodly fast comparitively. Ppc to x86 was less dramatic on raw perf, but was accompanied by a huge gain wrt perf per watt, and you could still emulate ppc on Intel about as well as you could run on a native ppc (with a JIT this time).
But now, Moore's law is in the process of hitting a brick wall. Those big wins for free just aren't there. And if there's a x86 to arm JIT, it's either going to be single core, or the arm cores are going to have to have a stronger x86 like memory model, thus negating a huge part of their architectural win.
IMO, Apple's going to make their own x86 chips because the base x86_64 patents are going to expire real soon now, and they have enough patents from the crazy amount of fabless acquisitions to potentially cross license the rest.
Processors are commodities now, and that's really going to shake things up in crazy ways.
> The 68k to ppc transition came with ppc being able to emulate 68k code faster than any 68k you could buy (in an interpreter, no JIT!!!)
This simply isn't true, it wasn't until the G3-300 was released that the 68k emulator could run 68k code at 40MHz comparable speeds, and that was after 10 years of ppc601s and 603s running 68k system binaries at slower than quadra speeds on 180 and 200MHz processors.
The 68k to ppc transition came with ppc being able to emulate 68k code faster than any 68k you could buy (in an interpreter, no JIT!!!), and the native ppc code was just ungodly fast comparitively.
Neither part of that statement is true. I had an LCII with a 68030-40Mhz card before upgrading to a 6100/60. The 6100/60 (601-60Mhz processor with a half speed bus) was much slower running 68K software than my LCII. It was about the same speed once I bought SpeedDoubler.
Also, between the slower bus, the slow shared graphics memory and System 7 on the PPC being emulated, it felt much slower than a decent 486-DX2/66 or a Pentium-60.
Yep and Macs of that era were also horribly unstable due to lack of memory protection, and this seemed even more complicated by the 68k emulation. Crashed all the time. At one of my offices there was a constant problem with Macs crashing if FileMaker and Netscape ran at the same time.
That’s true but in all fairness, it was a point of nerd pride if your operating system could handle a Netscape crash. Netscape was horrible on every single operating system it ran on. People seem to forget that IE was actually better than NS around IE 3.0.
>The company initiated a plan several years ago to replace Intel chips in its Mac computers with processors based on the ARM architecture as early as 2020.
Really sounds like they have some detailed knowledge, but yeah, no source is mentioned.
I don't think I could use a Mac for software development anymore if they switched away from Intel.
So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common.
I also need a Windows VM quite frequently for the odd program that only runs in Windows, or if I need to run Visual Studio one day. Windows is also very important for me to keep around so I can test software products in the same environment as other windows users, and there are definitely a handful of windows users out there.
Sure there may be alternative options in both areas but I'm not interested in solutions that work 80% of the time. I can't let my development environment get in the way of my work.
You know one of the great things about VMs? They're cross-platform. I'm guessing once the same amount of optimization is put into arm has has been put into x86, the performance ought to be comparable. I'm also about 99% sure docker can be run on arm (RPIs support it, right?).
With that said, I sincerely doubt Apple will kill x86 wholesale overnight. I'm guessing there will be a transitional period of quite some time.
Also, windows has been doing a ton of work around getting onto arm. I managed to test on my rpi 3, and it was pretty good. it would probably be very doable.
My understanding is that you could expect, very roughly, maybe a 50% performance hit using best of breed emulators translating from one ISA to an other ISA nowadays.
> So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common.
Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Because unless you are, I don't see what the issue would be with multiarch, assuming you don't manually compile the binaries for your containers.
Also AArch64 cloud servers are a commodity available from at least Amazon right now, and the hardware is available on the open market.
Not to mention, if you're running Docker right now, it's not running natively on macOS anyway. If you're just looking to test basic correctness, then surely you can run your dockers in QEMU or whatever AMD64 DBT/emulator is made available. Apple has a history of shipping good emulators (namely Rosetta and the 68k emulator) for their previous architectures when they change ISA.
> Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements?
Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS.
TLS is in just about everything.
You really need to develop and QA on the expected deployment platform
> "Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything."
Sure, but when it comes to platform enablement, that only really needs to be done once per vertical/native dependency. AArch64 has all of those things you listed. Don't know about .NET (though there's not that much .NET development on Linux, at least not when compared with the amount of Node and Java), but OpenJDK, Node, C/C++/Rust/Go toolchains all have mature support for AArch64, among others.
It's obviously less mature than the 40-year-old x86 ecosystem, but it's basically all there. Furthermore, the ease with which new ISAs can be adopted by toolchains and libraries is accelerating, so POWER and RISC-V are also getting there in terms of software availability.
There are so many different flavors of AMD64 that it’s not even a single target from my perspective. Check out the quantity of compiler flags and ifdef statements you see in just about everything.
I’ve seen binaries in production run at 30% of the speed seen DEV/QA. These would also segfault every few hours. But debug builds ran fine in production.
Root cause in that case was the Intel server had some hardware instructions available that the Intel developer and QA systems didn’t. The runtime chose to use these fancy new instructions, which turned out to be a buggy and slow code path.
Again, if you’re not doing DEV/QA on hardware (and OS, dependency, and firmware versions) that differ from production you will eventually be bitten.
Everything is so complex and there are so many layers involved it is impossible to have confidence. Containers make this worse in my opinion by adding another complex (and buggy) abstraction layer.
It would be slightly less convenient, but it probably wouldn’t affect your development capabilities so badly. Pretty much any Dockerfile that works on x86 should work on ARM. Linux runs totally fine on ARM. If anything, the worse problems are with Linux desktop and games software that assume ARM == embedded and attempt to use EGL and GLES.
There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues. (The latter is straight up a non-issue with a good CD pipeline.)
Windows 10 also runs on ARM platforms, with the ability to transparently emulate Intel. I’m sure this is or will be usable inside of VMs even if dual booting is not an option.
Most linux desktops work fine on ARM chips FYI. GPUs in the ARM world are usually just for OpenGL used by video games.
Video decoding/encoding is handled by a VPU (not GPU), HDMI is handled by a separate HDMI PHY, and most of these components have mainline, libre kernel support if you use an Allwinner based single board computer.
Microsoft has started branding some Mali GPUs as DirectX 11 capable, though YMMV on using these features.
Sure, but many games and applications are hardcoded to use EGL and GLES (which is not always available for desktop ARM.) For example, I believe Qt4 makes the assumption that ARM = GLES.
> There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues.
I'm not sure thats true. At the very least its going to suck for the first year as gaps are being filled, but those differences might matter too. I would hate to have to duplicate every single Dockerfile just because of this, as engineering orgs are typically heterogenous (win/lin/mac).
Should not need to duplicate the Dockerfiles; they should work as-is. The repositories may not contain aarch64 builds, but just like docker repos can contain windows container builds alongside linux, they can contain aarch64 alongside amd64, at the same URL, with the same tags, and in fact I think plenty of official images already have that.
Few images should need Dockerfile changes unless they are bootstrapping from scratch. People are already using Docker and Kubernetes on Raspberry Pi and other small ARM devices.
I don't think I could use a Mac for software development anymore if they switched away from Intel.
A clear message that's been coming from Apple over the past few years is that developers are not a market they care very much about. I strongly suspect a lot of us won't be using Macs for development in the future.
Do they? The App store is so full of automatically generated cookie-cutter apps with minor cosmetic differences that no one can really make a successful app any more. It's a lottery of who gets an Editor's Pick. That's not developer friendly.
Really? My iOS devices are full of high-quality applications that I bought on the App Store: Omnifocus, Omnioutliner, IA Writer, Pixelmator, Bear, Devonthink, Carrot Weather, Overcast, and dozens more.
I'm not suggesting there aren't great apps out there - I'm saying they're effectively impossible to find, and new app developers pretty much can't break in any more. There are 100 terrible apps for every good one, and you'll never find some of the best apps out there using the app store because of that noise. Finding new apps is driven by word of mouth, curation, etc. Apple themselves add practically nothing to the ecosystem, and certainly not enough to justify their 30% cut.
The list you added to your post is a good example of this - all those apps are examples of things that had a community outside of the app store before they had iOS versions. They're not good or successful because of Apple, but in spite of Apple.
No one has even try to give any convincing argument for ARM on Mac. And yet everyone seems to believe it as Fact.
1. There are articles that suggest Apple could move the Macbook, MacBook Air to their own ARM SoC, and leave the higher end MacBook Pro, Mac Pro, iMac on x86-64 for Professional Apps. In the case How is the Macbook different to iPad Pro with Keyboard? It is one thing to have a transition between two ISA, it is another thing to have the platform permanently on two ISA.
2. Is Apple going to spend hundreds of millions a year just to invest into Mac Desktop / high performance CPU, for use in iMac and Mac Pro CPU that runs from 100W to 220W. The Desktop Mac represent 20% of all Mac unit, that is roughly 4M. Majority of those are iMac, not iMac Pro or Mac Pro with high TDP.
3. If Apple want to lower its reliance on Intel ( After it has all of its modem and wireless patents sort out with Intel ), why not just use AMD to leverages the price or switch to AMD. AMD gets the PR win for Apple using it, win win for both companies.
4. The rumours would have some ground before WWDC, but Apple just announced a monster Mac Pro. Catering for real Hollywood professionals and Rack Mount Mac Pro for Servers.
I see no impediment to Apple running two CPU architectures in parallel for a decade. Arm for ultra-portables and base model Macs, Intel for mid/top spec macs.
Then eventually once the worldwide ecosystem becomes less x86 dominated, I could imagine Intel chips being a BTO option for people who need it, possibly even implemented as a secondary CPU available through a hypervisor.
But why does anyone really care about x86 vs ARM anyway? Assuming 100% of Mac software is recompiled, the only thing which would affect me is having Windows VMs with native speed... And I could easily replace that with a headless NUC and Remote Desktop.
> In the case How is the Macbook different to iPad Pro with Keyboard?
Why is this a problem? Maybe they phase one of them out when they make the change? Or maybe leave them as slightly differentiated products like the jumble of different laptops they already have.
> Is Apple going to spend hundreds of millions a year just to invest into Mac Desktop / high performance CPU, for [Pro]
This seems like a number you just made up. Here is a comparison of last year's A12 ($50?) and a 2017 Xeon 8176 ($5K?):
> If Apple want to lower its reliance on Intel ( After it has all of its modem and wireless patents sort out with Intel ), why not just use AMD to leverages the price or switch to AMD. AMD gets the PR win for Apple using it, win win for both companies.
Well they're fed up with Intel and there's the price gap but the primary reason is that the chip performance is rapidly converging so there is a massive opportunity to create a unified platform. Further they've been able to create a year plus performance gap between themselves and the competition in mobile on a commodity platform and with third party fab - if they do the same thing in desktop the Mac platform could really take off and they could go after the console market too.
>This seems like a number you just made up. Here is a comparison of last year's A12 ($50?) and a 2017 Xeon 8176 ($5K?):
You will have R&D just for the high TDP CPU, you don't just magically scale up your Phone CPU and expect it to work in a Server / Workstation. And that CPU has comparatively small volume. I.e The Unit Economics does't work.
The only Unit Economics would work better is to follow a similar strategy as AMD, where you have a single die and they are replicated across the 45W to 220W product line. This is a small sub 100mm2 Die Size with 4M yearly unit. But that is excluding the complexity of I/O where EPYC had a 400mm2 I/O die.
1. MacOS and iPad are similar, but distinct user experiences. Its more than hardware (one with keyboard, one without), its about those differences in experience. Apple is nothing if not patient about introducing change to computing paradigms and experiences, so it's fine to co-exist for a while. Switching to ARM gives them better margins, better control over price, better control over physical chassis constraints, better control over features offered, access to a better chip team than Intel's, and now TSMC and/or Samsung's better EUV processes. E.g. features-wise, Intel still isn't shipping LPDDR4 chips, something the 4 year old iPhone 6S had.
2. Basically, x86 becomes a co-processor, just like how discrete GPUs are handled. This avoids having to compete with tiny sliver of market that wants Xeons.
3. AMD is a lateral move, with exactly the same lack of control over core technologies problem. Also AMD is historically not as reliable a supplier for volumes that Apple has.
4. See #2 and my comment. Also, they needed to intro Mac Pro to satisfy / shore up existing Mac contingent before they abandoned entirely. This is a multi-year journey.
> 2. ... x86 becomes a co-processor, just like how discrete GPUs are handled ...
That's become my hunch too in the transition to ARM, with Apple producing a SoC that integrates an entry level x86, with usual 2 upgrade options. Eg the next product line would be:
$1599 -- Dual-Core 1.5ghz A14 + Dual-core 1.2ghz x86
$1899 -- Quad-Core 1.9ghz A14 + Quad-Core 2.4ghz x86
$2199 -- Quad-Core 2.5ghz A14 + Quad-Core 2.7ghz x86
To me that sounds way too costly (especially if they need to be an x86 licensee). And managing a heterogenous platform (HW/FW/OS) is damn hard without even considering the user experience standards that Apple are proud of.
I think they will take a different approach. Put a decent keyboard on a future iPad Pro. Make iOS more like macOS. And then they'll eventually kill macOS.
Because all these hypotheses assumes Co-Processor model works. And as far as I know,It doesn't. You cant move process between different ISA, not to mention memory access.
They also have the most silicon to work with. If you are designing a chip with x resources vs y resources its kind of unfair to say one design is better than the other. One design is optimized for one thing vs another. Arm needs to sell to wide set of customers who might be more more price sensitive than apple. If I could create a chip with more decoders, alu units, cache, etc. I can design a faster chip, but it wouldn't necessarily mean I am a better designer than an engineer who works at company x.
It's sort of a little bit of both. Like for sure their raw gate count is a huge part, but if you go look at a bunch of their acquisitions (particularly looking at Intrinsity here https://en.wikipedia.org/wiki/Intrinsity ), they have a lot of really cool techniques for making their designs count even gate for gate. Intrinsity's work is neat, because they didn't really make any uarch changes or increase the gate count really, they just made their Cortex-A8 core way better which lets you judge the work in an apples to apples (lol) way that you normally don't get.
Guy like Filippo, Keller, Koduri and such are pretty much like football players in the top leagues. Crazy signing bonuses, and clubs pay more for depriving an enemy team a key player, and assurance of him not playing against them, rather than for the genuine expectation of him performing for the team.
There are certainly many signs over the last few years that point to ARM Macs.
I don't mind what CPU my Mac runs on, but I am worried about how long I'll be able to play older games, run the occasional Windows/Linux software, and dabble in OS hacking or low-level tinkering to add custom features, on the same machine.
The seemingly gradual lockdown of macOS – mandatory "notarization", moving system files to a read-only volume, and disallowing kernel extensions in the future* – has generated some concern where before I used to just trust Apple to know what's best for everyone.
I welcome the extra security as long as we can manually bypass it if we really want to, but I warily wonder if the move to ARM Macs will come with a macOS that is almost as locked-down or "sanitized" as iOS.
* As mentioned during this WWDC's Platforms State of the Union.
I have used multiple gens of the MacBook Air for web programming—often docked—most recently w the assist of an egpu.
I am interested in battery efficiency, raw cpu and graphics performance and do not care to do low level tinkering on my Mac.
I do expect it to be much more open to tinkering than iOS, but I also welcome the litany of security measures introduced so far and caution when it comes to executing wild code that affects my privacy.
I realize this puts me further in with trusting Apple to make good compromise decisions on what is possible and the hoops they create for developers on Macos, but I trust they will mostly make the right call for me.
It’s certainly been better than when I’ve had to deal with windows over the past decade.
You may not, but many do. Those many may actually be a small minority, but it would really suck for those folks.
At the end of the day, sometimes I need to run random x86/64 executables and there isn't any way around that. I could deal with a performant virtual machine.
It was just an example. What applications require hardware support that isn’t baked in? Surely the Mac isn’t being used in an industrial space with niche one off instruments? The point is more things are moving to userpsace and Apple is controlling the kernel as, I think, they should.
As with all such changes there will be with time either open source or manufacturers who support the new user space / kernel lock down mode. What you’ll likely experience is temporary loss of use as things transition. In any case the benefits outside of your specific use case outweigh the headaches in just security alone.
You already have to opt into kernel extensions in a very explicit way. I don't think what you mentioned about privacy is actually relevant to this dicussion.
I like to use my Mac as a normal *nix machine, however I have a lot more trust in my iPhone from a security POV these days. I can see a case for a much better desktop/laptop security model.
Not OP, but I certainly would not be ok with that.
iOS is system build mostly for content consumption and designed for non-technical users. As such it has to be protected from both external threats (malware etc) and users themselves (social engineering, phishing protection).
macOS is for me my workbench for content creation and I want it to protected from external threats but I do not want it to be protected from me. Even having to go into System Preferences and typing in my password to run unsigned apps since 10.12 is driving me crazy.
When is comes to privacy, today everything is web app anyway. And to be honest I would feel my privacy would be much more secure if I could run latest version of uBlock Origin in Safari, but I cannot.
For native apps I want to decide if I trust them or not. The only new thing I would love to see in macOS is easy blocking of internet access for particular apps.
There is a significant community in the (biological) sciences that are reliant on the Mac platform as an intermediate between Windows based applications such as Office and, importantly, the often highly specific programs/scripts/applications created for Unix platforms for analysis. Ignoring these users would be a mistake.
Personally, after 13 years of Macs any computer I'm buying in the near future are going to be Linux based because of the current trajectories Apple have decided to take.
Wouldn't running Windows 10 and the Microsoft Subsystem for Linux make way more sense for these users? Seems more like inertia that is keeping some on the Mac.
In academic environments there is often no dedicated IT department, so all support is done by the technically versed colleagues. Replacing machines with Macs has always resulted in an enormous reduction of these support calls, in my experience. Moving back to Windows would destroy all of that.
I agree, the Microsoft subsystem for Linux will draw many more users away from macOS in the future. When I was starting post-graduate studies/research there was no such support from Microsoft officially. However, now that there is I wouldn't be surprised if academics are more likely to consider Windows in the future for this reason. Good move from Microsoft.
As a Mac lover of 15+ years, at least put PCs under consideration. I bought a Lenovo X1 Yoga to replace my dead MBP. It has a touchscreen, fingerprint reader with U2F support, folds into a tablet, and I do all my development in windows VSCode linked into Ubuntu on WSL. The only thing I miss is having iMessage on the desktop.
> touchscreen, fingerprint reader with U2F support, folds into a tablet
None of that is a compelling enough reason to switch, when the OS is the primary reason I jumped ship to Macs in the first place.
It's not just about being able to run this or that app, but the overall comfort of my everyday work environment, while still giving me the room to occasionally step out of my comfort zone on lazy afternoons.
As long as macOS retains the ability to run emulators, I think I'll be fine with its growing number of security-based restrictions.
However, whenever I have occasionally peeked back in on the state of Windows (the last time being a year ago, to run some games), it still had many of the same annoyances, frustrations and archaic encumbrances that made me wish for a better world and try out Macs around 10 years ago, and I still don't agree with the overall philosophy of Microsoft (as I perceive it.)
Apple/macOS remains the "lesser evil", at least for me.
Do you write any code? Because that is not allowed on iOS. Do you want to browse see an application and want to use it? Because that is not allowed on iOS. iOS is so far from being a useable OS that I don't think it will ever be anything more then an internet machine with light video and image editing capabilities. The last update to the ipad pro should tell you enough about what apple thinks constitutes a "professional" OS.
That being said OSX running on a higher specced ipad pro CPU could be really awesome but I don't think that is what will happen.
And that is ignoring cloud/browser-based code editors. That execution model (write code local, run in the cloud) makes sense with mobile devices which have limited power supply. I personally don't want to spin up several docker containers on my iPhone ;)
> I personally don't want to spin up several docker containers on my iPhone
But other people might? Especially if it not a phone but a 12.5 inch iPad that is supposed to be more powerful than my 5-year-old dev laptop (and has more RAM too).
> It is allowed to write code on iOS
Great, so you can pen&paper your code like in the 1960s. In the 21st century, writing code includes being able to run the compiler/interpreter on your terminal to debug as well.
Moving from Intel -> Arm would be a dealbreaker for me, as I presume any VST/Au/FCPX plugins would be unusable. As people using those tools typically acquire them over a period of years, the original developer isn't always going to be still around or interested in developing a port for an older product. Over the years, the investment in plugins can be much greater than the host (DAW or NLE) that they run in.
I for one have never really felt or noticed the effects of poor OpenGL support on macOS, at all in the last 10 years.
Metal seems much more compelling anyway, the Apple lock-in notwithstanding (even that is not so bad considering you can still target 4 rather popular device categories with Metal.)
For long spans of Mac OS X's history, Apple always shipped an incredibly old version of OpenGL. With Apple deprecating OpenGL, this isn't really anything new or interesting — that is, until the day Apple removes OpenGL, we will have the exact same situation we always had: a really old version of OpenGL.
In the mean time, people have already developed ways to run OpenGL code atop Metal. A lot of game developers have already started to move their code to either Metal or these OpenGL-compatible shims in order for compatibility with iOS, so a lot of the adoption has already begun.
> Notarization is not “mandatory”. You can still turn it off.
For how much longer? I'm not asking facetiously, the trends across the entire industry are quite obvious at this point.
> So now it’s a bad thing that rogue apps can’t destroy your system.
It's a bad thing that modern "security measures" somehow consistently manage to be as restrictive towards user freedom as possible. Methods that would accomplish the same user protection without resulting in a walled garden or vendor control of the device are somehow never selected for.
I'm sure there are no ulterior motives at play here though. /s
For how much longer? I'm not asking facetiously, the trends across the entire industry are quite obvious at this point.
This same panic has been going on since 10.6 with the introduction of the Mac App Store. How do you propose that you would be able to develop software on the Mac if you had to sign your executable every time that you recompiled it?
It's a bad thing that modern "security measures" somehow consistently manage to be as restrictive towards user freedom as possible.
So what would be the financial motive for Apple to force signing of apps and allow them to be outside of the App Store? What would be the financial motive of making system files readonly or introducing DriverKit to increase stability. Do you really want third party kext to be “free” to crash your entire system?
They could require a paid Apple developer account to sign MacOS binaries just like they do with iOS (with the exception of those certs that expire after a week).
I think they would be crazy to do it and don't really expect them to anytime soon but they clearly could. The financial motive is exactly the same as the iOS App Store: get 30% of all app sales revenue and make the OS more secure.
I think they, along with every other major vendor, are consistently moving towards precisely this model. I don't think they will do it soon, but I think it is likely to happen eventually.
So how do you propose they force signing for programs built on top of a VM like C# or Java or scripting languages?
Also, they don’t get 30% of all app sales. All of the biggest non game money makers either allow you to purchase subscriptions and content outside of the store or force you to.
The same way they already force signing for iOS programs. I don't know the details but you can write iOS apps in C#, Java, and Python today so clearly this solution already exists.
No a solution doesn’t exist - all of those solutions compile down to a native executable and don’t run on a VM. Even in a hypothetical unlikely future where the JVM, CLR, and whatever runtimes the scripting languages run on had to be signed (which is not a bad idea), you still would be able to write a program that did whatever you wanted unless now you’re going to say that in this hypothetical future, Apple is not only going to force signing, it’s also going to refuse to sign any executable that can run other programs.
> This same panic has been going on since 10.6 with the introduction of the Mac App Store.
And rightfully so! How is this not an obvious trend to you?! It isn't just Apple, it's cell phones and tablets with unlockable bootloaders, Windows S-Mode, Samsung Knox, Firefox extension signing that can't be disabled, and a great many other examples. It's the trend that's alarming, not the specific way macOS is configured right now.
> How do you propose that you would be able to develop software on the Mac if you had to sign your executable every time that you recompiled it?
By paying the Apple tax for a developer license and then just... signing your code every time you compile it? You already have to do this for Firefox extension development if you don't bother to run a dev or unbranded build. Alternatively, just run your (unsigned) compiled code in a VM.
> So what would be the financial motive ...
The financial motive is the glaringly obvious walled garden! It's the vendor's control over the device you purchased!
> Do you really want third party kext to be “free” to crash your entire system?
Obviously not; that is a bad faith interpretation of what I said previously. There are ways to ensure user security that don't remove control of the system from the end user. These options are consistently not chosen, by more or less all the major manufactures. I believe that the motives for such behavior are quite obvious.
By paying the Apple tax for a developer license and then just... signing your code every time you compile it?
You really think after selling computers for 43 years Apple is not going to allow people to compile programs without signing every time you compile?
How do you propose they are going to lock down scripting languages and programs built with .Net Cord and Java? Are they going to disallow any code on the Mac that’s built on top of a VM?
The financial motive is the glaringly obvious walled garden! It's the vendor's control over the device you purchased!
So are they now going to lock down outside vendors from creating whatever the new equivalent of kext are without paying a fee?
bad faith interpretation of what I said previously. There are ways to ensure user security that don't remove control of the system from the end user.
You mean by allowing advanced users of the Mac to turn off safeguards- exactly what they are doing now?
Btw, a lot of developers are saying that moving away from kernel extensions will make it easier to build Hackintoshes not harder.
> The financial motive is the glaringly obvious walled garden! It's the vendor's control over the device you purchased!
While this is certainly technically possible, I think this presumption -- which I see a fair amount around HN -- is at the least somewhat dubious. There's an extremely crucial difference between the Mac and the iPhone/iPad that this argument downplays at its peril: the iOS ecosystem has never been open in this way; the Mac ecosystem has been open in this way for over three decades. Customers do not tend to react well to having things taken away from them.
What's the cost of not just individual users but whole companies moving off the Mac platform en masse? What's the cost of a press firestorm so intense it'll make the butterfly keyboard shitshow look like free passes to Disneyland? Are you sure so many users would just docilely acquiesce to "guess I'll have to re-buy all my software all over again, herp de derp?" Because for this plan to make sense, Apple needs to sell a whole, whole, whole lot of software to make up for every single person who decides this is the straw that breaks the camel out of the habit of buying $2500 laptops every three or four years.
The bottom line is that I don't think attempting to lock the Mac down to the point the iPad is locked down makes business sense. (I'm not convinced keeping the iPad locked down makes business sense in the long run, either. But that's a different post.)
I think you’re on the wrong platform. The platform of openness you’re looking for is the vast ecosystem of Linux or the BSDs. Apple has never really been open. They don’t release the OS to run on x86 boxes we build, the company is famously vertically integrated so it’s no surprise to me that they’re moving in this direction.
The Nintendo Switch does have a WWW browser, solely for permitting access to Internet connection points that require loading a WWW page and performing a certain action as a prerequisite for use.
It's appalling an entire WWW browser would be necessary for connecting to certain Internet access points, but that's the current state of things.
In any case, someone has already achieved arbitrary code execution through it, but it was sandboxed anyway.
I don't want random applications to access $HOME just because they feel like it.
If the application was designed for accessing $HOME given its purpose, then I as user, will gladly authorize it.
As developer, and someone that in the past dealt with games and mobile development like J2ME and Symbian, I don't see a big issue going through app certification processes.
Game consoles also disallow running any software you may want and you can only run whatever is sanctioned by the console makers. This is the #1 reason i do not buy any console and the reason that instead of getting something like the Switch i got a GPD Win instead (a gaming handheld PC that runs x86 Windows, although you can install Linux if you want too) even though it is more expensive: i can run anything i want on it without requiring approval from anyone (in fact so far i only have used games from my GOG catalog and the installation process was just copying the installers to a USB from my main PC and running them on the GPD Win).
Being able to do that isn't just a nice thing to have, it is a downright mandatory ability any computer must have.
You can remove them anytime. Do you really want your car to not start at all if the seatbelt is not on? I'm sure that would improve survival rate by something like 0.1%, too.
This is optional, available only for specific professional uses and above all: wearing a belt doesn't impact where you can go, whereas a locked down OS does impact what you run on it.
I do not have any problem with app stores as long as they are not tied to a locked down OS. See Steam or any Linux repository front-end as an example of app stores that do it right.
So you need Apple's yearly approval to run your own software. Personally i consider this a major dystopian flaw of iOS and one of the main reasons i do not buy their devices (the other being their disregard towards backwards compatibility).
How dare they drop support for 68K software! How far back do you think they should stay backwards compatible? The newest ARM chips in iOS devices don’t have any support for 32 bit instructions and MacOS hasn’t supported 32 but processors for over a decade.
Having to use a seatbelt or helmet doesn't prevent you from going to any place you want to go.
Not being able to install any software you want on a device you own is not a small inconvenience cost, it is a great artificial limitation meant to take control away from the user and put the user at the mercy of the vendor who can then use it for other user hostile actions (e.g. forced obsolescence, a common tactic in the example of gaming consoles brought before).
And especially in this case, any "better" outcome is really small and short term (the user being unable to do much with their own device means they are also unable to install unwanted software) whereas the larger picture outcome is user hostile - a gradual loss of control and ownership to the goods you are paying for.
I rather have a store than a background application taking machine resources, to ensure that applications are safe to use and do not expose my computer contents to the world when connected.
I'd thank malware authors and virus writers only if i was a platform vendor trying to find a scapegoat for why i "have" to take away control from users.
Thankfully i'm not one. But that doesn't make me blind on such schemes.
Also that background application you mention, even though it isn't necessarily needed in all cases, it is still a better solution than a locked down system since it is under the user's control.
For how much longer? I'm not asking facetiously, the trends across the entire industry are quite obvious at this point. [...] I'm sure there are no ulterior motives at play here though. /s
If that's Apple's trajectory, why did they things like Hypervisor.framework (much more recent than 10.6's introduction of the App Store), which allows one to make unprivileged virtualization solutions, that can run any OS/application?
To me, it their motivation seems two-fold: (1) they want to carve out a niche for security and privacy. People are willing to spend a lot of money to avoid the data grab of Facebook, Google et al. And people are willing to spend money on a system that focuses on security. So, Apple have invested a lot in hardware security (T2) and software security (sandboxing, read-only system files, mandatory kext signing, user-space drivers).
And, yes (2) they probably also want to funnel more and more through the Mac App store for profit. The thing is, they can make macOS a walled garden system, while keeping the back door open for advanced users. My dad is protected by the Mac App store, application bundle signing, notarization, and sandboxing, he is not going to boot in recovery mode and run csrutil in the command-line. While I can in the use csrutil to lower protection a bit to be able to run DTrace. In other words, I don't believe that they want to or need to turn macOS in a complete walled garden: 90% of the users does not want to or cannot disable security measures, while at the same time keeping the csrutil around keeps the other 10% happy.
---
I think the more serious danger for macOS was negligence. With key execs primarily using iPads and glacial development of macOS, the most imminent danger seemed to be that macOS developed into nothing else but an SDK/IDE for iOS development. But after the last WWDC, I am mildly optimistic that they have woken up.
Perhaps what Apple wants is to keep improving their iPhone / iPads with better ARM processors (from where the make most of the money).
Just remember that they don't use the regular "off-the-shelf" ARM processor.
By having even better ARM processors, they can keep having and edge over the competition.
One day, they might switch Mac to ARM. But I don't see that in the short term.
I wonder if it would be possible to have an heterogeneous processor with a mix of arm and x86 cores. (They would probably have to partner with AMD which will produce x86 chiplets for them)
From what I remember at the time it never took off due to being expensive and having overly high power consumption. But perhaps it's an idea worth revisiting.
The RISC PC [1] was based on ARM but had a ‘guest processor’ slot which could be filled with an x86 chip amongst others. You could run Windows in a window on its own CPU.
This is roughly my hypothesis, except they'd be separate CPUs and AMD wouldn't be involved. Due to the markets Apple is in with Mac, they can't just stop using Intel altogether - they need both x86 and ARM to coexist.
How it'd work - ARM SoC expands on what the T2 does today, except it now runs all system threads, any ARM native user space apps, and maybe specialty fixed function blocks that Apple throws on those chips (e.g. media encode). Meanwhile the Intel chip is a co-processor for any x86 specific user space apps, and it otherwise doesn't touch drivers or any system things.
The market would be segmented with ARM chips at the lower end (MacBooks), and ARM chips with Intel co-processors at the higher end (15" MacBook Pro, iMac, iMac Pro, Mac Pro). This is equivalent to how integrated v discrete GPUs are segmented today.
Over time the ARM chips get faster and faster as Intel inevitably blunders, and more and more code is rewritten as native ARM code, so that after several years the need for x86 is significantly reduced, maybe only existing as thunderbolt eCPU boxes and/or Mac Pro. And by around MacOS ~10.23 in 2026, x86 is sunsetted because remaining use cases are so minimal.
How it'd work - ARM SoC expands on what the T2 does today, except it now runs all system threads, any ARM native user space apps, and maybe specialty fixed function blocks that Apple throws on those chips (e.g. media encode). Meanwhile the Intel chip is a co-processor for any x86 specific user space apps, and it otherwise doesn't touch drivers or any system things.
That's not really Apple's style, at least not under Steve Jobs ;). You just throw the old architecture under the bus, provide some emulation to make Microsoft and Adobe catch up, all developers have to adapt and build fat binaries or get left behind.
Apple can do this, since no one has a strong expectation of backwards compatibility anyway.
Of course, ARM might not be competitive enough yet for Mac Pros. So they'll probably start with the MacBook Air or 12", require every developer that submits to the Mac App store to build universal binaries, and have some partners (probably Microsoft) that will provide support on day 1. For a chunk of the MacBook Air audience the architecture will be irrelevant, since they do Office, browse the web, and send e-mails. So, if they get a laptop with significantly better battery life doing that, it will sell. Once the Air has prepared the software market, go up the product line after 1-2 years.
I like the Intel co-processor idea, but Intel CPUs are relatively expensive. So, they'd have to jack up prices, while going ARM directly would increase their margins at the same price points.
Agree that they'll have devs submit ARM builds and all that.
fwiw, the reason I think the co-processor idea is likely is that Apple has recently re-committed to the Mac and specifically some niche use cases therein (thus they can't fully ditch Intel), and that they're already shipping an A10 equivalent in Macs today (the T2) so not that hard to go a bit further into the water. Also, in single core perf its possible the ARM chips would exceed most Xeons they ship, which clock lower in favor of more cores.
Agree if Apple had its way and could pick its markets perfectly, they'd have slowly shed niche use cases in favor of the highest margin markets (which is mainstream not pro), and thus at the appropriate moment dumped Intel and gone all-in on ARM. However, they're seeing the traditional pc market only moves so fast, there's many many pro niches they didn't really consider enough, and those niche Mac users really do have a lot of indirect value to Apple's brand. Emulation wouldn't cut it for those users - it'd only work if Apple saw ditching those markets as an acceptable tradeoff.
Intel CPUs are expensive but so are GPUs, and they'd only be bundled in the higher end machines - nothing that's below $2500-3000.
What do you gain from it being open? Things like home brew will adapt. And this way the system gets a ton more secure. And with an ARM cpu we will get great performance but even better battery life probably. The software that we used to run will likley have to adapt and I’m sure we’ll be able to emulate x86 but the future seems to be ARM at least to Apple.
Security is fine as long as the user is in control. The problem is that very often companies make decisions that take away control from the user with "security" as a "but think of the children" blanket excuse.
For any company other than Apple I would agree with you. There’s too great an incentive for a company to, given this lack of transparency, do something nefarious. But I trust Apple to not do this. Because it is in their best interest to be the anti-Google. To not spy is a value add for them.
Apple made iOS which is heavily locked down, not even allowing the -ridiculously named- "sideloading" that (some of) Android allows, i'm not sure why you think they wouldn't like that sort of control on macOS. The only reason they haven't already locked down macOS like iOS is the precedence of computers not being locked down for decades, but this is exactly why they chip away that freedom little by little instead of going all-in.
If they had no incentive for macOS to be locked down then they wouldn't have any incentive for iOS to be locked down either.
This is FUD. Apple has clearly stated that MacOS and iOS will stay separate platforms. It makes no sense to sell laptops at all if they make them into iOS style appliances as you have described.
Apple has stated a lot of things they changed later. Companies have many reasons to lie, especially if they have a long term plan that they want the public/customers to follow. Just because a company stated something, it doesn't make it fact.
Also i never said that laptops will be made into appliances, i said that they'll be locked down like iOS. You can still do a lot of things on iOS but all of them need to things pre-approved by Apple and a lot of the things you cannot do on iOS is because of its form factor - something that can be addressed with the form factor of a laptop.
If anything i think you may have already fallen victim to the artificial separation that Apple has introduced between laptops and tablets: why doesn't it make sense for laptops to be limited whereas it makes perfect sense for tablets and phones to be limited? It doesn't. There is no reason why iOS has to be limited just like there is no reason for laptops (and desktops) to be limited, it is just that this is how phones and tablets were introduced to the mainstream audience and how the mainstream audience has come to accept and expect them.
Apple’s “pre-approval” is what makes the iOS platform secure. I get the impression that you’re airing this angst out in a field with your fist to the sky... what you’re complaining about is a feature not a bug. If you want side-loading and a relatively wild-west approach to freedom and access try Android.
Regarding the MacOS platform though: I don’t think they’ll get rid of the ability to add binaries to a user’s home directory much like it is now. It’s a development and productivity platform that doesn’t abstract its Unix underpinnings like iOS does.
But I'm not so much of a zealot to think that if they do do something underhanded like lock down MacOS to a completely unusable outside of Apple ways to not go to a different platform. Until then I will stick with them for sure.
It is also what gives Apple the power to lock older iOS devices from getting new apps - regardless if those devices would be able to run those apps or not and many of those devices would be able to run a large number of applications they have not access to - and force users to upgrade their devices to newer models.
Also Android is not wild-west freedom, the entire idea behind "side-loading" (which is not available everywhere) is a sign to that - or even worse, the inability to gain root access to your own device. If you want an example of such freedom, it would be something like what you see on desktop systems such as Windows or Linux (though Windows 8 and later did piss in the pool with their Metro/UWP efforts).
macOS can become a development and productivity platform while at the same time being locked down. For example you'd be able to install Xcode and even a (user-only) Unix command line environment that will autosign any executable you create for use only on your own machine and a few preapproved others. AFAIK this is how it is already done with iOS devices, except Xcode doesn't run there (but that is mainly an issue with API availability, not it requiring anything that couldn't be provided on a locked down macOS). Since this would require an annual developers' fee, it'd make any source-based releases impractical outside of developers and even that only for as long as you pay that fee (again see iOS: it isn't like you cannot download some iOS program in source code form and install it on your own device, but to do that you need to pay Apple for the privilege).
I think I understand where you're coming from but I think a lot of your concerns are overblown. But to each their own, let's just see where they take things.
Of course, it's just one step further to what Apple want. Make MacBooks so much more efficient and powerful than PC competitors that theres no competition, then force everyone to use the App Store where they can get their 30% cut of another entire platform.
On iOS you can compile code that uses SIMD instructions, but querying whether the CPU supports them is privileged, and iOS does not provide an API to do that.
So if you want to write code that uses SIMD instructions depending on whether they are available, you need to use Apple math libraries, which is super messed up.
It’s been a while since there was an iOS device without NEON support. Unless you’re supporting something like iOS 4 (which is a whole other headache) you can use the SIMD instructions unconditionally. This is the armv6/armv7 distinction you can find in the XCode settings. For 64-bit slices of your app, you’re in even safer territory.
arm64 CPUs support NEON unconditionally. arm64e implies the armv8.2 and armv8.3 extensions (but not SVE), notably half-precision arithmetic and interleaved complex ops. You generally should not need to do runtime selection.
Binary translation emulators are pretty damn good these days, I would imagine that Apple would have to include one if they fully moved over to ARM of some description from x86
Just hope they have an AI gpu gp programme. Otherwise a bit forced to move to windows and linux currently even for my personal pc. (Cloud ok but offline or testing still want one close by. Current apple no Nvidia.)
Considering the launch of Mac's App Store, the move to using LLVM IR-based distribution, and this, it sounds reasonable that they're trying to build an ARM-based MacBook! And considering the present state that OSX performs much better than Windows of the same hardware spec, it would be really a big game changer if Apple were to succeed in creating a performant ARM-based Macbook! Battery life of such Macbook would be super crazy and I guess more people would move over to Mac? I hope Linux and Microsoft do something before this happens...
199 comments
[ 3.6 ms ] story [ 213 ms ] thread>Apple is in the process of migrating its Mac line to ARM processors as it looks to reduce its reliance on Intel.
EDIT: I think you may have been referring to the 9to5mac article- I'm going to leave this comment here, but the current article is way more specific.
Has that calculus changed in the meantime?
Then again Apple was also the other partner (with Acorn) in founding ARM.
https://en.m.wikipedia.org/wiki/Apple%27s_transition_to_Inte...
Regardless, that makes the financial calculus even more suspect as they would have even fewer units to amortize the cost over. But I don't work for Apple, and quite frankly the CPU market could certain use the injection of some more competition.
Quite the opposite. Apple, according to the book The Race for a New Game Machine, was an unprofitable demanding customer. The scale of the XBox 360 and PS3 dwarfed Apple's usage and IBM made several decisions that were contrary to Apple's needs. PowerPC for the embedded market has been the primary driver of PowerPC development.
I'm glad Apple opted to move to Intel then. The Cell is the hardest thing I ever tried to write code for.
Intel is behind on process and has been for a couple of generations right as everyone hits a process wall.
For the first time since I got into computers in the late 80s Intel looks vulnerable.
As to whether Apple would go ARM on a MacBook who knows, I’d guess they wouldn’t but they could straight buy AMD in cash so it’s not beyond the realm they could tool up for desktop class ARM.
I can't help but think there must be some secret benefit to make them pursue such a risky endeavour for something so tangential to their comparative advantage. Apple doesn't sell custom components, they sell consumer experiences. They must be planning on going a completely different direction with iOS to warrant custom processor technology.
How is this risky?
At least, that's according to what I've read about it.
The cross licensing deal (of AMD on x86) with Intel would be off. Pretty much AMD is not sellable in this regard.
AMD could produce/design an ARM chiplet, attached with infinity fabric to their Zen2.
But now, Moore's law is in the process of hitting a brick wall. Those big wins for free just aren't there. And if there's a x86 to arm JIT, it's either going to be single core, or the arm cores are going to have to have a stronger x86 like memory model, thus negating a huge part of their architectural win.
IMO, Apple's going to make their own x86 chips because the base x86_64 patents are going to expire real soon now, and they have enough patents from the crazy amount of fabless acquisitions to potentially cross license the rest.
Processors are commodities now, and that's really going to shake things up in crazy ways.
This simply isn't true, it wasn't until the G3-300 was released that the 68k emulator could run 68k code at 40MHz comparable speeds, and that was after 10 years of ppc601s and 603s running 68k system binaries at slower than quadra speeds on 180 and 200MHz processors.
Neither part of that statement is true. I had an LCII with a 68030-40Mhz card before upgrading to a 6100/60. The 6100/60 (601-60Mhz processor with a half speed bus) was much slower running 68K software than my LCII. It was about the same speed once I bought SpeedDoubler.
Also, between the slower bus, the slow shared graphics memory and System 7 on the PPC being emulated, it felt much slower than a decent 486-DX2/66 or a Pentium-60.
Really sounds like they have some detailed knowledge, but yeah, no source is mentioned.
https://www.bloomberg.com/news/articles/2018-04-02/apple-is-...
So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common.
I also need a Windows VM quite frequently for the odd program that only runs in Windows, or if I need to run Visual Studio one day. Windows is also very important for me to keep around so I can test software products in the same environment as other windows users, and there are definitely a handful of windows users out there.
Sure there may be alternative options in both areas but I'm not interested in solutions that work 80% of the time. I can't let my development environment get in the way of my work.
With that said, I sincerely doubt Apple will kill x86 wholesale overnight. I'm guessing there will be a transitional period of quite some time.
Also, windows has been doing a ton of work around getting onto arm. I managed to test on my rpi 3, and it was pretty good. it would probably be very doable.
Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Because unless you are, I don't see what the issue would be with multiarch, assuming you don't manually compile the binaries for your containers.
Also AArch64 cloud servers are a commodity available from at least Amazon right now, and the hardware is available on the open market.
Not to mention, if you're running Docker right now, it's not running natively on macOS anyway. If you're just looking to test basic correctness, then surely you can run your dockers in QEMU or whatever AMD64 DBT/emulator is made available. Apple has a history of shipping good emulators (namely Rosetta and the 68k emulator) for their previous architectures when they change ISA.
Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS.
TLS is in just about everything.
You really need to develop and QA on the expected deployment platform
Sure, but when it comes to platform enablement, that only really needs to be done once per vertical/native dependency. AArch64 has all of those things you listed. Don't know about .NET (though there's not that much .NET development on Linux, at least not when compared with the amount of Node and Java), but OpenJDK, Node, C/C++/Rust/Go toolchains all have mature support for AArch64, among others.
It's obviously less mature than the 40-year-old x86 ecosystem, but it's basically all there. Furthermore, the ease with which new ISAs can be adopted by toolchains and libraries is accelerating, so POWER and RISC-V are also getting there in terms of software availability.
I’ve seen binaries in production run at 30% of the speed seen DEV/QA. These would also segfault every few hours. But debug builds ran fine in production.
Root cause in that case was the Intel server had some hardware instructions available that the Intel developer and QA systems didn’t. The runtime chose to use these fancy new instructions, which turned out to be a buggy and slow code path.
Again, if you’re not doing DEV/QA on hardware (and OS, dependency, and firmware versions) that differ from production you will eventually be bitten.
Everything is so complex and there are so many layers involved it is impossible to have confidence. Containers make this worse in my opinion by adding another complex (and buggy) abstraction layer.
There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues. (The latter is straight up a non-issue with a good CD pipeline.)
Windows 10 also runs on ARM platforms, with the ability to transparently emulate Intel. I’m sure this is or will be usable inside of VMs even if dual booting is not an option.
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
Video decoding/encoding is handled by a VPU (not GPU), HDMI is handled by a separate HDMI PHY, and most of these components have mainline, libre kernel support if you use an Allwinner based single board computer.
Microsoft has started branding some Mali GPUs as DirectX 11 capable, though YMMV on using these features.
I'm not sure thats true. At the very least its going to suck for the first year as gaps are being filled, but those differences might matter too. I would hate to have to duplicate every single Dockerfile just because of this, as engineering orgs are typically heterogenous (win/lin/mac).
Few images should need Dockerfile changes unless they are bootstrapping from scratch. People are already using Docker and Kubernetes on Raspberry Pi and other small ARM devices.
A clear message that's been coming from Apple over the past few years is that developers are not a market they care very much about. I strongly suspect a lot of us won't be using Macs for development in the future.
The list you added to your post is a good example of this - all those apps are examples of things that had a community outside of the app store before they had iOS versions. They're not good or successful because of Apple, but in spite of Apple.
1. There are articles that suggest Apple could move the Macbook, MacBook Air to their own ARM SoC, and leave the higher end MacBook Pro, Mac Pro, iMac on x86-64 for Professional Apps. In the case How is the Macbook different to iPad Pro with Keyboard? It is one thing to have a transition between two ISA, it is another thing to have the platform permanently on two ISA.
2. Is Apple going to spend hundreds of millions a year just to invest into Mac Desktop / high performance CPU, for use in iMac and Mac Pro CPU that runs from 100W to 220W. The Desktop Mac represent 20% of all Mac unit, that is roughly 4M. Majority of those are iMac, not iMac Pro or Mac Pro with high TDP.
3. If Apple want to lower its reliance on Intel ( After it has all of its modem and wireless patents sort out with Intel ), why not just use AMD to leverages the price or switch to AMD. AMD gets the PR win for Apple using it, win win for both companies.
4. The rumours would have some ground before WWDC, but Apple just announced a monster Mac Pro. Catering for real Hollywood professionals and Rack Mount Mac Pro for Servers.
Yes, everyone believes it is coming, just like they believed the iPhone was coming, the iPad was coming, the Apple watch was coming.
There are enough news to support such rumors than there are news to discredit them.
But of course, there are stories like AirPower too.
- Cost
- Motherboard size
- Performance per watt
- Battery life
- Custom optimizations
I see no impediment to Apple running two CPU architectures in parallel for a decade. Arm for ultra-portables and base model Macs, Intel for mid/top spec macs.
Then eventually once the worldwide ecosystem becomes less x86 dominated, I could imagine Intel chips being a BTO option for people who need it, possibly even implemented as a secondary CPU available through a hypervisor.
But why does anyone really care about x86 vs ARM anyway? Assuming 100% of Mac software is recompiled, the only thing which would affect me is having Windows VMs with native speed... And I could easily replace that with a headless NUC and Remote Desktop.
Why is this a problem? Maybe they phase one of them out when they make the change? Or maybe leave them as slightly differentiated products like the jumble of different laptops they already have.
> Is Apple going to spend hundreds of millions a year just to invest into Mac Desktop / high performance CPU, for [Pro]
This seems like a number you just made up. Here is a comparison of last year's A12 ($50?) and a 2017 Xeon 8176 ($5K?):
https://www.reddit.com/r/apple/comments/9midcx/apple_really_...
> If Apple want to lower its reliance on Intel ( After it has all of its modem and wireless patents sort out with Intel ), why not just use AMD to leverages the price or switch to AMD. AMD gets the PR win for Apple using it, win win for both companies.
Well they're fed up with Intel and there's the price gap but the primary reason is that the chip performance is rapidly converging so there is a massive opportunity to create a unified platform. Further they've been able to create a year plus performance gap between themselves and the competition in mobile on a commodity platform and with third party fab - if they do the same thing in desktop the Mac platform could really take off and they could go after the console market too.
You will have R&D just for the high TDP CPU, you don't just magically scale up your Phone CPU and expect it to work in a Server / Workstation. And that CPU has comparatively small volume. I.e The Unit Economics does't work.
The only Unit Economics would work better is to follow a similar strategy as AMD, where you have a single die and they are replicated across the 45W to 220W product line. This is a small sub 100mm2 Die Size with 4M yearly unit. But that is excluding the complexity of I/O where EPYC had a 400mm2 I/O die.
https://news.ycombinator.com/item?id=20292762
1. MacOS and iPad are similar, but distinct user experiences. Its more than hardware (one with keyboard, one without), its about those differences in experience. Apple is nothing if not patient about introducing change to computing paradigms and experiences, so it's fine to co-exist for a while. Switching to ARM gives them better margins, better control over price, better control over physical chassis constraints, better control over features offered, access to a better chip team than Intel's, and now TSMC and/or Samsung's better EUV processes. E.g. features-wise, Intel still isn't shipping LPDDR4 chips, something the 4 year old iPhone 6S had.
2. Basically, x86 becomes a co-processor, just like how discrete GPUs are handled. This avoids having to compete with tiny sliver of market that wants Xeons.
3. AMD is a lateral move, with exactly the same lack of control over core technologies problem. Also AMD is historically not as reliable a supplier for volumes that Apple has.
4. See #2 and my comment. Also, they needed to intro Mac Pro to satisfy / shore up existing Mac contingent before they abandoned entirely. This is a multi-year journey.
That's become my hunch too in the transition to ARM, with Apple producing a SoC that integrates an entry level x86, with usual 2 upgrade options. Eg the next product line would be:
$1599 -- Dual-Core 1.5ghz A14 + Dual-core 1.2ghz x86
$1899 -- Quad-Core 1.9ghz A14 + Quad-Core 2.4ghz x86
$2199 -- Quad-Core 2.5ghz A14 + Quad-Core 2.7ghz x86
I think they will take a different approach. Put a decent keyboard on a future iPad Pro. Make iOS more like macOS. And then they'll eventually kill macOS.
I think this is news for the sake of news. It’s just head hunting
"At ARM, Filippo was a lead engineer behind chip designs...
...Filippo was also a key designer at chipmakers Advanced Micro Devices and Intel Corp."
And his LinkedIn resume has much more detail - pretty impressive guy.
https://www.linkedin.com/in/mike-filippo-ba89b9/
I don't mind what CPU my Mac runs on, but I am worried about how long I'll be able to play older games, run the occasional Windows/Linux software, and dabble in OS hacking or low-level tinkering to add custom features, on the same machine.
The seemingly gradual lockdown of macOS – mandatory "notarization", moving system files to a read-only volume, and disallowing kernel extensions in the future* – has generated some concern where before I used to just trust Apple to know what's best for everyone.
I welcome the extra security as long as we can manually bypass it if we really want to, but I warily wonder if the move to ARM Macs will come with a macOS that is almost as locked-down or "sanitized" as iOS.
* As mentioned during this WWDC's Platforms State of the Union.
I am interested in battery efficiency, raw cpu and graphics performance and do not care to do low level tinkering on my Mac.
I do expect it to be much more open to tinkering than iOS, but I also welcome the litany of security measures introduced so far and caution when it comes to executing wild code that affects my privacy.
I realize this puts me further in with trusting Apple to make good compromise decisions on what is possible and the hoops they create for developers on Macos, but I trust they will mostly make the right call for me.
It’s certainly been better than when I’ve had to deal with windows over the past decade.
You may not, but many do. Those many may actually be a small minority, but it would really suck for those folks.
At the end of the day, sometimes I need to run random x86/64 executables and there isn't any way around that. I could deal with a performant virtual machine.
USB to ethernet dongle.
Little Snitch.
Karabiner.
Hammerspoon.
NTFS read/write driver.
I really doubt they will all remain working but the dongle is hardware.
iOS is system build mostly for content consumption and designed for non-technical users. As such it has to be protected from both external threats (malware etc) and users themselves (social engineering, phishing protection).
macOS is for me my workbench for content creation and I want it to protected from external threats but I do not want it to be protected from me. Even having to go into System Preferences and typing in my password to run unsigned apps since 10.12 is driving me crazy.
When is comes to privacy, today everything is web app anyway. And to be honest I would feel my privacy would be much more secure if I could run latest version of uBlock Origin in Safari, but I cannot.
For native apps I want to decide if I trust them or not. The only new thing I would love to see in macOS is easy blocking of internet access for particular apps.
Does right clicking and hitting "Open" not work anymore?
Personally, after 13 years of Macs any computer I'm buying in the near future are going to be Linux based because of the current trajectories Apple have decided to take.
Just insight from a different community I guess.
None of that is a compelling enough reason to switch, when the OS is the primary reason I jumped ship to Macs in the first place.
It's not just about being able to run this or that app, but the overall comfort of my everyday work environment, while still giving me the room to occasionally step out of my comfort zone on lazy afternoons.
As long as macOS retains the ability to run emulators, I think I'll be fine with its growing number of security-based restrictions.
However, whenever I have occasionally peeked back in on the state of Windows (the last time being a year ago, to run some games), it still had many of the same annoyances, frustrations and archaic encumbrances that made me wish for a better world and try out Macs around 10 years ago, and I still don't agree with the overall philosophy of Microsoft (as I perceive it.)
Apple/macOS remains the "lesser evil", at least for me.
That being said OSX running on a higher specced ipad pro CPU could be really awesome but I don't think that is what will happen.
There are several code editors for iOS https://duckduckgo.com/?q=ios+code+editor and Apple has even published an own app for students to learn coding called Swift Playgrounds https://www.apple.com/swift/playgrounds/ - it isn't a full-blown code editor, but it clearly allows you to write and run code.
And that is ignoring cloud/browser-based code editors. That execution model (write code local, run in the cloud) makes sense with mobile devices which have limited power supply. I personally don't want to spin up several docker containers on my iPhone ;)
But other people might? Especially if it not a phone but a 12.5 inch iPad that is supposed to be more powerful than my 5-year-old dev laptop (and has more RAM too).
> It is allowed to write code on iOS
Great, so you can pen&paper your code like in the 1960s. In the 21st century, writing code includes being able to run the compiler/interpreter on your terminal to debug as well.
http://omz-software.com/pythonista/
https://scriptable.app/
Notarization is not “mandatory”. You can still turn it off.
The seemingly gradual lockdown of macOS – mandatory "notarization", moving system files to a read-only volume,
So now it’s a bad thing that rogue apps can’t destroy your system.
and disallowing kernel extensions in the future
And they developed a way to do the same thing and improve system stability.
Metal seems much more compelling anyway, the Apple lock-in notwithstanding (even that is not so bad considering you can still target 4 rather popular device categories with Metal.)
In the mean time, people have already developed ways to run OpenGL code atop Metal. A lot of game developers have already started to move their code to either Metal or these OpenGL-compatible shims in order for compatibility with iOS, so a lot of the adoption has already begun.
In fact had Apple not chosen to go with OpenGL ES on iPhone back when they released it, OpenGL would be pretty meaningless nowadays.
The few people buying NeXTSTEP computers for graphics programming were doing it due to Renderman, not OpenGL.
For how much longer? I'm not asking facetiously, the trends across the entire industry are quite obvious at this point.
> So now it’s a bad thing that rogue apps can’t destroy your system.
It's a bad thing that modern "security measures" somehow consistently manage to be as restrictive towards user freedom as possible. Methods that would accomplish the same user protection without resulting in a walled garden or vendor control of the device are somehow never selected for.
I'm sure there are no ulterior motives at play here though. /s
This same panic has been going on since 10.6 with the introduction of the Mac App Store. How do you propose that you would be able to develop software on the Mac if you had to sign your executable every time that you recompiled it?
It's a bad thing that modern "security measures" somehow consistently manage to be as restrictive towards user freedom as possible.
So what would be the financial motive for Apple to force signing of apps and allow them to be outside of the App Store? What would be the financial motive of making system files readonly or introducing DriverKit to increase stability. Do you really want third party kext to be “free” to crash your entire system?
I think they would be crazy to do it and don't really expect them to anytime soon but they clearly could. The financial motive is exactly the same as the iOS App Store: get 30% of all app sales revenue and make the OS more secure.
Also, they don’t get 30% of all app sales. All of the biggest non game money makers either allow you to purchase subscriptions and content outside of the store or force you to.
And rightfully so! How is this not an obvious trend to you?! It isn't just Apple, it's cell phones and tablets with unlockable bootloaders, Windows S-Mode, Samsung Knox, Firefox extension signing that can't be disabled, and a great many other examples. It's the trend that's alarming, not the specific way macOS is configured right now.
> How do you propose that you would be able to develop software on the Mac if you had to sign your executable every time that you recompiled it?
By paying the Apple tax for a developer license and then just... signing your code every time you compile it? You already have to do this for Firefox extension development if you don't bother to run a dev or unbranded build. Alternatively, just run your (unsigned) compiled code in a VM.
> So what would be the financial motive ...
The financial motive is the glaringly obvious walled garden! It's the vendor's control over the device you purchased!
> Do you really want third party kext to be “free” to crash your entire system?
Obviously not; that is a bad faith interpretation of what I said previously. There are ways to ensure user security that don't remove control of the system from the end user. These options are consistently not chosen, by more or less all the major manufactures. I believe that the motives for such behavior are quite obvious.
You really think after selling computers for 43 years Apple is not going to allow people to compile programs without signing every time you compile?
How do you propose they are going to lock down scripting languages and programs built with .Net Cord and Java? Are they going to disallow any code on the Mac that’s built on top of a VM?
The financial motive is the glaringly obvious walled garden! It's the vendor's control over the device you purchased!
So are they now going to lock down outside vendors from creating whatever the new equivalent of kext are without paying a fee?
bad faith interpretation of what I said previously. There are ways to ensure user security that don't remove control of the system from the end user.
You mean by allowing advanced users of the Mac to turn off safeguards- exactly what they are doing now?
Btw, a lot of developers are saying that moving away from kernel extensions will make it easier to build Hackintoshes not harder.
While this is certainly technically possible, I think this presumption -- which I see a fair amount around HN -- is at the least somewhat dubious. There's an extremely crucial difference between the Mac and the iPhone/iPad that this argument downplays at its peril: the iOS ecosystem has never been open in this way; the Mac ecosystem has been open in this way for over three decades. Customers do not tend to react well to having things taken away from them.
What's the cost of not just individual users but whole companies moving off the Mac platform en masse? What's the cost of a press firestorm so intense it'll make the butterfly keyboard shitshow look like free passes to Disneyland? Are you sure so many users would just docilely acquiesce to "guess I'll have to re-buy all my software all over again, herp de derp?" Because for this plan to make sense, Apple needs to sell a whole, whole, whole lot of software to make up for every single person who decides this is the straw that breaks the camel out of the habit of buying $2500 laptops every three or four years.
The bottom line is that I don't think attempting to lock the Mac down to the point the iPad is locked down makes business sense. (I'm not convinced keeping the iPad locked down makes business sense in the long run, either. But that's a different post.)
A key difference between the Mac and iOS. https://developer.apple.com/videos/play/wwdc2019/701/
One cannot have security while allowing apps to do whatever they feel like.
That's why Nintendo not putting a browser on Switch
It's appalling an entire WWW browser would be necessary for connecting to certain Internet access points, but that's the current state of things.
In any case, someone has already achieved arbitrary code execution through it, but it was sandboxed anyway.
Also this is an orthogonal issue, the console wasn't designed to have security exploits to start with.
One cannot have a general purpose computer while preventing apps to do whatever they were designed to do.
I don't want random applications to access $HOME just because they feel like it.
If the application was designed for accessing $HOME given its purpose, then I as user, will gladly authorize it.
As developer, and someone that in the past dealt with games and mobile development like J2ME and Symbian, I don't see a big issue going through app certification processes.
Being able to do that isn't just a nice thing to have, it is a downright mandatory ability any computer must have.
You're more likely to get seriously scammed in a browser than by an actual malware/virus.
https://www.autotrader.com/car-news/new-general-motors-featu...
As consumer, app stores are more than proven.
I cannot parse this, what do you mean?
> As consumer, app stores are more than proven.
I do not have any problem with app stores as long as they are not tied to a locked down OS. See Steam or any Linux repository front-end as an example of app stores that do it right.
But yeah, it's still a choice and Apple is not one of them.
I rather have the inconvenience of using them, even if they don't prevent accidents.
Not being able to install any software you want on a device you own is not a small inconvenience cost, it is a great artificial limitation meant to take control away from the user and put the user at the mercy of the vendor who can then use it for other user hostile actions (e.g. forced obsolescence, a common tactic in the example of gaming consoles brought before).
And especially in this case, any "better" outcome is really small and short term (the user being unable to do much with their own device means they are also unable to install unwanted software) whereas the larger picture outcome is user hostile - a gradual loss of control and ownership to the goods you are paying for.
I rather have a store than a background application taking machine resources, to ensure that applications are safe to use and do not expose my computer contents to the world when connected.
Thankfully i'm not one. But that doesn't make me blind on such schemes.
Also that background application you mention, even though it isn't necessarily needed in all cases, it is still a better solution than a locked down system since it is under the user's control.
At this point?? Here's my blog post from nine years ago, almost to the day. http://drupal4hu.com/future/freedom
> Microsoft can [...] make it so that any new app needs to be sanctioned. Apple, obviously can easily follow or even do it before Microsoft.
If that's Apple's trajectory, why did they things like Hypervisor.framework (much more recent than 10.6's introduction of the App Store), which allows one to make unprivileged virtualization solutions, that can run any OS/application?
To me, it their motivation seems two-fold: (1) they want to carve out a niche for security and privacy. People are willing to spend a lot of money to avoid the data grab of Facebook, Google et al. And people are willing to spend money on a system that focuses on security. So, Apple have invested a lot in hardware security (T2) and software security (sandboxing, read-only system files, mandatory kext signing, user-space drivers).
And, yes (2) they probably also want to funnel more and more through the Mac App store for profit. The thing is, they can make macOS a walled garden system, while keeping the back door open for advanced users. My dad is protected by the Mac App store, application bundle signing, notarization, and sandboxing, he is not going to boot in recovery mode and run csrutil in the command-line. While I can in the use csrutil to lower protection a bit to be able to run DTrace. In other words, I don't believe that they want to or need to turn macOS in a complete walled garden: 90% of the users does not want to or cannot disable security measures, while at the same time keeping the csrutil around keeps the other 10% happy.
---
I think the more serious danger for macOS was negligence. With key execs primarily using iPads and glacial development of macOS, the most imminent danger seemed to be that macOS developed into nothing else but an SDK/IDE for iOS development. But after the last WWDC, I am mildly optimistic that they have woken up.
While it might not be mandatory for users, it is for software which is supposed run seamlessly on every Mac, isn't it?
One day, they might switch Mac to ARM. But I don't see that in the short term.
In theory it seems you could be able to convert "on the fly" from multiple high level instruction sets to a singl low level microcode.
Not sure it's a good idea tho.
https://en.wikipedia.org/wiki/Transmeta_Crusoe
[1] https://en.wikipedia.org/wiki/RiscPC
How it'd work - ARM SoC expands on what the T2 does today, except it now runs all system threads, any ARM native user space apps, and maybe specialty fixed function blocks that Apple throws on those chips (e.g. media encode). Meanwhile the Intel chip is a co-processor for any x86 specific user space apps, and it otherwise doesn't touch drivers or any system things.
The market would be segmented with ARM chips at the lower end (MacBooks), and ARM chips with Intel co-processors at the higher end (15" MacBook Pro, iMac, iMac Pro, Mac Pro). This is equivalent to how integrated v discrete GPUs are segmented today.
Over time the ARM chips get faster and faster as Intel inevitably blunders, and more and more code is rewritten as native ARM code, so that after several years the need for x86 is significantly reduced, maybe only existing as thunderbolt eCPU boxes and/or Mac Pro. And by around MacOS ~10.23 in 2026, x86 is sunsetted because remaining use cases are so minimal.
That's not really Apple's style, at least not under Steve Jobs ;). You just throw the old architecture under the bus, provide some emulation to make Microsoft and Adobe catch up, all developers have to adapt and build fat binaries or get left behind.
Apple can do this, since no one has a strong expectation of backwards compatibility anyway.
Of course, ARM might not be competitive enough yet for Mac Pros. So they'll probably start with the MacBook Air or 12", require every developer that submits to the Mac App store to build universal binaries, and have some partners (probably Microsoft) that will provide support on day 1. For a chunk of the MacBook Air audience the architecture will be irrelevant, since they do Office, browse the web, and send e-mails. So, if they get a laptop with significantly better battery life doing that, it will sell. Once the Air has prepared the software market, go up the product line after 1-2 years.
I like the Intel co-processor idea, but Intel CPUs are relatively expensive. So, they'd have to jack up prices, while going ARM directly would increase their margins at the same price points.
fwiw, the reason I think the co-processor idea is likely is that Apple has recently re-committed to the Mac and specifically some niche use cases therein (thus they can't fully ditch Intel), and that they're already shipping an A10 equivalent in Macs today (the T2) so not that hard to go a bit further into the water. Also, in single core perf its possible the ARM chips would exceed most Xeons they ship, which clock lower in favor of more cores.
Agree if Apple had its way and could pick its markets perfectly, they'd have slowly shed niche use cases in favor of the highest margin markets (which is mainstream not pro), and thus at the appropriate moment dumped Intel and gone all-in on ARM. However, they're seeing the traditional pc market only moves so fast, there's many many pro niches they didn't really consider enough, and those niche Mac users really do have a lot of indirect value to Apple's brand. Emulation wouldn't cut it for those users - it'd only work if Apple saw ditching those markets as an acceptable tradeoff.
Intel CPUs are expensive but so are GPUs, and they'd only be bundled in the higher end machines - nothing that's below $2500-3000.
Well, that's my hunch anyway.
Security is fine as long as the user is in control. The problem is that very often companies make decisions that take away control from the user with "security" as a "but think of the children" blanket excuse.
If they had no incentive for macOS to be locked down then they wouldn't have any incentive for iOS to be locked down either.
Also i never said that laptops will be made into appliances, i said that they'll be locked down like iOS. You can still do a lot of things on iOS but all of them need to things pre-approved by Apple and a lot of the things you cannot do on iOS is because of its form factor - something that can be addressed with the form factor of a laptop.
If anything i think you may have already fallen victim to the artificial separation that Apple has introduced between laptops and tablets: why doesn't it make sense for laptops to be limited whereas it makes perfect sense for tablets and phones to be limited? It doesn't. There is no reason why iOS has to be limited just like there is no reason for laptops (and desktops) to be limited, it is just that this is how phones and tablets were introduced to the mainstream audience and how the mainstream audience has come to accept and expect them.
Regarding the MacOS platform though: I don’t think they’ll get rid of the ability to add binaries to a user’s home directory much like it is now. It’s a development and productivity platform that doesn’t abstract its Unix underpinnings like iOS does.
But I'm not so much of a zealot to think that if they do do something underhanded like lock down MacOS to a completely unusable outside of Apple ways to not go to a different platform. Until then I will stick with them for sure.
Also Android is not wild-west freedom, the entire idea behind "side-loading" (which is not available everywhere) is a sign to that - or even worse, the inability to gain root access to your own device. If you want an example of such freedom, it would be something like what you see on desktop systems such as Windows or Linux (though Windows 8 and later did piss in the pool with their Metro/UWP efforts).
macOS can become a development and productivity platform while at the same time being locked down. For example you'd be able to install Xcode and even a (user-only) Unix command line environment that will autosign any executable you create for use only on your own machine and a few preapproved others. AFAIK this is how it is already done with iOS devices, except Xcode doesn't run there (but that is mainly an issue with API availability, not it requiring anything that couldn't be provided on a locked down macOS). Since this would require an annual developers' fee, it'd make any source-based releases impractical outside of developers and even that only for as long as you pay that fee (again see iOS: it isn't like you cannot download some iOS program in source code form and install it on your own device, but to do that you need to pay Apple for the privilege).
So if you want to write code that uses SIMD instructions depending on whether they are available, you need to use Apple math libraries, which is super messed up.