....
Enter BitCode.
....
...
...
So, predictions time.
- Apple will produce ARM based desktop/laptop hardware.
Running what? iOS , Watch OS, and maybe TViOS .... sure. App thinning and BitCode are solving platform fragmentation issues in that space in the next version. They could be used for other stuff but that is what they are being applied to currently.
OS X, not so clear.
To date BitCode is targeted more so toward "smaller" rather than more capable devices. Watch and other Wearable and/or Internet of things that Apple jumps into likely will have less capable CPUs and GPUs than the mainstream iOS devices, let alone the OS X ones with Intel CPUs in them.
An energy efficiency optimizer that has different thermal and/or power profiles is pretty much in the range of what they have.
Also Apple doesn't do the Mx (motion) chips. They buy those. The Apple Watch CPU is trailing edge (looks like a chopped down A7 class core or maybe an slightly upgraded A6 core on 28nm process. )
http://www.chipworks.com/about-chip...e-apple-watch-technical-teardown-blog#Update1
If someone ( Intel , NXP , TI , etc ) comes up with a better watch CPU than Apple for the right price Apple will probably buy it .... just like they buy the Mx chips. For example, small memory on watch may warrant staying at 32 bit while the iOS ecosystem transitions to 64 only.
- iOS and OS X will merge into a common platform
Doubtful. Bigger iPads and more multitasking apps? Yes. iOS and OS X will have a larger overlapping upper/lower edges but probably not merge. Similar visual design cues? Yes. Merge at core services layer probably not. OS X has to deal with a wider set of 3rd party devices ( meaning broader device drivers ) and 3rd party software ( the Mac App Store is not going to 100% of the Mac software market; Adobe and Microsoft. aren't in a hurry to cough up 30% to Apple for their mainstream apps. iOS is a "race to the bottom" lost cause, but Windows is fully viable alternative to OS X. ).
If bigger iPads gobble up more of the low end OS X range then Apple is done. They don't actually need more fratricide in that situation ( increase OS X moving down into iOS zone).
- The mechanisms for architecture change are being sown now
Fat Binary infrastructure is present in OS X now but Apple isn't using it. What do ARM "desktop" solution ( if existed, because do no right now) buy? As long as Intel is delivering at workable prices there is not a good reason to move. If AMD implodes and Intel jacks up the prices or becomes unmotivated then can pull the trigger on moving.... but until it is really more so a fact of whether there is an actual "problem" to solve by going to ARM. AMD has a pretty good chance of not disappear. ( there is more doom and gloom talk that is a problem now than AMD on the wrong path. They just need some bridge financing until exit the tunnel. )
Control isn't "the core problem". A deep need for substantially cheaper Macs isn't it either. Apple has an extremely successful OS for ARM. iOS. Waaaaaaaaaay bigger than Macs and way more profitable. What Apple needs is something different than that which is still integrated to augment their revenues.
- They will have the capability to republish software without developer intervention (eg. refactoring APIs arising from platform changes/fixes)
BitCode does nothing for significantly refactoring code. It is basically the internal representation that the compiler uses before it dumps the assembler (or binary if assembly is fused) at the last stage of compile. What BitCode primarily allows is different compiler optimizer passes to be run just before doing the assembly conversion. It doesn't refactor the code. It may convert a manual series sequence of math ops into a vector operation if it detects that is the actual intent but it isn't going to change what the code is doing or flip CocoaTouch into mainstream Cocoa.
- They can intelligently scan BitCode uploaded for potential issues (security, unauthorised API etc)
Can do that now with current binaries. BitCode makes it a bit more uniform, but it doesn't particularly improve things.
All the stubs for the dynamic bindings to the API calls are present BitCode or not.
BitCode could allow more trace path analysis (e.g., what are you doing before get to call points), but I'd be shocked if Apple would put that into the inspection process flow.
PS: For all you developers using low level assembly - I'm not sure how that fits in with the above. Maybe Apple won't care.
Don't care they don't get some device drivers. .... that really isn't all that viable when competitor Windows fully enables it.
PPS: If developers distribute outside the AppStore then it's up to you I guess how you'd target the different architectures.
Rosetta worked all the way down the device driver level.... in part because Apple knew they needed those pieces to be competitive.
If absolutely everything is in the app store and on ARM then for the most part largely have iOS. Apple already has iOS. Apple could do a Chromebook like device with iOS relatively easily. Keyboard support in iOS is improved in version 9. Force touch trackpad means probably don't necessarily need to touch the screen as much.