Apple aside, doing this kind of thing silently sucks for users -- one of the benefits of native applications over the web is having control over when updates containing potential regressions are inserted into your workflow.
Yes, but as a developer, you're less likely to ship regressions in the first place if your deployment process involves more structure (beta testing, internal code freezes, release branches containing only bug fixes, etc) than 'git push'.
Of course, that runs counter to the "continual deployment" idea popular in web circles, but that's the entire point.
This doesn't prescribe which branch you do the git push to though. I'm sure you could just as easily set up a branching scheme where you went through testing and internal releases, and launched new code off a stable branchline
Yes it's a double edged sword, in most cases I would favor the ability to update and fix the application without having to force users to manually install an update.
Totally agree with this. As a dev it might sound like a cool thing, but as a user it sucks. Many, many times I found myself not updating an app because I won't agree with the changes (UI, new features, etc) or new permissions that were required.
