Yes.
First, you are missing an entire class of software. Drivers. The systems that general OS X users operate tend to involve more than solely Apple hardware and/or Apple drivers. Push a button and recompile is likely an over simplification.
Good arguments and clarifications, thanks for those.
Are drivers nowadays still hardware-related, and made with low level coding and causing problems in this case. If, that is bad news for my current external device collection? Firewire and usb? I once put Arch Linux for my NAS, but did not check how its hardware support was. The box went to a nonresponsive state pretty fast when I started to experiment with that….
.
Second, the majority of software development is not spent pushing the "compile it" button. Much of the process is spent in fixing stuff that is broken. Some failure modes can like in parts that aren't so similar. Generalized enough, all instruction sets are the similar. Developers don't have to write in low level instruction specific assembler, but higher level compilers are much better at isolating developers when everything goes right rather than when things don't.
That hints to me, that this hardware transition could comes with a heftier software price tag than we originally hoped for, and also sometimes can result with crashing software, when testing is left to the users.
For customers with limited Internet bandwidth they had to download twice as much stuff if have both x86 and ARM Macs. Developers now has twice as many uploads and applications to test. Apple has twice as many applications to test and approve.
Again, costy. The ARM chips may be cheaper which partly compensates for that, but I start to see a my wallet getting thinner and thinner.
Have you used an iPad with a bluetooth keyboard? Not completely elegant but quite pragmatically useful if largely engaged in writing lots of text. It isn't like the trackpad has to be highly leveraged in all workloads. An additional trackpad can be largely in the same "boat" as an additional keyboard.
Yes, I have. For writing it works indeed, and solves one big problem with iOS. the virtual keyboard taking a lions share of display when editing. There are some inconveniences, like having to keep the iPad in not so optimum angle, and iOS display is simply too small for my eyes if it is kept too far away, but those could be solved with laptop like form factors. As I understand, ARM can be put in any form factors, and it works. I actually wonder how powerful Mini-sized ARM machine could be, CPU/GPU-wise. Top end Macbook Pro or just Apple TV capable?
Win8 Metro mouse is more different than inelegant. It is also not particularly necessarily to implement that specific way either.
I personally find it inelegant with mouse, because the controls including buttons are too large and scattered to every corner. I have to move eyes and the cursor too much. Inelegant and impractical mean the same here. For WP8 or Surface, it is nice and practical. For large vertical displays with mouse, not so much. Definitely not what Apple should find acceptable.
There is no reason developers should compelled to make OS X software the exact price as iOS software. That is a consistency for consistency sake argument. There is little to do with economics to back that up.
I agree about pricing. iOS and OSX are not comparable. Fuller software has a right to be more expensive, because it is priceworthy. If the software is the same… paying twice is not tempting. Now, if iOS and OSX platforms will be mixed, can pro software of Macs still be succesful and temptating or will it be cribbled and complicated with cryptic business models, subscriptions and app in purchases.
ARMs in Macs similar for consistency (i.e., completely maximize the components that both Macs and iOS devices use) is similarly lacking in economic reasoning and far more homogenous for sake of homogenous line of reasoning. Apple already has a OS/app ecosystem for ARM devices. The simplest approach is to just deploy that to any ARM based laptop/desktop box. In that case the user experience works just like it does now. Done.
Putting the OS/apps into another physical form factor doesn't particular do much to the apps. Can add keyboards now where they don't come by default. A trackpad as an alternative point/touch device isn't a huge leap from a touch screen. Nor does it necessarily preclude a touch screen being present.
For deploying, I am not sure. Now when I think about it, are there UIs that work equally well for both mouse and touch currently and don't lose in comparison to more optimized interface on Mac side? That could be a quideline to follow. If x86 to ARM and ARM to x86 are relatively straight forward processes and the resulting UI were really usable and close to optimal, then why don't we have that vast iOS software library compiled and sold succesfully to our Intel Macs with mouses already.
Webpages are quite usable on both platforms, but they don't have complicated selection dialogs in general. Those, who have, tend to be buggy at least on my iPad. Touches are neglected and so on, which hints that touch areas do not correlate well with cursor.
