Comments on: Someone at Apple, please review stance on PhoneGap

By: iphonedevelopment

iphonedevelopment — Tue, 15 Dec 2009 19:31:01 +0000

Developing for the iPhone is super tricky. Even if you think your onto a great app idea you have to keep a close eye on apples policies, its stopped be several times from getting my app in the appstore. SO FRUSTRATING!

By: Nosredna

Nosredna — Wed, 20 May 2009 14:39:03 +0000

My problem with Apple’s response is twofold. 1) Inconsistency. Some apps get through and some don’t. 2) The reason Apple gives is “external framework.” If Apple could be more clear about what’s bugging them in these cases, that would remove a lot of uncertainty. This issue is just way too gray.

Anything you can do with PhoneGap, you can do without it with a bit of code, all using Apple’s SDK.

By: perenzo

perenzo — Wed, 20 May 2009 08:47:52 +0000

If you just need the features of PhoneGap but not a custom app on the AppStore you should have a look at Big5 and Big5lite available on the AppStore http://www.big5apps.com

By: atnan

atnan — Wed, 20 May 2009 00:29:22 +0000

@jmatthewpryor There’s a big difference between loading content and loading dynamic, interpreted code from any source.

I’m guessing a big issue for Apple is that PhoneGap accepts gap:// requests from the embedded webkit regardless of the domain that makes the call. This means the trust model is slightly different to an application that makes explicit requests for content from known domains.

The reason I think the issue is with a subset of PhoneGap rather than the whole framework is due to the way Apple’s AppStore application works. The AppStore API returns UI configuration code via a web service returning plist (XML) formatted data. This means that Apple can customise their application UI without releasing a new version of their application. The difference to PhoneGap is that a) the content comes from a known source, and b) the UI code is for presentation only, and does not call out to native APIs.

I’ll be interested to see whether removing the online mode and/or disabling gap:// dispatching from anything other than file:// URIs will make a difference to Apple accepting the use of PhoneGap. I suspect that’s the only thing holding it back, rather than malice on Apple’s part.

By: jmatthewpryor

jmatthewpryor — Tue, 19 May 2009 22:55:33 +0000

Forgive my lack of understanding but how it is any different that a PhoneGap based app could use a UIWebView to download dynamic content that any of the huge number of existing apps in the AppStore that clearly do the same thing?
This is not an attempt to understand Apple’s policy, its really a technical question. What additional vulnerabilities or unwanted surprises would/could a PhoneGap based app expose a user to that any Objective-C based app that used UIWebView didn’t?
I use the ABC (Australia) app regularly which clearly downloads dynamic content in to a custom UI (not mobile Safari), and I assume that this content could include Javascript. Is it the fact that PhoneGap exposes native API to JS that creates the problem?
I feel it would be better to take the “you should have known/that’s the way it is” element out of this discussion and move it to a rational technical conversation about what PhoneGap can & can’t do & stay within a reasonably unambiguous interpretation of the AppStore listing rules.
Constructive & detailed technical input seems a far more valid contribution to the debate at this stage.

By: ajaxery

ajaxery — Tue, 19 May 2009 22:53:42 +0000

i started writing an app in PhoneGap, but the framework is so young and needs a lot of work. once i found out that it doesn’t work with iphone os 3.0, i stopped using it.

By: kb0

kb0 — Tue, 19 May 2009 22:33:14 +0000

I have to agree with those here who think Apple is in the right. Apple clearly stated their policy and PhoneGap clearly violates that policy.

The reason that policy is in place is because Apple is attempting to protect the user and the user experience. They don’t want a piece of software on someone’s phone that can allow other, non-reviewed and potentially harmful software to run on the iphone.

That said, I think phoneGap is a great idea and would’ve been my entryway into iphone development. However, every app I’ve wanted to write doesn’t need the full iphone API and can be done as a web app because of webkit’s great features (like cool transition effects, code caching, local database, etc.).

By: vsviridov

vsviridov — Tue, 19 May 2009 19:45:40 +0000

@idio – you shouldn’t call the whole platform “crap” just because of several impeding factors. By same logic iPhone is crap, due to their application acceptance policy. Also, moko people never called the platform as the “iPhone killer”, they were pursuing completely different goals. “iPhone killer” hype is just poor journalism.

By: nunziofiore

nunziofiore — Tue, 19 May 2009 17:52:34 +0000

