Not a troll-question - I honestly don't know. Does AMD have an x86 license from Intel, or did they reverse-engineer it ? My recollection is that they did the latter but I don't know for sure. Does anyone have a definitive answer ?
A MacBook ARM could be the new Microsoft Surface RT, wasting potentially hundreds of millions of dollars that could be better spent on sapphire iPhone displays.
Nope. Not possible. Those hundreds of millions of dollars already went under the bridge.
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?
If you have then please enlighten us, in detail. Because I have and all I've seen is less-than-nice. But maybe I just didn't think hard enough.
How does MS intend on accomplishing that with Windows 10 & Windows Universal Apps? You basically buy the app once and it will run on all x86 and ARM-based Windows 10 devices.
Apple wrote XCode to handle the switch from PPC to Intel. Now we have Swift. Apple didn't spend 3 years writing a new programming language for the hell of it.
Most of the dimwits can't see that, Swift and Metal are there for Apple's long range plans and one of those plans involves moving on from Intel. Microsoft, Google and Intel will be shit out of luck.
I don't know much about hardware. However Apples GCD is a very easy way for devs to leverage easy multi threading. In fact a function or method can call what looks like a local "block" of code on a seperate thread (the creation of which is abstracted away) and then call back to the main thread (for UI purposes) within the local scope.
This is a common pattern and most iOS and Mac apps use it religiously leading to a fairly common multi threaded model. (The GCD api generally decides what threads to use or reuse unless you specify a thread by a unique name). And of course lower level API use this fairly commonly . On a fairly conservative Mac app it's common to see 5-10 threads.
Well it was one guy for 2 years. I don't see much advantages to swift on Intel vs ARM or vice versa.
One super talented programer is worth at least 1000 average programers.
The problem with the x86 hardware market is that it is essentially profitless for most of the OEM's while Intel maintains its high margins by metering out its releases. This isn't acceptable to Apple, which is eager to push for more customization than Intel is willing to allow, and at a development pace that would leave the OEM's in the dust.
What is Apple to do other than abandon Intel where it can in its Mac product line and/or add ARM in new products, and deprecate x86 over some period of time, divorcing itself from x86 and Intel?
Apple will leave Intel like it left Motorola and IBM, Apple wants to move on to a higher level and Intel is holding them back.
Most of the dimwits can't see that, Swift and Metal are there for Apple's long range plans and one of those plans involves moving on from Intel. Microsoft, Google and Intel will be shit out of luck.
Why do people keep bringing up Swift in this? Swift has nothing whatsoever to do with processor architectures. It's a programming language. It has nothing more to do with Intel vs. ARM than what font Apple uses for the menu bar.
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?
If you have then please enlighten us, in detail. Because I have and all I've seen is less-than-nice. But maybe I just didn't think hard enough.
How does MS intend on accomplishing that with Windows 10 & Windows Universal Apps? You basically buy the app once and it will run on all x86 and ARM-based Windows 10 devices.
I am not sure how MS plans to run all apps on both x86 and ARM, unless they have fat-binaries. Which they can readily do for MS apps, but you mentioned all apps. That sounds like a Rosetta-style emulation if it indeed means all.
My point was different. I am not so concerned with x86/ARM differences, but with iOS/OS X ones. Apple can readily bridge the x86/ARM divide as I described in a recent post. Work on fat binaries, work with developers for "major" apps, stay with a "very mainstream" workflow requiring few other apps, and create Rosetta2 if necessary. Start low, build up.
The iOS/OS X differences are very different. There are obvious things such as touch and pointing devices (mouse/trackpad) but most of these can be readily mapped between mouse/trackpad/touchscreen. The problem that no-one has addressed is the one with the how users interact with the file system. In OS X your files are stored in your home directory, typically in "Documents". Coming from an older-school Unix background, my habit is different, but they're still within home. And I can choose a file and then decide on an app that I want to process it. In iOS none of these things are possible. Files are stored within the app's directory, which on OS X is certainly "bad practice" and often not permitted (apps are in /Applications which is not world-writable). And, of course, on iOS there IS no "home" directory. It's a single-user paradigm. There is zero chance that iOS and OS X apps will be "merged" or "common" unless and until iOS becomes multi-user capable. And we aren't there yet.
Why do people keep bringing up Swift in this? Swift has nothing whatsoever to do with processor architectures. It's a programming language. It has nothing more to do with Intel vs. ARM than what font Apple uses for the menu bar.
It has everything to do with Apple's future with the watch (new cpu to be announced and it ain't Intel inside), iPads, and Mac's, the acquisitions of Pa-Semi, Intrinsity, Anobit, Passif Semiconductor, along with the intro of Swift and Metal means Apple is moving far beyond their competition and Intel won't be on board for much longer.
Why do people keep bringing up Swift in this? Swift has nothing whatsoever to do with processor architectures. It's a programming language. It has nothing more to do with Intel vs. ARM than what font Apple uses for the menu bar.
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.
Twenty, maybe. A thousand? You should be selling real estate.
One great Programer-Mathematician with insight (a great idea) is easily worth a 1000 average programer's and the same can be said of a great game changing CEO, the real purpose of Swift and Metal will become more obvious after the Apple smartwatch is introduced.
I am not sure how MS plans to run all apps on both x86 and ARM, unless they have fat-binaries. Which they can readily do for MS apps, but you mentioned all apps. That sounds like a Rosetta-style emulation if it indeed means all.
My point was different. I am not so concerned with x86/ARM differences, but with iOS/OS X ones. Apple can readily bridge the x86/ARM divide as I described in a recent post. Work on fat binaries, work with developers for "major" apps, stay with a "very mainstream" workflow requiring few other apps, and create Rosetta2 if necessary. Start low, build up.
The iOS/OS X differences are very different. There are obvious things such as touch and pointing devices (mouse/trackpad) but most of these can be readily mapped between mouse/trackpad/touchscreen. The problem that no-one has addressed is the one with the how users interact with the file system. In OS X your files are stored in your home directory, typically in "Documents". Coming from an older-school Unix background, my habit is different, but they're still within home. And I can choose a file and then decide on an app that I want to process it. In iOS none of these things are possible. Files are stored within the app's directory, which on OS X is certainly "bad practice" and often not permitted (apps are in /Applications which is not world-writable). And, of course, on iOS there IS no "home" directory. It's a single-user paradigm. There is zero chance that iOS and OS X apps will be "merged" or "common" unless and until iOS becomes multi-user capable. And we aren't there yet.
Sorry, I meant all apps that will be sold through the MS App Store (ie: Modern UI apps)
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?
It has everything to do with Apple's future with the watch (new cpu to be announced and it ain't Intel inside), iPads, and Mac's
Mac's what?
the acquisitions of Pa-Semi, Intrinsity, Anobit, Passif Semiconductor, along with the intro of Swift and Metal means Apple is moving far beyond their competition and Intel won't be on board for much longer.
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.
Swift is not a "piece necessary for a seamless x86->ARM 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.
Xcode has been able to build for both x86 and ARM since 2007, and it's been able to build fat binaries since 2005 (Apple themselves have been making fat binaries since the 680x0->PPC transition in 1994). None of this has anything to do with Swift. Yes, Swift can be compiled for both x86 and ARM. Also, Objective-C can be compiled for x86 and ARM. So can C. So can C++. So could Pascal, if anyone were still using it. So can Java and C# — actually, these two languages both run on a VM of sorts, so you actually can compile it once and run it on any supported processor architecture, as opposed to C and friends which have to be compiled separately for each processor. If Swift were like this, you'd have a point. But it isn't. Swift is basically Objective-C with the dynamic features removed, some type safety features added, and a more C-like syntax.
The only language in any kind of widespread use that can't run on both x86 and ARM is assembler.
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.
Swift certainly has nothing to do with Rosetta or similar technologies, other than the fact that an emulator could conceivably be written in it, just like any other app could, although in practice something as performance-sensitive as an emulator would almost certainly have the important bits written in C or assembler, not a higher-level language.
One great Programer-Mathematician with insight (a great idea) is easily worth a 1000 average programer's and the same can be said of a great game changing CEO, the real purpose of Swift and Metal will become more obvious after the Apple smartwatch is introduced.
1000 is way too much. And as has been pointed out swift adds nothing to portability.
Can people stop opining on what they don't understand.
Repeat after me: iOS is NOT OS X, OS X is NOT iOS, iOS is NOT OS X, OS X is NOT iOS
Get it ??? There is NO way that an iOS/OS X combo app makes sense. The user interface to the file system is totally different and that's where this "compatibility" breaks down. Files in iOS are stored in the app's folder, and in OS X they're elsewhere.
And in OS X a user can run an app and open a file anywhere (within reason). Not possible in iOS.
I understand both OS X and iOS and their differences. And I want them to stay different - there are very good reasons for them to be that way.
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.
Quote:
Originally Posted by plovell
There is a BIG difference between OS X apps and iOS apps. And it has NOTHING to do with ISAs
This makes zero sense. And, no, this is not what Windows is doing.
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.
MikhailT - thank you for your long post on page 2 where you rebut the naysayers.
I can't remember the exact multiple but Apple is ramping up performance of the Ax chips very quickly, especially in the area of graphics. 50x or 84x or whatever, the curve is aggressive.
It wouldn't surprise me to see a breakthrough from Apple in the area of processor design, enough to warrant a switch. We'd enjoy supposedly less expensive hardware. Apple would no longer be tethered to Intel and their production delays. Apple could tweak the design for specific applications. In addition, yet another barrier for competitors would be erected.
This is the direction Apple wants to go. Intel will keep innovating but I'm guessing Apple will out-innovate and soon the performance gap will be close enough to make the move. Plus I really want to run WWF while I work.
Price? Intel charges hundreds of dollars for their processors. Imagine how much cheaper ARM Macs would be?
We already saw the result of Apple depending on Intel for processors - they couldn't launch new iMacs last year, screwing up their whole release schedule which I'm sure Apple lost millions of $$.
Additionally, we don't know that Apple is even going to use the same ARM chips in Macs as they do iOS devices. They might be designing a whole new desktop chip.
You're greatly missing the point.
NOBODY moves to a die shrink until Intel does. 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.
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.
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.
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. 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.
"Good enough" is never good enough when it comes to a computer. 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. 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. 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.
Comments
Not a troll-question - I honestly don't know. Does AMD have an x86 license from Intel, or did they reverse-engineer it ? My recollection is that they did the latter but I don't know for sure. Does anyone have a definitive answer ?
This from 2009
http://beta.slashdot.org/story/09/03/16/1839231/intel-threatens-to-revoke-amds-x86-license
Thanks for the info.
A MacBook ARM could be the new Microsoft Surface RT, wasting potentially hundreds of millions of dollars that could be better spent on sapphire iPhone displays.
Nope. Not possible. Those hundreds of millions of dollars already went under the bridge.
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?
If you have then please enlighten us, in detail. Because I have and all I've seen is less-than-nice. But maybe I just didn't think hard enough.
How does MS intend on accomplishing that with Windows 10 & Windows Universal Apps? You basically buy the app once and it will run on all x86 and ARM-based Windows 10 devices.
Apple wrote XCode to handle the switch from PPC to Intel. Now we have Swift. Apple didn't spend 3 years writing a new programming language for the hell of it.
Most of the dimwits can't see that, Swift and Metal are there for Apple's long range plans and one of those plans involves moving on from Intel. Microsoft, Google and Intel will be shit out of luck.
I don't know much about hardware. However Apples GCD is a very easy way for devs to leverage easy multi threading. In fact a function or method can call what looks like a local "block" of code on a seperate thread (the creation of which is abstracted away) and then call back to the main thread (for UI purposes) within the local scope.
This is a common pattern and most iOS and Mac apps use it religiously leading to a fairly common multi threaded model. (The GCD api generally decides what threads to use or reuse unless you specify a thread by a unique name). And of course lower level API use this fairly commonly . On a fairly conservative Mac app it's common to see 5-10 threads.
Well it was one guy for 2 years. I don't see much advantages to swift on Intel vs ARM or vice versa.
One super talented programer is worth at least 1000 average programers.
The problem with the x86 hardware market is that it is essentially profitless for most of the OEM's while Intel maintains its high margins by metering out its releases. This isn't acceptable to Apple, which is eager to push for more customization than Intel is willing to allow, and at a development pace that would leave the OEM's in the dust.
What is Apple to do other than abandon Intel where it can in its Mac product line and/or add ARM in new products, and deprecate x86 over some period of time, divorcing itself from x86 and Intel?
Apple will leave Intel like it left Motorola and IBM, Apple wants to move on to a higher level and Intel is holding them back.
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?
If you have then please enlighten us, in detail. Because I have and all I've seen is less-than-nice. But maybe I just didn't think hard enough.
How does MS intend on accomplishing that with Windows 10 & Windows Universal Apps? You basically buy the app once and it will run on all x86 and ARM-based Windows 10 devices.
I am not sure how MS plans to run all apps on both x86 and ARM, unless they have fat-binaries. Which they can readily do for MS apps, but you mentioned all apps. That sounds like a Rosetta-style emulation if it indeed means all.
My point was different. I am not so concerned with x86/ARM differences, but with iOS/OS X ones. Apple can readily bridge the x86/ARM divide as I described in a recent post. Work on fat binaries, work with developers for "major" apps, stay with a "very mainstream" workflow requiring few other apps, and create Rosetta2 if necessary. Start low, build up.
The iOS/OS X differences are very different. There are obvious things such as touch and pointing devices (mouse/trackpad) but most of these can be readily mapped between mouse/trackpad/touchscreen. The problem that no-one has addressed is the one with the how users interact with the file system. In OS X your files are stored in your home directory, typically in "Documents". Coming from an older-school Unix background, my habit is different, but they're still within home. And I can choose a file and then decide on an app that I want to process it. In iOS none of these things are possible. Files are stored within the app's directory, which on OS X is certainly "bad practice" and often not permitted (apps are in /Applications which is not world-writable). And, of course, on iOS there IS no "home" directory. It's a single-user paradigm. There is zero chance that iOS and OS X apps will be "merged" or "common" unless and until iOS becomes multi-user capable. And we aren't there yet.
One super talented programer is worth at least 1000 average programers.
Twenty, maybe. A thousand? You should be selling real estate.
Why do people keep bringing up Swift in this? Swift has nothing whatsoever to do with processor architectures. It's a programming language. It has nothing more to do with Intel vs. ARM than what font Apple uses for the menu bar.
It has everything to do with Apple's future with the watch (new cpu to be announced and it ain't Intel inside), iPads, and Mac's, the acquisitions of Pa-Semi, Intrinsity, Anobit, Passif Semiconductor, along with the intro of Swift and Metal means Apple is moving far beyond their competition and Intel won't be on board for much longer.
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.
Twenty, maybe. A thousand? You should be selling real estate.
One great Programer-Mathematician with insight (a great idea) is easily worth a 1000 average programer's and the same can be said of a great game changing CEO, the real purpose of Swift and Metal will become more obvious after the Apple smartwatch is introduced.
I am not sure how MS plans to run all apps on both x86 and ARM, unless they have fat-binaries. Which they can readily do for MS apps, but you mentioned all apps. That sounds like a Rosetta-style emulation if it indeed means all.
My point was different. I am not so concerned with x86/ARM differences, but with iOS/OS X ones. Apple can readily bridge the x86/ARM divide as I described in a recent post. Work on fat binaries, work with developers for "major" apps, stay with a "very mainstream" workflow requiring few other apps, and create Rosetta2 if necessary. Start low, build up.
The iOS/OS X differences are very different. There are obvious things such as touch and pointing devices (mouse/trackpad) but most of these can be readily mapped between mouse/trackpad/touchscreen. The problem that no-one has addressed is the one with the how users interact with the file system. In OS X your files are stored in your home directory, typically in "Documents". Coming from an older-school Unix background, my habit is different, but they're still within home. And I can choose a file and then decide on an app that I want to process it. In iOS none of these things are possible. Files are stored within the app's directory, which on OS X is certainly "bad practice" and often not permitted (apps are in /Applications which is not world-writable). And, of course, on iOS there IS no "home" directory. It's a single-user paradigm. There is zero chance that iOS and OS X apps will be "merged" or "common" unless and until iOS becomes multi-user capable. And we aren't there yet.
Sorry, I meant all apps that will be sold through the MS App Store (ie: Modern UI apps)
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?
Swift has nothing to do with any of that.
Swift is not a "piece necessary for a seamless x86->ARM transition." Xcode has been able to build for both x86 and ARM since 2007, and it's been able to build fat binaries since 2005 (Apple themselves have been making fat binaries since the 680x0->PPC transition in 1994). None of this has anything to do with Swift. Yes, Swift can be compiled for both x86 and ARM. Also, Objective-C can be compiled for x86 and ARM. So can C. So can C++. So could Pascal, if anyone were still using it. So can Java and C# — actually, these two languages both run on a VM of sorts, so you actually can compile it once and run it on any supported processor architecture, as opposed to C and friends which have to be compiled separately for each processor. If Swift were like this, you'd have a point. But it isn't. Swift is basically Objective-C with the dynamic features removed, some type safety features added, and a more C-like syntax.
The only language in any kind of widespread use that can't run on both x86 and ARM is assembler. Swift certainly has nothing to do with Rosetta or similar technologies, other than the fact that an emulator could conceivably be written in it, just like any other app could, although in practice something as performance-sensitive as an emulator would almost certainly have the important bits written in C or assembler, not a higher-level language.
Meaningless response.
1000 is way too much. And as has been pointed out swift adds nothing to portability.
Can people stop opining on what they don't understand.
Repeat after me: iOS is NOT OS X, OS X is NOT iOS, iOS is NOT OS X, OS X is NOT iOS
Get it ??? There is NO way that an iOS/OS X combo app makes sense. The user interface to the file system is totally different and that's where this "compatibility" breaks down. Files in iOS are stored in the app's folder, and in OS X they're elsewhere.
And in OS X a user can run an app and open a file anywhere (within reason). Not possible in iOS.
I understand both OS X and iOS and their differences. And I want them to stay different - there are very good reasons for them to be that way.
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.
There is a BIG difference between OS X apps and iOS apps. And it has NOTHING to do with ISAs
This makes zero sense. And, no, this is not what Windows is doing.
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.
MikhailT - thank you for your long post on page 2 where you rebut the naysayers.
I can't remember the exact multiple but Apple is ramping up performance of the Ax chips very quickly, especially in the area of graphics. 50x or 84x or whatever, the curve is aggressive.
It wouldn't surprise me to see a breakthrough from Apple in the area of processor design, enough to warrant a switch. We'd enjoy supposedly less expensive hardware. Apple would no longer be tethered to Intel and their production delays. Apple could tweak the design for specific applications. In addition, yet another barrier for competitors would be erected.
This is the direction Apple wants to go. Intel will keep innovating but I'm guessing Apple will out-innovate and soon the performance gap will be close enough to make the move. Plus I really want to run WWF while I work.
You're greatly missing the point.
NOBODY moves to a die shrink until Intel does. 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.
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.
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.
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. 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.
"Good enough" is never good enough when it comes to a computer. 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. 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. 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.