You still have to push the apk and stay alert for the feedback, but you have to be careful with web apps update too anyway.
I'm not sure about Apple because it appears the auto-update process is not that smooth and people don't upgrade their app as often as Android users.
Beside that I think virmundi above has his points, and I agree with him. App updates are not instantaneous.
The auto-update process on iOS is basically the same as recent versions of Android: check a box for completely automatic background updates or see a notification with the available update count and an “Update everything” button. The main difference is for things like games which hit the legacy 100MB cellular transfer limit which Apple added back when AT&T had grossly underprovisioned their network.
What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data?
> Notify the users to keep their equipment on the network from time X to Y
Not your problem. Have your packaged app in the place its expected to be updated from (a HTTPS server for something like Sparkle framework, and/or the respective App stores).
The client will periodically check for updates and download the new version.
If your back-end functionality somehow changes in a way that breaks the old version (or something changes such that the old version cannot be allowed to operate, such as a law changing) - you simply use a versioned API in your backend, and respond to requests to the old version of the API, with an error message telling user an update is required.
> Your app is not the product. Your app is tool to get the product: information
That makes a huge assumption about the purpose of the app. If the app in question is a game, or an image editor, or a word processor or any number of other types of app - the app very much is the product.
> If it lacks UX for native, don't target native. Target app-y
And say goodbye to customers. People like the experience of a real native app.
The web has supported this for years, but few use it.
If the data is tied to a browser, how do I back it up/save a copy of it? How do I persist it when the browsers local settings/cache are cleared (either by clearing or eg. when the OS is installed)?
I meant your wording was strange. I had to reread it several times to understand what you meant, and I think the parent poster also didn't understand what you meant.
If the data is tied to a browser, how do I back it up/save a copy of it?
In Firefox, back up your profile.
How do I persist it when the browsers local settings/cache are cleared (either by clearing or eg. when the OS is installed)?
If you clear it intentionally then why should it persist?
that's hardly the same as having a file i can copy and use anywhere.
> If you clear it intentionally then why should it persist?
In Safari at least, "local storage" is cleared when clearing other data like cookies etc. I would imagine that's not unique to Safari.
You also failed to cover the concept of "the OS is re-installed" or "a new device is purchased".
"Backup your firefox profile" is an unbelievably short-sighted suggestion - am I supposed to keep transporting a Firefox profile around forever? What if I want to use a different browser? What if I want to use my data on a device that doesn't expose the raw filesystem to the user, and thus I can't copy my profile to the correct location (assuming it was even binary compatible)?
I can't believe I have to explain the benefits of a regular file with data in it, to a directory containing a mix of browsing history, cookies, crash dumps, plugin information, and somewhere, an SQLite database containing my data.
Yes?
It's like asking whether you should keep your homedir or Windows Roaming User folder around forever. If you want your data and/or settings, you do. And both of those fit the description in your last line pretty well.
You're offended at the suggestion but it's the same way it works in native apps in reality.
No it isn't. A Firefox profile is a folder full of a mishmash of data, the vast majority of which is inherently not data I want to keep.
I deliberately don't keep my entire home folder when I re-install/upgrade OS X. I get much better results taking a short time to re-set a few preferences than deal with the effects of a carried-over ~/Library folder.
That's exactly what the Firefox profile folder is like - it's not just user data from local storage, it's fucking cookies and crash dumps and shit. Why would I ever want to keep that stuff forever?
> it's the same way it works in native apps in reality
It just really isn't, and it's not surprising that you chose to ignore all the other issues I raised with this suggested "solution".
* the customer is powerless when it comes to deciding whether to upgrade when e.g. the company decides to change strategies.
* the customer data lies unsecured, covered by a standard privacy policy in some foreign jurisdiction somewhere. HTTPS by itself is useless when the data is available to pretty much anyone working at the company and in some cases the server providers too. I think this covers 99% of web services out there like Evernote, Dropbox, FB, Google's stuff, etc.
Apparently, these things called "app stores" are so good, that on these new things called "mobile devices," native apps are more popular than web applications!
Sorry for being a pedantic. Updating applications is quite painless on every platform except for Windows. (On Mac, you can use the app store or include Sparkle in your application.) It's only Windows that makes updating difficult; and this is the fundamental weakness of the operating system.
To me there should be a bit of a feeling when to use native vs web on mobile. If you're making a fairly static, pretty booklet app, I'd use web. Cordova makes this simple and clean. If your moving much beyond that, from personal experience, I'd go native. I've tried all of the free-to-type hybrids. The tools try to smooth over the issues of complex API centralize business logic in JS while having multiple views to target different OSs. Sadly, most only really support iOS. For example, Ionic tries to support Android, but it's general appearance is iOS. Appcelerator is the same.
I've done it. The one thing it requires is a lot of coordination. Notify the users to keep their equipment on the network from time X to Y. Notify the infrastructure team to schedule a push. Have the dev team on standby in case the push goes bad. Have the software protect itself when inevitably someone's install is corrupted or skipped.
Compare that to the web. User opens Chrome; they get the new app. No push. No real notification of any team. Hell, Ops probably doesn't have to be notified if they automated web app deployment to servers. The whole thing is very easy. Even if you have the added complexity of a Chrome-app wrapper, still pretty easy.
Given the ease of deployment and the mitigated risk of data corruption due to version issues of the app, the web looks pretty good. Given the advancement of hardware and software, UX can be close to native. If not native, app-y for lack of a better word.
If it lacks UX for native, don't target native. Target app-y. This is between native and document. It might become complex to manage local state, but that shouldn't be a deterrent.
Tangentially related, to the general question: does the user want to have a link to your product on their desktop? The answer is probably no. They want easy access to your product, but the link conflates how this occurs with a sense of permanence. Your app is not the product. Your app is tool to get the product: information. UX and installation are both just means to the end.