I don't this app will be approved, for what it's worth, but I see more in Tulkas' logic than yours anonymouse.
Quote:
Originally Posted by anonymouse
I'd be completely and utterly shocked if it were approved because a) it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement
So you're saying "duplicates core functionality". Which is probably fair enough.
Quote:
Originally Posted by anonymouse
It seems pretty obvious to me. It launches other executable code on Opera's proxy's, thus falling foul of at least the "otherwise" clause. It uses interpreted code not run by Apple's Documented APIs and built-in interpreter(s) by running JavaScript on those proxies. The quoted restriction doesn't limit itself to "other executable code" or interpreters located on the iPhone. Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
This is an idiotic interpretation at best. Every web request must necessary result in code being executed on the other end. Thus, by your interpretation, anything that connects to the internet must not be acceptable.
Surely Apple must mean within the context of the four wall of their device. Any other interpretation is asinine.
Apple API does not do your work for you as a programmer. You are still expected to write the code, using the provided API when necessary. Opera could written their own decompression algorithm. That in and of itself is not a violation of the SDK, at least not the clause quoted.
How does a decompression engine violate this:
"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)."?
Any decompression will be built into the app, so it would't be launching (or installing) additional executable code. Decompressing a data stream is not the same as interpreting or executing additional code. If Opera's implementation does rely on interpreted code or launching additional executable code, outside of their app (not on a server), then yes, they are in violation. I just don't see how you can say decompressing data is in violation, simply by being decompression.
Apple offer developers UIWebView API for displaying webpages. Opera admitted that they are using their "own little language" for the front-end. Therefore, they are are using a non Apple documented API. If a developer want to display webpages then he/she will have to use Apple's UIWebView class. If a developer is not using UIWebView to view webpages then he is violating the mentioned clause.
I don't know why this is hard for you to understand.
Even if you don't want to use it for banking and stuff like that, it can still be used for reading news, etc.
I'm pretty sure that Apple doesn't want users to have to be thinking with iPhone apps, "Is it OK for me to use this app in these circumstances?" Sort of undermines the whole user experience to satisfy an extremely tiny minority of users.
With Opera mini, you're not only not getting "the full internet," you're getting compressed renderings of web pages filtered through internet proxies you have no control over. You might as well be behind the great firewall of China.
So are you saying that Opera is censoring sites? If not, then what on earth is the GFW comparison all about?
Quote:
Originally Posted by NasserAE
Opera knows this app will be rejected because the app violates the iPhone SDK agreement. Everyone knew that since the first public release of the app store.
Except Opera Mini doesn't execute code. All JS handing is done on the server, not on the Opera Mini client.
Quote:
Originally Posted by pumpkinhead
On the other hand, I work at a carrier and as someone who builds web apps that have to support multiple browsers on a device, including Opera Mini, it can be a major pain.
You'd better get used to it. Opera Mini has more than 50 million users, and adds new users at a rate of 4-5 million a month or so. Active users, that is. Not just downloads.
Quote:
And there seems to be a long list of sites that Opera mini can't handle and has to bump them into the handset's native browser, confusing them further.
Most of them is probably because of browser sniffing.
it is, as you point out, "dangerous" because it, "doesn't provide any of the standard protections people expect to be there,"
This is clearly nonsense.
Quote:
Opera are clearly baiting Apple, in a rather childish manner, in fact.
Baiting? LOL. Opera is doing PR. Nothing childish about that.
Quote:
I think this is a slam-dunk rejection for violating the developer agreement
Which is nonsense because it doesn't execute code on the client.
Quote:
and for undermining the iPhone user experience and security
Again, nonsense. It's even more secure than Safari because all code is executed remotely, not on the phone.
Quote:
It's not like more than a handful of people care about Opera anyway, and it's not like it offers anything useful without also bringing huge downsides with it.
Opera Mini has more than 50 million users. I guess you are saying that no one cares about the iPhone either, then?
This is an idiotic interpretation at best. Every web request must necessary result in code being executed on the other end. Thus, by your interpretation, anything that connects to the internet must not be acceptable.
Only, if as pointed out countless times (ok, a bit of hyperbole, but won't people bother to actually read?) in this thread, if you ignore this part of my post:
Quote:
Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
I'm pretty sure that Apple doesn't want users to have to be thinking with iPhone apps, "Is it OK for me to use this app in these circumstances?" Sort of undermines the whole user experience to satisfy an extremely tiny minority of users.
Users don't have to think about that. Only paranoid people will be worried. Opera has an excellent privacy track record.
Seriously, "Tulkas"??? you filled pages and pages of writing and I've read it all and you just don't have any argument against what anonymouse is saying. Nothing. Nada.
Anonymouse like all of us, could turn out to be wrong, but nothing you have said indicates that in any way. You are just being bitchy and harping about perceived details in conversations that didn't actually even happen the way you thought they did.
Really, which point that anonymouse has posted, especially his first post since he referenced it again, has any merit? I have repeatedly, and clearly explained the faults in his 'reasons'. If you are not capable of reading the fairly simple posts, do not try to blame that limitation on my bitchiness.
It isn't that he and you could turn out to be wrong. But that nothing he has asserted has a basis in fact or reason. He claims it violates this and that, yet cannot back any of it up. I could claim it will be rejected because their logo is red. How does one argue against that sort of assertion? You could ask for proof, but that won't happen.
The 'perceived' details are simply what he posted. Perhaps you could give an example were I have railed against something he didn't post? I guess this should be expected from someone that thinks Opera isn't a browser.
I'll only bother responding to this point. It's not more secure than Safari because your SSL connections are not encrypted end-to-end.
It is more secure because any malicious code aimed at taking over the phone is executed on the server rather than the phone itself, making the phone safer.
Users don't have to think about that. Only paranoid people will be worried. Opera has an excellent privacy track record.
You can discount this issue if you wish, but Opera's behavior in this regard is contrary to everything people have come to expect in sending "private" information over the web. And, it's not paranoia to worry about it, it's stupidity not to.
Apple offer developers UIWebView API for displaying webpages. Opera admitted that they are using their "own little language" for the front-end. Therefore, they are are using a non Apple documented API. If a developer want to display webpages then he/she will have to use Apple's UIWebView class. If a developer is not using UIWebView to view webpages then he is violating the mentioned clause.
I don't know why this is hard for you to understand.
Apple offers the API, but that doesn't demand that you have to use their API for every function of your app. If they are using their own API, then of course it is an undocumented API. (This should not be confused with using an undocumented Apple API). That clause does not state that devs are restricted to using Apple provided APIs and only Apple provided APIs. If the SDK has such a restriction, that clause is not it.
It is more secure because any malicious code aimed at taking over the phone is executed on the server rather than the phone itself, making the phone safer.
That doesn't necessarily make it more secure (ignoring the SSL issue for the time being). It's still at least possible that someone can develop an exploit that causes the server to send data to the browser that causes it to perform a malicious action.
Apple offers the API, but that doesn't demand that you have to use their API for every function of your app. If they are using their own API, then of course it is an undocumented API. (This should not be confused with using an undocumented Apple API). That clause does not state that devs are restricted to using Apple provided APIs and only Apple provided APIs. If the SDK has such a restriction, that clause is not it.
Really?!
Quote:
"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)."
"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 can't get clearer than that.
Oh f me gently. Do we really need to have a refresher course on interpreted vs compiled code?
Edit: ok, maybe that came off a bit harsh.
We can be pretty sure Opera won't be implementing their decompression in Java or python or some other interpreted language. Their browser will be a native Obj-C/C app and will implement their decompression in C or ObjC, i.e. compiled code. A restriction prohibiting interpreted code does not prohibit them from writing a native app that uses code not directly referenced from the iPhone API.
Oh f me gently. Do we really need to have a refresher course on interpreted vs compiled code?
Edit: ok, maybe that came off a bit harsh.
We can be pretty sure Opera won't be implementing their decompression in Java or python or some other interpreted language. Their browser will be a native Obj-C/C app and will implement their decompression in C or ObjC, i.e. compiled code. A restriction prohibiting interpreted code does not prohibit them from writing a native app that uses code not directly used from the iPhone SDK.
If taken at face value, the restrictions would ban seemingly innocuous apps, according to a blog entry made by Mozilla developer Rob Sayre. Besides the Firefox web browser made by his own company, programs such as Opera and Excel would be forbidden from running on the phone as-is due to their uses of scripting language inside the software. Even some games that use an interpretive language in the background, such as Quake, would also be barred from the iPhone.
That article is from before a single native app was released and was speculation from a Mozilla dev regarding Opera. Not an Opera dev regarding Opera Mini.
The inclusion of their own interpreter would be a problem, if they are including an interpretter. Not related to their implementation of data decompression with in their app.
Comments
I'd be completely and utterly shocked if it were approved because a) it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement
So you're saying "duplicates core functionality". Which is probably fair enough.
It seems pretty obvious to me. It launches other executable code on Opera's proxy's, thus falling foul of at least the "otherwise" clause. It uses interpreted code not run by Apple's Documented APIs and built-in interpreter(s) by running JavaScript on those proxies. The quoted restriction doesn't limit itself to "other executable code" or interpreters located on the iPhone. Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
This is an idiotic interpretation at best. Every web request must necessary result in code being executed on the other end. Thus, by your interpretation, anything that connects to the internet must not be acceptable.
Surely Apple must mean within the context of the four wall of their device. Any other interpretation is asinine.
Apple API does not do your work for you as a programmer. You are still expected to write the code, using the provided API when necessary. Opera could written their own decompression algorithm. That in and of itself is not a violation of the SDK, at least not the clause quoted.
How does a decompression engine violate this:
"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)."?
Any decompression will be built into the app, so it would't be launching (or installing) additional executable code. Decompressing a data stream is not the same as interpreting or executing additional code. If Opera's implementation does rely on interpreted code or launching additional executable code, outside of their app (not on a server), then yes, they are in violation. I just don't see how you can say decompressing data is in violation, simply by being decompression.
Apple offer developers UIWebView API for displaying webpages. Opera admitted that they are using their "own little language" for the front-end. Therefore, they are are using a non Apple documented API. If a developer want to display webpages then he/she will have to use Apple's UIWebView class. If a developer is not using UIWebView to view webpages then he is violating the mentioned clause.
I don't know why this is hard for you to understand.
Even if you don't want to use it for banking and stuff like that, it can still be used for reading news, etc.
I'm pretty sure that Apple doesn't want users to have to be thinking with iPhone apps, "Is it OK for me to use this app in these circumstances?" Sort of undermines the whole user experience to satisfy an extremely tiny minority of users.
With Opera mini, you're not only not getting "the full internet," you're getting compressed renderings of web pages filtered through internet proxies you have no control over. You might as well be behind the great firewall of China.
So are you saying that Opera is censoring sites? If not, then what on earth is the GFW comparison all about?
Opera knows this app will be rejected because the app violates the iPhone SDK agreement. Everyone knew that since the first public release of the app store.
Except Opera Mini doesn't execute code. All JS handing is done on the server, not on the Opera Mini client.
On the other hand, I work at a carrier and as someone who builds web apps that have to support multiple browsers on a device, including Opera Mini, it can be a major pain.
You'd better get used to it. Opera Mini has more than 50 million users, and adds new users at a rate of 4-5 million a month or so. Active users, that is. Not just downloads.
And there seems to be a long list of sites that Opera mini can't handle and has to bump them into the handset's native browser, confusing them further.
Most of them is probably because of browser sniffing.
it is, as you point out, "dangerous" because it, "doesn't provide any of the standard protections people expect to be there,"
This is clearly nonsense.
Opera are clearly baiting Apple, in a rather childish manner, in fact.
Baiting? LOL. Opera is doing PR. Nothing childish about that.
I think this is a slam-dunk rejection for violating the developer agreement
Which is nonsense because it doesn't execute code on the client.
and for undermining the iPhone user experience and security
Again, nonsense. It's even more secure than Safari because all code is executed remotely, not on the phone.
It's not like more than a handful of people care about Opera anyway, and it's not like it offers anything useful without also bringing huge downsides with it.
Opera Mini has more than 50 million users. I guess you are saying that no one cares about the iPhone either, then?
This is an idiotic interpretation at best. Every web request must necessary result in code being executed on the other end. Thus, by your interpretation, anything that connects to the internet must not be acceptable.
Only, if as pointed out countless times (ok, a bit of hyperbole, but won't people bother to actually read?) in this thread, if you ignore this part of my post:
Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
I'm pretty sure that Apple doesn't want users to have to be thinking with iPhone apps, "Is it OK for me to use this app in these circumstances?" Sort of undermines the whole user experience to satisfy an extremely tiny minority of users.
Users don't have to think about that. Only paranoid people will be worried. Opera has an excellent privacy track record.
Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
And Opera doesn't execute code on the phone. It's executed on Opera's servers. What's sent to the phone is basically an image.
Again, nonsense. It's even more secure than Safari because all code is executed remotely, not on the phone.
I'll only bother responding to this point. It's not more secure than Safari because your SSL connections are not encrypted end-to-end.
Anonymouse wins the thread! Yay!
Seriously, "Tulkas"??? you filled pages and pages of writing and I've read it all and you just don't have any argument against what anonymouse is saying. Nothing. Nada.
Anonymouse like all of us, could turn out to be wrong, but nothing you have said indicates that in any way. You are just being bitchy and harping about perceived details in conversations that didn't actually even happen the way you thought they did.
Really, which point that anonymouse has posted, especially his first post since he referenced it again, has any merit? I have repeatedly, and clearly explained the faults in his 'reasons'. If you are not capable of reading the fairly simple posts, do not try to blame that limitation on my bitchiness.
It isn't that he and you could turn out to be wrong. But that nothing he has asserted has a basis in fact or reason. He claims it violates this and that, yet cannot back any of it up. I could claim it will be rejected because their logo is red. How does one argue against that sort of assertion? You could ask for proof, but that won't happen.
The 'perceived' details are simply what he posted. Perhaps you could give an example were I have railed against something he didn't post? I guess this should be expected from someone that thinks Opera isn't a browser.
There's been speculation that opera is trying to bait Apple into a trap here.
What kind of trap might that be?
This conspiracy nonsense needs to stop. All Opera wants is to get more users, and the iPhone is an untapped user base of millions.
I'll only bother responding to this point. It's not more secure than Safari because your SSL connections are not encrypted end-to-end.
It is more secure because any malicious code aimed at taking over the phone is executed on the server rather than the phone itself, making the phone safer.
Users don't have to think about that. Only paranoid people will be worried. Opera has an excellent privacy track record.
You can discount this issue if you wish, but Opera's behavior in this regard is contrary to everything people have come to expect in sending "private" information over the web. And, it's not paranoia to worry about it, it's stupidity not to.
And Opera doesn't execute code on the phone. It's executed on Opera's servers. What's sent to the phone is basically an image.
Now you're just ignoring the first part of the post.
Apple offer developers UIWebView API for displaying webpages. Opera admitted that they are using their "own little language" for the front-end. Therefore, they are are using a non Apple documented API. If a developer want to display webpages then he/she will have to use Apple's UIWebView class. If a developer is not using UIWebView to view webpages then he is violating the mentioned clause.
I don't know why this is hard for you to understand.
Apple offers the API, but that doesn't demand that you have to use their API for every function of your app. If they are using their own API, then of course it is an undocumented API. (This should not be confused with using an undocumented Apple API). That clause does not state that devs are restricted to using Apple provided APIs and only Apple provided APIs. If the SDK has such a restriction, that clause is not it.
It is more secure because any malicious code aimed at taking over the phone is executed on the server rather than the phone itself, making the phone safer.
That doesn't necessarily make it more secure (ignoring the SSL issue for the time being). It's still at least possible that someone can develop an exploit that causes the server to send data to the browser that causes it to perform a malicious action.
Apple offers the API, but that doesn't demand that you have to use their API for every function of your app. If they are using their own API, then of course it is an undocumented API. (This should not be confused with using an undocumented Apple API). That clause does not state that devs are restricted to using Apple provided APIs and only Apple provided APIs. If the SDK has such a restriction, that clause is not it.
Really?!
"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 can't get clearer than that.
Really?!
"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 can't get clearer than that.
Oh f me gently. Do we really need to have a refresher course on interpreted vs compiled code?
Edit: ok, maybe that came off a bit harsh.
We can be pretty sure Opera won't be implementing their decompression in Java or python or some other interpreted language. Their browser will be a native Obj-C/C app and will implement their decompression in C or ObjC, i.e. compiled code. A restriction prohibiting interpreted code does not prohibit them from writing a native app that uses code not directly referenced from the iPhone API.
Oh f me gently. Do we really need to have a refresher course on interpreted vs compiled code?
Edit: ok, maybe that came off a bit harsh.
We can be pretty sure Opera won't be implementing their decompression in Java or python or some other interpreted language. Their browser will be a native Obj-C/C app and will implement their decompression in C or ObjC, i.e. compiled code. A restriction prohibiting interpreted code does not prohibit them from writing a native app that uses code not directly used from the iPhone SDK.
This will help you understand what that clause mean and how it applies to Opera app.
If taken at face value, the restrictions would ban seemingly innocuous apps, according to a blog entry made by Mozilla developer Rob Sayre. Besides the Firefox web browser made by his own company, programs such as Opera and Excel would be forbidden from running on the phone as-is due to their uses of scripting language inside the software. Even some games that use an interpretive language in the background, such as Quake, would also be barred from the iPhone.
This will help you understand what that clause mean and how it applies to Opera app.
That article is from before a single native app was released and was speculation from a Mozilla dev regarding Opera. Not an Opera dev regarding Opera Mini.
The inclusion of their own interpreter would be a problem, if they are including an interpretter. Not related to their implementation of data decompression with in their app.