6 ms·

What about the benefit that the web brings to updating the user's install? I know that it is technically possible to push a new Java or .NET app out to users.

What about the benefit that the web brings to updating the user's install? I know that it is technically possible to push a new Java or .NET app out to users. 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.

eloisant 11y ago
To be honest, Google takes care of all the complexity to have apps updated on Android. It's even better, because you can do a stage rollout really easily (i.e. just deploy to 10% of users, then 20%, then 50%, etc.). It's possible to do on a web app but you'll have to do it manually. 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.
- frik 11y ago
  Auto-updates are great except in the rare cases where they aren't at all. Picking up my phone in the morning to recognize that it lost half its battery in the night due an extensive auto update and being left in the cold with a 10% battery (instead of 60%) isn't that great. Beside that I think virmundi above has his points, and I agree with him. App updates are not instantaneous.
  - jpadkins 11y ago
    i think the default setting for new android releases is only update on wifi and plugged in.
    - s73v3r 11y ago
      I looked, and you can tell it to only update when on wifi, but the Play Store has no setting that I could find to only update when plugged in.
  - kaolinite 11y ago
    As of iOS 8, apps will only update automatically when the phone is plugged in to charge and connected to WiFi.
- acdha 11y ago
  > 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. 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.
gwbas1c 11y ago
Ever hear of these things called "app stores?" I hear they make pushing apps quite seamless. 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.
- virmundi 11y ago
  I've heard plenty of people on HN bemoan the process of pushing updates out via Apple. You can have a critical bug (yes, yes better testing), but it can take the store up to a week to review, approve and deploy your app. Sure there are ways to expedite that, but should you have to be so concerned? 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.
stephenr 11y ago
> What about the benefit that the web brings to updating the user's install 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.
- TazeTSchnitzel 11y ago
  > What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data? The web has supported this for years, but few use it.
  - stephenr 11y ago
    Care to name the technology that allows a browser app to read/write file data to local storage that isn't inherently tied to the browser?
    - TazeTSchnitzel 11y ago
      Why is it being tied to the browser a problem?
      - rockdoe 11y ago
blub 11y ago
This ease of updating can be beneficial for some types of software (e.g intranet LOB). I have two issues with it for consumer software: * 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.

eloisant 11y ago

To be honest, Google takes care of all the complexity to have apps updated on Android. It's even better, because you can do a stage rollout really easily (i.e. just deploy to 10% of users, then 20%, then 50%, etc.). It's possible to do on a web app but you'll have to do it manually. 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.

frik 11y ago
Auto-updates are great except in the rare cases where they aren't at all. Picking up my phone in the morning to recognize that it lost half its battery in the night due an extensive auto update and being left in the cold with a 10% battery (instead of 60%) isn't that great. Beside that I think virmundi above has his points, and I agree with him. App updates are not instantaneous.
- jpadkins 11y ago
  i think the default setting for new android releases is only update on wifi and plugged in.
  - s73v3r 11y ago
    I looked, and you can tell it to only update when on wifi, but the Play Store has no setting that I could find to only update when plugged in.
- kaolinite 11y ago
  As of iOS 8, apps will only update automatically when the phone is plugged in to charge and connected to WiFi.
acdha 11y ago
> 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. 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.

gwbas1c 11y ago

Ever hear of these things called "app stores?" I hear they make pushing apps quite seamless. 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.

virmundi 11y ago
I've heard plenty of people on HN bemoan the process of pushing updates out via Apple. You can have a critical bug (yes, yes better testing), but it can take the store up to a week to review, approve and deploy your app. Sure there are ways to expedite that, but should you have to be so concerned? 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.

stephenr 11y ago

> What about the benefit that the web brings to updating the user's install 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.

TazeTSchnitzel 11y ago
> What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data? The web has supported this for years, but few use it.
- stephenr 11y ago
  Care to name the technology that allows a browser app to read/write file data to local storage that isn't inherently tied to the browser?
  - TazeTSchnitzel 11y ago
    Why is it being tied to the browser a problem?
    - rockdoe 11y ago

blub 11y ago

This ease of updating can be beneficial for some types of software (e.g intranet LOB). I have two issues with it for consumer software: * 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.