And again idiots trying to do something different and worse than the standard UI is reason for rejecting the app. iPhone scrolls by swiping, that's how all apps should scroll.
Why? It's imprecise because it doesn't always advance by the same amount. It's also too much work to use repeatedly when going through a long text.
I'll ignore the rest and say only that I stand by my original points blaming confusion about the UI. I will note that other developers blame the "rate on delete" mechanism that skews the reviews:
I have mailed Apple many times asking them what is wrong with PhoneGap and heard nothing. Many PhoneGap developers tell me that they've also asked Apple again and again for what is so problematic and no one has ever offered what you do.
But I'm not sure that I understand the scope of the problem when you say it will "run any code that is downloaded." I think you pretty much need to write the Objective C before hand and I've never added any extra functions.
While I appreciate the pointer you've provided here, I'm still not sure why this is any different from any arbitrary native application that reads data from the web. Every native app could be said to offer the same opportunity.
One of the classic philosophical tropes from theoretical computer science is that there's no real distinction between data and code.
But this is getting away from my overall point that the AppStore review process is damaged by bad communication and random reactions. The debate over the potential security problems with PhoneGap is a deep one that is better conducted in the open. I hope you'll have the time to write a deeper note about this to the PhoneGap mailing list.
And perhaps you're right that I would have been better off writing something from scratch. But I think there's a real value to working with an open source group because many eyes help fix many potential bugs.
Funny, when I go to the store I see an average of two stars. If the average of the fifteen ratings is said to be two stars, how can everyone be one star?
Second, many of those complaints appeared while my bug fixes were waiting in the queue. I described my frustration with trying to fix bugs in the piece.
And I don't think it was a bug as much as a misinterpretation of how to use the system. I like taps on the top and bottom. Other apps like to swipe a finger-- something I find too much work.:-)
The version that sat in Apple's queue included a new instruction box that seems to help.
Third, I would have more time to find problems like this if I didn't get distracted by phantom menaces that might be caused by using UIWebView.
Finally, if we accept for the sake of argument that the app was a pile of manure--something I don't believe-- than this still bolsters my thesis that the review process is random and can't be trusted.
I've been thinking about this a bit more. These dangers sound scary, but aren't they an even bigger problem for native apps? Certainly DNS poisoning could affect Yelp, Urbanspoon or any native app that goes to a server looking for data. And those servers could also replace any of those reviews with something lurid or unfortunate. They could change the behavior of the app after the fact very easily.
And aren't these dangers a real problem for the ad networks because the ad networks always change the content after the app ships. They have to.
At least PhoneGap would dump any new HTML in the UIWebView sandbox where it would be a bit safer. No one knows what the native code is doing. Doesn't this sound like PhoneGap is actually safer and easier for Apple to police?
A perfectly fair point. But why stop with that auditing that? Do they fact check all of the non-fiction books? Do they make sure that Grand Theft Auto accurately represents life in a city?
I easily encountered more than a couple dozen people. You're only hearing the most vocal ones. Most are careful not to say anything because they don't want to offend anyone.
I think you make a good point, but why stop there. How can Apple police any of the non-fiction content coming through the store. If they publish my book, how can they be sure about any of the claims in it or any of the facts?
Again, we're getting to the core of Apple's dilemma. They want to be the benevolent dictator making sure that everyone is happy with everything that happens with their iPhone, but they don't have the time or the energy to police it.
Hmm. I don't see why it's code that I'm interpreting. Didn't Apple write Webkit? Didn't Apple create the UIWebView? Didn't Apple write the version of Javascript embedded in it? That sounds like it fits entirely in the exception clause of 3.3.1:
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)."
Well, I never activated any online mode and that's pretty obvious from my HTML. It's actually easier for them to check than binary code.
You're absolutely right about things that can happen in online mode, but again I fail to see why that's either (1) much of a problem or (2) against Apple's regulations. They ship Safari, after all.
Section 3.3.1 states
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)."
Isn't UIWebView a documented part of the API? And didn't Apple write the Javascript interpreter?
Well, then I guess we don't agree. I think it complied with all of their rules from the beginning. I think that reviewers eventually agreed, perhaps after I pointed out why I felt that way.
If Apple's reviews and reasons were more consistent, I might agree that I'm failing to comply. But they were never consistent and I don't expect that they could be. There's no way that they can tell the author of code nor is there any reason for them to insist that everyone write every line of code themselves. If anything, it's asking for everyone to make the same beginner's mistakes and that only increases the bugs.
Your point about the updates is well-taken. If I were to put out a big stream of books, I would think carefully about the best way to approach it. It's important to remember that this was as much an experiment in a new platform as a way to republish a book.
Of course it's ironic to say that Kindle is a solution for publishing without censors. I can understand how Amazon got into trouble with the rights to 1984 but that doesn't make the platform any more stable or censor-free. It just means that there are two layers and thus two gatekeepers. I would be surprised if Apple shut down the Kindle or Stanza readers, but it's possible.
Then there's the price. Both the Kindle and Stanza developers want their cut. I haven't priced their options. Perhaps they're cheaper than Amazon's 30%. But I've heard numbers that are much worse.
Also, if I remember correctly, neither the Kindle or the Stanza reader was available when I started this experiment. Things have certainly changed.
The number of people you see whinging on the web about rejections represents a fraction of a percent of the iPhone developer community. Certainly in that number of app reviews, Apple does make mistakes. But your story is one of you being told once what was wrong, and just continuing to resubmit without the problem being fixed.
What fraction? We'll never know but I found it pretty easy to find other complaints. Even more told me that they held their tongue to avoid offending Apple. So the fraction could be pretty large.
As for my app, I fixed the problems that were-- as far as I can tell-- never there in the first place. It was published not once but twice. A twin version, though, was rejected. That strikes me as random and that's why I pretty much concluded that it's dangerous to invest any time, energy or especially money in the platform.
But I'm glad you've had good luck. I hope it stays with you.
No. Of course not. I've been around the world enough to realize that you don't write what I wrote without expecting the immune system to dispense as many white blood cells as it can muster.
If you read TFA, you'll see toward the end that I'm heading toward pure webapps now. They've got their own issues, but they're cross platform and there's no gatekeeper.
Not a single version of the Apps I submitted had the ability to change themselves or allow me to change them remotely. None. Nada.
If they really are doing more than checking for forbidden strings, they would be able to see that quickly by skimming the HTML. It's very boring. Plus, it's easier to read. It's not in binary like many apps.
I don't see how an "external framework"-- the term they used-- has anything to do with this. The rejection note said that I was to make sure that everything was to be "interpreted and run by Apple's Published APIs and built-in interpreter(s)". It's always been that way from the start. It doesn't matter who writes the code.
The only way I can interpret (hah!) what you're saying is to conclude that App development is meant to be like elementary school. You're not supposed to work with others. You're not allowed to use well-tested open source code. You're supposed to write your own code. Why is this wrong? Why is working with others going to give me the magical ability to change how my app works remotely?
Ultimately, it doesn't really matter why Apple rejected my application because many others come away with exactly the same experience even if they don't use PhoneGap: it's all pretty much random. Sometimes you get a cogent rejection note. Sometimes you don't. Sometimes they're fair. Sometimes they're not. It's all a coin flip which is the main point of my piece. It's not about PhoneGap. It's about the randomness and the brick wall and the lack of communication and the absolute power etc.
It's not worth speculating on why Apple rejected my application because I don't know. The notes were short and pretty much inscrutable. Eventually they accepted one version while rejecting one that was pretty much the same thing. So maybe it was some Javascript, but that doesn't sound like it should be against the rules. They only insist that code be "interpreted and run by Apple's Documented APIs and built-in interpreter(s)." Well, it sure sounds like Safari and Javascript fit that definition to me.
When I wrote this piece, I went out of my way to discuss the subject with many other developers. If this were simply a question of my problems, it wouldn't be worth writing. But many other developers are having similar problems with entirely different approaches. That's why I included the long list of adjectives that other developers are using. Go read their posts. Are they all simply dismissed as loons?
While BasilBrush seems to feel that it is obvious that PhoneGap is forbidden, it's not spelled out in any of the rule books. Can you point out where? Can you even explain why someone might even come to that conclusion? There's been no answer and Apple never answered any of my emails. When I speak to members of the PhoneGap team-- members who've successfully published many apps-- they tell me that they've been unable to get any worthwhile guidance from Apple.
My reading of the rules tells me that PhoneGap should produce apps that are more compliant because they only push information through one major part of the API, the UIWebView.
So if you can explain what's wrong with the code, I'm sure many would like to understand what's going on.
But that's not what my rejection notes said. They prattled on about using a "framework" or misusing some part of the API.
And they also told me I couldn't tell anyone I was giving my revenues to charity.
If it was all as useless as you feel, they could have saved everyone a great deal of time by just stamping "useless" on it from the git-go. Then I wouldn't have wasted time fretting about misusing the API and they would have had one more useless App to reject once again with a passive aggressive reason.
It's possible that Apple has encouraged a great deal of innovation but stifled a great deal more. Imagine that there are 100,000 great apps out there. If they publish, 50k then they've encouraged those. But they've also discouraged 50k.
Given that there are so many complaints about random reviews from all sorts of developers, I think it's fair to say that many feel stifled and discouraged from innovating.
The real issue is much deeper. You can tell whether all the calls are to legit library entry points, but you can't tell if the calls are somehow malicious You're right. The binary will tell you a few things, but it won't tell you everything. I contend that you can't make firm decisions about that without reading the source.
They obviously have scripts that create and check class dumps and search for tell tale strings.
Tell-tale strings are a pretty bad way to search for malicious or dangerous applications. It's fighting the last war.
I'm curious. Why do you say that Apple doesn't allow PhoneGap? Is it spelled out in any rule?
I've read the PhoneGap code. I've read the rules. As far as I can tell, PhoneGap doesn't violate any of them. In fact, it pretty much encourages the developer to write HTML which is-- as Apple insists-- only "interpreted and run by Apple's Documented APIs and built-in interpreter(s)."
I've always assumed that the number of PhoneGap applications accepted by the program support my reading. I've written Apple numerous times. I've tried to discuss it with their engineers. No one will say, "PhoneGap is forbidden."
I've heard the number 65,000 more recently and it's probably grown since then.
While I don't want to take anything away from the iPhone store or the developers who have the patience to submit their apps to the process, I want to point out that PalmGear.com claims 32,000+ apps for the old Palm platform. That's just one company. If you add in all of the Palm open source applications and what not, I wouldn't be surprised if there are 50,000+. We'll never know because there's not one bottleneck.
And let's not forget Microsoft's PocketPC and Nokia's Symbian. Each of these platforms let users download apps from websites or even swap them with friends.
I think it's entirely possible that each of these three platforms might claim 1, 1.5 or even 2 billion downloads a piece if there was some central tabulating center. But we'll never know.
I thought about this before working on the project and I saw that many other apps were distributing single books. After I tested some of the free ones, I decided that it wasn't a bad system at all. Sure, it added another icon, but I could live with that. When I was done with the book, I was going to delete it anyways to make room for others.
I can understand why you might want a different solution, but it boils down to a question of menu branching. Some people like a shallow tree with many options. Others want a deeper one. So it's a question of taste.
Yes, I did consider that and I may still follow that route in the future. But I like to experiment with new platforms and the iPhone has been one of the shiniest ones around. So I wanted to code it myself.
While I can see why you wouldn't want another app cluttering the springboard, I don't mind it. I picked up a number of books from other devs and liked the experience. So I figured I would go ahead.
Also, you'll notice, for instance, that the book has been available from SiSU archive for some time. http://www.wayner.org/node/5 So that's sort of a solved problem.:-) Not that it can't be revisited.
Slashdot Mirror
And again idiots trying to do something different and worse than the standard UI is reason for rejecting the app. iPhone scrolls by swiping, that's how all apps should scroll.
Why? It's imprecise because it doesn't always advance by the same amount. It's also too much work to use repeatedly when going through a long text.
I'll ignore the rest and say only that I stand by my original points blaming confusion about the UI. I will note that other developers blame the "rate on delete" mechanism that skews the reviews:
http://www.marco.org/66440065
The sad problem is that this is really the only efficient way to collect bug reports.
I have mailed Apple many times asking them what is wrong with PhoneGap and heard nothing. Many PhoneGap developers tell me that they've also asked Apple again and again for what is so problematic and no one has ever offered what you do.
But I'm not sure that I understand the scope of the problem when you say it will "run any code that is downloaded." I think you pretty much need to write the Objective C before hand and I've never added any extra functions.
While I appreciate the pointer you've provided here, I'm still not sure why this is any different from any arbitrary native application that reads data from the web. Every native app could be said to offer the same opportunity.
One of the classic philosophical tropes from theoretical computer science is that there's no real distinction between data and code.
But this is getting away from my overall point that the AppStore review process is damaged by bad communication and random reactions. The debate over the potential security problems with PhoneGap is a deep one that is better conducted in the open. I hope you'll have the time to write a deeper note about this to the PhoneGap mailing list.
And perhaps you're right that I would have been better off writing something from scratch. But I think there's a real value to working with an open source group because many eyes help fix many potential bugs.
Thanks again for writing.
Funny, when I go to the store I see an average of two stars. If the average of the fifteen ratings is said to be two stars, how can everyone be one star?
Second, many of those complaints appeared while my bug fixes were waiting in the queue. I described my frustration with trying to fix bugs in the piece.
And I don't think it was a bug as much as a misinterpretation of how to use the system. I like taps on the top and bottom. Other apps like to swipe a finger-- something I find too much work. :-)
The version that sat in Apple's queue included a new instruction box that seems to help.
Third, I would have more time to find problems like this if I didn't get distracted by phantom menaces that might be caused by using UIWebView.
Finally, if we accept for the sake of argument that the app was a pile of manure--something I don't believe-- than this still bolsters my thesis that the review process is random and can't be trusted.
I've been thinking about this a bit more. These dangers sound scary, but aren't they an even bigger problem for native apps? Certainly DNS poisoning could affect Yelp, Urbanspoon or any native app that goes to a server looking for data. And those servers could also replace any of those reviews with something lurid or unfortunate. They could change the behavior of the app after the fact very easily.
And aren't these dangers a real problem for the ad networks because the ad networks always change the content after the app ships. They have to.
At least PhoneGap would dump any new HTML in the UIWebView sandbox where it would be a bit safer. No one knows what the native code is doing. Doesn't this sound like PhoneGap is actually safer and easier for Apple to police?
A perfectly fair point. But why stop with that auditing that? Do they fact check all of the non-fiction books? Do they make sure that Grand Theft Auto accurately represents life in a city?
Well, when you're being told your claims are absurd, you don't need to prove something accurately. You only need to suggest a possibility.
I easily encountered more than a couple dozen people. You're only hearing the most vocal ones. Most are careful not to say anything because they don't want to offend anyone.
TSPhoenix gives a great response to this.
I think you make a good point, but why stop there. How can Apple police any of the non-fiction content coming through the store. If they publish my book, how can they be sure about any of the claims in it or any of the facts?
Again, we're getting to the core of Apple's dilemma. They want to be the benevolent dictator making sure that everyone is happy with everything that happens with their iPhone, but they don't have the time or the energy to police it.
Hmm. I don't see why it's code that I'm interpreting. Didn't Apple write Webkit? Didn't Apple create the UIWebView? Didn't Apple write the version of Javascript embedded in it? That sounds like it fits entirely in the exception clause of 3.3.1:
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)."
Well, I never activated any online mode and that's pretty obvious from my HTML. It's actually easier for them to check than binary code.
You're absolutely right about things that can happen in online mode, but again I fail to see why that's either (1) much of a problem or (2) against Apple's regulations. They ship Safari, after all.
Section 3.3.1 states
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)."
Isn't UIWebView a documented part of the API? And didn't Apple write the Javascript interpreter?
Well, then I guess we don't agree. I think it complied with all of their rules from the beginning. I think that reviewers eventually agreed, perhaps after I pointed out why I felt that way.
If Apple's reviews and reasons were more consistent, I might agree that I'm failing to comply. But they were never consistent and I don't expect that they could be. There's no way that they can tell the author of code nor is there any reason for them to insist that everyone write every line of code themselves. If anything, it's asking for everyone to make the same beginner's mistakes and that only increases the bugs.
Your point about the updates is well-taken. If I were to put out a big stream of books, I would think carefully about the best way to approach it. It's important to remember that this was as much an experiment in a new platform as a way to republish a book.
Of course it's ironic to say that Kindle is a solution for publishing without censors. I can understand how Amazon got into trouble with the rights to 1984 but that doesn't make the platform any more stable or censor-free. It just means that there are two layers and thus two gatekeepers. I would be surprised if Apple shut down the Kindle or Stanza readers, but it's possible.
Then there's the price. Both the Kindle and Stanza developers want their cut. I haven't priced their options. Perhaps they're cheaper than Amazon's 30%. But I've heard numbers that are much worse.
Also, if I remember correctly, neither the Kindle or the Stanza reader was available when I started this experiment. Things have certainly changed.
The number of people you see whinging on the web about rejections represents a fraction of a percent of the iPhone developer community. Certainly in that number of app reviews, Apple does make mistakes. But your story is one of you being told once what was wrong, and just continuing to resubmit without the problem being fixed.
What fraction? We'll never know but I found it pretty easy to find other complaints. Even more told me that they held their tongue to avoid offending Apple. So the fraction could be pretty large.
As for my app, I fixed the problems that were-- as far as I can tell-- never there in the first place. It was published not once but twice. A twin version, though, was rejected. That strikes me as random and that's why I pretty much concluded that it's dangerous to invest any time, energy or especially money in the platform.
But I'm glad you've had good luck. I hope it stays with you.
No. Of course not. I've been around the world enough to realize that you don't write what I wrote without expecting the immune system to dispense as many white blood cells as it can muster.
If you read TFA, you'll see toward the end that I'm heading toward pure webapps now. They've got their own issues, but they're cross platform and there's no gatekeeper.
Not a single version of the Apps I submitted had the ability to change themselves or allow me to change them remotely. None. Nada.
If they really are doing more than checking for forbidden strings, they would be able to see that quickly by skimming the HTML. It's very boring. Plus, it's easier to read. It's not in binary like many apps.
I don't see how an "external framework"-- the term they used-- has anything to do with this. The rejection note said that I was to make sure that everything was to be "interpreted and run by Apple's Published APIs and built-in interpreter(s)". It's always been that way from the start. It doesn't matter who writes the code.
The only way I can interpret (hah!) what you're saying is to conclude that App development is meant to be like elementary school. You're not supposed to work with others. You're not allowed to use well-tested open source code. You're supposed to write your own code. Why is this wrong? Why is working with others going to give me the magical ability to change how my app works remotely?
Ultimately, it doesn't really matter why Apple rejected my application because many others come away with exactly the same experience even if they don't use PhoneGap: it's all pretty much random. Sometimes you get a cogent rejection note. Sometimes you don't. Sometimes they're fair. Sometimes they're not. It's all a coin flip which is the main point of my piece. It's not about PhoneGap. It's about the randomness and the brick wall and the lack of communication and the absolute power etc.
It's not worth speculating on why Apple rejected my application because I don't know. The notes were short and pretty much inscrutable. Eventually they accepted one version while rejecting one that was pretty much the same thing. So maybe it was some Javascript, but that doesn't sound like it should be against the rules. They only insist that code be "interpreted and run by Apple's Documented APIs and built-in interpreter(s)." Well, it sure sounds like Safari and Javascript fit that definition to me.
When I wrote this piece, I went out of my way to discuss the subject with many other developers. If this were simply a question of my problems, it wouldn't be worth writing. But many other developers are having similar problems with entirely different approaches. That's why I included the long list of adjectives that other developers are using. Go read their posts. Are they all simply dismissed as loons?
Uh, I've addressed this elsewhere.
While BasilBrush seems to feel that it is obvious that PhoneGap is forbidden, it's not spelled out in any of the rule books. Can you point out where? Can you even explain why someone might even come to that conclusion? There's been no answer and Apple never answered any of my emails. When I speak to members of the PhoneGap team-- members who've successfully published many apps-- they tell me that they've been unable to get any worthwhile guidance from Apple.
My reading of the rules tells me that PhoneGap should produce apps that are more compliant because they only push information through one major part of the API, the UIWebView.
So if you can explain what's wrong with the code, I'm sure many would like to understand what's going on.
Useless? Perhaps.
But that's not what my rejection notes said. They prattled on about using a "framework" or misusing some part of the API.
And they also told me I couldn't tell anyone I was giving my revenues to charity.
If it was all as useless as you feel, they could have saved everyone a great deal of time by just stamping "useless" on it from the git-go. Then I wouldn't have wasted time fretting about misusing the API and they would have had one more useless App to reject once again with a passive aggressive reason.
It's possible that Apple has encouraged a great deal of innovation but stifled a great deal more. Imagine that there are 100,000 great apps out there. If they publish, 50k then they've encouraged those. But they've also discouraged 50k.
Given that there are so many complaints about random reviews from all sorts of developers, I think it's fair to say that many feel stifled and discouraged from innovating.
The real issue is much deeper. You can tell whether all the calls are to legit library entry points, but you can't tell if the calls are somehow malicious You're right. The binary will tell you a few things, but it won't tell you everything. I contend that you can't make firm decisions about that without reading the source.
They obviously have scripts that create and check class dumps and search for tell tale strings.
Tell-tale strings are a pretty bad way to search for malicious or dangerous applications. It's fighting the last war.
I'm curious. Why do you say that Apple doesn't allow PhoneGap? Is it spelled out in any rule?
I've read the PhoneGap code. I've read the rules. As far as I can tell, PhoneGap doesn't violate any of them. In fact, it pretty much encourages the developer to write HTML which is-- as Apple insists-- only "interpreted and run by Apple's Documented APIs and built-in interpreter(s)."
I've always assumed that the number of PhoneGap applications accepted by the program support my reading. I've written Apple numerous times. I've tried to discuss it with their engineers. No one will say, "PhoneGap is forbidden."
So how do you know that it is?
I've heard the number 65,000 more recently and it's probably grown since then.
While I don't want to take anything away from the iPhone store or the developers who have the patience to submit their apps to the process, I want to point out that PalmGear.com claims 32,000+ apps for the old Palm platform. That's just one company. If you add in all of the Palm open source applications and what not, I wouldn't be surprised if there are 50,000+. We'll never know because there's not one bottleneck.
And let's not forget Microsoft's PocketPC and Nokia's Symbian. Each of these platforms let users download apps from websites or even swap them with friends.
I think it's entirely possible that each of these three platforms might claim 1, 1.5 or even 2 billion downloads a piece if there was some central tabulating center. But we'll never know.
I thought about this before working on the project and I saw that many other apps were distributing single books. After I tested some of the free ones, I decided that it wasn't a bad system at all. Sure, it added another icon, but I could live with that. When I was done with the book, I was going to delete it anyways to make room for others.
I can understand why you might want a different solution, but it boils down to a question of menu branching. Some people like a shallow tree with many options. Others want a deeper one. So it's a question of taste.
Yes, I did consider that and I may still follow that route in the future. But I like to experiment with new platforms and the iPhone has been one of the shiniest ones around. So I wanted to code it myself.
While I can see why you wouldn't want another app cluttering the springboard, I don't mind it. I picked up a number of books from other devs and liked the experience. So I figured I would go ahead.
Also, you'll notice, for instance, that the book has been available from SiSU archive for some time. http://www.wayner.org/node/5 So that's sort of a solved problem. :-) Not that it can't be revisited.