Domain: cocoachina.com
Stories and comments across the archive that link to cocoachina.com.
Comments · 5
-
Re:64-bit Proc != 64-bit OS
Following your links I don't see anything that says its a 64-bit OS, its all ambigious. A binary that runs on 32-bit and 64-bit devices may simply mean its able to use new registers.
OK, follow the link to this copy of Apple's 64-Bit Transition Guide for Cocoa Touch - nothing ambiguous about, for example:
Two Conventions: ILP32 and LP64
The 32-bit runtime uses a convention called ILP32, in which integers, long integers, and pointers are 32-bit quantities. The 64-bit runtime uses the LP64 convention; integers are 32-bit quantities, and long integers and pointers are 64-bit quantities. These conventions match the ABI for apps running on OS X (and similarly, the Cocoa Touch conventions match the data types used in Cocoa), making it easy to write interoperable code between the two operating systems. -
Re:64-bit BS
But that's not what the article said. It talked about using the "same codebase", meaning same source code, and thought it didn't state it explicitly, it sure sounded like he was implying same backend data-handling code, not UI.
To what are you referring when you speak of "the article"? There are several things linked in the posting. There's Adrian Kingsley-Hughes's ZDNet article, in which he says:
Unifying the iOS/OS X app codebase Apple openly acknowledges that moving iOS up to 64-bit brings iOS and OS X apps much closer. Take this line from Apple's 64-bit iOS 7 documentation:
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems.
This could be huge.
which does not seem to indicate anything about common backend data-handling code; that's not "unifying the iOS/OS X app codebase", it's "sharing part of the codebase between iOS and OS X, at least if it doesn't depend on a large address space or fast handling of 64-bit integers etc. (in which case 64-bitness isn't that relevant) or if you don't care whether the app runs on anything other than an iPhone 5S and maybe the upcoming iPad 5 and maybe maybe the iPad mini 2 if it's 64-bit", which is a lot less "huge" than "you can just recompile your app for x86 and it'll run on OS X".
And then there's the Apple document, also linked in the original post, which says
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X. Pointers and some common C types change from 32 bits to 64 bits. Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
which, with its explicit mentions of Cocoa and Cocoa Touch, makes it much clearer that you ain't going to "unify the iOS/OS X app codebase", you'll just continue to be able to share some code between iOS and OS X versions of your app.
-
Re:64-bit BS
Apple did not write the speculation in TFA.
So, you believe that this is something other than an Apple marketing press release. I don't.
What Apple said in their document was
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X. Pointers and some common C types change from 32 bits to 64 bits. Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
which explicitly speaks of both "Cocoa" and "Cocoa Touch", so there are limits to the extent of the "common code base" - it doesn't include UI code.
The stuff about "Unifying the iOS/OS X app codebase" is, however, just Mr. Kingsley-Hughes trying to score points by Yet Again bringing up the damn "iOS/OS X unification" meme up to show how Forward Thinking he is; perhaps developers might understand what "common code base" meant (having as much of the non-UI parts of the app as possible common between 32-bit iOS, 64-bit iOS, 32-bit OS X if they still care about it, and 64-bit OS X, with the UI built atop Cocoa on OS X and atop Cocoa Touch on iOS), but technology journalists might not.
Anything you read in the tech press immediately after an Apple product announcement is suspect, to me, since there is absolutely no original reporting in any of it.
But what about original bloviating, which is what we have in Mr. Kingsley-Hughes's column? That, unlike original reporting, doesn't require real work.
-
No, it doesn't "bring iOS and OS X closer"
The architecture for 64-bit apps on iOS will be almost identical to the architecture for OS X apps
Well, if you read the full quote from the Apple document in question, it says:
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X.
That sounds more like "we 64-bitified iOS in a fashion almost identical to the way we 64-bitified OS X", not "64-bit iOS and 64-bit OS X are closer to each other than are 32-bit iOS and 32-bit OS X". You still have to go from Cocoa to Cocoa Touch....
-
Re:Moronic
He doesn't understand. Here's a picture and bio of the guy who wrote the article. He's mainly focused on hardware, as in books about assembling PCs from parts, so it looks like his career path was PC-repair-guy-to-author. He's obviously never written any substantial cross-platform software. He was looking through new iPhone documentation (which is right here), and he saw a line that mentions it's easy to write code that is shared on iOS and OSX. He thought that was something new, he didn't realize that it's already easy, and has nothing to do with 64bit.