@idio but do you really know what s phonegap? It’s nothing more than a tools that extends the UIWebView.. It’s not an external tool… it’s something that Apple released in it’s language… not a plugin or a third part code… The PhonGap developer are great, yes… but what they do it’s not so difficult or so far from what you can make alone when you make your own iPhone application… the best point they give to us is the time they spent coding PhonGap… all time that we can earn developing our tools…
I repeat, my analysis since three months ago it was perfect and i trust in PhoneGap. A lot of application were apcetted in Apple Store look here a list and the app I m developing are simmilar to those… but in last week i read also in the google group associated this news about some app rejected.. and I wanna understand one time for all: it’s a PhoneGap last release fault? We can fix it? Because the rule somebody wrote in one of the comment upper that row, it was a rule also when the app in list werw apcetted.. what change really now?
Perhaps it s all a missunderstanding and app rejected had really some content that it’s against the Apples’ rules… but it’s not PhoneGap the problem…

By: idio

idio — Tue, 19 May 2009 16:57:27 +0000

“It’s a big damn for business, when you discover only when you’re on release phase, that your program can’t be added to the app store for ridiculous thing…”

No offense, but you must be a really, really bad business if you didn’t realize this type of application would be rejected. I don’t regularly program the iPhone, and it’s certainly not where i make my money. But seriously even I knew this was their policy. Did you even read the license agreement??? It’s your own fault.

By: idio

idio — Tue, 19 May 2009 16:56:01 +0000

This is a poorly written, factually incorrect article. I don’t know what you guys are talking about.

RegexKitLite and Google Toolbox for Mac are totally different projects than what PhoneGap does, and the Apple review process was entirely clear from the beginning that these types of run-time environments built on top the iPhone were not going to be tolerated. Heck, before the SDK even came out I read an article stating exactly that; Apple made their position abundantly clear.

You guys can bitch and moan all you want, but you’re wrong. I’m not saying I like Apple’s policy, but it’s not like they pulled a bait and switch on anyone here. You knew what you signed up for, and if you don’t like it… Uh.. Build your own phone.

Or can you all go running to that “iPhone killer” open-moko… Oh wait, that thing is a piece of crap :P

By: vvtim

vvtim — Tue, 19 May 2009 16:17:03 +0000

@JonathanLeech With the iPhone ecosystem, it’s pretty darn easy to recoup the $100 registration fee with a $1 app. People buy anything.

By: JonathanLeech

JonathanLeech — Tue, 19 May 2009 15:30:37 +0000

Now I am glad I didn’t spend the $100 bucks on registering as a developer. It would already be tough to recoup that with app store sales of a $1 app, but impossible if Apple wouldn’t accept it anyway.

By: mudx

mudx — Tue, 19 May 2009 15:04:48 +0000

Wow, that’s ridiculous. I was thinking about developing for the iPhone, but now, I’m going to be holding out until some serious changes are made.

By: mdmadph

mdmadph — Tue, 19 May 2009 14:20:41 +0000

@nunziofiore

That’s why big companies have teams of IP lawyers working on a thing for months before anything is ever released (or at least they should).

By: randomrandom

randomrandom — Tue, 19 May 2009 12:25:03 +0000

After the last 6 months of negative iPhone/App store stories, is anyone really so credulous as to be surprised by this kind of behaviour from Apple? When will developers put their money where their mouths are and switch to an open platform like Android?

By: dangoor

dangoor — Tue, 19 May 2009 11:54:04 +0000

FWIW, there is apparently now a version of PhoneGap up on github that doesn’t include the “online mode” that can download new code. If Apple allows PhoneGap apps that do not download new code, then I’d say they’re being consistent with their policy (which exists to ensure that programs are reviewed before they go into the App Store).

By: nunziofiore

nunziofiore — Tue, 19 May 2009 09:30:59 +0000

It’s a big damn for business, when you discover only when you’re on release phase, that your program can’t be added to the app store for ridiculous thing…
I don’t understand why this happen. There’s also a lot of PhonGap application that were apcetted in last months… why some other’s are not?
Sorry for quick and dirty english…
Nunzio Fiore

By: atnan

atnan — Tue, 19 May 2009 07:20:35 +0000

@segdeha, Downloaded code accessing native functionality via Phonegap's messaging system (the gap:// URI) is the problem, and has nothing to do with whether or not the overall solution uses Apple's built-in UIWebView. The -webView:shouldStartLoadWithRequest:navigationType: implementation in PhoneGapDelegate is precisely the kind of interpreter that section 3.3.2 intends to prevent.

By: segdeha

segdeha — Tue, 19 May 2009 05:30:18 +0000

@atnan, You’re leaving out an important phrase from your analysis: “…except for code that is interpreted and run by Apple’s Published APIs
and built-in interpreter(s).” UIWebView is clearly a built-in interpreter of the downloaded code, so I think this has more to do with Apple retaining control of the user experience.