Settles on a proposition that the iPad will consume and replace the Mac.
I don't agree with that position; I think the form factor of the Mac and the capabilities of MacOS are going to continue to be relevant, even in a world where a fully featured Xcode can be run from an iPad Pro.
It seems more realistic to me that apples' efforts to get catalyst to a point of usability is about enabling software to make a seamless transition to the arm architecture.
Honestly it's hard to imagine. Laptops are an incredibly important form factor.
I actually suspect the move to/inclusion of ARM in the macOS lines of product is part of the motivation behind dumping support for 32-bit apps in Catalina. By preemtively removing support for a large amount of legacy software, which will likely never be recompiled for ARM, they avoid the situation where their new machines appear much less capable than the old ones.
Exactly. By “clearing the deck” of all APIs (and software using them) that won’t make it to ARM, they can position it as the same OS and apps, just running on a more-efficient chip. And for 90+% of Catalina-compatible apps, a recompile is all that’s needed. (And/or they’ll have an emulator)
There was a push to make all laptops have a touchscreen a few years back, but this seems to have fizzled out, and I've seldom seen anyone use them (deliberately anyway).
They're already on the path to do that by making the Mac unusable. I tried getting Little Snitch installed on Catalina and it has to contact apple before it can be enabled.
This whole "ask apple's permission" thing really annoys me.
> I tried getting Little Snitch installed on Catalina and it has to contact apple before it can be enabled
(A) It doesn't contact Apple for permission; it's asking you, the user, for permission to access certain aspects to prevent malicious apps from encroaching on user privacy and security — in no part of the transaction is it phoning home.
Locking applications out of unfettered access to the system is nothing new nor particularly Apple-specific.
Please do not spread unnecessary FUD.
> This whole "ask apple's permission" thing really annoys me
When you install little snitch, you have to go to the security and privacy pane, which should have a dialog to allow obdev.at to install a kernel extension.
However, if you're not connected to the internet, that dialog doesn't seem to show up.
Until now the speculation has been that Apple might port OSX to ARM. I think with the move to deep, rich keyboard, trackpad and mouse support in iPadOS that basically becomes an uninteresting question. It looks like iPadOS is on a trajectory to become a very capable laptop, and maybe later desktop OS. Looking at the iPad and magic keyboard in profile reminds me a bit of the ‘lamp shade’ Macs back in the day.
The iPad tablet form factor will eventually hit limits in screen size. Is a 15”, 24” or even 27” tablet really feasible? If eventually the iPad becomes highly usable in docked mode with a keyboard, why not bring it out in a full clamshell or even desktop form factor?
Looking at it this way ok, maybe the Mac will move to ARM, or maybe it won’t. The thing is in the long run it might not matter.
"haven't worked for any company where they were still actively spending money acquiring desktops."
It's still very common for companies to supply desktops to lower paid desk workers that don't work from home. The total cost is lower, fewer failures, etc.
After Coronavirus, I can see even that dwindling further. Laptops are cheap enough that TCO-wise its better to have a small, portable all-in-one solution than a desktop.
> Apple just needs to have a docking station on their offerings.
But they do, it's called Thunderbolt, and they were the first manufacturer to really buy in hard.
For any laptop that can run within the 100 watt limit of USB-C charging there's little to nothing a proprietary docking solution offers compared to TB3, and even those that require more power can still use a TB dock just with one additional cable to plug in.
Yes there are a lot of crappy Thunderbolt and/or USB-C docks out there, but it's not like proprietary docks were ever bug-free either. At least now you have a choice of dozens of vendors rather than being stuck with whatever the laptop OEM wants to offer, and changing model lines doesn't mean buying a whole new set of docks.
> An answer to the now age-old ARM-ed Mac question now emerges: With the emphasis on the iPad Pro as a real computer, there’s no reason for Apple to move the Mac off of trusty if perhaps less glamorous Intel processors. Does this mean that iPad Pro sales will cannibalize the Mac? We’ve long known the answer that one. It doesn’t really matter to the company as long as customers enjoy their Apple devices.
I don’t think Gassée is arguing that the iPad definitively will replace the Mac, or that this is Apple's intention. I think he’s arguing that Apple is positioning the iPad in a way that it could, and that this positioning lets the Mac off the hook for an architecture transition.
His (roundabout) answer is to point to the new iPad Pro and cursor support, i.e., Apple is moving everybody to the iPad so it doesn't matter what the Mac does.
Of course, as always, whether this is "an answer" or not depends on whether you happen to believe in this particular branch of Apple Kremlinology.
I love this term. What a fantastic way to look at this story and take a step back so that we recognize what we're doing here. Maybe Apple, like the Soviet Union, doesn't have it all figured out? Maybe they're just trying stuff to see what sticks?
I think, deep down, there are a bunch of people at Apple that know they'd have to pry the Terminal, vim/emacs, and command line tools out of macOS developers' cold, dead hands before they'd ever switch to iOS full-time.
This is actually an interesting question for any company that makes operating systems.
* I'm sure Microsoft's Windows developers all work on Windows.
* I assume Apple uses Macs for all development right now.
* If memory serves, Google uses a lot of Macs themselves, but did at least make an effort to make it possible to do development on Chromebooks.
* Oracle... it's not clear to me that Oracle actually has anybody working on Solaris, but if they do then they have to use Solaris to work on Solaris unless they've managed to completely overhaul the build system. For everything else, OEL should at least theoretically be completely adequate.
* I'd be interested to know what IBM uses internally; AIX was a workstation OS but I have no idea if they've maintained that capability, and they own RH now so that's an option if they wanted to stay "in-house"
* I don't have any specific knowledge about it, but Red Hat absolutely could use Fedora and/or RHEL for most everything.
* Canonical is almost certainly running Ubuntu everywhere.
Maybe they don't need to. A terminal app with a busybox-like set of tools within the sandbox would make iOS/iPadOS a lot nicer to us nerds. We already have Files.app. A terminal can't be that far.
iSH is reasonably popular and is ripe for Apple to either Sherlock them or bless them by allowing them on the app store https://ish.app
edit: "but iSH is Linux, surely Apple would do Darwin!" you say. By looking at how poorly they're maintaining the command line experience on the Mac (deprecating their bundled Python, Ruby, not updating anything GNU GPLv3 etc), it's easy to imagine them happy to outsource that drudgery to the Linux community, like Microsoft is with WSL. Add to that all the web developers telling them they want a deploy-ready environment...
Terminus is available now and works well enough. It’s not a shell into local iOS, but that’s fine for me. and standard external USB keyboards work fine with a $10 Lightning adapter.
A busybox-like set of tools would not be very useful without a package manager and the ability to install arbitrary software like compilers, editors, and the like. Just out of curiosity, I counted how many formulae I have installed with homebrew on my Mac:
$ brew list | wc -w
244
That's probably not that many compared to some people out there.
That's the case right this minute, but thanks to Apple's famous secrecy, all that could change five minutes from now. Much in the way people say "I'm certain there are ARM-based Macs running inside Apple", I'd be pretty certain that there is at least one iPad running XCode inside of Apple.
Ok fair enough. My issue is, whenever a project grows beyond trivial scope, it will usually involve at least some scripting, and likely some tooling, like a process which watches the source files and performs some action when they're updated.
It's very limiting not to have a shell, and arbitrary execution environment, and the wealth of tools which have been created over the years for the *nix environment.
An IDE is never going to be as flexible as a unix environment. It can deliver some of that, but it's likely you will run into limitations sooner or later.
Xcode will probably run on iPad soon. I still won't care. As a developer, I need two kinds of freedom: The freedom to choose or build my own language and IDE, and the freedom of my customers to install my software without paying a tax to or needing approval from $FAANG.
Apple has made it quite clear that neither of those is ever going to happen on IOS.
I am not convinced although I will admit this is the first iPad I am considering buying in a long time.
Unless an iPad can compile code at speeds equivalent of C / C++ I cannot see it happening. I could see some programming on the new iPad though. Would be nice if Apple opened it up for trivial scripting though.
Does Swift Playgrounds allow general App development? No one doubts that you could do software development on an iPad Pro, just that Apple so far has disallowed any real software development on that platform.
> In the grand scheme of things, do you realize how niche software development is?
During the Mac Pro redesign, Apple said developers are by far their largest group of "pro" users. Then they built a $6000+ workstation (with a $6000+ display) that appears to be primarily aimed at video editors. I don't see why adding some real programmability to iOS would be too niche.
I think the more likely answer is that Apple is suffering from tunnel vision in their conception of what "software development" means.
There largest group of “pro users” but not their largest group of users. But realistically, does anything about the Mac Pro seemed like it was designed for development?
As a primary purpose? Hard to be certain, but I'd say no. The base configuration is in some ways ridiculously overpowered for the typical developer, while missing some easy wins.
It looks like a great machine for developing software (if you can afford it) but all of its strengths as a development machine look like simply side effects of video editing machines needing lots of power. There is no design or feature on it that I can point to and say "this was done for developers". There are many that were obviously done for video -- like a $2000 FPGA option that's only good for 2 intermediate video codecs.
I have no inside information here, but I suspect that Apple sees the MacBook Pro as the Mac aimed at developers, not the Mac Pro. MBPs are more common in Silicon Valley than roadside poppies. So while the Mac Pro was the first stop on their Hardware Apology Tour,† the 16" MBP is the "please stay with us, developers" machine: fixing the keyboard, increasing the performance substantially, and not raising the price.
†Not that they'll actually ever say "I'm sorry" out loud, but it's pretty clear they're rolling back some of the late stage Ive-isms. Yes, I know they kept the Touch Bar and didn't add ports, but I think they're all fully committed to USB-C as the Way Of The Future™ and, uh, somebody high up loves that damn Touch Bar.
If the argument is that the iPad will replace a Mac then you cant just do that and provide a mediocre development experience. You will need C / C++ and other languages to use third party libraries for apps.
Without a reasonably performant platform to develop on the iPad will kill itself.
If anything, in the future I see iOS (or iPadOS) getting more and more 'MacOS-ified' and not the other way round. As the HW inside iPads get more and more powerful, I could imagine Apple eventually porting MacOS to iPads (and therefore to ARM); not to replace the Intel-based Macs with ARM-powered ones, but to empower iPad users with a much more productive OS. Sure, iPad users wouldn't be able to run x86 binaries, but with Apple incentivizing developers to build x86+ARM fat binaries, the software library available for 'MacOS iPad' users would keep growing over time.
> I could imagine Apple eventually porting MacOS to iPads (and therefore to ARM)
There's not much to port. The underlying Darwin operating system is shared by all Apple products (AFAIK, excepting Airports for some weird reason). They would have to do a recompile and maybe make sure that nobody accidentally put architecture specific bugs into the finder or something stupid, but the grand difference between Apple's different operating systems is which graphical interface they put on and some amount of user space tooling. And honestly, I would be absolutely shocked if Apple doesn't have internal builds of the desktop-oriented "Mac OS" for ARM, probably as part of the usual CI pipeline.
What I see as more likely is that Apple is hedging it’s bets. On the iPhone / iPad side, they continue to develop better and better processors. One day they _may_ be sufficiently better than Intel that Apple could pull a “Rosetta” a second time on the Mac, translating apps from x86 to ARM at the software level.
But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing.
So in the meantime, it makes sense to push the iPad toward being a stronger and stronger computing platform with things like the recently added trackpad, better multi tasking, etc. They’ve got a way to go, but given a few more years of iteration, who knows how many more of the “real computer” niches the iPad can fill.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition, and Apple will probably shift it farther upmarket as the iPad cannibalizes every use case that doesn’t need x86. And if the processors do get that much better, then ARM comes to the Mac.
Either way, Apple is in a good place to leverage the iPad as their vision of what the next generation of the personal computer looks like.
But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing.
Apple has already done this. The 68K to PPC transition wasn't nearly as quick as the PPC to x86 transition. They released new 68K Macs after releasing PPC Macs. The apps were "fat binary".
When I bought my first PPC Mac, all of my apps were on an external SCSI drive. I attached the drive to PPC Mac and it ran native software.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition,
Again it doesn't have to. I had a first generation PPC Mac 6100/60 that ran emulated code slightly slower than my accelerated 68030-40Mhz LCII. My 68K Mac was about half the speed of the high end 68040-40Mhz Macs. It couldn't emulate programs that used the 68040's FPU at all. There were third party hacks that you could run like SoftwareFPU (a 68K program nonetheless) that could emulate an FPU.
The high end programs are always the first to be ported. The other apps are "good enough" and depending on how much time an emulated app spends running native operating system code, it won't be all emulated.
> Apple could pull a “Rosetta” a second time on the Mac
You mean a third time though! The mac went through three architecture transition, and each came with an emulator to keep compatibility for a while. The first one was when they went from Motorolla 68000 to PPC, and they built the Mac 68k Emulator[0] to keep software going.
I also think they could pull it off again. Microsoft has shown us that it's possible to run a lot of x86 software on ARM64 with little noticeable impact[1]. It would, however, require immense engineering effort.
If you don't limit the discussion to "Macintosh", Apple had a 4th architecture (and a 3rd 'transition'): 6502. There were third-party software emulators for 6502-on-68K, but Apple only provided a hardware one.
> One day they _may_ be sufficiently better than Intel that Apple could pull a “Rosetta” a second time on the Mac, translating apps from x86 to ARM at the software level.
Emulating x86 on ARM is very hard because x86 has a strong memory model while ARM has a weak one. This either makes emulation very slow or will break lots of multithreaded applications.
The other emulation direction (ARM on x86) works much better.
That's true for now. But due to RISC-V's openness, ARM has recently started allowing licensees to add extra features to the architecture.
If emulation were taken seriously, Apple could add extra features to their ARM-ISA processors in support of x86 emulation, including x86 compatible implicit memory barriers.
QEMU exists and so do others, and has for many years, so I think x86 software emulation might turn out to be fair game.
In fact, out of Intel and ARM, ARM is the only one I know that tried to shut down software emulation...
(ARM blocked parts of QEMU from being published for a while, citing "you must have read the manual to implement this therefore you are bound by the terms of the manual". They also had an open source design removed from OpenCores.)
It would not be completely silly to modify QEMU with x86 guest and modified-ARM target (for implicit-barrier mode), and then just use QEMU for the emulation.
As long as implicit-barrier mode was generic enough I think Intel would have an interesting time claiming it infringed some patent of theirs. Making it efficient would remain Apple's problem but they are good at that. (Or were until the CPU designers left to start Nuvia.)
If Intel won that, implicit-barrier would have to be explicit-barrier which is just normal ARM, but there is no fundamental reason why that cannot be fast, if the processor is designed to expect a lot of barriers and optimised accordingly. Especially if a dense instruction encoding is created for it.
(Everything I just said applies to RISC-V as well as ARM, should Apple decide to change course again.)
Have they? I've never heard anything about that. Microsoft has been shipping x86 emulation in ARM64 machines for the past few years. (And does original Xbox back-compat emulate x86 also? Or was it statically recompiled to PPC somehow?)
I think it's a safe guess that such an emulation would be made correctness-first.
But most apps are not very parallelized, only computationally heavy ones are. Those are of course going to suffer from emulation anyway. As a performance lower bound we can imagine that it would emulate a single-core x86 so the memory model differences wouldn't come into play.
Microsoft already has x86 emulation working in Windows for ARM, anyone know implementation details of that, or even publications?
Surprised to see no mention of emulation. Apple has pulled off emulation-based transitions twice before - from 680x0 to PowerPC and from PowerPC to x86 - and nobody else has tried. Why wouldn't we expect Apple to try again?
Seems like a lot of work would need to go into moving existing macOS apps to touch friendly interfaces if that were the case. I’m using a Bluetooth mouse and the cursor is finger sized.
I think the idea is that ideally apps should be recompiled for ARM, but for those apps that aren’t you will still want to have a way to run those x86 apps on an ARM Mac.
(As I preface, I have zero qualification to speak about microprocessor and instruction set design)
Microsoft currently has 32-bit-only x86 emulation on the ARM-powered Surface X and the reviews aren't positive. I don't know if it's actual emulation, trap/HLE emulation, dynamic translation, or something else - but Microsoft takes backwards compatibility far more seriously than Apple does, and if that's the best Microsoft can do, what hope does Apple have?
While x86 and ARM's ISAs are fundamentally different (y'know: CISC vs RISC) but given that x86 CPUs today are generally implemented using RISC microcode - could x86 be emulated by instead translating x86's RISC microcode to ARM?
I realize another alternative exists: Apple could buy-up cheap, low-power Intel x86/x64 chips (like an i3 or something) as a co-processor to the primary ARM chip and only use the i3 if ARM-based emulation is too slow for a given process?
I don't have any links or sources, but I remember reading somewhere that Intel has a ton of patents for x86 stuff, making emulation a legally risky manoeuver.
The author, Jean-Louis Gassée, has some good points. It seems less risky to let the iPad pro evolve gradually into a fully fledged Mac replacement, than switching from intel to ARM based processors. Many years ago, the same Jean-Louis Gassée, wrote that all operating systems eventually gets cancer and dies. Maybe it is time for OSX to slowly die and be replaced by the much more light weight iOS?
"ARM-Ed" sounds like a special ARM architecture, while ARM-ed and ARMed elicit the author's intended meaning to me. It's pretty clear as to why the author didn't capitalize "ed" in their own title.
I Believe This is HN's Auto-Capitalisation of Titles.
It really annoys me when submitting; it does it only if there's a certain number of capitals in the submission, so 'ARM' probbaly triggered it. (It's now 'Arm' anyway, so it needn't have.) It does accept a more sensible case on re-submission if the submitter edits it quickly enough.
Nobody really knows what Apple is up to. Their processor design/manufacturing seems top tier. Until you can develop an iPad Pro app on an iPad Pro, it seems like a toy. (And I say this as someone who uses an iPad Pro as their primary mobile device. I don't own a laptop.)
To me it seems like another case of big-company-itis. Someone on the processor design team wants a promotion. Someone on the Macbook Air team wants a promotion. Working together is not the easiest path to that promotion, so the products remain separate. That is the reality of big companies and why startups get so much done. Nobody on the MacOS team is going to say "we should delete this thing and start working on XCode for the iPad instead", and so... as end-users we wonder wtf they're up to.
I'm extremely skeptical that the decision of on which platforms Xcode runs would be left in the hands of anyone below the executive level.
Obviously engineers play a role in evaluating the practicality of running it on an iPad, but that's such an incredibly strategic decision for Apple it's hard to imagine it's purely a question of Mac engineers not feeling like doing it.
> Working together is not the easiest path to that promotion, so the products remain separate
OTOH, another case of big-company-itis is over-segmenting your products and not allowing them to grow organically our of fear of cannibalizing your higher profit margin products.
Apple never letting the iPad get full keyboard and cursor support and saying "that's a Mac thing" leaves them open for disruption from Microsoft instead.
Xcode is likely planned for iPad, but it's a massive ecosystem (not just one app, don't forget there's Instruments, the Simulator, compiler build step scripts, etc etc) and will take a LONG time to port
Apple never letting the iPad get full keyboard and cursor support and saying "that's a Mac thing" leaves them open for disruption from Microsoft instead
Full keyboard and mouse support is in iOS
13.4.
The Surface is just another Windows computer with all the baggage that entails - x86 processors with horrible battery efficiency, an operating system that requires more RAM and storage, an operating system that still has parts that aren’t touch friendly and plenty of apps that still have a UI that doesn’t work well with touch.
Sorry, that was the point I was trying to make. Apple isn't afraid to cannibalize their own product lines by improving their "lesser" product. Rather than being a sign of "big-company-itis", it's a sign of being agile.
> The Surface is just another Windows computer with all the baggage that entails
Microsoft has a history of evolving their products until they are a success, I wouldn't count anything out on it's current iteration.
There's not just the Surface either, the Chromebook could have a future as software moves more and more onto the web and people don't really leave their browsers.
Microsoft has been trying to make a good touch screen/desktop OS hybrid since Windows 8. The Surface line has been around since 2012.
The entire idea of the Surface is fundamentally flawed because of three factors - it’s dependence on backwards compatibility with Windows and using x86 processors.
The Chromebook is already a success in education, but it has the opposite problem than the Surface. Google has no clue in how to create an ecosystem. Android on tablets have been a non starter and Chromebooks are still nowhere as capable as iPads.
Android succeeded because Apple refuses to compete on price and everyone needs an phone. A tablet is a luxury product and Apple competes pretty well on price. The $329 iPad is a very good device with a better ecosystem.
I dunno.. why is jlg blogging about Apple so much... he ran Beos, but that stalled and then went belly up.
Is he looking for a position at Apple? I hope not.
As for the cpu side.. Apple switched before. Also, the tooling is way more up to date and code is more high level these days than before.
Intel as a company isn’t performing, so it’s been AMD and their own CPUs.. they pulled it off before, and I think it will depend on tooling, and app compatibility/performance when emulating. Although I’m not sure if that would require a license
It's not rare to leave a company but still be interested in that company's projects. And when you're a tech blogger, it's hard to not write about a trillion USD tech company. I don't think speculating about his motives is necessary.
But he’s not a tech blogger.. He was silent for over 15 years about any tech news. Apple was also interesting when Steve was still alive. I dunno.. I get salty when I see these sorts of posts. Especially when there’s absolutely no new insights in them.
I have had student try to use ipads in class for simple things like note taking and things. It doesn't seem like a great experience. They don't seem to know how to switch between apps very well. Certain things like working on a collaborative google doc requires (or at least really encourages) them to download the app which means they have to wait for it to download and install while group members are already working on it.
On mobile, some sites refuse to show anything other than their "Go ahead, download our app!" page. In many cases, switching to desktop view doesn't work.
They don't seem to know how to switch between apps very well.
I'm temporarily between computers and using my iPad as my main computer. I also thought it would be a fun experiment so that I could learn the pros and cons of using an iPad as my main computing device first hand.
The new(-ish) mouse support is wonderful. Absolutely wonderful. I have a keyboard with a built-in trackpad, and when I'm using my iPad at a desk, it's far superior to constantly reaching up and pawing at the screen. Apple took a huge step forward here.
But there are still some pretty serious issues. The iPad is really aggressive about killing apps, to the point that I'd switch back and forth between apps (using Cmd+Tab on the keyboard) and it would frequently restart the apps from scratch. Even when switching between just two apps. And a lot of apps don't fully restore where you were at when the app was killed.
This issue alone is bad enough that, long-term, there's no way I could use my iPad as a laptop replacement.
The other issue is that I'm a software developer, and the software development story on the iPad (not for the iPad) is quite sad. There's absolutely no support for the two languages I use most frequently (Java and C). I can't even develop a simple web page (HTML/CSS/JS) on the iPad itself. There's no way to save and view local web pages.
Based on Apple's history, I think they'll be stubborn and thus really, really slow to add the features I want (though I think they'll add them eventually).
Call me crazy but my bet is that Apple will eventually do an iPadOS to macOS transition, kind of like they did with iOS to iPadOS in 2019. The existing macOS would be scrapped for the iPadOS fork of macOS. This would simplify their operating systems into one “Apple OS” where individual features/layouts can be configured based on the host device. MacOS would still look like Mac UI and iPadOS would still look like iPad UI. This would make easy for developers to make a single app for all of Apple platforms and would allow Apple to release more uniform OS updates. As for the x86 to ARM transition, I’ll bet they make developers rewrite their apps for this new platform, kind of how they dumped support for 32-bit apps in Catalina. If it’s a Catalyst app, then it will automatically run on ARM and x86. Others will be left in the dust.
Apple has consistently been dumming down their products[0] for the past few years (decades?), in the name of ostensible usability and looks. If they continue along this trend, given that iPadOS is generally more dummed down than macOS, the former will eventually replace the latter.
As for having a single appleOS, we're talking about the company that owns (1) watchOS, (2) iOS, (3) iPadOS, (4) macOS, and (5) tvOS - I believe that's more than Microsoft and Google combined.
[0] They're slowly making everything more touchpad-centred and graphics-oriented, for example.
I find the notion of ARM-based Macs dubious and I think JLG is on the mark in seeing iPad being positioned to replace low-end PC’s.
What did Apple gain from switching from PPC to Intel in the first place? They gained faster processors (their market share was insufficient to keep performance parity) and the ability to virtualize or even dual-boot Windows on Mac hardware. I don’t see these factors changing; iPhones and iPads don’t have the performance properties of laptops and desktops, meaning even Apple’s internally-developed ARM architecture is going to treat Macs as as much of an afterthought as Motorola and IBM did back in the day. Meanwhile, even if Windows compatibility is less relevant, the ability to virtualize Linux distros on Macs has become more relevant.
If I’m a software developer and I want to run my code on a x86-based Linux server somewhere, I’ll often want my development environment to be capable of reproducing that same environment, and tools like Vagrant and Docker accomplish this on Macs using virtualization. Without a shared CPU architecture, these tools will either stop working entirely or rely upon emulation, which would hinder performance and potentially introduce inconsistent behavior compared to the real hardware. Now, it’s true that iOS development relies on the Mac performing ARM emulation. But there’s already a working solution for this, and you can still use actual iOS hardware for testing. If I had to connect my Mac to an x86-based Linux box for testing and development, why wouldn’t I just use the Linux box? And the Linux box is a server that I can either Remote Desktop or SSH into, why would I need a Mac to be able to do that? Maybe I’m biased because I already think Macs aren’t a very good development environment, but I don’t really see switching CPU architectures as a move that makes them any better. All bets are off if ARM servers actually take off, though.
Just FYI, there are ARM versions of both Linux and Windows these days. There are also high end ARM server CPUs, [1] and Amazon even offers EC2 instances backed by a custom ARM CPU. [2] (While we're at it Linux also supports POWER9. [3])
I’m aware that Linux supports ARM (it also supports PowerPC) but if I’m not running my services on an ARM server, that doesn’t help me. Hence the last sentence of my post.
Honestly I don’t think they’re very good for development, or at least the type of development I’ve done. For iOS development they basically lock you in, and for frontend web stuff it’s probably fine if the convenience of testing against iOS or desktop Safari combined with having a Unix environment outweighs the value of convenient testing against MS browsers or the advantages I discuss below.
But the more you live in the terminal, the more of a mess it becomes compared to Linux. All the built in utilities are either very old or feature-impoverished BSD variants. Making it usable at all requires Homebrew, which manages to get broken by every major OS update. The default file system is case insensitive, which probably improves usability for mundanes but can result in some utterly broken Git workflows. And the more effort you invest into automating your workflow, the more time and effort you have to expend on the relatively useless and non-transferrable skill of macOS system administration. So I switched to Linux. Tiling window managers are nice, too.
Like the girl in the taco shell commercial said "Why not both?" Use both an AMD and Intel chips in new Macs. Use the ARM chip as a co-processor to run iOS apps on the Mac. This would make it easier to develop iOS apps on a Mac. Also it would foil the Hackintosh crowd because PC Clones don't have ARM chips in them.
The T2 boot security chip (which is ARM and has all of the standard iOS (renamed BridgeOS) security features) which is presently shipping in most/all Macs will be able to foil Hackintoshes just as soon as the installed base is sufficient that a new macOS release can demand an attestation from it to boot.
The Air and mini just got an update that brings the T2. I’m not sure if they are still shipping any non-T2 Macs, I don’t think they are.
You don’t need ARM to run iOS apps. All iOS apps started life running on x86. When running on the iOS simulator, iOS apps are compiled for x86 and linked to x86 versions of the iOS frameworks.
QEMU can run Intel MacOSX code and they can use it to emulate the old Intel Macs. This version of QEMU was designed to run older OSX Intel versions under new Intel versions to run legacy software.
CommodoreOS is based on Linux and in order to run old Amiga apps they use UAE for 68K and PowerPC Amigas. This seems to be that virtual machines and emulation can run the legacy software needed on the new ARM Macs.
For Apple using its own CPUs might mean less money spent for hardware, more control and greater user lock in.
But I don't see what's in for the users and software developers? Transition to another architecture might mean more money spent for end-users and more money and time spent for software developers.
Because people assume ARM would give us better performance and/or battery life. Hard to know if that would actually pan out in the laptop form factor (and if it would hold true forever), but at least right now iPads get better Geekbench scores than MacBook Air.
As for more money and time… I dunno, I make my living writing mostly iOS and Mac software and I can't recall the last time I did anything that was architecture specific. I'd imagine that applies to the vast majority of people working on ordinary application software on these platforms.
My take which is probably not what Apple want to hear is that they simply want to go the Microsoft Surface way.
I am personally a Linux/Thinkpad person, but all the persons I am working with who happen to have a Surface just love it.
Well executed, the concept is beautiful and practical. Apple is coming from the tablet side and Microsoft from the laptop side, they will converge at some point.
With the recent changes, Apple seems indeed to try to strengthen the iPad as a platform. Hardware-wise, the new iPad Pro 12.9" with the new keyboard stand seems to pretty much equal, if not superior to the also refreshed MacBook air. It even has two USB-C ports, though with less versatility. Ironically the main hardware missing in comparison is the headphone jack.
The ARM chip in the iPad should compare well with the MacBook, only the limited ram could be a cons.
But where iPadOS lacks significantly behind MacOS is the software. And this is based on the AppStore rules. Applications are limited in their capabilities which would be natural on a "computer". With "Files", applications can finally exchange data, but that still has complexities for the user and is less natural than it works on the Mac.
The biggest elephant in the room is the missing ability to do any real software development on the iPad. One might say that the software developers are the minority of the users and that is correct, but the software developers are the critical group for a platform which creates the software which all the other users can use. While the AppStore on the Mac has grown over time, just look how large the software universe outside the AppStore is, to get an idea, how important this is for the Mac platform. Not even counting the number of users, which wouldn't qualify as software developers, but are running a few scripts here and there for special task, either written by themselves or grabbed from the internet and modified to their needs. And yes, sometimes you really need a shell.
It will be interesting to watch what gets shown for iPadOS 14. If the iPad should go further into the Mac space, some significant changes need to be announced. The trackpad addition goes in the right direction, but does not address the points I mentioned above.
I don't think changing the microarchitecture would only require developers to swap compiler toolchains from x86 to ARM. The community is largely dependent on x86 architecture. Not a case for high level application developers, but some developers do serious optimization based on instruction set.
I think the author misses the obvious advantage of having ARM macs: it gives Apple even more vertical integration by moving the chip design in-house. They could in theory iterate faster on core design changes quicker than Intel could and would no longer have to pay what little markup they already to pay for Intel chips.
138 comments
[ 3.2 ms ] story [ 78.1 ms ] threadI don't agree with that position; I think the form factor of the Mac and the capabilities of MacOS are going to continue to be relevant, even in a world where a fully featured Xcode can be run from an iPad Pro.
It seems more realistic to me that apples' efforts to get catalyst to a point of usability is about enabling software to make a seamless transition to the arm architecture.
I actually suspect the move to/inclusion of ARM in the macOS lines of product is part of the motivation behind dumping support for 32-bit apps in Catalina. By preemtively removing support for a large amount of legacy software, which will likely never be recompiled for ARM, they avoid the situation where their new machines appear much less capable than the old ones.
There was a push to make all laptops have a touchscreen a few years back, but this seems to have fizzled out, and I've seldom seen anyone use them (deliberately anyway).
This whole "ask apple's permission" thing really annoys me.
(A) It doesn't contact Apple for permission; it's asking you, the user, for permission to access certain aspects to prevent malicious apps from encroaching on user privacy and security — in no part of the transaction is it phoning home.
Locking applications out of unfettered access to the system is nothing new nor particularly Apple-specific.
Please do not spread unnecessary FUD.
> This whole "ask apple's permission" thing really annoys me
(B) I will direct you to point A.
When you install little snitch, you have to go to the security and privacy pane, which should have a dialog to allow obdev.at to install a kernel extension.
However, if you're not connected to the internet, that dialog doesn't seem to show up.
The iPad tablet form factor will eventually hit limits in screen size. Is a 15”, 24” or even 27” tablet really feasible? If eventually the iPad becomes highly usable in docked mode with a keyboard, why not bring it out in a full clamshell or even desktop form factor?
Looking at it this way ok, maybe the Mac will move to ARM, or maybe it won’t. The thing is in the long run it might not matter.
The people that required desktop like compute power either got a laptop workstation like Thinkpad W series (now P), or some server connected via RDP.
Apple just needs to have a docking station on their offerings.
It's still very common for companies to supply desktops to lower paid desk workers that don't work from home. The total cost is lower, fewer failures, etc.
But they do, it's called Thunderbolt, and they were the first manufacturer to really buy in hard.
For any laptop that can run within the 100 watt limit of USB-C charging there's little to nothing a proprietary docking solution offers compared to TB3, and even those that require more power can still use a TB dock just with one additional cable to plug in.
Yes there are a lot of crappy Thunderbolt and/or USB-C docks out there, but it's not like proprietary docks were ever bug-free either. At least now you have a choice of dozens of vendors rather than being stuck with whatever the laptop OEM wants to offer, and changing model lines doesn't mean buying a whole new set of docks.
> An answer to the now age-old ARM-ed Mac question now emerges: With the emphasis on the iPad Pro as a real computer, there’s no reason for Apple to move the Mac off of trusty if perhaps less glamorous Intel processors. Does this mean that iPad Pro sales will cannibalize the Mac? We’ve long known the answer that one. It doesn’t really matter to the company as long as customers enjoy their Apple devices.
I don’t think Gassée is arguing that the iPad definitively will replace the Mac, or that this is Apple's intention. I think he’s arguing that Apple is positioning the iPad in a way that it could, and that this positioning lets the Mac off the hook for an architecture transition.
Of course, as always, whether this is "an answer" or not depends on whether you happen to believe in this particular branch of Apple Kremlinology.
I love this term. What a fantastic way to look at this story and take a step back so that we recognize what we're doing here. Maybe Apple, like the Soviet Union, doesn't have it all figured out? Maybe they're just trying stuff to see what sticks?
I think, deep down, there are a bunch of people at Apple that know they'd have to pry the Terminal, vim/emacs, and command line tools out of macOS developers' cold, dead hands before they'd ever switch to iOS full-time.
[1] https://www.itworld.com/article/2782495/apple-kremlinology.h...
* I'm sure Microsoft's Windows developers all work on Windows.
* I assume Apple uses Macs for all development right now.
* If memory serves, Google uses a lot of Macs themselves, but did at least make an effort to make it possible to do development on Chromebooks.
* Oracle... it's not clear to me that Oracle actually has anybody working on Solaris, but if they do then they have to use Solaris to work on Solaris unless they've managed to completely overhaul the build system. For everything else, OEL should at least theoretically be completely adequate.
* I'd be interested to know what IBM uses internally; AIX was a workstation OS but I have no idea if they've maintained that capability, and they own RH now so that's an option if they wanted to stay "in-house"
* I don't have any specific knowledge about it, but Red Hat absolutely could use Fedora and/or RHEL for most everything.
* Canonical is almost certainly running Ubuntu everywhere.
I wish I had a super-like for this answer.
edit: "but iSH is Linux, surely Apple would do Darwin!" you say. By looking at how poorly they're maintaining the command line experience on the Mac (deprecating their bundled Python, Ruby, not updating anything GNU GPLv3 etc), it's easy to imagine them happy to outsource that drudgery to the Linux community, like Microsoft is with WSL. Add to that all the web developers telling them they want a deploy-ready environment...
Hire the guy and do it natively in house.
https://termius.com/ios
And as someone on the inside, who knows the answer to this story (nope, not telling) it's interesting to read the conjecture :)
Those toy environments on Amiga, Mac OS, Windows, Symbian, J2ME, Android.
What are you talking about? You've got basically a complete unix shell available there.
It's very limiting not to have a shell, and arbitrary execution environment, and the wealth of tools which have been created over the years for the *nix environment.
The shell is a subset of what an IDE REPL is capable of, with OS API integration and structured data manipulation.
As for background processes, that is a basic feature of any modern IDE.
Apple has made it quite clear that neither of those is ever going to happen on IOS.
Now that it isn't happening, lets see how it goes.
It won't split the Mac lineup into ARM and x86, it will split it into iPad and Mac.
Describe pre-pointer iPads as Model T fords, and now we're entering the 1950's…
Unless an iPad can compile code at speeds equivalent of C / C++ I cannot see it happening. I could see some programming on the new iPad though. Would be nice if Apple opened it up for trivial scripting though.
Have you used Swift Playgrounds?
Besides that, why do you think that the current ARM chips aren't already faster than most x86 chips that people use?
Would be nice if Apple opened it up for trivial scripting though.
You can already do that using Shortcuts and various third party apps..
https://apps.apple.com/us/app/scriptable/id1405459188
During the Mac Pro redesign, Apple said developers are by far their largest group of "pro" users. Then they built a $6000+ workstation (with a $6000+ display) that appears to be primarily aimed at video editors. I don't see why adding some real programmability to iOS would be too niche.
I think the more likely answer is that Apple is suffering from tunnel vision in their conception of what "software development" means.
It looks like a great machine for developing software (if you can afford it) but all of its strengths as a development machine look like simply side effects of video editing machines needing lots of power. There is no design or feature on it that I can point to and say "this was done for developers". There are many that were obviously done for video -- like a $2000 FPGA option that's only good for 2 intermediate video codecs.
†Not that they'll actually ever say "I'm sorry" out loud, but it's pretty clear they're rolling back some of the late stage Ive-isms. Yes, I know they kept the Touch Bar and didn't add ports, but I think they're all fully committed to USB-C as the Way Of The Future™ and, uh, somebody high up loves that damn Touch Bar.
Without a reasonably performant platform to develop on the iPad will kill itself.
There's not much to port. The underlying Darwin operating system is shared by all Apple products (AFAIK, excepting Airports for some weird reason). They would have to do a recompile and maybe make sure that nobody accidentally put architecture specific bugs into the finder or something stupid, but the grand difference between Apple's different operating systems is which graphical interface they put on and some amount of user space tooling. And honestly, I would be absolutely shocked if Apple doesn't have internal builds of the desktop-oriented "Mac OS" for ARM, probably as part of the usual CI pipeline.
Non-touch iPods as well.
But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing.
So in the meantime, it makes sense to push the iPad toward being a stronger and stronger computing platform with things like the recently added trackpad, better multi tasking, etc. They’ve got a way to go, but given a few more years of iteration, who knows how many more of the “real computer” niches the iPad can fill.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition, and Apple will probably shift it farther upmarket as the iPad cannibalizes every use case that doesn’t need x86. And if the processors do get that much better, then ARM comes to the Mac.
Either way, Apple is in a good place to leverage the iPad as their vision of what the next generation of the personal computer looks like.
Apple has already done this. The 68K to PPC transition wasn't nearly as quick as the PPC to x86 transition. They released new 68K Macs after releasing PPC Macs. The apps were "fat binary".
When I bought my first PPC Mac, all of my apps were on an external SCSI drive. I attached the drive to PPC Mac and it ran native software.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition,
Again it doesn't have to. I had a first generation PPC Mac 6100/60 that ran emulated code slightly slower than my accelerated 68030-40Mhz LCII. My 68K Mac was about half the speed of the high end 68040-40Mhz Macs. It couldn't emulate programs that used the 68040's FPU at all. There were third party hacks that you could run like SoftwareFPU (a 68K program nonetheless) that could emulate an FPU.
The high end programs are always the first to be ported. The other apps are "good enough" and depending on how much time an emulated app spends running native operating system code, it won't be all emulated.
It took me forever to realize where the name came from.
“Close but no cigar”.
You mean a third time though! The mac went through three architecture transition, and each came with an emulator to keep compatibility for a while. The first one was when they went from Motorolla 68000 to PPC, and they built the Mac 68k Emulator[0] to keep software going.
I also think they could pull it off again. Microsoft has shown us that it's possible to run a lot of x86 software on ARM64 with little noticeable impact[1]. It would, however, require immense engineering effort.
[0]: https://en.wikipedia.org/wiki/Mac_68k_emulator
[1]: https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
https://en.wikipedia.org/wiki/Apple_IIe_Card
https://en.wikipedia.org/wiki/Apple_IIGS#Gus
Emulating x86 on ARM is very hard because x86 has a strong memory model while ARM has a weak one. This either makes emulation very slow or will break lots of multithreaded applications.
The other emulation direction (ARM on x86) works much better.
If emulation were taken seriously, Apple could add extra features to their ARM-ISA processors in support of x86 emulation, including x86 compatible implicit memory barriers.
In fact, out of Intel and ARM, ARM is the only one I know that tried to shut down software emulation...
(ARM blocked parts of QEMU from being published for a while, citing "you must have read the manual to implement this therefore you are bound by the terms of the manual". They also had an open source design removed from OpenCores.)
It would not be completely silly to modify QEMU with x86 guest and modified-ARM target (for implicit-barrier mode), and then just use QEMU for the emulation.
As long as implicit-barrier mode was generic enough I think Intel would have an interesting time claiming it infringed some patent of theirs. Making it efficient would remain Apple's problem but they are good at that. (Or were until the CPU designers left to start Nuvia.)
If Intel won that, implicit-barrier would have to be explicit-barrier which is just normal ARM, but there is no fundamental reason why that cannot be fast, if the processor is designed to expect a lot of barriers and optimised accordingly. Especially if a dense instruction encoding is created for it.
(Everything I just said applies to RISC-V as well as ARM, should Apple decide to change course again.)
https://www.forbes.com/sites/tiriasresearch/2017/06/16/intel...
Thanks for clearing that up. Wonder what the difference is that this article mentions.
But most apps are not very parallelized, only computationally heavy ones are. Those are of course going to suffer from emulation anyway. As a performance lower bound we can imagine that it would emulate a single-core x86 so the memory model differences wouldn't come into play.
Microsoft already has x86 emulation working in Windows for ARM, anyone know implementation details of that, or even publications?
It seems to depend on a feature that is specific for Qualcomm processors: https://news.ycombinator.com/item?id=14318877
I know that to be true, but could you point me to some articles and documentation that tell more. I'd like to learn more.
Seems like a lot of work would need to go into moving existing macOS apps to touch friendly interfaces if that were the case. I’m using a Bluetooth mouse and the cursor is finger sized.
Microsoft currently has 32-bit-only x86 emulation on the ARM-powered Surface X and the reviews aren't positive. I don't know if it's actual emulation, trap/HLE emulation, dynamic translation, or something else - but Microsoft takes backwards compatibility far more seriously than Apple does, and if that's the best Microsoft can do, what hope does Apple have?
While x86 and ARM's ISAs are fundamentally different (y'know: CISC vs RISC) but given that x86 CPUs today are generally implemented using RISC microcode - could x86 be emulated by instead translating x86's RISC microcode to ARM?
I realize another alternative exists: Apple could buy-up cheap, low-power Intel x86/x64 chips (like an i3 or something) as a co-processor to the primary ARM chip and only use the i3 if ARM-based emulation is too slow for a given process?
"ARM-Ed" sounds like a special ARM architecture, while ARM-ed and ARMed elicit the author's intended meaning to me. It's pretty clear as to why the author didn't capitalize "ed" in their own title.
It really annoys me when submitting; it does it only if there's a certain number of capitals in the submission, so 'ARM' probbaly triggered it. (It's now 'Arm' anyway, so it needn't have.) It does accept a more sensible case on re-submission if the submitter edits it quickly enough.
To me it seems like another case of big-company-itis. Someone on the processor design team wants a promotion. Someone on the Macbook Air team wants a promotion. Working together is not the easiest path to that promotion, so the products remain separate. That is the reality of big companies and why startups get so much done. Nobody on the MacOS team is going to say "we should delete this thing and start working on XCode for the iPad instead", and so... as end-users we wonder wtf they're up to.
Obviously engineers play a role in evaluating the practicality of running it on an iPad, but that's such an incredibly strategic decision for Apple it's hard to imagine it's purely a question of Mac engineers not feeling like doing it.
OTOH, another case of big-company-itis is over-segmenting your products and not allowing them to grow organically our of fear of cannibalizing your higher profit margin products.
Apple never letting the iPad get full keyboard and cursor support and saying "that's a Mac thing" leaves them open for disruption from Microsoft instead.
Xcode is likely planned for iPad, but it's a massive ecosystem (not just one app, don't forget there's Instruments, the Simulator, compiler build step scripts, etc etc) and will take a LONG time to port
Full keyboard and mouse support is in iOS 13.4.
The Surface is just another Windows computer with all the baggage that entails - x86 processors with horrible battery efficiency, an operating system that requires more RAM and storage, an operating system that still has parts that aren’t touch friendly and plenty of apps that still have a UI that doesn’t work well with touch.
Sorry, that was the point I was trying to make. Apple isn't afraid to cannibalize their own product lines by improving their "lesser" product. Rather than being a sign of "big-company-itis", it's a sign of being agile.
> The Surface is just another Windows computer with all the baggage that entails
Microsoft has a history of evolving their products until they are a success, I wouldn't count anything out on it's current iteration.
There's not just the Surface either, the Chromebook could have a future as software moves more and more onto the web and people don't really leave their browsers.
The entire idea of the Surface is fundamentally flawed because of three factors - it’s dependence on backwards compatibility with Windows and using x86 processors.
The Chromebook is already a success in education, but it has the opposite problem than the Surface. Google has no clue in how to create an ecosystem. Android on tablets have been a non starter and Chromebooks are still nowhere as capable as iPads.
Android succeeded because Apple refuses to compete on price and everyone needs an phone. A tablet is a luxury product and Apple competes pretty well on price. The $329 iPad is a very good device with a better ecosystem.
As for the cpu side.. Apple switched before. Also, the tooling is way more up to date and code is more high level these days than before.
Intel as a company isn’t performing, so it’s been AMD and their own CPUs.. they pulled it off before, and I think it will depend on tooling, and app compatibility/performance when emulating. Although I’m not sure if that would require a license
https://mondaynote.com/archive/2008
Phones are another matter, of course.
I'm temporarily between computers and using my iPad as my main computer. I also thought it would be a fun experiment so that I could learn the pros and cons of using an iPad as my main computing device first hand.
The new(-ish) mouse support is wonderful. Absolutely wonderful. I have a keyboard with a built-in trackpad, and when I'm using my iPad at a desk, it's far superior to constantly reaching up and pawing at the screen. Apple took a huge step forward here.
But there are still some pretty serious issues. The iPad is really aggressive about killing apps, to the point that I'd switch back and forth between apps (using Cmd+Tab on the keyboard) and it would frequently restart the apps from scratch. Even when switching between just two apps. And a lot of apps don't fully restore where you were at when the app was killed.
This issue alone is bad enough that, long-term, there's no way I could use my iPad as a laptop replacement.
The other issue is that I'm a software developer, and the software development story on the iPad (not for the iPad) is quite sad. There's absolutely no support for the two languages I use most frequently (Java and C). I can't even develop a simple web page (HTML/CSS/JS) on the iPad itself. There's no way to save and view local web pages.
Based on Apple's history, I think they'll be stubborn and thus really, really slow to add the features I want (though I think they'll add them eventually).
As for having a single appleOS, we're talking about the company that owns (1) watchOS, (2) iOS, (3) iPadOS, (4) macOS, and (5) tvOS - I believe that's more than Microsoft and Google combined.
[0] They're slowly making everything more touchpad-centred and graphics-oriented, for example.
What did Apple gain from switching from PPC to Intel in the first place? They gained faster processors (their market share was insufficient to keep performance parity) and the ability to virtualize or even dual-boot Windows on Mac hardware. I don’t see these factors changing; iPhones and iPads don’t have the performance properties of laptops and desktops, meaning even Apple’s internally-developed ARM architecture is going to treat Macs as as much of an afterthought as Motorola and IBM did back in the day. Meanwhile, even if Windows compatibility is less relevant, the ability to virtualize Linux distros on Macs has become more relevant.
If I’m a software developer and I want to run my code on a x86-based Linux server somewhere, I’ll often want my development environment to be capable of reproducing that same environment, and tools like Vagrant and Docker accomplish this on Macs using virtualization. Without a shared CPU architecture, these tools will either stop working entirely or rely upon emulation, which would hinder performance and potentially introduce inconsistent behavior compared to the real hardware. Now, it’s true that iOS development relies on the Mac performing ARM emulation. But there’s already a working solution for this, and you can still use actual iOS hardware for testing. If I had to connect my Mac to an x86-based Linux box for testing and development, why wouldn’t I just use the Linux box? And the Linux box is a server that I can either Remote Desktop or SSH into, why would I need a Mac to be able to do that? Maybe I’m biased because I already think Macs aren’t a very good development environment, but I don’t really see switching CPU architectures as a move that makes them any better. All bets are off if ARM servers actually take off, though.
[1] https://www.phoronix.com/scan.php?page=article&item=ampere-a...
[2] https://aws.amazon.com/ec2/graviton/
[3] https://www.raptorcs.com/TALOSII/
But the more you live in the terminal, the more of a mess it becomes compared to Linux. All the built in utilities are either very old or feature-impoverished BSD variants. Making it usable at all requires Homebrew, which manages to get broken by every major OS update. The default file system is case insensitive, which probably improves usability for mundanes but can result in some utterly broken Git workflows. And the more effort you invest into automating your workflow, the more time and effort you have to expend on the relatively useless and non-transferrable skill of macOS system administration. So I switched to Linux. Tiling window managers are nice, too.
The Air and mini just got an update that brings the T2. I’m not sure if they are still shipping any non-T2 Macs, I don’t think they are.
QEMU can run Intel MacOSX code and they can use it to emulate the old Intel Macs. This version of QEMU was designed to run older OSX Intel versions under new Intel versions to run legacy software.
CommodoreOS is based on Linux and in order to run old Amiga apps they use UAE for 68K and PowerPC Amigas. This seems to be that virtual machines and emulation can run the legacy software needed on the new ARM Macs.
But I don't see what's in for the users and software developers? Transition to another architecture might mean more money spent for end-users and more money and time spent for software developers.
Why is everybody so excited?
As for more money and time… I dunno, I make my living writing mostly iOS and Mac software and I can't recall the last time I did anything that was architecture specific. I'd imagine that applies to the vast majority of people working on ordinary application software on these platforms.
I am personally a Linux/Thinkpad person, but all the persons I am working with who happen to have a Surface just love it.
Well executed, the concept is beautiful and practical. Apple is coming from the tablet side and Microsoft from the laptop side, they will converge at some point.
ARM is an implementation detail.
But where iPadOS lacks significantly behind MacOS is the software. And this is based on the AppStore rules. Applications are limited in their capabilities which would be natural on a "computer". With "Files", applications can finally exchange data, but that still has complexities for the user and is less natural than it works on the Mac.
The biggest elephant in the room is the missing ability to do any real software development on the iPad. One might say that the software developers are the minority of the users and that is correct, but the software developers are the critical group for a platform which creates the software which all the other users can use. While the AppStore on the Mac has grown over time, just look how large the software universe outside the AppStore is, to get an idea, how important this is for the Mac platform. Not even counting the number of users, which wouldn't qualify as software developers, but are running a few scripts here and there for special task, either written by themselves or grabbed from the internet and modified to their needs. And yes, sometimes you really need a shell.
It will be interesting to watch what gets shown for iPadOS 14. If the iPad should go further into the Mac space, some significant changes need to be announced. The trackpad addition goes in the right direction, but does not address the points I mentioned above.