That makes no sense ... apps that run in Mobile Safari get Nitro, native apps that use a browser component use the old JS engine. How is that boosting the App Store?
I'm not saying I agree that it's intentional, but I do agree that the result boosts the app store. It does so because you have to write the app for iOS rather than HTML5. If you wrote it for HTML 5 it would be lot less work to write a Android / Chrome / generic HTML 5 version.
Monetizing a pure web app is a lot more difficult than monetizing an app-store app. It may be coincidence that HTML5 is a developer friendly way of creating a multiplatform mobile app and that Apple has kneecapped HTML5 offline apps via the architecture of iOS.
HTML5 applications run from the browser, where they are most likely to be executed, are going to be fine. The fact that locally installed offline webclips don't have Nitro is frankly, honestly, an oversight. This really has nothing to do with native vs. HTML, it has to do with the browser vs. third party apps.
The only way to stop the jailbreakers is to not release the physical device. I suppose the jailbreakme.com website from iOS<=4.0.1 made jailbreaking extremely easy even for the non tech savvy, but even the "harder" jailbreaks are just programs that can easily be installed on Windows and they do everything for you.
While you're most certainly right, Jailbreaks aren't hard as long as you don't accidentally update too soon, they're not plentiful enough that @comex et al can waste exploits yet with 0 day releases timed with Apple's releases.
If they opened nitro access to non-mobile safari people, I'm guessing they would have tons.
I honestly expect nitro access to open plenty of new avenues.
Oh most certainly. However, I'm going to say there is at least one serious security flaw out and published every release (the currently used one by jail breakers) that can be used access usually. Generally speaking, you can just use that one for worms, rootkits, etc if the web is your attack vector (not all of them are that easy to exploit unaware, but many of them are).
I really, really need to get this fixed, we're in the middle of selling a web-based ipad app to a very large client, utilizing the local caching. This is a terrible bug for me :(
Don't open source operating systems have the same problem? It's legally and technically possible to fix or improve the system, but you may not have the skill or time. You also have to convince the maintainers to accept your patch and wait for your users to upgrade.
No matter what system you write for, you have to work with what you've got. All open source lets you do is fork it and distribute your own version of the OS.
That's true enough, but there's a bigger distinction, isn't there? Maybe the better golden rule for developing for iOS is "work with what Apple will let you"?
My point being Windows developers do not have exactly the same problems.
I'm surprised the local caching hasn't gotten the media spotlight as that's been broken since 4.2.1. and is more important for web apps aiming to replace native apps.
It's sad that Apple has a disincentive against improving web-based dev tools. On my own project, I keep bumping up against unnecessary limitations on touch and focus events for form fields.
For what it's worth, local caching should still work fine, either in Safari or UIWebView, so long as it doesn't involve natively executed ARM code.
Did you try and package fallback versions of files into a native app and load them with a UIWebView unless there's an internet connection?
It's not perfect, but it could save your ass until they fix the bug. Afterwards, make sure you don't forget how much Apple cares about you if you're not in line with their objectives :-)
Mmmm. I'm no Apple fan but in this case I have to say this is paranoia. But we have to see if they fix it, at least for web applications saved to the home screen. Are those not just links opening up mobile safari?
I don't buy the security argument. If it's available to web application can they not take advantage of security bugs in nitro?
Oh and while there fixing stuff for web apps could they please get WebGL in a release real soon :) That would make my day.
This really has the stink of sensationalism, Ars. Xpost from another thread:
I don't have any idea where the truth lies, here, but it's worth pulling the whole paragraph:
But according to Matt Asay, who is vice president of business development for mobile Web framework maker Strobe, Apple supposedly has no plans to fix them. Instead, they are marked "not to be fixed by exec order," suggesting that a higher up at Apple is preventing engineers from fixing the problems.
"Supposedly" and "suggested" let Ars weasel out of determining the truth of these assertions. Unless Apple has suddenly turned absurdly transparent, I have a hard time believing that this guy actually has any inside knowledge. On the other hand, he certainly has an incentive to bring pressure on Apple to make his business work better.
Meanwhile, the author of Cydia, saurik, points out:
Apple can't turn on the ability to do executable, dynamically written to memory pages just for their library: they'd have to turn it on for the entire process, at which point you could also do crazy things like download native code and execute it, bypassing the entire concept of their "codesign" mechanism.
It's starting to sound less and less like Apple is doing anything shady here. Remember that RIM is having people disable JS entirely because of a WebKit exploit. This is a snarly problem.
WebSheet.app is obviously not doing anything MobileSafari.app isn't. I'd like to see this bug marked "not to be fixed by exec order" with my own eyes, after which I will disregard Objective C as easily as rounded-corners and transparent PNGs in IE6.
Not ever a problem I've had with Free Software. The walled garden is great until you realize that they are filling it with water and you don't know how to swim.
