iOS is a subset of OS X. They share the same Darwin-based code base and share a lot of the fundamental framework, including the same file system. The differences are the front-end levels of the OS, where they have different framework such as Cocoa Touch for iOS and Cocoa for OS X among others.
iOS does have a file system, it is just not user-accessible. You can jailbreak and gain access to its file system via ssh, you can change root password, etc etc. You would be able to create folders, files, delete, etc etc like you can via Terminal on OS X. In fact, if you don't want to jailbreak your device right now, look at iFunBox or iExplorer to get some basic file system access to your device.
Also, considering you probably are not programmer, you can develop OS X and iOS apps with the same code base while "forking" the different interfaces for each platform. I know, I work for a company that does this.
You also missed the part about iCloud drive, where apps store their data files and can be accessed by OS X versions of the same app. iOS 8 now has Document Picker, that replicates a file system via iCloud Drive for apps. So, yes totally possible.
Yes, there's a big difference, they're not the same architecture. That's what I just said. You can build x86 version of iOS apps actually, it's done all the time via Xcode's iOS simulator which runs the x86 native code of iOS apps.
It does have everything to do with architecture. You can code the same way, a string is a string in the code. However, when you compile the code, it translates to different code for different architecture such as x86 and ARMv8, because they do not not process a string of "text" the same way. A code compiled for ARM can run on both iOS and OS X and Xcode when compiling the code will know the difference in interfaces that the developers ask for. So yes, you can run the same app on both Mac and iOS but you don't see the same app, it will behave differently to fit the screen they're for. Touchscreen on iOS and keyboard/mouse for OS X.
It is exactly how Windows 10 is going to do it. Microsoft demo'ed the entire process already at the last event they had. Same codebase, runs on all Windows devices. Note, this requires using the specific runtime, you can't use the old win32 runtime.
While all that is theoretically true, the mixture of OS X apps ( with access to the file system) and iOS apps (without that ability to save anywhere) as well as the differences between how the UI and UX would be a nightmare.
I can see two modes maybe: an extension of what we have already with the launchPad ( which looks like an iOS style layout). In there you could have a tab on top which shows either iOS or OS X apps. Launching an iOS app will show it as an iOS type app - taking up an iPad sized window in the screen with access to reading documents on the file system via UIDocumentPicker but saving in a sandbox ( which will be synced to the cloud).
This is effectively two distinct type of Apps and application modes although the iOS apps should also get mouse events ( which doesn't happen at the moment). Also they need to work out how to pinch zoom with a keyboard,( the simulator already has that in a geeky fashion.)
It would be clear with this kind of system that the iOS apps would be second class citizens. Nevertheless its possible and in fact is possible on either ARM or Intel chips.
Have you seriously thought about how to run an iOS app on a Mac? Seriously considered where your files go in the file system, and all the little things that go with that?
Yep. Like the Xcode iOS emulator, running on a touchscreen Mac. Only this time, a fully formed Apple app in the way that Apple always does. Might be the 1st actual useful use of forced full screen mode.
Quote:
Originally Posted by plovell
If you have then please enlighten us, in detail. Because I have and all I've seen is less-than-nice.
You know, like in a VM? Like we do with Windows on OS X already, all the time?
iTunes (or whatever replaces it) would install and control the virtual instance like it does for physical devices now. All the ways your mobile apps sync data to your desktop would work here too. Maybe some new ways as well.
See, that was easy. Would cost Apple next to nothing to create. Would cannibalize nothing. New halo effect. Adds hundreds of thousands of apps to OS X instantly. All the IBM effort - running on Macs too...
Quote:
Originally Posted by plovell
But maybe I just didn't think hard enough.
You didn't... But then, you don't work for Apple.
If you think there would be no demand for this, don't buy it when it comes out. They would sell a buttload of these...
You know, like in a VM? Like we do with Windows on OS X already, all the time?
iTunes (or whatever replaces it) would install and control the virtual instance like it does for physical devices now. All the ways your mobile apps sync data to your desktop would work here too. Maybe some new ways as well.
See, that was easy. Would cost Apple next to nothing to create. Would cannibalize nothing. New halo effect. Adds hundreds of thousands of apps to OS X instantly. All the IBM effort - running on Macs too...
The simulator isn't an emulator and there would be no need for a VM, just a recompile.
Its possible that an app designed for the iPad 12" in landscape mode and the Air 12" would work in full screen. But the vast majority of iPad/iPhone apps won't scale to a full screen because there would just be too much space. Imagine a 27" iMac. The typical list view wouldn't work, right and left toolbar buttons would be too far apart. At least on any decent sized monitor. So my guess is that iOs apps on Os X ( which will probably happen but doesn't need an ARM chip) will max out at the 12" landscape mode. Games excepted.
However a UI designed for touch and a UI designed for mouse and trackpad are always going to have different interactions. Pinch to zoom needs to be replicated in a different way. Add to that the iOS app can't write to local filesystem outside it's sandbox and normal apps can and you have a definite recipe for confusion.
Maybe I was the first to introduce Swift to the discussion, but I'm prepared to take the fall.
My point is not that Swift is a magic solution to x86/ARM issues - it clearly is not. It's that the development of Swift has shown that Apple has the talent and the patience to develop all the pieces necessary for a seamless x86->ARM transition, like the PPC->x86 transition. I haven't looked at the tools for over a year, but Xcode can build for x86 (32/64) and ARM and there are packaging tools to build fat binaries. If there's any tweaking needed to do a nice package for a multi-ISA OS X than it's quite minor.
Years ago Apple licensed Rosetta from Transitive for the PPC-> x86 transition. Later on, the company was acquired and the new owners, it seems, did not want to relicense the technology. But - the new owner is IBM and Apple could probably do a deal now - if it has not already done so.
Back to the Swift argument - even if IBM declines again, Apple is now in the position where it could create its own Rosetta2 if it wished. Whether it does will depend upon resources and priorities but it's clear to me that Apple now has the talent to do it. That's why Swift is important.
I think you miss the point of what Swift is. Swift is intended as a replacement for C and its variants. As such, it works on both ARM and X86.
Metal, on the otherhand, is intended for developers to get closer to the hardware, similar to how a developer might program for a console.
After reading what you wrote a few times, are you trying to say that Swift is a way to show the world that Apple is capable of creating wonderful software and tools?
Yes - as I said at the start, Swift in itself is not part of any x86/ARM solution.
What the development of Swift shows is that Apple now has the talent to develop a Rosetta2. That wasn't possible ten or fifteen years ago. It is now.
Costs can be got down to a couple of dollars by using their own chips. But the main thing is that cheap Apple chip is a big stick to beat Intel into low prices.
Yes - as I said at the start, Swift in itself is not part of any x86/ARM solution.
What the development of Swift shows is that Apple now has the talent to develop a Rosetta2. That wasn't possible ten or fifteen years ago. It is now.
Still not really getting it.
Why not just rewrite(in swift) or port an existing hypervisor like Xen or QEMU, the latter of which also has PPC and ARM(Granted not ARMv8 to my knoweldge, as far as up as v7) virtualization support alongside X86? Seems like NIH syndrome to me if you are not going to at least evaluate proven software first.
Odd way to end the article, undermining everything written before. The whole point is that "good enough" isn't Apple's M.O. They smoke the competition, which tries to make ends meet with cheaply made, off the shelf products. If Apple powers its computers to be "good enough" for most consumers in order to save on costs, while undercutting their premium edge, they'll suffer the same fate as the others. I think the rumored 12" Air will say a lot about Apple's direction. It's hard to imagine it coming close to the performance of current, i7 Airs, assuming it doesn't have a fan.
Why not just rewrite(in swift) or port an existing hypervisor like Xen or QEMU, the latter of which also has PPC and ARM(Granted not ARMv8 to my knoweldge, as far as up as v7) virtualization support alongside X86? Seems like NIH syndrome to me if you are not going to at least evaluate proven software first.
I don't see why Apple couldn't do that, but wouldn't using PPC or ARM still make it much slower emulation, not virtualization?
Anyway, I think the bigger question is why would Apple even want to spend time and money supporting Windows on ARM. I am not convinced that Bootcamp would have ever been created if there wasn't a grassroots solutions to make that happen when Apple moved to Intel.
I think it's clear that being able to run Windows on a Mac has helped convert a lot of people to the Mac, but I am not sure that is something they care about anymore. I'd think the iPad and iPhone are a big enough example of Apple's ability to make a great system, and the stats we hear from colleges seem to show an overwhelming number of students using Macs. Based on that info I'd say "**** Windows support" if I were running Apple… and I saw that as someone that is looking for a work notebook that runs Windows.
And it is not the cost that matters.
Apple will spend what it takes.
And Apple's customers will spend what it takes.
Apple and its customers want only the best of breed.
Their lives must be improved by the new product.
Otherwise it is not worthwhile.
An ARM Mac currently will be hell to Apple customers.
It has to be faster than the fastest Intel processors.
If it is a new product category, which it almost certainly will be at the outset, then Intel as a comparison fails. All that matters is how the device performs with the software that is available at release, especially MS Office and Apple's various products, and a few of the staples from Adobe and others.
Pretty much the same situation that the iPad faced, only I'd expect Apple to supply a smooth transition from OS X Intel to OS X ARM for developers, necessarily without x86 support.
Cost ways matters. You don't think Ape could build a better phone that would cost the consumer a lot more than their stable and carefully planned price points?
An ARM Mac currently will be hell to Apple customers.
And how did you come to that baseless conclusion?
It has to be faster than the fastest Intel processors.
While all that is theoretically true, the mixture of OS X apps ( with access to the file system) and iOS apps (without that ability to save anywhere) as well as the differences between how the UI and UX would be a nightmare.
I can see two modes maybe: an extension of what we have already with the launchPad ( which looks like an iOS style layout). In there you could have a tab on top which shows either iOS or OS X apps. Launching an iOS app will show it as an iOS type app - taking up an iPad sized window in the screen with access to reading documents on the file system via UIDocumentPicker but saving in a sandbox ( which will be synced to the cloud).
This is effectively two distinct type of Apps and application modes although the iOS apps should also get mouse events ( which doesn't happen at the moment). Also they need to work out how to pinch zoom with a keyboard,( the simulator already has that in a geeky fashion.)
It would be clear with this kind of system that the iOS apps would be second class citizens. Nevertheless its possible and in fact is possible on either ARM or Intel chips.
You do understand that you're mixing up two different concepts, right? i think the other few users are too.
I am not talking about running both iOS and OS X apps on the same Mac, that's not going to happen. Nothing changes in terms of how iOS and OS X "feel" on each platform.
What I am talking about is the ability for developers to create a single app that runs on both OS X and iOS (likely AppleWatch as well). The backend code remains the same for both OS X and iOS, the only thing the developers have to do is create interfaces for each platform such as OS X, iOS, and iOS. They don't have to worry about how data are created for each platform, they just focus on interfaces instead.
For an example, loading your tweets from Twitter is the same code for all three platforms but the interface to show them is different for each platform. You write the backend code for the Twitter stuff and it runs the same way for all platforms. You then write the keyboard/mouse based interface for when it is on OS X, switches to the iOS interface when it is on iOS, and so on for AppleWatch without changing a single thing to the backend code.
Another example, TweetBot. The developer only has to create Tweetbot once and it runs on all Apple platforms. There is no need to have Tweetbot for iPhone, for iPad, and for OS X separately. Same shared code plus custom interfaces for each platform, one app for all.
There are so many awesome apps that are created for iOS that could be useful on OS X but you hear stories that developers don't have time to fork their apps for OS X. Imagine Apple and Xcode making it extremely easy to do this. Now, Apple has a bigger halo effect of having more productive and innovative OS X apps because it is simpler to create them at the same time with the OS X app.
I don't see why Apple couldn't do that, but wouldn't using PPC or ARM still make it much slower emulation, not virtualization?
Anyway, I think the bigger question is why would Apple even want to spend time and money supporting Windows on ARM. I am not convinced that Bootcamp would have ever been created if there wasn't a grassroots solutions to make that happen when Apple moved to Intel.
I think it's clear that being able to run Windows on a Mac has helped convert a lot of people to the Mac, but I am not sure that is something they care about anymore. I'd think the iPad and iPhone are a big enough example of Apple's ability to make a great system, and the stats we hear from colleges seem to show an overwhelming number of students using Macs. Based on that info I'd say "**** Windows support" if I were running Apple… and I saw that as someone that is looking for a work notebook that runs Windows.
ARMv8 has support for enabling virtualization extensions that speeds up the translations code, it will be much faster than emulation like Rosetta. It's already been coded in the latest Xen version and they're saying they can get it within 2-5% of overhead for virtualization.
Apple doesn't have to spend more money or time than they already do on supporting Windows, they just have to custom build their SoCs to handle virtualization properly and let Parallels/Fusion/Xen/Virtualbox handle that. In fact, Yosemite has a brand new lightweight Hypervisor framework to help with this.
Bootcamp would be eliminated. Apple could just route people to the virtualization packages instead.
Since Apple goes beyond what ARM provides, Apple can customize their SoC further to focus more on virtualization to ensure the performance is not that big of a hit. They probably won't do that but they have that power, something they don't have with Intel's CPUs.
You do understand that you're mixing up two different concepts, right? i think the other few users are too.
I am not talking about running both iOS and OS X apps on the same Mac, that's not going to happen. Nothing changes in terms of how iOS and OS X "feel" on each platform.
What I am talking about is the ability for developers to create a single app that runs on both OS X and iOS (likely AppleWatch as well). The backend code remains the same for both OS X and iOS, the only thing the developers have to do is create interfaces for each platform such as OS X, iOS, and iOS. They don't have to worry about how data are created for each platform, they just focus on interfaces instead.
For an example, loading your tweets from Twitter is the same code for all three platforms but the interface to show them is different for each platform. You write the backend code for the Twitter stuff and it runs the same way for all platforms. You then write the keyboard/mouse based interface for when it is on OS X, switches to the iOS interface when it is on iOS, and so on for AppleWatch without changing a single thing to the backend code.
What you are describing we already have at least in the sense that back end code is shared.
If you think however that ios and OS x SDK will be merged at the Appkit/UIKit level I think you don't understand the challenges involved or are not articulating what you understand very well.
ARMv8 has support for enabling virtualization extensions that speeds up the translations code, it will be much faster than emulation like Rosetta. It's already been coded in the latest Xen version and they're saying they can get it within 2-5% of overhead for virtualization.
Apple doesn't have to spend more money or time than they already do on supporting Windows, they just have to custom build their SoCs to handle virtualization properly and let Parallels/Fusion/Xen/Virtualbox handle that. In fact, Yosemite has a brand new lightweight Hypervisor framework to help with this.
Bootcamp would be eliminated. Apple could just route people to the virtualization packages instead.
Since Apple goes beyond what ARM provides, Apple can customize their SoC further to focus more on virtualization to ensure the performance is not that big of a hit. They probably won't do that but they have that power, something they don't have with Intel's CPUs.
How does ARM virtualize — not emulate — x86 and x86_64?
I don't see why Apple couldn't do that, but wouldn't using PPC or ARM still make it much slower emulation, not virtualization?
Maybe I worded it wrong. Or maybe I'm reading this wrong.
QEMU is a hardware virtualizer straight up. I don't believe QEMU has an ARM port(but it does support ARM virtualization, though Apple might need to update this to ARMv8), but Apple can probably take care of that. Most commonly I saw people using Qemu on their PC's to play around with OS 9 using the PPC virtualizer.
Xen I think is more of an advanced emulator Hypervisor, but Xen does have an ARM port(again, needs to be updated I think) and does have support for Windows(though OSX will need to be added as far as I'm aware).
What I meant to say was that Apple has little reason to write a theoretical X86 virtualizer from scratch when there are 2 already written for them(minus swift translations), and the latter of which is used extensively in enterprise environments. Both mentioned pieces of software also have support for each other.
Actually Intel has more or less lost its massive two year lead over the rest of the industry.
Apple does not own any fabs. Intel does. Not even AMD or nVidia can produce better GPU's until TSMC or Global Foundries move to a fabrication process after Intel does. There's no more tick-tock's left in the Intel cycle. No more die shrinks can be done without either becoming uneconomical.
You make statements with authority here you simply can't make. Intel in fact does have plans for more process shrinks. Further technologies are coming that may allow much faster chips to aid in increasing performance as process shrinks slow. The industry isn't at a dead end.
Beyond that both AMD and NVidia have been improving their hardware designs independent of process shrinks. AMD actually shifted the architecture of its chips significantly a couple of years ago. So yeah better GPUs are being made even if a process shrink doesn't come along for the ride.
As for licencing the x86-64 ISA. I'm sure that would be a mess, and Apple would have nothing to gain by doing so.
This I agree with totally. I86 compatibility just isn't a big deal anymore. If it was apple IOS devices and all those Android devices would be a complete failure.
That said, it's not a clock-for-clock game, we've played that game already with AMD and Intel (and when VIA/Cyrix used to produce x86 parts.) The fact is, x86-clones were never clock-for-clock at parity, and were often much cheaper but substantially less stable and much weaker. Most of the early x86 clones during the 486/586 era pulled the "weak x87 FPU" trick because most software of the day didn't do FPU stuff much at all (FPU stuff didn't become important until 3D accelerators.) AMD even today is pulling the "weak x87" trick back from the book. We're not getting fooled again.
I don't think you know what you are talking about here. It is AMD,with their 64 but extensions and high performance chips that lite a fire under Intel and got them to get serious about performance. As for AMDs so called weak FPU they aren't that bad and if you had a clue about their intentions for the GPU you would understand why it isn't even important.
The best option for Apple, is that at some point in the future, they could make a ECC-capable server/workstation grade ARM processor with the same TDP as an Xeon using more cores. This unfortunately will only benefit highly parallelizeable code, which is basically nothing but video compression.
Why is a server chip a best option when Apple doesn't give a crap about servers?
No games know how to use more than a single core, and what passes for multi-core rendering in OpenGL is really just parallelizing certain workloads (Eg linear file decompression (eg zip, png)) that the GPU isn't great at (the GPU is better JPEG-style video and image decompression.) So we may see a return of the "Mac OS X server" as an ARM system first for render-farms before we see it make it's way into any desktop.
Whoa there, you seriously think Apple will return to the server market?
"Good enough" is never good enough when it comes to a computer.
Yep I agree with this 100% and is one reason I see little hope for the rumored MBA replacement. It just boggles the mind that people argue that the MBA is good enough, or any computer is for that matter.
Manufacturers out there, including Apple, put weak parts in their systems and sell them as "new" when the performance is actually worse than anything released in the last 7 years (See also "Netbooks") When the iPhone came out, it wasn't good enough, but it was finally the convergence of two things people actually hated carrying around as separate items.
When iPhone came out it was as good as the technology of the day allowed. That is far different than releasing something that is good enough. The fact is iPhone was good enough to upset an entire industry.
The next version adds a camera... and every iteration after that removed one extra thing that people hated carrying around with them. The Phablet trend is kind that trend tripping over itself and trying to also be an eBook reader, when the NFC Apple Pay was really the feature people wanted. But I don't see an iPhone replacing a desktop, ever. It's a moving target.
For some users IOS devices have in fact replaced desktops and laptops. Not every user needs or wants a desktop, the move away from desktops started with laptops, IOS devices just take things a step further.
The A series parts can't catch up to Intel until Intel stops moving. That's why Apple switched from PPC in the first place, PPC stopped moving.
The A series has in fact caught up with similar Intel hardware already. It is certainly a better platform than the Atom solution from Intel. You may think that there is a huge uncles eagle gap between the A series's and Intels mainstream chips but that isn't what Apple designed the current A series to do. Apple could easily put in the effort to deliver an ARM based chip hat is credible competition for Intels mainstream laptop chips.
The big question is there an overwhelming technical or strategic reason for them to do so? That is a very difficult question to answer.
Actually Intel has more or less lost its massive two year lead over the rest of the industry.
You make statements with authority here you simply can't make. Intel in fact does have plans for more process shrinks. Further technologies are coming that may allow much faster chips to aid in increasing performance as process shrinks slow. The industry isn't at a dead end.
...
The big question is there an overwhelming technical or strategic reason for them to do so? That is a very difficult question to answer.
Intel Pentium 4 3.73GHz released in Q4'04 (90nm 115 W) is the same performance as a Intel Core i3-4020Y @ 1.50GHz released Q3'13 (22 nm 11.5 W), the market is determined by it's weakest parts that OEM's are willing to buy. Now consider that the top-of-the-line part with the highest single-thread performance is Intel Core i7-4790K 4Ghz(22nm 88 W) is 3 times as powerful but consumes 8 times the amount of power.
So if you apply the scaling logic to the A8, it needs to be clocked 2.5-3 times higher(4Ghz to 4.5Ghz) to come close. But we don't know if it actually scales that way.
Comments
iOS is a subset of OS X. They share the same Darwin-based code base and share a lot of the fundamental framework, including the same file system. The differences are the front-end levels of the OS, where they have different framework such as Cocoa Touch for iOS and Cocoa for OS X among others.
iOS does have a file system, it is just not user-accessible. You can jailbreak and gain access to its file system via ssh, you can change root password, etc etc. You would be able to create folders, files, delete, etc etc like you can via Terminal on OS X. In fact, if you don't want to jailbreak your device right now, look at iFunBox or iExplorer to get some basic file system access to your device.
Also, considering you probably are not programmer, you can develop OS X and iOS apps with the same code base while "forking" the different interfaces for each platform. I know, I work for a company that does this.
You also missed the part about iCloud drive, where apps store their data files and can be accessed by OS X versions of the same app. iOS 8 now has Document Picker, that replicates a file system via iCloud Drive for apps. So, yes totally possible.
Yes, there's a big difference, they're not the same architecture. That's what I just said. You can build x86 version of iOS apps actually, it's done all the time via Xcode's iOS simulator which runs the x86 native code of iOS apps.
It does have everything to do with architecture. You can code the same way, a string is a string in the code. However, when you compile the code, it translates to different code for different architecture such as x86 and ARMv8, because they do not not process a string of "text" the same way. A code compiled for ARM can run on both iOS and OS X and Xcode when compiling the code will know the difference in interfaces that the developers ask for. So yes, you can run the same app on both Mac and iOS but you don't see the same app, it will behave differently to fit the screen they're for. Touchscreen on iOS and keyboard/mouse for OS X.
It is exactly how Windows 10 is going to do it. Microsoft demo'ed the entire process already at the last event they had. Same codebase, runs on all Windows devices. Note, this requires using the specific runtime, you can't use the old win32 runtime.
While all that is theoretically true, the mixture of OS X apps ( with access to the file system) and iOS apps (without that ability to save anywhere) as well as the differences between how the UI and UX would be a nightmare.
I can see two modes maybe: an extension of what we have already with the launchPad ( which looks like an iOS style layout). In there you could have a tab on top which shows either iOS or OS X apps. Launching an iOS app will show it as an iOS type app - taking up an iPad sized window in the screen with access to reading documents on the file system via UIDocumentPicker but saving in a sandbox ( which will be synced to the cloud).
This is effectively two distinct type of Apps and application modes although the iOS apps should also get mouse events ( which doesn't happen at the moment). Also they need to work out how to pinch zoom with a keyboard,( the simulator already has that in a geeky fashion.)
It would be clear with this kind of system that the iOS apps would be second class citizens. Nevertheless its possible and in fact is possible on either ARM or Intel chips.
Quote:
Have you seriously thought about how to run an iOS app on a Mac? Seriously considered where your files go in the file system, and all the little things that go with that?
Yep. Like the Xcode iOS emulator, running on a touchscreen Mac. Only this time, a fully formed Apple app in the way that Apple always does. Might be the 1st actual useful use of forced full screen mode.
Quote:
If you have then please enlighten us, in detail. Because I have and all I've seen is less-than-nice.
You know, like in a VM? Like we do with Windows on OS X already, all the time?
iTunes (or whatever replaces it) would install and control the virtual instance like it does for physical devices now. All the ways your mobile apps sync data to your desktop would work here too. Maybe some new ways as well.
See, that was easy. Would cost Apple next to nothing to create. Would cannibalize nothing. New halo effect. Adds hundreds of thousands of apps to OS X instantly. All the IBM effort - running on Macs too...
Quote:
But maybe I just didn't think hard enough.
You didn't... But then, you don't work for Apple.
If you think there would be no demand for this, don't buy it when it comes out. They would sell a buttload of these...
You know, like in a VM? Like we do with Windows on OS X already, all the time?
iTunes (or whatever replaces it) would install and control the virtual instance like it does for physical devices now. All the ways your mobile apps sync data to your desktop would work here too. Maybe some new ways as well.
See, that was easy. Would cost Apple next to nothing to create. Would cannibalize nothing. New halo effect. Adds hundreds of thousands of apps to OS X instantly. All the IBM effort - running on Macs too...
The simulator isn't an emulator and there would be no need for a VM, just a recompile.
Its possible that an app designed for the iPad 12" in landscape mode and the Air 12" would work in full screen. But the vast majority of iPad/iPhone apps won't scale to a full screen because there would just be too much space. Imagine a 27" iMac. The typical list view wouldn't work, right and left toolbar buttons would be too far apart. At least on any decent sized monitor. So my guess is that iOs apps on Os X ( which will probably happen but doesn't need an ARM chip) will max out at the 12" landscape mode. Games excepted.
However a UI designed for touch and a UI designed for mouse and trackpad are always going to have different interactions. Pinch to zoom needs to be replicated in a different way. Add to that the iOS app can't write to local filesystem outside it's sandbox and normal apps can and you have a definite recipe for confusion.
Maybe I was the first to introduce Swift to the discussion, but I'm prepared to take the fall.
My point is not that Swift is a magic solution to x86/ARM issues - it clearly is not. It's that the development of Swift has shown that Apple has the talent and the patience to develop all the pieces necessary for a seamless x86->ARM transition, like the PPC->x86 transition. I haven't looked at the tools for over a year, but Xcode can build for x86 (32/64) and ARM and there are packaging tools to build fat binaries. If there's any tweaking needed to do a nice package for a multi-ISA OS X than it's quite minor.
Years ago Apple licensed Rosetta from Transitive for the PPC-> x86 transition. Later on, the company was acquired and the new owners, it seems, did not want to relicense the technology. But - the new owner is IBM and Apple could probably do a deal now - if it has not already done so.
Back to the Swift argument - even if IBM declines again, Apple is now in the position where it could create its own Rosetta2 if it wished. Whether it does will depend upon resources and priorities but it's clear to me that Apple now has the talent to do it. That's why Swift is important.
I think you miss the point of what Swift is. Swift is intended as a replacement for C and its variants. As such, it works on both ARM and X86.
Metal, on the otherhand, is intended for developers to get closer to the hardware, similar to how a developer might program for a console.
After reading what you wrote a few times, are you trying to say that Swift is a way to show the world that Apple is capable of creating wonderful software and tools?
Yes - as I said at the start, Swift in itself is not part of any x86/ARM solution.
What the development of Swift shows is that Apple now has the talent to develop a Rosetta2. That wasn't possible ten or fifteen years ago. It is now.
But the main thing is that cheap Apple chip is a big stick to beat Intel into low prices.
Win Win
Yes - as I said at the start, Swift in itself is not part of any x86/ARM solution.
What the development of Swift shows is that Apple now has the talent to develop a Rosetta2. That wasn't possible ten or fifteen years ago. It is now.
Still not really getting it.
Why not just rewrite(in swift) or port an existing hypervisor like Xen or QEMU, the latter of which also has PPC and ARM(Granted not ARMv8 to my knoweldge, as far as up as v7) virtualization support alongside X86? Seems like NIH syndrome to me if you are not going to at least evaluate proven software first.
I don't see why Apple couldn't do that, but wouldn't using PPC or ARM still make it much slower emulation, not virtualization?
Anyway, I think the bigger question is why would Apple even want to spend time and money supporting Windows on ARM. I am not convinced that Bootcamp would have ever been created if there wasn't a grassroots solutions to make that happen when Apple moved to Intel.
I think it's clear that being able to run Windows on a Mac has helped convert a lot of people to the Mac, but I am not sure that is something they care about anymore. I'd think the iPad and iPhone are a big enough example of Apple's ability to make a great system, and the stats we hear from colleges seem to show an overwhelming number of students using Macs. Based on that info I'd say "**** Windows support" if I were running Apple… and I saw that as someone that is looking for a work notebook that runs Windows.
Here endeth the lesson.
Here endeth the lesson.
Not much of a lesson if history serves.
If it is a new product category, which it almost certainly will be at the outset, then Intel as a comparison fails. All that matters is how the device performs with the software that is available at release, especially MS Office and Apple's various products, and a few of the staples from Adobe and others.
Pretty much the same situation that the iPad faced, only I'd expect Apple to supply a smooth transition from OS X Intel to OS X ARM for developers, necessarily without x86 support.
Cost ways matters. You don't think Ape could build a better phone that would cost the consumer a lot more than their stable and carefully planned price points?
And how did you come to that baseless conclusion?
And why can't it be?
While all that is theoretically true, the mixture of OS X apps ( with access to the file system) and iOS apps (without that ability to save anywhere) as well as the differences between how the UI and UX would be a nightmare.
I can see two modes maybe: an extension of what we have already with the launchPad ( which looks like an iOS style layout). In there you could have a tab on top which shows either iOS or OS X apps. Launching an iOS app will show it as an iOS type app - taking up an iPad sized window in the screen with access to reading documents on the file system via UIDocumentPicker but saving in a sandbox ( which will be synced to the cloud).
This is effectively two distinct type of Apps and application modes although the iOS apps should also get mouse events ( which doesn't happen at the moment). Also they need to work out how to pinch zoom with a keyboard,( the simulator already has that in a geeky fashion.)
It would be clear with this kind of system that the iOS apps would be second class citizens. Nevertheless its possible and in fact is possible on either ARM or Intel chips.
You do understand that you're mixing up two different concepts, right? i think the other few users are too.
I am not talking about running both iOS and OS X apps on the same Mac, that's not going to happen. Nothing changes in terms of how iOS and OS X "feel" on each platform.
What I am talking about is the ability for developers to create a single app that runs on both OS X and iOS (likely AppleWatch as well). The backend code remains the same for both OS X and iOS, the only thing the developers have to do is create interfaces for each platform such as OS X, iOS, and iOS. They don't have to worry about how data are created for each platform, they just focus on interfaces instead.
For an example, loading your tweets from Twitter is the same code for all three platforms but the interface to show them is different for each platform. You write the backend code for the Twitter stuff and it runs the same way for all platforms. You then write the keyboard/mouse based interface for when it is on OS X, switches to the iOS interface when it is on iOS, and so on for AppleWatch without changing a single thing to the backend code.
Another example, TweetBot. The developer only has to create Tweetbot once and it runs on all Apple platforms. There is no need to have Tweetbot for iPhone, for iPad, and for OS X separately. Same shared code plus custom interfaces for each platform, one app for all.
There are so many awesome apps that are created for iOS that could be useful on OS X but you hear stories that developers don't have time to fork their apps for OS X. Imagine Apple and Xcode making it extremely easy to do this. Now, Apple has a bigger halo effect of having more productive and innovative OS X apps because it is simpler to create them at the same time with the OS X app.
I don't see why Apple couldn't do that, but wouldn't using PPC or ARM still make it much slower emulation, not virtualization?
Anyway, I think the bigger question is why would Apple even want to spend time and money supporting Windows on ARM. I am not convinced that Bootcamp would have ever been created if there wasn't a grassroots solutions to make that happen when Apple moved to Intel.
I think it's clear that being able to run Windows on a Mac has helped convert a lot of people to the Mac, but I am not sure that is something they care about anymore. I'd think the iPad and iPhone are a big enough example of Apple's ability to make a great system, and the stats we hear from colleges seem to show an overwhelming number of students using Macs. Based on that info I'd say "**** Windows support" if I were running Apple… and I saw that as someone that is looking for a work notebook that runs Windows.
ARMv8 has support for enabling virtualization extensions that speeds up the translations code, it will be much faster than emulation like Rosetta. It's already been coded in the latest Xen version and they're saying they can get it within 2-5% of overhead for virtualization.
Apple doesn't have to spend more money or time than they already do on supporting Windows, they just have to custom build their SoCs to handle virtualization properly and let Parallels/Fusion/Xen/Virtualbox handle that. In fact, Yosemite has a brand new lightweight Hypervisor framework to help with this.
Bootcamp would be eliminated. Apple could just route people to the virtualization packages instead.
Since Apple goes beyond what ARM provides, Apple can customize their SoC further to focus more on virtualization to ensure the performance is not that big of a hit. They probably won't do that but they have that power, something they don't have with Intel's CPUs.
What you are describing we already have at least in the sense that back end code is shared.
If you think however that ios and OS x SDK will be merged at the Appkit/UIKit level I think you don't understand the challenges involved or are not articulating what you understand very well.
How does ARM virtualize — not emulate — x86 and x86_64?
I don't see why Apple couldn't do that, but wouldn't using PPC or ARM still make it much slower emulation, not virtualization?
Maybe I worded it wrong. Or maybe I'm reading this wrong.
QEMU is a hardware virtualizer straight up. I don't believe QEMU has an ARM port(but it does support ARM virtualization, though Apple might need to update this to ARMv8), but Apple can probably take care of that. Most commonly I saw people using Qemu on their PC's to play around with OS 9 using the PPC virtualizer.
Xen I think is more of an advanced emulator Hypervisor, but Xen does have an ARM port(again, needs to be updated I think) and does have support for Windows(though OSX will need to be added as far as I'm aware).
What I meant to say was that Apple has little reason to write a theoretical X86 virtualizer from scratch when there are 2 already written for them(minus swift translations), and the latter of which is used extensively in enterprise environments. Both mentioned pieces of software also have support for each other.
Beyond that both AMD and NVidia have been improving their hardware designs independent of process shrinks. AMD actually shifted the architecture of its chips significantly a couple of years ago. So yeah better GPUs are being made even if a process shrink doesn't come along for the ride. This I agree with totally. I86 compatibility just isn't a big deal anymore. If it was apple IOS devices and all those Android devices would be a complete failure. I don't think you know what you are talking about here. It is AMD,with their 64 but extensions and high performance chips that lite a fire under Intel and got them to get serious about performance. As for AMDs so called weak FPU they aren't that bad and if you had a clue about their intentions for the GPU you would understand why it isn't even important. Why is a server chip a best option when Apple doesn't give a crap about servers? Whoa there, you seriously think Apple will return to the server market? Yep I agree with this 100% and is one reason I see little hope for the rumored MBA replacement. It just boggles the mind that people argue that the MBA is good enough, or any computer is for that matter. When iPhone came out it was as good as the technology of the day allowed. That is far different than releasing something that is good enough. The fact is iPhone was good enough to upset an entire industry. For some users IOS devices have in fact replaced desktops and laptops. Not every user needs or wants a desktop, the move away from desktops started with laptops, IOS devices just take things a step further. The A series has in fact caught up with similar Intel hardware already. It is certainly a better platform than the Atom solution from Intel. You may think that there is a huge uncles eagle gap between the A series's and Intels mainstream chips but that isn't what Apple designed the current A series to do. Apple could easily put in the effort to deliver an ARM based chip hat is credible competition for Intels mainstream laptop chips.
The big question is there an overwhelming technical or strategic reason for them to do so? That is a very difficult question to answer.
http://www.quora.com/Why-havent-CPU-clock-speeds-increased-in-the-last-5-years
Also
http://www.gamespot.com/articles/the-past-present-and-future-of-the-cpu-according-t/1100-6421514/
The point is that single-core performance has essentially been at a plateau for several years
http://www.cpubenchmark.net/singleThread.html
Intel Pentium 4 3.73GHz released in Q4'04 (90nm 115 W) is the same performance as a Intel Core i3-4020Y @ 1.50GHz released Q3'13 (22 nm 11.5 W), the market is determined by it's weakest parts that OEM's are willing to buy. Now consider that the top-of-the-line part with the highest single-thread performance is Intel Core i7-4790K 4Ghz(22nm 88 W) is 3 times as powerful but consumes 8 times the amount of power.
So if you apply the scaling logic to the A8, it needs to be clocked 2.5-3 times higher(4Ghz to 4.5Ghz) to come close. But we don't know if it actually scales that way.