Want to develop an iPhone app? Here's a section of the updated iPhone Developer License Agreement that has gained instant infamy:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
I _want_ to be an Apple fanboy. But Apple makes it hard for me when they pull stunts like this. Apple is dictating what computer languages you can use to develop an iPhone App. You can't code in your favourite language unless that language is Objective-C, C, C++, or JavaScript. You can't write in another language, even if you use an automated tool to convert your code into one of Apple's happy languages. Dear Apple, I - and hundreds of other developers - are not happy.
Posts
6 comments:
I love my iphone 3gs, ipod touch 2nd gen, shuffle, mac book pro, and mac pro. But today, I HATE APPLE. And I haven't released or even worked on an app for the iphone, etc.
I like John Gruber's take on this: http://daringfireball.net/2010/04/why_apple_changed_section_331
I think Apple do this to have good applications for the iPhone, if u want an application for iPhone or other system, WORK!.
Will u like a conversor to windows for PokerCopilot?
Hi Steve, check this out, they say it's because of the new multitasking:
http://www.tuaw.com/2010/04/09/apple-blocking-flash-built-apps-because-of-multitasking/
I'm sure you can guess which side of this divide I land on. I am 100% certain that this is a "user experience" decision, based on a desire to keep our digital toys from crashing out as they move to a multi-tasking OS.
Background: I cut my teeth writing assembler for 60's era mainframes, and I hate middleware layers of software. There is just no way that interpreters or converters perform at the same level as something coded to the OS API's.
Forget the iPhone for a sec and focus only on the iPad, that's where this decision is likely to have the biggest impact. With a single-core processor and only 256GB of RAM, It's a one-squirrel "computer" or a relatively high-powered digital toy. When you turn on multi-processing on that platform you'll be stressing out the squirrel even with good coding practices.
"Good software" in this case means Objective C code specifically designed to make use of the new multi-processing OS-level API's. Then you can do things like freeze the state of an app that's been shoved into the background, and make sure that it consumes 0 CPU cycles until it's pulled back to the front. This will be "nice" on an iPhone, but will be absolutely essential on an iPad.
But then again, I'm biased, Cocoa is one of my favorite technologies.
Seems like this might be a bit of a sore subject, however a few new thoughts are popping up that I believe are worth mentioning.
Nobody knows exactly what CPU the iPad is running on. We do know that's it's proprietary and the full specs will never be made public. It was produced by Samsung using a 45 nm process. There are 256MB (not GB) of RAM, an integrated graphics module, and a 64 bit memory bus. Everything else you've read about it is pure speculation, particularly that it has a single-core Cortex CPU. There is some quite reasonable speculation now that it is a dual-core PA Semi CPU, which seems likely given that Apple bought PA Semi several years ago. It seems unlikely that Apple would use the PA Semi team to simply reproduce a Cortex-based design.
What does all that really mean to programmers? Apple appears ready to embark on a serious game of hide the salami, and I intentionally use that metaphor in all its aspects. From now on we will never know what's really going on inside Apple CPUs on mobile devices. For example, the iPad could be running an emulator to support OS 3.x which will be jettisoned for OS 4.x.
If any part of this speculation is true, Apple will screw all their competitors to the wall in a very direct way within a year on mobile platforms, and within two years on full blown OSX platforms. The code warriors who follow them down the Objective C path won't know the difference, excepting of course that they'll be riding the wave of products that work on the new CPUs on day one, a huge competitive advantage.
Think about this simple question: "What Would Steve Jobs Do?" I believe the answer, now that he has so much cash and such a huge mobile market share, is "screw every competitor as elegantly as possible." Hence proprietary CPUs are not only possible, but in my opinion, highly likely.
Post a Comment