Getting away from the frenzied rhetoric, my opinion is that what Apple <i>really</i> wants to prevent is people releasing multi-platform compilers. So taking Flash as just one example, if I can build one app and the compiler can make me an iPhone executable, an Android executable, and so forth, Apple don't want that.<p>In my experience so far with such "cross platform compatibility layers," they always produce results that water down each platform's individual strengths and differentiations. And of course, instead of the developer being locked into the phone platform, they are locked into the compatibility layer's platform.<p>Adobe's Flash compiler is a classic maneuver to "commoditize your complements," as Joel put it so well. Apple don't want to be commoditized, especially if it means having apps that don't take advantage of the iPhone's strengths.<p>Adobe want to lock developers into Flash and commoditize everything else as Flash-delivery devices. Apple want to commoditize applications and lock developers into their APIs.<p><a href="http://www.joelonsoftware.com/articles/StrategyLetterV.html" rel="nofollow">http://www.joelonsoftware.com/articles/StrategyLetterV.html</a>
I don't like this at all. Maybe they only meant to hit Flash, and maybe not, but as written this is in direct opposition to one of the most important principles of software development. Apple themselves must have benefited countless times from writing software in layers. But no layer above their layers is permitted?<p>I wonder if the open source world can successfully fight back, by making compilers that generate code the app store police can't tell from hand written.
Putting aside the intention of this agreement which does seem targeted at the Flash-to-iPhone compiler, this just seems overly broad and silly from a "how things work" point of view.<p>Let's say I write an iPhone app originally in Scheme (like this guy did: <a href="http://jlongster.com/blog/2009/06/17/write-apps-iphone-scheme/" rel="nofollow">http://jlongster.com/blog/2009/06/17/write-apps-iphone-schem...</a>), and compile it down to C, which is then compiled to object code and linked against the iPhone libraries. At this point, the object code is the same (or functionally the same in terms of its syscalls, library calls, and general program flow) as if I had originally written it in C, except that I would have lost the unique developer efficiencies I got from using Scheme in the first place. I'm not saying Scheme is better or should be an officially sanctioned source language for the iPhone SDK. I'm just saying, where the rubber meets the road -- object code linking against libraries and making certain calls -- there is no difference to the computer what the original source was.<p>Seems very silly.
Say hello to the new boss, same as the old boss. The corporate pissing matches have started in earnest...<p>When Alan Kay said Apple would take over the world with an iPad, I don't think he realized that eToys or anything like eToys would never be allowed to run on the device and that a majority of the apps will probably have commercial spots embedded within them. Actually it reminds me of "educational" tv all over again...<p>I'm starting to see the point of people who complain about the consume vs. create nature of the iPad...
Wow, this could also ban iPhone apps from using Scheme (<a href="http://jlongster.com/blog/2009/06/17/write-apps-iphone-scheme/" rel="nofollow">http://jlongster.com/blog/2009/06/17/write-apps-iphone-schem...</a>) or maybe even model-driven tools (<a href="http://code.google.com/p/iphonical/" rel="nofollow">http://code.google.com/p/iphonical/</a>).<p>Telling developers which languages to use? Might as well stick with enterprise software development, more innovation going on over there Apple!
I can think of only two (tenuously) justifiable reasons for this.<p>1 - Perhaps, during the beta, they want code written in C (and derivatives) to aid in debugging framework bugs. Rather than "My App doesn't WORK!!!!! (Using MonoTouch Vxxyy)", they can get a repro using a stack they know and control top to bottom. In this case, I can see it as justified.<p>2 - If it's specifically to target cross-compilers as a business decision, to ensure that iPhone only gets "exclusives", then I suppose it's their prerogative. It will probably backfire long-term, as their market share isn't <i>that</i> dominant. "Browser, Palm, Android + all else" or "iPhone" makes the iPhone a secondary port target versus a first class platform.<p>If it's any other reason, it is ridiculous. It makes me seriously question my upcoming Mac Pro & iPad purchases. Even though I currently develop for Mac and iPhone using only Obj-C, I can't build a development strategy around a schizophrenic "partner". What's next - documentation not written in Pages? Failure to use Steve's favourite colour in the background? It's getting... bizarre.
This is unsavory in the extreme. I had been writing an iPhone app in Haskell, and now I have to can it? What the fuck? Fuck you, Apple! Blowhards.<p>Hope you guys enjoy the mass exodus of decent developers from your dumbass platform with kiddie languages.
Isn't MacRuby sponsored by Apple? There's been discussion re: writing iPhone apps with MacRuby, AOT compilation. I wonder how that project will be affected?<p><a href="http://lists.macosforge.org/pipermail/macruby-devel/2010-January/004049.html" rel="nofollow">http://lists.macosforge.org/pipermail/macruby-devel/2010-Jan...</a>
> Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine<p>Controlling programmers like this seems positively insane, doesn't it? Does this mean that games can't do scripting in something like Lua either, under the letter of Apple's law?
Oh man, just when I was impressed with what they're doing in iPhone OS 4.0, they throw this in.<p>I was hoping to finally develop for the platform thanks to background services, but my moral objection is now at par with my profit motive.
Wow. Just wow.<p>I was planning on building an app in Titanium. I guess I'll wait and see how this shakes out first.<p>btw, at the time of writing this comment Titanium's developer center is hosed. Maybe it became self aware at the same time and commited suicide.<p><a href="http://developer.appcelerator.com/" rel="nofollow">http://developer.appcelerator.com/</a>
1. Apple takes iPhone stability and security Very Seriously.<p>2. ???<p>3. Therefore, if you write native iPhone apps, you must use C derivatives that expose raw pointers and direct memory access.
Is there a legitimate reason for this, or is Apple just thumbing their noses at Adobe (and everyone else)?<p>Is Apple primarily annoyed that Adobe's app and MonoTouch aren't doing it the "Apple" way? Or do they not like that those frameworks present non-standard UI's (I haven't used MonoTouch, so I don't even know if that's the case here)?
Looking forward to Adobe's response. Going to wager it'll be in the form of a lawsuit, and that the FCC will get involved. Whip out the marshmallows, this should be interesting :)
While Adobe is going to bear the brunt of this, this looks like a calculated move against Android as well. By precluding things like PhoneGap (if it turns out that it's "an intermediary translation or compatibility layer"), they're forcing developers that can only afford to write an application once to choose one platform. Right now, iPhone is the easy choice for a lot of developers, just based on market.<p>The end result being fewer apps for Android and a less vibrant software ecosystem.
"Applications must be originally written in Objective-C, C, C++, or JavaScript"<p>So porting from another language is now forbidden? Or is it unoriginal code that is banned?<p>Either way, the sheer craziness is astounding.
In principle, couldn't any of these translation layers be converted to code generators that would produce compiled Obj-C that would fall within the rules?<p>Surely they aren't saying that all code has to be entirely hand-written? If so, then is running search-and-replace on a source file not allowed?
Due to time mostly, my Port of Cocos2D to MonoTouch (<a href="http://github.com/city41/cocosnet" rel="nofollow">http://github.com/city41/cocosnet</a>) has gone untouched for sometime. Looks like that was inadvertently the correct decision :(<p>Damn Apple is evil.
I'd love to see something like Logo or MIT's Scratch for the iPad. As I think about introducing my kids to computers that totally makes sense. This new language from Apple seems to preclude that.<p>It is totally off base.
The App Store has always been a set of moving goalposts, but Apple just moved them completely out of the end zone.<p>Such a relocation tends to be more visible from a distance.
There is no longer any debate as to who the "bad guy" is in this story -- Apple has proven themselves to be anti-competition, anti-developer, and anti-consumer.<p>Just created a new "I'm with Adobe" Facebook Group:<p><a href="http://www.facebook.com/group.php?gid=113492765344092" rel="nofollow">http://www.facebook.com/group.php?gid=113492765344092</a>
This feels wrong on so many levels...<p>Basically, they reserve the right to ban any sort of DSL/runtime/engine application architecture. Imagine you are building adventure games (like Money Island). You'd have a game engine and a domain language in which you describe the game. The beauty of this is, you don't have to rewrite the engine every time you finish a story for a game, you just write in your DSL. The same holds for a range of other applications such as travel guides, recipes for cooking... How can you be sure where they draw the line between data and code?<p>Well, it probably just depends on whether it comes from an Adobe tool or not. Let's see who's next.
Apple's going to annoy a lot of big developers with this. Who's going to use Game Center, when a lot of big games are written with the help of Unity, etc.? There are so many top-10 games affected by this.<p>Even THQ's Star Wars: Trench Run is affected. You can't really get more high profile than that. I wrote a blog post (<a href="http://bit.ly/disQ2C" rel="nofollow">http://bit.ly/disQ2C</a>) with some links to various SDKs and their app showcases to give people a bit of an idea of just how many existing apps this SDK change will effect.
Compared to the video game console industry, this is still pretty nice. Several of the companies require submission of the <i>source code</i> for review. And Nintendo in particular is renowned among my video game programming friends for having ridiculous, undocumented rules that change over time.<p>If you think of the iPhone as a PC-like platform, yes, it's worth being crazy. But I think of mine as more like a game console. That helps me minimize my own feather ruffling, even when Apple does snarky things to me during the review process.
This could mean instant death for MonoTouch. What developer would choose to write an iphone/ipad app in MonoTouch with the risk of having to re-write their app if apple drops the hammer.
Is it not possible that all this fuss is over a typo?<p>> 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 <i>only</i> code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to <i>Documented</i> APIs through an intermediary translation or compatibility layer or tool are prohibited).<p>My thought on what they probably meant:<p>> 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 code written in C, C++, and Objective-C may compile and directly link <i>only</i> against the Documented APIs (e.g., Applications that link to <i>Un</i>Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).<p>I bet what they're trying to do is prevent intermediate tools from allowing people to "whitewash" private API access.<p>I say this because the interpretation everyone else is seeing in this clause is obviously a horrible position, and I just don't think that's the intent.<p>Time will tell!
Apple has pursued a single consistent goal under the reign of King Jobs II: protect the ecosystem, and grow it in careful, measured increments.<p>In order to keep something great from turning to crap, you have to have a gatekeeper. If you don't trust the gatekeeper, that's OK. But I'm hearing a lot of noise from developers who are already beholden to their own gatekeepers (whether it's the core team of your open source project, Microsoft, Oracle/Sun, or whoever). I mean, Adobe?! Could there be a more arbitrary and horrible gatekeeper than Adobe?!<p>Just because Apple doesn't do what you want doesn't make them better or worse than any maintainer of any "good thing". In the end, it all boils down to whether you trust Apple to do the right thing.<p>If you don't, then you're welcome to go punt on the umpteen device platforms that are currently vapor. (How many years have we been hearing about "iPod killers", and where are we with that?)<p>It's OK to complain, but I really would have thought the HN audience would understand that EVERYTHING EVERYWHERE is a trade-off. Yes, we should be debating the rules that Apple imposes, because we have a say in that. No, that doesn't validate rhetoric about Apple being "evil" or "anti-developer" etc.
Here's where this hurts. The Adobe blog stated that you'd be able to build iPhone apps.<p>It wasn't until recently that some of us stopped and thought, wait.... what if Apple decides to deny all Flash built apps???<p>A lot of time was probably lost by developers. There's going to be a lot of crushed dreams.<p>Plus, instead of spending $600 on CS5, I'll probably buy a Mac Mini.
Don't forget another possible explanation: Objective C, C and C++ are difficult languages, meaning there's a barrier to entry. Apple may also want to prevent application development from becoming a commodity: they don't want "widget shops" employing warm bodies to churn out low-value applications.<p>Of course, I disagree with this approach: there already <i>are</i> widget shops. It's possible to program in a language without knowing it, by writing it non-idiomatically resulting in buggier, slower code that takes longer to develop and is difficult to maintain. The fact that they write in languages that take longer to develop an app in would just mean they'll choose "low quality" while still maintaining the same quantity.
Problems with it aside, and I certainly don't like it anymore then anyone else here (I was still hoping to get a lisp working for iPhone development), I think it would be wrong to attribute the decision to malice.<p>Apple's doing this for the exact same reason they do EVERYTHING else controversial that they do on iPhone OS: because the primary (only?) thing they care about is the end user experience being as good as possible. In this case, Flash (which I'm sure this is entirely aimed at) doesn't provide as good of a user experience as the native UI controls, so they're nixing it while they can without as much bad publicity as they'd have if they waited until after CS5 was released.
"Apple responsible for 99.4% of mobile app sales in 2009"<p><a href="http://arstechnica.com/apple/news/2010/01/apple-responsible-for-994-of-mobile-app-sales-in-2009.ars" rel="nofollow">http://arstechnica.com/apple/news/2010/01/apple-responsible-...</a><p>so obviously AppStore is a monopole - the other 3~10 stores have a miserable 0.6% ... of course that says a lot about Apple genius and how its competitors are plain retarded ... but ...<p>still i think they are more and more abusing their dominant position with their draconian dev rules ... and that should be looked at - could present some legal challenges for them ... im no lawyer - but i think the only way they can get away with it is tru the private nature of the dev agreement ...<p>incidentally - i really think Apple is special - one of a kind genius company - but also because of that people cut them way too much slack ...<p>to prove my point - just try this simple mental exercise - try to picture - what would happen on this same forum if we were discussing about say - Microsoft - say Microsoft just put out a nice new license for Windows-7 that said you "can develop for W7 only if you use C#, .NET, Microsoft own compilers, Flash is banned and Redmond will need to approve all any application" ...<p>dude - it's so funny i cannot even finish typing it ... really - it just sounds so crazy - like a story from another world - a world of evil monopolistic corporations that try to control our free lives... yet all we did with this simple exercise is to change one word : Apple -> Microsoft ... and - last time i checked - Windows does not even have 99.4% of the market - more like 90% coupled with a boring, inferior resource hogging product that though comes with all the freedoms democracy brigs us ...<p>and that proves my point - we do cut Apple way too much slack just because they are so awesome in making great products ...<p>full disclosure - i owned both iPhone 2G and 3G, just recently dumped 3G for a nexus-one because id rather own an imperfect (though rapidly improving) democracy than in a perfect nazional-socialistic system ... i still use my mac - osx is awesome and kicks Windows-7 lower-back ... and just got an iPad - just because there are no other choices ... yet ...
You can't stop people from making their own choices, whenever you try to force any kind of sensor ship or prohibition on people, they will find out ways to go around. IMHO very stupid and arrogant move by Apple.
Two things I haven't seen mentioned: 1. The majority of iPhone developers aren't effected by this at all. 2. To some degree, this is is about ensuring the Mac remains a required part of iPhone/iPad development.
Bill Gates made a big mistake back in the late nineties. He could have just banned everything that didn't use the Windows API directly. Java and the web would never have happened. The world is so simple :-)
My original reaction to this was "WTF. There should be a class action suit against Apple by developers along the lines of hindering freedom of speech".<p>... but then, any compiler that can generate the processor's instructions can obviously also be modified to generate Objective-C code. So I guess this will result in all the cross-compilers just changing their target language from llvm or assembly to ... Objective-C.<p>I can live with that ... and watch Apple slap themselves on their pretty foreheads ... whatever it is they hoped to accomplish in terms of lock-in :)
Ok, idea: If we can't bring flash / other languages to the ip{{o,a}d,hone}, why not bring the ipod/ipad/iphone to other platforms? Write an Android wrapper around Cocoa's API, for example. Something like a WINE of sorts. People with lots of iphone app dev experience can write their iphone app, then turn around and recompile that Objective C code into an android app.<p>Far from ideal, but it may be the best solution at the moment.
This doesn't sound practical for Apple to enforce - they could cherry pick a few big targets perhaps (Adobe....).<p>It could also simply be a change just so they can see what the response from the development community is - and may change rather soon.<p>I just can't fathom this particular rule lasting very long... it's not just lock-in, or a little bit evil, it's patently insane.
If the installed base of the products is large enough, no matter how draconian the terms there will be a subset of all potential developers that will be swayed by the money to be made so they'll accept the terms. Any attempt at boycotting will simply fail because of that.
Apple is shifting the burden here from users to developers. It's easier for a developer to simply puke out a lowest common denominator app but it's not so good for the user who is buying the iPhone because of the cool UI/interaction/integration good native apps provide. It's easier for a developer to simply have their unmodified app run in the background but it's not so good for the user who is losing cycles/battery because of it. I don't want to justify it because obviously there's some valid downsides especially for developers to this approach. My only point would be that's Apple's secret sauce. It's gotta work right, it's gotta look right, everything has to work right together. Apple is going to do whatever it takes to make this happen because they feel like that's their core advantage over their competitors. They're probably right. If you disagree there's Android, BlackBerry, Palm, Nokia, etc. It's not like Apple has a gun to our head. As individuals we have free will.
Adobe will not be happy about this, which makes me think: given how events unfolded recently in Adobe-Apple relationship and given that Photoshop is getting crappier and crappier in its OS X incarnation—has Apple some Photoshop/CS analog in the works?
This is only enforceable for tools like CS5 that reverse engineered the app signing process. How could Apple distinguish binaries produced intermediaries like PhoneGap and Appcelerator's Titanium from binaries produced by native Objective C code?
Totally rational if:
- it doesn't undermine the market for Apple hardware
- it sets back competitors<p>The requirement to use Apple development tools, automatically means you must use Apple hardware to develop on. Ka-ching!<p>So, as an Apple shareholder, I'm happy about it.
Apple has always been too rude to developers. Returning the iPad will be a good way to protest. Lets see how well apple does without early adopters (a major chunk of which are developers and developer referrals)
I am not regretting my decision to move away from Apple and it's products.<p>The first thing that came to my mind when I read the title is "wtf". What a really bad move. I wonder how much more can the app developers take.
I am not trying to defend Apple, but is it possible that the approval process was being slowed done by having to ensure that all the other intermediary translators were not using private APIs?
Looks like <a href="http://xmlvm.org/overview/" rel="nofollow">http://xmlvm.org/overview/</a> is still usable, isn't it?
I am wondering when apple will close this route down, too, though
I want to code in Objective-C, and I don't think Android allows that, so I'm stuck programming for iPhone/iPad. I wish Google will support Objectice-C calls against their APIs.
Okay, there is ECL (Embeddable Common Lisp) which has been hacked up to work on the iPhone. It compiles to C.<p>I can't use it?<p>I hope there are other companies that will release usable tablet hardware.
I'm no economist, and certainly no lawyer, but this does seem to me like it violates anti-trust law. Can anyone more informed about such issues comment on that?
I think Apple could have done with some explanation on this, despite all the anti-compertative conspiracy theories, this has probably got more to do with weeding out apps that wont be able to multi-task on the new OS 4 platform, than being another salvo in an apple-adobe wars. Thats why the Rule change has been couched more in terms of how you can write apps (objective-c, api's etc), and not in terms of how you cant which is pure conjecture at the moment.
isn't it possible to distribute apps written using other languages with this method ? <a href="http://www.networkworld.com/news/2010/040810-apple-iphone-os4.html" rel="nofollow">http://www.networkworld.com/news/2010/040810-apple-iphone-os...</a>
I think this decision is also about preventing the virus and trojan hell like that on Windows platform and other "unauthorized" code to be spread on millions of devices. It is much easier and cheaper to examine and control such restricted binaries before releasing them on iTunes.<p>About Flash, Java and other outdated WM-based crap - they are pragmatic. They don't need any WM to run apps on their hardware. Modern CPU is the only necessary WM. So, there will be much less complains about crashes, bad performance and out-of-memory issues.<p>Together, these two major problems sank the reputation of Windows and Apple want to avoid them.<p>So, there is nothing special. Apple can dictate rules which helps them to make more profit, and of course they will.<p>Wanna freedom - there is Android. Google trying very hard to position it as Linux (community-driven open and free platform) for smartphones.
And Microsoft just announced they silverlight can work on iPhone/iPad using IIS Media Services<p><a href="http://www.theregister.co.uk/2010/04/08/silverlight_media_server_ipad_iphone/" rel="nofollow">http://www.theregister.co.uk/2010/04/08/silverlight_media_se...</a>
If you want to develop apps for the iPhone, iPod, or iPad, then you have two choices--make a webapp, or make a native app.<p>Don't want to learn Objective-C? Then build a webapp.<p>Apple is not restricting your rights. Apple is not stealing your freedoms. Apple is not being tyrannical. Apple is not snatching your children away as payment for your access to the AppStore. I bet there's very few on here who are even developing apps that are doing all the bitching. Your the I'm-a-Flash-developer I-can-has-AppStore? type who want to have access to the latest opportunity to grab some money bags without having to learn a new trick. Did you try to read a line of Obj-C and realize it has a different syntax than your Flash timeline and AS and decide to cry cos you might have to work for those riches you're after?<p>Do you all gripe that the web requires HTML? Did you all complain when Macromedia didn't give you Flash that only required you have a scant understanding of HTML and CSS to call yourself a "developer"? Your complaints are so lame.<p>Companies make products. They want to control their products and its image as much as they can because it is their livelihood. If you want to base your livelihood on that product, then you pay by their rules. If you want to be outside the rules then you go your own way, but don't start crying cos they ask you to use their product to make your money in a specified way that protects their name and image.<p>If you don't want to use the tools, make a web app. If you want to complain thAt web apps can't do everything a native app can, then learn the platform and make a native app.<p>Stop expecting that the company that has taken all of the risk and spent all the money on r&d and given you an SDK and documented it exhaustively and covers the costs of distribution and takes all that WORK and COST off your back is asking too much to request that you repay them with the kindness of protecting and advancing the brand by using the tools THEY BUILT FOR YOU so the product and the platform can stay popular and successful and keep making you money.<p>Good grief. That shit is so hard to swallow isn't it? Let's all burn our Macs and sound like morons with all our Android-or-Nothing cries while we quietly go fire up XCode so we can make some offing money.<p>This is stupid.