Well, with over $140B in the bank, a zillion stores worldwide, people queuing up to buy their products, I would say Apple knows what they are doing. Even if I understood zippo about technology, I'd look at those telling stats, and have confidence this company is on top of it's game. So who's got $200B in the bank to tell me otherwise?
Actually, iOS root like OSX is coming from Nextstep developed on a 33mhz 68040 processor. While it debuted as a locked OS, they quickly open up the platform with iOS 2.
No one is questioning where iOS came from. I was merely pointing out that like Android, iOS was designed to fit in memory and cpu-constrained environments, and they did a better job of it by aggressively limiting multitasking, etc. Android has more of a traditional multitasking design, with various apps working together via inter-app communication (intents) to accomplish tasks, and ran poorly on lower-powered devices particularly in the early days of dalvik.
The iPhone 5S has a near workstation class CPU of a decade ago.
Can't say I completely agree. The definition of a workstation is not merely centered around the CPU. Graphics has a lot to with it too. So does the A7 have the computing and graphics performance of a workstation of a decade ago? Not quite, AFAIK.
Google doesn't need production hardware. Most low-level OS software development is done on dev boards. 64-bit ARMv8 dev boards have been available since last year.
Interesting that your 'evidence' is nothing more than wishful thinking.
As soon as there's some evidence that Google has 64 bit Android ready, let us know. Until then, Apple has a big head start.
Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.
Not always. I do know many Google and ARM engineers though. Android coped with the move to multi-core CPUs just fine and I don't doubt that it'll handle the move to 64-bit as well.
DED's analysis on Android's transition to 64-bit is completely devoid of evidence. He presents his opinion as fact. He has no insider knowledge and apparently no specialist understanding of modern operating system architecture.
I also love the way that he asserts that Android has no "console-style" games, despite the fact that severalconsoles are based on Android!
Most of his article is devoid of evidence. He's no engineer.
Quote:
Originally Posted by Chandra69
iOS, as a platform for webapps? Give me a break!
Another fact disappears down the memory hole.
Quote:
Originally Posted by auxio
Not really. If you read the backstory on the creation of the iPhone, Apple rushed it to market very quickly (burning out a few engineers in the process). So some things, like a 3rd party app development environment, had to be left out to make the deadline.
As someone who was involved with helping reverse-engineer a development environment for the first iPhone, I can definitively say that all of the native development frameworks were in place already (but only Apple could use them). I have no doubt that 3rd party application development was planned from the start, they just needed a bit more time to polish the development tools and document everything (not to mention create an app store).
Apple were using Objective C API ported from OS X on the iPhone ( in fact Jobs said "we put OS X on this thing" in the iPhone's debut). That doesn't mean that the company had intended to ever make those API open to external devs. As far asI recall reading it was Forstall who campaigned for that. Forstall was much more important than people realize. I don't particularly like the guy but he was important.
To be fair, iOS was also designed initially for low-memory low-powered devices like the original iPhone. Moreover, it debuted mainly as a platform for web apps, and only later were provisions for third-party apps added in.
The iPhone of 2007 did have a 1/40 the power of the new 5s, but it still shipped with "desktop class" email, browser, maps, and media apps,
As in, ObjC Cocoa Touch apps. Not initially supporting any real third party apps is not comparable to Android shipping as a rewarmed JavaME that didn't even get a real browser until years after the iPhone.
Android remained a hobbyist curiosity until late 2009, nearly 3 years after iPhone despite originating as a project years before iPhone was launched.
When did the terrible "Android Browser" finally get replaces with Chrome? 2011?
I also think that this article is terrible on the technical details. DED claims that would be too hard to do, fraught with compromises and ultimately not practical. What is fails to realize is that Oracle/Sun has been offering 32 and 64 bit versions of the Java JVM for years now. Recently I had a customer who was having serious problems running their enterprise middleware software stack. The recommendation was to change from the 64 bit JVM from the 32 bit one since they were running on the ragged edge of memory utilization. The change was successful with no changes necessary to the middleware Java code...and trust me, it's a lot more code than runs on a phone. Also, they ended up using the 64 bit version of a Java 5 JVM (not the latest Java 7). So this capability has been around for YEARS.
The article started well laying down the groundwork between the processor differences. But it quickly veered into the realm of BS in making the argument with the technical difficulty of making a 64 bit transition. I agree that Google has more work to do that Apple in this regard. But it's not impossible, nor is it a fool's errand. There will be advantages to Android making the switch, and I expect them to make it in 2014.
richl I think you are missing some of the points of the article. ARMV8 was never claimed to be a secret, it was intended to target low power server markets. It was not on any handset roadmap, especially with some rather public failures trying to embed the last arm server arch. Note both qualcomm (KRAIT) and A6 sidestepped that arch with their mobile offerings for a reason and were glad for it.
Apple owns its compiler technology, the frameworks, the developer IDE, the review process, and the storefront. Their iOS underpinnings and frameworks (cocoa) share 64-bit implementations with OS X. This made their decision easier to swallow, and given the large developer community that make almost 75% of the entire mobile SW sales, they have the incentive to get the devs moving.
Actually, iOS root like OSX is coming from Nextstep developed on a 33mhz 68040 processor.
Is that really true?
I realize common lore says Apple acquired NeXT and subsumed NeXTSTEP into Mac OS X. But it's more nuanced than that. Someone here, I believe, worked at NeXT and therefore could correct me.
Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.
The answer is "very easy". Java byte code is platform (64/32 bit) agnostic. A 32 bit app will run perfectly fine on 64-bit Java with no compilation changes necessary. There is no ambiguity of int sizes in java, an int is always 32 bits. If you need/use 64 bit values in your java app you will specifically declare them and they will work on 32 or 64 bit jvm.
The majority of the work in moving to 64 bit Android is in the kernel/jvm and native interfaces. This is "mostly" already established work. 64 bit linux kernels have been around for a long time as have 64 bit java VM's.
"When iOS is executing on a 64-bit device, iOS includes separate 32-bit and 64-bit versions of the system frameworks. When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly," Apple explains.
"Because all of the built-in apps already support the 64-bit runtime, it is to everyone?s benefit that all apps running on 64-bit devices be compiled for the 64-bit runtime, especially apps that support background processing. Even apps that are not performance sensitive gain from this memory efficiency."
This really means that, to begin with, the memory footprint for shared libraries in shared memory will double, and will in fact do so until the user gets rid of all 32 bit apps on his machine. And the footprint on the flash drive is going to be larger as well as fat versions of the libraries will be there.
So the benefits?
Except for calculations of integers larger than the 4G limit, not much. Floating point calculations will have more precision, but not necessarily speed since the CPU is not optimized for floating point operations.
How is a sandbox a critical element for creating an app? It's only needed for security. Seriously, I (and many others -- Erica Sadun from TUAW for one) had tons of native apps on the original iPhone. They weren't signed or sandboxed (kinda like apps on jailbroken iPhones), but they worked just fine for learning the capabilities of the iPhone and how to develop apps for it.
How is a sandbox a critical element for creating an app? It's only needed for security. Seriously, I (and many others -- Erica Sadun from TUAW for one) had tons of native apps on the original iPhone. They weren't signed or sandboxed (kinda like apps on jailbroken iPhones), but they worked just fine for learning the capabilities of the iPhone and how to develop apps for it.
It's not critical for creating or running an app, but we were talking about whether the original iOS was intended to run third-party apps, not whether it was technically capable of doing so.
It looks to me that the long play (with A7) is an eventual convergence of iOS and MacOS...
Definitely. I definitely see a near-future MacBook Air using one of these A7s, or more likely the A7X. That will free Apple from Intel's ultra-portable processor pricing. I think a lot of people would be happy with a touchscreen MBA running "iOSX" on an A7X - effectively an iPad with Mac OS X abilities and apps in a more laptoppy formfactor.
But they haven't enabled building Mac OS X apps on ARM yet - which will be a major announcement - so it probably won't be this generation. So the A8X. Or the A9X. But it is coming, all signs point to it.
I realize common lore says Apple acquired NeXT and subsumed NeXTSTEP into Mac OS X. But it's more nuanced than that. Someone here, I believe, worked at NeXT and therefore could correct me.
It's pretty much true. NeXTSTEP is the grandfather of iOS (with OS X being the father). iOS, OS X and NeXTSTEP all use Obj-C as the primary programming language, had similar kernel structures, I/O and system calls.
Of course ARM (a corp co-founded by Apple and Acorn Computer) discuss a lots with their partner, since they doesn't sold any hardware, they only licences their hardware to anyone who want to mfg. Problem is Google doesn't do any ARM development internally, they got no production hardware to work on a 64 bit version of Android and Samsung and Qualcomm, 2 of the most prominent ARM SoC maker chooses the cores multiplication way, look at the Exynos 5 Octa non-sense.
If you think that a major ARM OS provider has no communication with ARM then I have a nice bridge to sell you.
ARMv8 emulators, simulators and FPGA implementations have been around for quite some time for software validation.
Samsung and Qualcomm don't only offer the Octa and the SD800 (which are their "X" chips).
The answer is "very easy". Java byte code is platform (64/32 bit) agnostic. A 32 bit app will run perfectly fine on 64-bit Java with no compilation changes necessary. There is no ambiguity of int sizes in java, an int is always 32 bits. If you need/use 64 bit values in your java app you will specifically declare them and they will work on 32 or 64 bit jvm.
The majority of the work in moving to 64 bit Android is in the kernel/jvm and native interfaces. This is "mostly" already established work. 64 bit linux kernels have been around for a long time as have 64 bit java VM's.
Meanwhile with Objective C's c legacy, an int vs long is a potential minefield. APple's tech note on this is fairly involved, although more for people using primitives in C rather than Obj C objects.
Apple were using Objective C API ported from OS X on the iPhone ( in fact Jobs said "we put OS X on this thing" in the iPhone's debut). That doesn't mean that the company had intended to ever make those API open to external devs. As far asI recall reading it was Forstall who campaigned for that. Forstall was much more important than people realize. I don't particularly like the guy but he was important.
Jobs was always like that from what I heard -- he had to be convinced of things outside of his scope of focus. He respected the top engineers, and so if the top engineers wanted something to happen, it would happen eventually. I'm certain the top engineers wanted 3rd party apps from the start, so it was all but an inevitability. Which is why a lot of us were prepping for it beforehand.
It's pretty much true. NeXTSTEP is the grandfather of iOS (with OS X being the father). iOS, OS X and NeXTSTEP all use Obj-C as the primary programming language, had similar kernel structures, I/O and system calls.
Applescript is what is left of OS 9. Since the Finder rewrite.
Comments
Well, with over $140B in the bank, a zillion stores worldwide, people queuing up to buy their products, I would say Apple knows what they are doing. Even if I understood zippo about technology, I'd look at those telling stats, and have confidence this company is on top of it's game. So who's got $200B in the bank to tell me otherwise?
Actually, iOS root like OSX is coming from Nextstep developed on a 33mhz 68040 processor. While it debuted as a locked OS, they quickly open up the platform with iOS 2.
No one is questioning where iOS came from. I was merely pointing out that like Android, iOS was designed to fit in memory and cpu-constrained environments, and they did a better job of it by aggressively limiting multitasking, etc. Android has more of a traditional multitasking design, with various apps working together via inter-app communication (intents) to accomplish tasks, and ran poorly on lower-powered devices particularly in the early days of dalvik.
The iPhone 5S has a near workstation class CPU of a decade ago.
Can't say I completely agree. The definition of a workstation is not merely centered around the CPU. Graphics has a lot to with it too. So does the A7 have the computing and graphics performance of a workstation of a decade ago? Not quite, AFAIK.
Interesting that your 'evidence' is nothing more than wishful thinking.
As soon as there's some evidence that Google has 64 bit Android ready, let us know. Until then, Apple has a big head start.
Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.
Not always. I do know many Google and ARM engineers though. Android coped with the move to multi-core CPUs just fine and I don't doubt that it'll handle the move to 64-bit as well.
I also love the way that he asserts that Android has no "console-style" games, despite the fact that several consoles are based on Android!
Most of his article is devoid of evidence. He's no engineer.
iOS, as a platform for webapps? Give me a break!
Another fact disappears down the memory hole.
Not really. If you read the backstory on the creation of the iPhone, Apple rushed it to market very quickly (burning out a few engineers in the process). So some things, like a 3rd party app development environment, had to be left out to make the deadline.
As someone who was involved with helping reverse-engineer a development environment for the first iPhone, I can definitively say that all of the native development frameworks were in place already (but only Apple could use them). I have no doubt that 3rd party application development was planned from the start, they just needed a bit more time to polish the development tools and document everything (not to mention create an app store).
Apple were using Objective C API ported from OS X on the iPhone ( in fact Jobs said "we put OS X on this thing" in the iPhone's debut). That doesn't mean that the company had intended to ever make those API open to external devs. As far asI recall reading it was Forstall who campaigned for that. Forstall was much more important than people realize. I don't particularly like the guy but he was important.
The iPhone of 2007 did have a 1/40 the power of the new 5s, but it still shipped with "desktop class" email, browser, maps, and media apps,
As in, ObjC Cocoa Touch apps. Not initially supporting any real third party apps is not comparable to Android shipping as a rewarmed JavaME that didn't even get a real browser until years after the iPhone.
Android remained a hobbyist curiosity until late 2009, nearly 3 years after iPhone despite originating as a project years before iPhone was launched.
When did the terrible "Android Browser" finally get replaces with Chrome? 2011?
2012, shipped with android 4.0
The article started well laying down the groundwork between the processor differences. But it quickly veered into the realm of BS in making the argument with the technical difficulty of making a 64 bit transition. I agree that Google has more work to do that Apple in this regard. But it's not impossible, nor is it a fool's errand. There will be advantages to Android making the switch, and I expect them to make it in 2014.
Apple owns its compiler technology, the frameworks, the developer IDE, the review process, and the storefront. Their iOS underpinnings and frameworks (cocoa) share 64-bit implementations with OS X. This made their decision easier to swallow, and given the large developer community that make almost 75% of the entire mobile SW sales, they have the incentive to get the devs moving.
Actually, iOS root like OSX is coming from Nextstep developed on a 33mhz 68040 processor.
Is that really true?
I realize common lore says Apple acquired NeXT and subsumed NeXTSTEP into Mac OS X. But it's more nuanced than that. Someone here, I believe, worked at NeXT and therefore could correct me.
Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.
The answer is "very easy". Java byte code is platform (64/32 bit) agnostic. A 32 bit app will run perfectly fine on 64-bit Java with no compilation changes necessary. There is no ambiguity of int sizes in java, an int is always 32 bits. If you need/use 64 bit values in your java app you will specifically declare them and they will work on 32 or 64 bit jvm.
The majority of the work in moving to 64 bit Android is in the kernel/jvm and native interfaces. This is "mostly" already established work. 64 bit linux kernels have been around for a long time as have 64 bit java VM's.
Take this from DED
"When iOS is executing on a 64-bit device, iOS includes separate 32-bit and 64-bit versions of the system frameworks. When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly," Apple explains.
"Because all of the built-in apps already support the 64-bit runtime, it is to everyone?s benefit that all apps running on 64-bit devices be compiled for the 64-bit runtime, especially apps that support background processing. Even apps that are not performance sensitive gain from this memory efficiency."
This really means that, to begin with, the memory footprint for shared libraries in shared memory will double, and will in fact do so until the user gets rid of all 32 bit apps on his machine. And the footprint on the flash drive is going to be larger as well as fat versions of the libraries will be there.
So the benefits?
Except for calculations of integers larger than the 4G limit, not much. Floating point calculations will have more precision, but not necessarily speed since the CPU is not optimized for floating point operations.
Interesting. Were critical elements like the sandbox already present in the original iOS? According to this site (
http://theiphonewiki.com/wiki/Sandbox) the sandbox debuted in iOS 2.0 along with the app store.
How is a sandbox a critical element for creating an app? It's only needed for security. Seriously, I (and many others -- Erica Sadun from TUAW for one) had tons of native apps on the original iPhone. They weren't signed or sandboxed (kinda like apps on jailbroken iPhones), but they worked just fine for learning the capabilities of the iPhone and how to develop apps for it.
How is a sandbox a critical element for creating an app? It's only needed for security. Seriously, I (and many others -- Erica Sadun from TUAW for one) had tons of native apps on the original iPhone. They weren't signed or sandboxed (kinda like apps on jailbroken iPhones), but they worked just fine for learning the capabilities of the iPhone and how to develop apps for it.
It's not critical for creating or running an app, but we were talking about whether the original iOS was intended to run third-party apps, not whether it was technically capable of doing so.
It looks to me that the long play (with A7) is an eventual convergence of iOS and MacOS...
Definitely. I definitely see a near-future MacBook Air using one of these A7s, or more likely the A7X. That will free Apple from Intel's ultra-portable processor pricing. I think a lot of people would be happy with a touchscreen MBA running "iOSX" on an A7X - effectively an iPad with Mac OS X abilities and apps in a more laptoppy formfactor.
Is that really true?
I realize common lore says Apple acquired NeXT and subsumed NeXTSTEP into Mac OS X. But it's more nuanced than that. Someone here, I believe, worked at NeXT and therefore could correct me.
It's pretty much true. NeXTSTEP is the grandfather of iOS (with OS X being the father). iOS, OS X and NeXTSTEP all use Obj-C as the primary programming language, had similar kernel structures, I/O and system calls.
Of course ARM (a corp co-founded by Apple and Acorn Computer) discuss a lots with their partner, since they doesn't sold any hardware, they only licences their hardware to anyone who want to mfg. Problem is Google doesn't do any ARM development internally, they got no production hardware to work on a 64 bit version of Android and Samsung and Qualcomm, 2 of the most prominent ARM SoC maker chooses the cores multiplication way, look at the Exynos 5 Octa non-sense.
If you think that a major ARM OS provider has no communication with ARM then I have a nice bridge to sell you.
ARMv8 emulators, simulators and FPGA implementations have been around for quite some time for software validation.
Samsung and Qualcomm don't only offer the Octa and the SD800 (which are their "X" chips).
The answer is "very easy". Java byte code is platform (64/32 bit) agnostic. A 32 bit app will run perfectly fine on 64-bit Java with no compilation changes necessary. There is no ambiguity of int sizes in java, an int is always 32 bits. If you need/use 64 bit values in your java app you will specifically declare them and they will work on 32 or 64 bit jvm.
The majority of the work in moving to 64 bit Android is in the kernel/jvm and native interfaces. This is "mostly" already established work. 64 bit linux kernels have been around for a long time as have 64 bit java VM's.
Meanwhile with Objective C's c legacy, an int vs long is a potential minefield. APple's tech note on this is fairly involved, although more for people using primitives in C rather than Obj C objects.
Apple were using Objective C API ported from OS X on the iPhone ( in fact Jobs said "we put OS X on this thing" in the iPhone's debut). That doesn't mean that the company had intended to ever make those API open to external devs. As far asI recall reading it was Forstall who campaigned for that. Forstall was much more important than people realize. I don't particularly like the guy but he was important.
Jobs was always like that from what I heard -- he had to be convinced of things outside of his scope of focus. He respected the top engineers, and so if the top engineers wanted something to happen, it would happen eventually. I'm certain the top engineers wanted 3rd party apps from the start, so it was all but an inevitability. Which is why a lot of us were prepping for it beforehand.
It's pretty much true. NeXTSTEP is the grandfather of iOS (with OS X being the father). iOS, OS X and NeXTSTEP all use Obj-C as the primary programming language, had similar kernel structures, I/O and system calls.
Applescript is what is left of OS 9. Since the Finder rewrite.