Steve Jobs bans all apps from iPhone (or thereabouts) You could argue that the new Jobsian SDK bars developers from writing any application for the iPhone - unless they possess some sort of savant-like ability to think solely in Objective C. The much-discussed software development kit for the upcoming iPhone OS 4.0 says that native applications must be "originally written" in …
Apple are insignificant in comparison to Microsoft, both by turnover and market share (overall not in a specific vertical). What M$ got away with in the past, that it has now been forced to relinquish still out weighs anything apple have done or could even do.
M$ actions affected hundreds of millions of users and over a billion installed systems.
Apple can only dream of such power to abuse, and will never achieve such a market share.
I don't blame them for trying to keep control of a good (for their pockets) thing but eventually, as history has proven time and time again, the end user and the developers who make this a sucess will get fet up and move on.
Apple = Humpty dumpty before he falls of the wall. Personally, I would like to see it happen as I think iSomethings are now stifiling the market place with a false sense of superiority that is undeserved. Hopefully developers will say fcuk this and move to other platforms.
Apple are not doing anything special that can't be done elsewhere, they are vulnerable, and they know it. Hence the megalomaniac attitude.
i think both the author of this article, author of titanium, and like minded fanbois are in a deep state of denial. This sdk clause is *crystal* clear and not ambiguous as they think. Titanium? Banned. SDL? Banned. Gtk app? Banned. Scripting? Banned (if you are using it to implement your app). You can port an app but not by using ANY portability layer. Jobs could change his mind, but from what i see any ambiguity people see is all in their heads and not reality.
furthermore, i think the confidence that this won't greatly reduce iphone development is unfounded. There's better devices on the market, i could easily see an exodus of developers if apple keeps adding more and more rules.
Agreed,
The no-translation clause may have been specifically crafted by apple to exclude adobe kit, but it clearly applies to these projects as well.
On the other hand, as the author said, the clause is meaningless since apple will do whatever it pleases anyways. It may permit certain translated programs and not others. This is about opportunism rather than technical merit. If the translation software were not made public, it's doubtful that apple themselves would even know whether an app was translated or not.
The T&Cs have always had a "we will refuse your app for any reason we feel like" .. you can't get more ambiguous than that ... does not put the thousands of developers off now does it.
Apple have made this "market", if they feel they have broken it they will change their mind. So bring on the competition, only the end-user will win.
I think the titanium guy might have a valid point - as long as the apps correctly use the Apple APIs, they'll probably be OK. This is probably what the new SDK clause was really about - his argument sounds plausible/sensible anyway.
In any case how would apple be able to tell an app was written using a translator (barring any headers it might add) and not straight in Objective C or C++ etc? (OK, if the app doesn't use the APIs i suppose that might give it away...)
It's understandable that Apple want to keep the API clean and require developers to go through them. This allows Apple to implement changes to the kernel and sub-systems with less fear of breaking the hundred of thousands of existing applications.
I've developed translation software in the past, e.g. generating pure X11 toolkit API calls from a graphical IDE. I don't see that Apple terms would restrict that approach if the generated code is clean, strictly follows the API and then Xcode is used to perform the final checks and compilation. In fact, if the translation mechanism is written correctly it should be quite hard to distinguish handwritten code from translated code. So Titanium could be okay .. only time will tell if Apple are trying to future-proof iPhoneOS APIs or if they are being unnecessarily draconian.
So long as people follow the PUBLISHED API and so long as Apple don't cock up the API in a non-backwards compatible way, then existing deployed apps should be fine.
The language used to write said app is irrelevant. App asks the language to call the API, whether it is a little BASIC interpreter, standard C, or a specific Apple-sanctioned version of C-with-bells-on.
Apple is quite obviously being draconian, because the technical reason doesn't make a lot of sense. The only excuse that would work is if Apple used a shared runtime-linkable library to interface with the API, so the library can change with the API... but that's a Scary-Bad way of developing an API...
But, hey, development will only slow down by a small minority becase all the sheep know of the iPhone and the developers will put up with a lot of different s**t because it is where the money is. Some developers do it for love, the rest do it for money. iPhone = money. So long as that equation holds up, it will be a self-continuing cycle.
.
Of course, there is an implicit fail lurking. How many apps will be lesser than they should be, or buggy in ways they shouldn't, because a developer used to one way of doing things will be forced into an unfamiliar language.
never mind the new ones.
3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built- in interpreter(s).
It's interpreting flash-like scripts.
Apple's ban translation layers could be seen as a bid for "exclusivity". If you write an app using some more widely portable framework and merely compile an iPhone version, that same app will be available for rival devices. Lots of developers prefer to work that way. If, on the other hand, Apple force you to write the iPhone version using an iPhone-only API, they're increasing the cost (to you) of maintaining both versions. You might reckon is isn't worth the cost and abandon either one of the platforms. Apple are therefore betting on more people abandoning the rivals than them. Time will tell.
I liked the title of your post because you're clearly missing the point.
"Apple's ban translation layers could be seen as a bid for "exclusivity". If you write an app using some more widely portable framework and merely compile an iPhone version, that same app will be available for rival devices. Lots of developers prefer to work that way"
You mean like writing in C?
Which is allowed...
"If, on the other hand, Apple force you to write the iPhone version using an iPhone-only API, they're increasing the cost (to you) of maintaining both versions."
Well, if you don't use the iPhone API how are you going to do anything?
The routines on Apple/Google/MS devices etc are all going to be called different things and work slightly differently, so there is no way around this at all!
Write the app as closely as you can to be within the confines of their own laws so that your app can be shown one day on itunes or the app store.
But once the program has been tested,alpha beta etc etc then crunch that program so tight and small and put it through some obfuscation program so that the apple testers can't
see the code properly as it is YOUR PROPERTY and not theirs.
If they refuse it then have a class action lawsuit against them.
How in the name of Heaven do you get from "[a]pplications must be originally written in[...]" to "originally conceived and written for the iPhone"?
Mr. Metz, you must be deliberately trolling for ad impressions; there is just no other explanation. I refuse to believe you are so think as to interpret the new clause in such a way.
As "Henry Wertz 1" mentioned above, the clause is perfectly unambiguous: if you want to write an iPhone application you must write it in one of the native languages and target the iPhone platform itself, not machine-translate it or cross-compile it from a different platform. And if using JavaScript, it must be executed by the internal WebKit engine, not a custom runtime.
-dZ.
Got it in one.
Most cross-platform development tools result in lowest-common-denominator application design. Apple are all about the UX, not the technology. What's the point of creating new UI features if developers are going to use the excuse of cross-platform compatibility to avoid using it?
Even if you develop for the desktop flavours of OS X you have to be prepared to update your apps in line with changes to APIs or your application(s) can easily fail to run properly on later OS X releases. Apple are a lot less fussed about backwards compatibility than the likes of MS and the FSF.
Apple don't *care* if the programmer has to suffer a little for his craft: it's the *customer* who rules. They're not a development tools company like Microsoft. They're sure as hell not the coder-centric FSF. If you're a programmer, you do NOT get to call the shots in the Apple ecosystem.
And you know what? This is exactly how it *should* be. And how it fucking well should have been from the start.
Design your code accordingly: separate the model *entirely* from the view and controller elements. Plan for reusability rather than focusing on mere portability. Be prepared to build new UIs for each platform, and you'll win the plaudits. Stick with merely duplicating the same UI over multiple platforms—regardless of its suitability—and you'll deserve everything you get.
And no, Objective-C isn't *that* hard. It's a blend of C and Smalltalk, not some batshit insane version of Forth.
>Apple are a lot less fussed about backwards compatibility than the likes of MS and the FSF.
Its stronger than that - iPhones and iPads are inherently life limited. Backwards compatibility is bad for business when your target consumer isn't business. Now obselete 2G owners who haven't already bought their second or third iPhone will doubtless do so soon, afterall the upgrades are 'free' aren't they?
Sad thing about PT Job's obvious low opinion of his consumers is he's probably right - only as well as one being born every minute, they also get reborn every year.
>Be prepared to build new UIs for each platform, and you'll win the plaudits.
Like Apple themselves do with Safari, iTunes and QuickTime Player on Windows? Do as I say not as I do.
Apple sucks.
"Like Apple themselves do with Safari, iTunes and QuickTime Player on Windows?"
Or like MS do with Word, Excel etc on OSX?
"Sad thing about PT Job's obvious low opinion of his consumers is he's probably right"
Apple seem to have a very high opinion of their customers and are doing their level best to make sure developers can't release crud that breaks with OS updates. Do MS have that level of care for their customers?
The fact is, Apple wrote the OS and they're saying "call our APIs in a friendly way" no sneaking your own assembler in there, just in case we change something.
Does anyone here remember what happened when developers started hitting hardware addresses on Amiga OS 1.3? Everything failed on OS 2.0. Apple obviously NEED to avoid a similar problem!
If they're so worried about changing something breaking apps (or vice versa), why have they waited so long? As far as I can tell, there's been umpteen iPhone types - and I'm forever hearing someone moan that the latest iPhone OS update crippled their jailbroken iPhone. However, I've yet to hear any big moan about a change to the OS/iPhone version breaking any app, or being broken by an app?
> why have they waited so long?
The whole thing was a big con.
They started all nice and sweet and then decided to turn into a jerk as soon as they thought they could get away with it. They wanted to sucker everyone into helping them build their mind share. Now that they have that, any particular developer is disposable to them. They view themselves as bigger than any particular developer or developers in general.
They think they've got a repeat of DOS on their hands where they think they have enough critical mass that no one can catch up to them.
What have MS got to do with this?
>Apple seem to have a very high opinion of their customers and are doing their level best to make sure developers can't release crud that breaks with OS updates.
The latest OS updates don't even support their own hardware, get a grip....
Apparently this is all about protecting Apple's customers - clearly Apple believe they lack the intelligence not to buy badly written software and will continually revisit websites with badly coded Flash content.
Thankfully Apple will protect you from these horrors - and the dangers of using your 3G connection as you might like, blacklisting callers who might have something important to say, viewing content which is political or contains bad language.....and worse of all Apps which compete with Apples own s/w offerings and might therefore confuse you with strangely desirable functionality.
This is nothing more than a written standard for a single product: NOT a single product written for many causing the many to prop it up (Flash).
"Even if you develop for the desktop flavours of OS X you have to be prepared to update your apps in line with changes to APIs or your application(s) can easily fail to run properly on later OS X releases. Apple are a lot less fussed about backwards compatibility than the likes of MS and the FSF."
This is why SJ jumped up-and-down about 12 y.o. Flash. Adobe freely admits it gives the responsibility of Flash upkeep to the platform (Linux, Apple, MS, Android, etc). If it does not run correctly, it's the platforms fault. So here, if Apple changes something in iPhone x, and your App does something strange, YOU fix it; not Apple.
"3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs ... The following non-public APIs are included in your application: u_charType ucol_close ucol_getAttribute ucol_getLocaleByType ucol_open ucol_setAttribute ucol_strcoll".
This chunk of 'quoted info' (freely available on the web) was sent to 'developer.appcelerator.com' from Apple, due to an iPhone App that was rejected about a month ago. This indicates Apple had already set the wheels in motion and it's just been discovered and revised for the iPad.
"Adobe freely admits it gives the responsibility of Flash upkeep to the platform (Linux, Apple, MS, Android, etc). If it does not run correctly, it's the platforms fault"
Which is why you can't view Flash in iPhone Safari.
Adobe's software is a flawed buggy mess and they refuse to take responsibility... if you've seen it on OSX you'd know exactly what I mean!
I suspect that Apple is having second thoughts about the direction of the app store. With the development of iPhone app creation systems and the soon to be released iPhone 4 with the new OS 4, they decided to put a stop, or at least reduce, the number of simple (and often function limited) cookie cutter apps and copies, created by these systems, which are overloading the store.
Adobe, Monotouch and Unity3d appear to be the main culprits, all either using only the simplest of iPhone API’s or cutting out the IPhone OS entirely (and Apple development environment). The problem for Apple is taking a TOS agreement, creating a rigid new rule on app development languages and applying it, when there are many companies and individuals who are now developing apps using these simplified systems. It may benefit the end user but will cause much pain to many ‘developers’.
Monotouch using the simplest of iPhone APIs ? They have just announced support for the beta 4.0 sdk which hardly sounds like simplest to me, nor does it cut out the iPhone OS entirely, it just provides a .net version of the API.
Unity is targeted towards games and provides .net support again. Simplest of iPhone APIs ? OpenGL and OpenAL are the only ones I can really think of that would be of use for games, maybe bluetooth for multiplayer. Being games you also wouldn't use all the UI APIs either. The OS would hardly be cut out though.
Adobe, can't comment on that.
since everybody & apple have their collective thongs in a wad over what should be allowed and what shouldn't, why doesn't some enterprising individual write an app that powers the iPhone off, the moment they try to use it? Think about it, it pacifies the Apple nay sayers, it get's the stick out of Jobs' ass and his overly paranoid concerns about people improperly using HIS property AND it keeps the users from doing anything that could stir up Jobs, Apple, and the anti-iPhone fanbois.
At the risk of sounding serious, I believe Mr. Jobs really needs to understand the fact that he just supplies the platform and the base OS and it's up to the consumers and developers to drive the development of the applications (outside of the standard, included applications).
Perhaps this is a sledge hammer clause to allow blocking an application that is not coded with processor cycles and memory constraints as important in the round.
Is it possible that developers of application that are most likely to be hit by this clause from the world of web and not the world of embed ?
Yes, translation produces inefficient (or flawed) code. The reasons why are simple.
1, When the APIs change, you're screwed
2, If any libraries you depend on change, you're screwed
...far better to do things the approved way.
Of course, you could write code that turns Flash into Objective-C and then compile that C. That would likely be allowed. You just can't write code that turns things into an executable binary.
This is purely a move to block platforms like .NET Compact on iPad/phone. Novell and mono nearly have .net compact working well and Apple are a bunch of scaredy cats. If .net worked on iPhone then nobody would bother using objectiveC or learning any new apple APIs. iPhones and iPads would start to look and feel like windows platforms. Personally this kind of greedy negativity is really awkward for developers and ultimatelly users will suffer. A phrase springs to mind - You know when you've been jobbied.
This is what concerns me too, my business has been developing some iPhone Apps over the last year using Unity3D with code written in C# and running on Mono ... and now we are in limbo.
What is Unity going to do? Despite their positive sentiment Apple's new TOC in iPhone OS SDK 4.0 section 3.3.1 seems perfectly clear that they are banned, and our works and investments are at risk.
Even if Apple allow Unity as and SDK with a Objective-C or C++ or C scripting rather than a platform, will be be hugely expensive for us to port all of our code from C# to Objective-C if we can?
What the fuck are you talking about?
.Net on an iPhone. Why would anyone want or need it? I for one can't be arsed learning Microsoft's new C sharp, their proprietary VB or J++.
"If .net worked on iPhone then nobody would bother using objectiveC or learning any new apple APIs. iPhones and iPads would start to look and feel like windows platforms."
Well, since my iPhone hasn't been targetted to join any bot-nets yet, I can only say that I'm VERY glad it doesn't feel like windows. Windows sucks, haven't you noticed? It's what brainless managers buy for their employees because "that's what we've always had".
"What the fuck are you talking about?" if you don't understand, why are you posting on a techie site such as this?
Here's one reason: using .Net / Mono means that one can develop cross-platform games, versus developing in Objective-C means limiting effort to Apple's products. Cross-platform development is the rational business decision for exploitation of one's work.
"...since my iPhone hasn't been targetted to join any bot-nets yet....."
What? You mean the *only* phone platform that's ever had a virus/worm/whatever circulating and spreading in numbers in the wild, despite the neverending hype of the A/V vendors for their products on all the others?
We need a FAIL and new keyboard please combined icon.
I assume the real reason for the ban is to maintain the barrier of entry.
It's relatively difficult to develop apps and yet there are already 150k apps and many/most of them are not good.
Imagine if every hack Flash "developer" could publish his rubbish "click on the carrot" game as an app... if you think the App Store is overflowing with crap now, you'd have another thing coming.
This move, while it will hurt some legitimate developers and their ability to release cross-platform titles, strikes me as fairly reasonable at this point.
Many of the top 100 apps for the iPhone were written using Unity3D.
What is annoying Jobs is the fact that Unity will soon target Android, etc..., making porting to those platforms relatively simple.
This is not about quality. It is about developer lock-in. What Mr. Jobs should keep in mind is that lock-in is also lock-out, for those game development businesses that don't like the high level of risk involved in dealing with Apple.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
