Wasn't this originally going to be the only way to release apps for iPhones? Later they caved in & allowed native. I didn't get an iPhone until a couple of years after all this though so my history may be off somewhat.
Point being, if true, this was no 'secret' - it was originally plan A.
No, you're exactly right. In fact, when the iPhone was first released, all the pundits and bloggers were practically screaming that it was so unfair that Apple didn't allow developers to write native apps and that HTML web apps were a poor substitute for what you could do natively. They pointed to how Google got to write a custom app for maps, and how it was unfair to competitors who would be locked out.
It was like that for the entire first year of the iPhone. Then, once the app store was announced, it's like all the bloggers and pundits suffered coordinated, selective amnesia. The irritating thing about this article is that the tone suggests this is somehow something Apple would be upset about, when in fact, Apple promotes HTML apps as an alternative to the restrictions of the app store.
The success of the App Store is 80% linked to the fact that it's a frictionless purchasing environment. I can buy an app from some random person for 99 cents and not have to worry that he/she has my credit card number. Furthermore, you're likely to think twice as you go to purchase a 99 cent fart joke app and you're entering your credit card number into a web form. That feels like you're spending money. But punching your password into iTunes rarely (if ever) feels like spending money. Apple is excellent at separating consumers from their money. Developers of App Store apps get to use "the hand of Jobs" to ply your cash from your wallet.
I suspect that if Apple allowed web apps to bill against itunes accounts, you'd see a huge explosion of pay iPhone-optimized web apps that would otherwise go into the App Store. With a little bit of Safari integration, you could allow developers to put little "buy now" buttons on their web apps and it would feel just like an app store purchase. I doubt Apple would ever roll out such a feature, since it sounds like it would be minimal benefit but have a fair number of headaches.
There are many types of utility apps (say a unit converter or tip calculator) that would be perfect as a web app.
With support for localstorage and cache manifests, the app can be available offline as well and can even have a nice optimized icon to put on the home screen and a splash screen to show.
The only drawback I currently see is that every time you load the web app it first checks with the server (for changes) before letting you interact with it.
Actually it is. "app-style experience" is the easy part - but there's more examples of bad then good.
The failing is when HTML/JS needs to do 'heavy lifting' that native code does better (such as large memory based tasks, 3d rendering for now, animations, heavy math, or hooking into hardware).
If there are many more examples of bad than good, and for JS apps, this is a dramatic understatement, this is a great pragmatic definition of it not being good for apps.
For example, I've never played a JS/Canvas game for the sake of it being a good game. Has anyone? I see a lot of frameworks, and a lot of demos to advocate for the platform, but no good games. Why is this? At this point, the novelty of the platform is no longer an excuse. It has been a forum darling for several years now.
Sadly this is true. Canvas is still very much in its infancy. I see two main issues with Canvas for games right now.
First, canvas really needs to be hardware accelerated (someone already does this, Microsoft?). Having a few objects move around should barely take any CPU but with Canvas today it can be anywhere from 10%-20%.
Second, their needs to be game engines/abstractions on top of Canvas. Most developers don't want to have to write there own render/clear loop with all the utility functions to do movement, render shapes, texture elements, and keep object state. I know their are a few out there now but they are no where near the quality needed. This second step will not happen until my first point (HW acceleration) is in place.
Writing you a snarky reply about your misuse of "their" and "there" and erasing it was somewhat cathartic. But not enough, so I had to write this. Please make sure that you can use some of the most basic building blocks of your native language.
Without going into flamewar about native vs. HTML5, HTML5 apps have their pros and cons. But they still need a commercial distribution channel. People should be able to buy HTML5 apps as simply as they buy native apps.
The OpenAppMkt app has a nice interface for being HTML only -- wonder how they got the fixed position buttons on the bottom while allowing scrolling in the body of the page?
As far as I knew, that was impossible due to Safari Mobile on the iPhone not supporting fixed position elements.
It's about control of distribution. Apple clearly is cool with HTML5, that isn't new. Everyone is also right that Apple clearly dominates distribution, but it's not an absolute lock. The only way you can ever wrestle control away from Apple is if someone creates an alternative, which is what OpenAppMkt has started. Just because it's not huge now, or it's not dominate now, doesn't mean that it can't become a player in the future.
Apple could "stop" this very easily. Don't allow access to native hardware APIs through the browser via JavaScript; thus, making "webapps" inferior to "native apps" based on capabilities of interacting with the hardware.
I've often wondered just how many people have ever used the "add to home screen" button, or even really noticed it. I assumed for a long time that the "+" icon just added a bookmark to mobile Safari.
Note that HN is clearly not a good sample group to poll this.
People hate the App store regardless of the iPhones HTML app capacity because they want what the App store offers without the compromise that Apple makes them take.
They want centralized marketing, distribution, security and payment handling which the HTML option doesn't have. They could build a website selling these apps if they wanted, but that would be work outside of developing, which they don't want to do.
Everyone wants to be on the App Store because that's where you go for apps. You don't Google for "html iPad App RSS reader". So no one is going to install your app.
With the recent security issues with Android phones (this will happen with Apple apps too, but maybe to a smaller degree) Apple's controls are looking nicer and nicer.
Sour grapes.
Also, what's with the title "which Apple can't stop". You're thumbing your nose at Apple with a feature they developed and encouraged?
I was with you until the end, where you start pretending that Apple's guidelines are capable of preventing malware. Take a look at the kind of stuff they reject apps for and tell me this is a process that has anything to do with security.
I mean, remember just a few days ago, when a 15-year-old released a tethering app right under Apple's nose? Remember a year ago when everyone was outraged because an iPhone app covertly uploaded your whole address book to the developer's server? This Android app is arguably less of a violation than that one. They only check the visible behavior of your program and whether you're using private API. As long as you don't throw up a dialog that says "DURRR, I'M STEALIN UR INFO NOW MAN," Apple isn't really looking for you.
It wasn't a true "teathering" app. It was just a flashlight app that also opened up a SOCKS proxy within the app. Its very possibly that if the App also had network code for loading ads, say through iAds or AdMob, that an API scanner wouldn't notice anything unusual for a reviewer to feel concerned about.
Apple did find an app that exploited an App Store feature that you only need to type in your iTunes password once for a period of 5 minutes -- allowing you to DL multiple apps with minimum hassle. An app used its in-app content purchase to bill buyers for $200 worth on content it purchases without the user's explicit consent.
Apple may not be looking out for you in general, but they looking out for their brand, which is tied to consumer experience.
Its very possibly that if the App also had network code for loading ads, say through iAds or AdMob, that an API scanner wouldn't notice anything unusual for a reviewer to feel concerned about.
That's precisely the point. They can't catch underhanded code in the app unless they do a full source code audit - and honestly, I wouldn't be the least bit surprised if Apple changed the SDK license to require developers to upload their .xcodeproj files which get built and released from Apple's servers directly.
I'm not sure even a full code-audit is practical. Some big vendors use libraries under licenses that don't allow them to distribute the source to third parties (I don't know how prevalent this is on iPhone, but I know it happens in general), and Apple has shown an aversion to rules that mess with the big guns this way. It would also require a much higher caliber of app testers, because finding malicious code in a large codebase is nontrivial even if the malware writer isn't being particularly clever.
This would basically require Apple to severely choke the App Store pipeline, and given Apple's relatively lax attitude toward security, I don't think they'd make that tradeoff.
Regarding: With the recent security issues with Android phones (this will happen with Apple apps too, but maybe to a smaller degree) Apple's controls are looking nicer and nicer.
I respectfully disagree. App approval process has nothing, repeat nothing, to do with security.
As an example I can create a time-bomb app, which does nothing nasty for 6 months and then once it is deployed on several Apple devices it begins to do whatever it was programmed to do.
There is no way an app approval process can handle that or catch that. That requires disassembly and careful analysis of the source or disassembled code.
That apps on Apple's devices are more secure is an illusion.
"That apps on Apple's devices are more secure is an illusion."
Yeah, and careful sandboxing of each app and control of the functions you use has nothing to do with security either.
Apple knows what functions you use and when, and the data you send receive using them. They know the format, nothing else is needed. That's one of the reason they only let you use documented calls.
For me its easy to make a software that monitors that activity,so with so many people smarter than me, I can not imagine that Apple has not done it. I know they have automated tools for analyzing Apps proposals, so I'm confident they monitor live the apps activity.
They want centralized marketing, distribution, security and payment handling which the HTML option doesn't have. They could build a website selling these apps if they wanted, but that would be work outside of developing, which they don't want to do.
Actually, no, I don't think I've ever heard anyone complain about lack of a central marketing and distribution channel.
Having one is nice but many developers would do away with it if it also means doing away with Apple's draconian control policies.
In any case, the argument is bogus because there's no reason why you can't have both except that it doesn't directly serve Apple's interests.
