Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Luckily this instruction difference is bridged by a compiler and almost all code is written in C (etc), a higher order language that doesn't depend on a specific instruction set. So, almost all programs, unless they contain hardware accelerated pieces of inline machine code, can be converted with one push of the XCode recompile button. Maybe your confused with ‘porting’ of applications, that's a whole different ballgame and consists of rewriting parts of code to fit a different API. But in this case the APIs are the same. It is also possible to translate x86 machine code directly to ARM, if no source (higher language) code is available, so even third party programs, designated for x86 can be used at almost full speed on ARM (this could also be an OS responsabilty, to translate fat binaries of the wrong kind automatically the first time they run and save this code for future runs).
No, that’s simply not true. I don’t get it. I’ve been through this several times before over the decades, and it was never true. Every time, we get the wags who exclaim that it’s only a recompile away. But that’s only true for smaller apps. It’s never true for more complex apps. There are a lot of reasons. Many developers, including Apple, don’t follow the rules. When this change happens, they have to scramble to figure out ways around their screwups.
It’s more complex than that though. Like it or not, C doesn’t do what you think it does. It’s not Java. Also, apps are written in various versions of Swift, and other languages.
you can’t just translate machine code around like that. There are often instructions that are not comparable, and it can be difficult to work around that.
really, your view on this is simplistic.
Simplistic, yes ok. It will take some extra time to give a more comprehensive view. But in essence its what I posted before. Your right that C is a difficult language and translating an elaborate program to another machine language can reveal bugs never noticed before (using different compilers for the same target architecture may do the same), and it can take a lot of time to work that out. The added bonus in this case is that a better program will eventually run on ARM. Directly translating machine code has its own specific difficulties of course, no one argues that it is easy to do, but it is certainly possible (I know I can write the code to do that, I worked for a compiler company ...).
I’ve never, in any discussion anywhere, said that it was impossible. That would be nuts! But while I haven’t orogrammed since 2000, I know enough about the processes, still, to understand just how difficult it all is. The fact that x86 and power pc had endian differences was itself enough to make grown men cry. There are enough differences between the simpler ARM instruction sets and the more complex x86 sets to make a number of translations very difficult. In all of this, it’s easier going from ARM to x86 than the other way around. X86 is just more versatile. Doesn’t mean it can’t be done though.
i’m just saying that this isn’t easy, it’s not a recompile away, and it may result in a lack of some expected features, speed differences and such. Code of millions of lines will require a lot of people, and a lot of time. Think of all the bugs in all software, and think of the number of bugs in big software. While most of them, and there can be hundreds to thousands, are relatively harmless, if they get translated, and not perfectly, to another platform, they can become busters, and can take a lot of time to track down.
apple is well aware of this, even as some here are not. So if they do this, and despite all we read and hear, they might not, they have to take all of this into account. So the OS itself will be native. Some of their more popular software will be native. But larger stuff won’t. Not at first. Neither will Adobe’s or Microsoft’s. Or big software from anyone else, such as the big commercial databases that are on the Mac.
and for emulation to work, it’s got to work slowly. The best we could hope for, in the beginning, is about 50% speed, maybe less, depending. If Apple manages to continue speeding their SoC up faster than Intel/and manage to, then maybe in a couple of years, or so, it will be equal. But just with slower machines. Faster machines will take longer. And hopefully, by then, big software will have moved over to a large extent,
but it let’s not go crazy here. We know that direct emulation if emulating an equally powerful processor family takes a processor that’s about 5 times faster, for emulation to run at the same speed. We saw that with the PPC emulation software for x86. We could never get anything to run at more than about 20% of the speed.
if Apple does this, they will have to be confident of the future, or else it will be a bust. Nobody major will move their software from x86 to ARM if all Apple can do is the MacBook. They need to be assured that within a few (very few!) years, all Macs will be on ARM. And if they see a bifurcation that will last, so that neither x86 or ARM will offer enough sales, we may see developers abandon the platform entirely. I hope that doesn’t happen, but developers aren’t Apple. They’re in business to make money for themselves, and their own companies.
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Luckily this instruction difference is bridged by a compiler and almost all code is written in C (etc), a higher order language that doesn't depend on a specific instruction set. So, almost all programs, unless they contain hardware accelerated pieces of inline machine code, can be converted with one push of the XCode recompile button. Maybe your confused with ‘porting’ of applications, that's a whole different ballgame and consists of rewriting parts of code to fit a different API. But in this case the APIs are the same. It is also possible to translate x86 machine code directly to ARM, if no source (higher language) code is available, so even third party programs, designated for x86 can be used at almost full speed on ARM (this could also be an OS responsabilty, to translate fat binaries of the wrong kind automatically the first time they run and save this code for future runs).
No, that’s simply not true. I don’t get it. I’ve been through this several times before over the decades, and it was never true. Every time, we get the wags who exclaim that it’s only a recompile away. But that’s only true for smaller apps. It’s never true for more complex apps. There are a lot of reasons. Many developers, including Apple, don’t follow the rules. When this change happens, they have to scramble to figure out ways around their screwups.
It’s more complex than that though. Like it or not, C doesn’t do what you think it does. It’s not Java. Also, apps are written in various versions of Swift, and other languages.
you can’t just translate machine code around like that. There are often instructions that are not comparable, and it can be difficult to work around that.
really, your view on this is simplistic.
Simplistic, yes ok. It will take some extra time to give a more comprehensive view. But in essence its what I posted before. Your right that C is a difficult language and translating an elaborate program to another machine language can reveal bugs never noticed before (using different compilers for the same target architecture may do the same), and it can take a lot of time to work that out. The added bonus in this case is that a better program will eventually run on ARM. Directly translating machine code has its own specific difficulties of course, no one argues that it is easy to do, but it is certainly possible (I know I can write the code to do that, I worked for a compiler company ...).
I’ve never, in any discussion anywhere, said that it was impossible. That would be nuts! But while I haven’t orogrammed since 2000, I know enough about the processes, still, to understand just how difficult it all is. The fact that x86 and power pc had endian differences was itself enough to make grown men cry. There are enough differences between the simpler ARM instruction sets and the more complex x86 sets to make a number of translations very difficult. In all of this, it’s easier going from ARM to x86 than the other way around. X86 is just more versatile. Doesn’t mean it can’t be done though.
i’m just saying that this isn’t easy, it’s not a recompile away, and it may result in a lack of some expected features, speed differences and such. Code of millions of lines will require a lot of people, and a lot of time. Think of all the bugs in all software, and think of the number of bugs in big software. While most of them, and there can be hundreds to thousands, are relatively harmless, if they get translated, and not perfectly, to another platform, they can become busters, and can take a lot of time to track down.
apple is well aware of this, even as some here are not. So if they do this, and despite all we read and hear, they might not, they have to take all of this into account. So the OS itself will be native. Some of their more popular software will be native. But larger stuff won’t. Not at first. Neither will Adobe’s or Microsoft’s. Or big software from anyone else, such as the big commercial databases that are on the Mac.
and for emulation to work, it’s got to work slowly. The best we could hope for, in the beginning, is about 50% speed, maybe less, depending. If Apple manages to continue speeding their SoC up faster than Intel/and manage to, then maybe in a couple of years, or so, it will be equal. But just with slower machines. Faster machines will take longer. And hopefully, by then, big software will have moved over to a large extent,
but it let’s not go crazy here. We know that direct emulation if emulating an equally powerful processor family takes a processor that’s about 5 times faster, for emulation to run at the same speed. We saw that with the PPC emulation software for x86. We could never get anything to run at more than about 20% of the speed.
if Apple does this, they will have to be confident of the future, or else it will be a bust. Nobody major will move their software from x86 to ARM if all Apple can do is the MacBook. They need to be assured that within a few (very few!) years, all Macs will be on ARM. And if they see a bifurcation that will last, so that neither x86 or ARM will offer enough sales, we may see developers abandon the platform entirely. I hope that doesn’t happen, but developers aren’t Apple. They’re in business to make money for themselves, and their own companies.
What I don't get is why bother with emulation when you could put a x86 co-processor in each Mac and that be what sets a Mac apart?
Most of the light-weight and common software runs on the ARM processor, anything old or demanding runs on the co-proceesor and streams the interface back for composition onto screen. Like Apple already does with dual GPU but the second sometimes powered chip is an x86 APU.
Developers then don't need to abandon any code. Customers don't need to abondon any old apps. Well at least until Apple stops making Mac's as the market isn't there anymore in maybe 10years or in the same period inferstructure speeds kick up and these apps become cloud services. Developers also get the incentive making ARM interface that hits a bigger market and incentive to break apps into "services" that can feed the main app and improve multi-threading.
As Arm gets more powerful the x86 chip can be smaller each generation.
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Luckily this instruction difference is bridged by a compiler and almost all code is written in C (etc), a higher order language that doesn't depend on a specific instruction set. So, almost all programs, unless they contain hardware accelerated pieces of inline machine code, can be converted with one push of the XCode recompile button. Maybe your confused with ‘porting’ of applications, that's a whole different ballgame and consists of rewriting parts of code to fit a different API. But in this case the APIs are the same. It is also possible to translate x86 machine code directly to ARM, if no source (higher language) code is available, so even third party programs, designated for x86 can be used at almost full speed on ARM (this could also be an OS responsabilty, to translate fat binaries of the wrong kind automatically the first time they run and save this code for future runs).
No, that’s simply not true. I don’t get it. I’ve been through this several times before over the decades, and it was never true. Every time, we get the wags who exclaim that it’s only a recompile away. But that’s only true for smaller apps. It’s never true for more complex apps. There are a lot of reasons. Many developers, including Apple, don’t follow the rules. When this change happens, they have to scramble to figure out ways around their screwups.
It’s more complex than that though. Like it or not, C doesn’t do what you think it does. It’s not Java. Also, apps are written in various versions of Swift, and other languages.
you can’t just translate machine code around like that. There are often instructions that are not comparable, and it can be difficult to work around that.
really, your view on this is simplistic.
Simplistic, yes ok. It will take some extra time to give a more comprehensive view. But in essence its what I posted before. Your right that C is a difficult language and translating an elaborate program to another machine language can reveal bugs never noticed before (using different compilers for the same target architecture may do the same), and it can take a lot of time to work that out. The added bonus in this case is that a better program will eventually run on ARM. Directly translating machine code has its own specific difficulties of course, no one argues that it is easy to do, but it is certainly possible (I know I can write the code to do that, I worked for a compiler company ...).
I’ve never, in any discussion anywhere, said that it was impossible. That would be nuts! But while I haven’t orogrammed since 2000, I know enough about the processes, still, to understand just how difficult it all is. The fact that x86 and power pc had endian differences was itself enough to make grown men cry. There are enough differences between the simpler ARM instruction sets and the more complex x86 sets to make a number of translations very difficult. In all of this, it’s easier going from ARM to x86 than the other way around. X86 is just more versatile. Doesn’t mean it can’t be done though.
i’m just saying that this isn’t easy, it’s not a recompile away, and it may result in a lack of some expected features, speed differences and such. Code of millions of lines will require a lot of people, and a lot of time. Think of all the bugs in all software, and think of the number of bugs in big software. While most of them, and there can be hundreds to thousands, are relatively harmless, if they get translated, and not perfectly, to another platform, they can become busters, and can take a lot of time to track down.
apple is well aware of this, even as some here are not. So if they do this, and despite all we read and hear, they might not, they have to take all of this into account. So the OS itself will be native. Some of their more popular software will be native. But larger stuff won’t. Not at first. Neither will Adobe’s or Microsoft’s. Or big software from anyone else, such as the big commercial databases that are on the Mac.
and for emulation to work, it’s got to work slowly. The best we could hope for, in the beginning, is about 50% speed, maybe less, depending. If Apple manages to continue speeding their SoC up faster than Intel/and manage to, then maybe in a couple of years, or so, it will be equal. But just with slower machines. Faster machines will take longer. And hopefully, by then, big software will have moved over to a large extent,
but it let’s not go crazy here. We know that direct emulation if emulating an equally powerful processor family takes a processor that’s about 5 times faster, for emulation to run at the same speed. We saw that with the PPC emulation software for x86. We could never get anything to run at more than about 20% of the speed.
if Apple does this, they will have to be confident of the future, or else it will be a bust. Nobody major will move their software from x86 to ARM if all Apple can do is the MacBook. They need to be assured that within a few (very few!) years, all Macs will be on ARM. And if they see a bifurcation that will last, so that neither x86 or ARM will offer enough sales, we may see developers abandon the platform entirely. I hope that doesn’t happen, but developers aren’t Apple. They’re in business to make money for themselves, and their own companies.
What I don't get is why bother with emulation when you could put a x86 co-processor in each Mac and that be what sets a Mac apart?
Most of the light-weight and common software runs on the ARM processor, anything old or demanding runs on the co-proceesor and streams the interface back for composition onto screen. Like Apple already does with dual GPU but the second sometimes powered chip is an x86 APU.
Developers then don't need to abandon any code. Customers don't need to abondon any old apps. Well at least until Apple stops making Mac's as the market isn't there anymore in maybe 10years or in the same period inferstructure speeds kick up and these apps become cloud services. Developers also get the incentive making ARM interface that hits a bigger market and incentive to break apps into "services" that can feed the main app and improve multi-threading.
As Arm gets more powerful the x86 chip can be smaller each generation.
There would be no point to that. It would just make everything more complicated, and expensive. If Apple does this, the point would be to eliminate x86 and any support chips entirely, and bring the cost, and price down. If x86 is in the machine, then big developers will have no incentive to move over, and Apple won’t be able to eliminate x86. You have to tell people that you’re doing this, and this is what it’s going to look like. If you give them a fall-back, then they’ll take it. I don’t think that Apple wants to play chicken with developers.
apple would need to have a complete changeover in maybe 3 years. Developers need to see that it’s happening, so that they have to get on it right away. Every time Apple did this, they lost developers. Sometimes those were very good programs. Not everyone wants to bother. In fact, a few years ago there were several articles wondering if developers would follow Apple again if they did this. The answer was inconclusive. It’s more difficult now with the Pro iPad getting more software. Companies may feel that the Mac is diminishing in percentage in Apple’s universe, so why bother with it when they can sell to a lot more customers on iOS? That is, if Apple can permanently reverse the iPad’s decline.
An unsubstantiated, and highly suspect, "leak" on Friday claims to reveal benchmarks from a pair of desktop-class ARM processors supposedly designed by Apple, offering what could be the first look at A-series silicon destined for Mac.
Outlined in a post to Slashleakson Friday are supposed Geekbench benchmarks for ARM big.LITTLE chips with 10- and 12-core architectures.
Information provided by an anonymous uploader claims the 10-core version is clocked at 3.4GHz, while supposed Geekbench screenshots show the 12-core chip, referenced as "APWL2@HmP," running at 3.19GHz. The two application processors achieved respective single-core scores of 7335 and 6912, and multi-core scores of 20580 and 24240.
What device the alleged ARM chips are powering is unknown, but the performance of each falls in line with desktop class hardware. Both processors beat single-core benchmarks set by Apple's 2017 27-inch Retina 5K iMac with 4.2GHz Intel Core i7-7700K, while the purported 12-core ARM chip's mutli-core score bests the 2018 15-inch MacBook Pro with 2.9GHz Intel Core i9-8950HK.
It is unclear if the benchmarks shared today are legitimate, but it should be noted that the uploader joined SlashleaksAppleInsider was unable to verify the leak and does not vouch for its veracity.
Apple has long been rumored to transition Mac away from Intel to a bespoke ARM architecture, but hard evidence of the development process has been elusive.
Last October, analyst Ming-Chi Kuo in a note to investors predicted an ARM-based mac to arrive in 2020 or 2021. More recently, Intel officials in February told Axios they expect the tech giant to make the switch "as soon as next year."
I am sure there are many ARM base laptop/desktop class machines running in Apple HQ. But if Apple really stop using Intel/X86 cpu, that means a big chunk of corporate/power user will stop Apple products for good. The ability to run windows, Linux and other x86 base OS on a quality Mac machine is why these companies willing to pay extra bucks for it, not MacOS.
Will Apple willing to make the switch just for being “I am special” like the good old days? I doubt it. After all, it is not like Intel has bad relationships with apple or not able to improve like Motorola/IBM.
Why do you assume that Windows and Linux will not run on these machines? Seriously I see this posted all the time and frankly we have no evidence that Apple intends to lock out these operating systems. They could of course but it doesn’t make any sense to do so.
Beyond that I really don’t think you understand what a mess the Windows world is right now. Far too many apps do not run on MS newer Windows versions. The industry already has significant transitional issues.
I am sure the arm base CPU can run windows and Linux, but most likely with something similar to Rosetta. Power user needs speed and precision which Rosetta or similar programs lack. Unless apple can make the arm cpu run like a x86, otherwise these corporate and power users will most likely disappear. But when an arm cpu runs like a x86. It is not exactly a ARM cpu, isn’t it?
This is my whole point Linux already run on ARM and MS is hell bent on Windows on ARM. That is native OS and Native apps. Their is no debate here because Linux distros actually exist for ARM already. The key will be Apple, do they make it easy or do they make it hard to run these other operating systems, ARM itself is not an issue.
As for corporate or power power users for one I don’t think Apple cares one bit. More importantly their is a more open mind set with both groups to find something that moves them out of the stagnation in the PC world. Done right an ARM based line of PCs will bring more users to the Mac world.
Personnally i I could see myself buying Apple hardware again if they leveraged the advantages of ARM to deliver high performance at a much lower cost.
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Your negativity in my mind is unwarranted. There certainly will be problem apps however Apple has been guiding the industry to this goal for years. That is apps that can be built and ran on different architectures. I would expect most of Mac App Store to have native binaries at launch.
As for developers and easy, never accept the ranting and ravings from a dog and pony show. However let’s not forget that new technologies often lead to major App refactoring. Often the delays are about new functionality.
I would fully expect that all key apps would be native at launch. That includes the entire ecosystem of Apple marketed apps and all of the operating system. I just don’t see Apple screwing this up.
I don’t understand why you would think that. In the past, every time Apple has done this, the big apps took about a year to arrive, including Apple’s own. Apps of intermediate size took months. Only smaller apps were available fairly quickly. We can even look at iOS. When Apple announced that 32 bit apps would not be allowed a year later, many apps were still not 64 bits when the time arrived. Many took months, and many never came. And that was the same processor family. With over a year’s notice.
I believe it because Apple has been pushing developers hard to write to APIs and avoid machine specific code. On the flip side you do have a lot of developers that don’t care, this especially with old 32 bit apps. Many of these unsupported apps stop working after one or more system updates so processor archetecture isn’t a thing here either.
In any event ARM compatibility will happen because Apple will mandate it. That is a Mac App Store Listing must provide for ARM executables. In any event from the point of view of a developer with access to all of Apples technical info I’d have to say that Apple has been planning for this for years. There will be no excuses for developers caught with their pants down.
Comments
i’m just saying that this isn’t easy, it’s not a recompile away, and it may result in a lack of some expected features, speed differences and such. Code of millions of lines will require a lot of people, and a lot of time. Think of all the bugs in all software, and think of the number of bugs in big software. While most of them, and there can be hundreds to thousands, are relatively harmless, if they get translated, and not perfectly, to another platform, they can become busters, and can take a lot of time to track down.
apple is well aware of this, even as some here are not. So if they do this, and despite all we read and hear, they might not, they have to take all of this into account. So the OS itself will be native. Some of their more popular software will be native. But larger stuff won’t. Not at first. Neither will Adobe’s or Microsoft’s. Or big software from anyone else, such as the big commercial databases that are on the Mac.
and for emulation to work, it’s got to work slowly. The best we could hope for, in the beginning, is about 50% speed, maybe less, depending. If Apple manages to continue speeding their SoC up faster than Intel/and manage to, then maybe in a couple of years, or so, it will be equal. But just with slower machines. Faster machines will take longer. And hopefully, by then, big software will have moved over to a large extent,
but it let’s not go crazy here. We know that direct emulation if emulating an equally powerful processor family takes a processor that’s about 5 times faster, for emulation to run at the same speed. We saw that with the PPC emulation software for x86. We could never get anything to run at more than about 20% of the speed.
if Apple does this, they will have to be confident of the future, or else it will be a bust. Nobody major will move their software from x86 to ARM if all Apple can do is the MacBook. They need to be assured that within a few (very few!) years, all Macs will be on ARM. And if they see a bifurcation that will last, so that neither x86 or ARM will offer enough sales, we may see developers abandon the platform entirely. I hope that doesn’t happen, but developers aren’t Apple. They’re in business to make money for themselves, and their own companies.
apple would need to have a complete changeover in maybe 3 years. Developers need to see that it’s happening, so that they have to get on it right away. Every time Apple did this, they lost developers. Sometimes those were very good programs. Not everyone wants to bother. In fact, a few years ago there were several articles wondering if developers would follow Apple again if they did this. The answer was inconclusive. It’s more difficult now with the Pro iPad getting more software. Companies may feel that the Mac is diminishing in percentage in Apple’s universe, so why bother with it when they can sell to a lot more customers on iOS? That is, if Apple can permanently reverse the iPad’s decline.
As for corporate or power power users for one I don’t think Apple cares one bit. More importantly their is a more open mind set with both groups to find something that moves them out of the stagnation in the PC world. Done right an ARM based line of PCs will bring more users to the Mac world.
Personnally i I could see myself buying Apple hardware again if they leveraged the advantages of ARM to deliver high performance at a much lower cost.
In any event ARM compatibility will happen because Apple will mandate it. That is a Mac App Store Listing must provide for ARM executables. In any event from the point of view of a developer with access to all of Apples technical info I’d have to say that Apple has been planning for this for years. There will be no excuses for developers caught with their pants down.