Seriously, I absolutely hate when apps change their behavior or looks without explicitly asking me for a permission (and so I can make a backup to revert if I don't fancy what goes on).
That's not to say app developers can't silently update, but using CodePush doesn't lock your app into that workflow.
(full disclosure: I'm doing other things now, but I worked on this project for a few months)
Only for a very tiny niche group of users. I'm part of that niche as well - but I recognize that most users love auto-updating things. They don't have to worry about updating, new features get pushed to them, etc. It's a great user experience for most people.
Only a small number of power users ever touch the settings/option menu of the software they use and fewer would ever see a reason to "downgrade" to a previous version - let alone know how to go about doing so.
So, I'm not sure it is really great experience for most people. Given that generally there is no way to roll back, I suppose most just learned to live with such things, whenever it's great for them or not so much.
I may have a wrong idea, but I perceive it as a culture where user is nearly powerless against the almighty Developers' will. I still haven't gave up on my own preferences, yet. Fear that future will break me, though.
Seriously, how is this the top voted comment???
It may work great for you. For a lot of us, it's tiring. It's not as if all these updates end up being bug-free.
The real solution is to do incremental changes in most cases. Though this is a bit troublesome for the whole "I control the code on my machine" thing. In which case you could rip out the updater
Anecdotally, my dad, which happened to run Chrome on Windows, didn't fancy most of visible changes.
You'd expect the latter to change whenever they update the server—so why not the former?
As for notifications - I'm not bothered by those. I think I get only a few every other week. Guess it's because I don't have many apps and the ones I have don't update every other day. Also, I allow some apps - those whose developers I trust, those that can't get worse and those I either don't care much about - to auto-update. But I manually track the updates for the apps I use daily. Don't want to find that things I'm used to are suddenly broken.
If there'd be a way to hook into Play Store to trigger a full backup before the upgrades, I suppose I would've enabled auto-updates for most apps.
its not nice for users but they dont give a crap
what would be okay i guess is if you could choose the branch and commits you're running yourself, so power users have choices, others get whatever is latest and freshest and safe and whatever.
For this particular issue, Apple allows apps to dynamically download Javascript and other web tech (in order for web browsers to work), and they explicitly mention that they're not into you pushing big updates:
provided that such scripts and code do not change the primary purpose of
the Application by providing features or functionality that are inconsistent
with the intended and advertised purpose of the Application as submitted
to the App Store.
Given the stuff you can change its pretty clear you could completely change the user experience. So yes, it would be a pretty big "hole" in the app experience management policy.
react-native, despite one of its core values probably being cross platform support, is extremely disinterested in providing anything but OSX support. Check out the wording from their site: https://facebook.github.io/react-native/docs/linux-windows-s...
""As React Native on iOS requires a Mac and most of the engineers at Facebook and contributors use Macs, support for OS X is a top priority. However, we would like to support developers using Linux and Windows too. We believe we'll get the best Linux and Windows support from people using these operating systems on a daily basis.
Therefore, Linux and Windows support for the development environment is an ongoing community responsibility.""
Which is to say "At Facebook we like Macs, we have Macs. Maybe someone else who likes Windows will build for Windows and Linux. Go ask them to do it."
I was recently looking for a cross platform development environment and was very interested in react-native but I completely lost interest after reading about their attitude to non-OSX support.
Facebook works on tools that help Facebook. We like to give back to the community whenever we can. Unlike most other platforms, our end goal is not building and making tools or technology. Instead, we build whatever helps us make better products.
This means that (IMO) we end up with higher-quality tools. It also means that we focus on the use cases that are important to us which occasionally differs from what's most important to the community. (Though even if you look at what the community has voted for, Linux and Windows support doesn't even make the list: https://productpains.com/product/react-native/?tab=top&.)
Since most developers at FB use Macs, that's what we supported first. If there's community interest in React Native running on Windows and Linux (and there is), we'll happily take pull requests that add support, and I see no reason why we can't make sure the support doesn't regress after it's merged.
I'm not sure why this strategy is upsetting to you. As a point of comparison, Rust's Windows support lagged behind for many years and what it did have was community-supported. Now, Windows has caught up and it will remain a first-class target for them. I expect React Native to end up in the same place within the next few months.
In that context it makes a lot of sense: Microsoft wants any kind of apps on Windows Mobile, and I believe Cordova/React works fine for that.
And in react native only the main framework is compiled, with the actual application running in a JS interpreter. So unless we upgrade the RN version, or start using a new SDK etc there will never be a reason to go through the App Store.
All interpreted code is sandboxed anyway, so there's no security risks involved.
It's hard to believe that the same company that cursed the world with IE 6 just released an open-source accessory for a Facebook platform and signed it "with <3 from Redmond."
I love and hate that name at the same time :-)
Seems to me it's effectively bypassing their checks - a developer can release v1.0.0 to the app store, never again update it, and push updates via this?
According to section 3.3.2 of Apple’s developer agreement, as long as you are using the CodePush service to release bug fixes and improvements/features that maintain the app’s original/presented purpose (i.e. don’t CodePush a calculator into a first-person shooter), then you will be fine, and your users will be happy. In order to provide a tangible example, our team published a (pretty cheesy!) CodePush-ified game to the Google Play Store and Apple App Store, and had no problems getting it through the review process.
Because Cordova apps are executed within a WebView, and React Native apps are executed within JavaScriptCore, from a technology perspective, these runtimes are unique in their ability to leverage dynamic code downloads according to the aforementioned Apple developer agreement.
(copy pasted directly from codepush site)
They do a pretty good job explaining binary versioning, which is eluded too with CodePush but not in detail. Basically, it might seem too good to be true, and it is. You can push small changes up to the app store, but still have to re-submit for any binary changes.
As it is, both are definitely useful for better handling upgrade process with users. A couple drawbacks with mobile apps are that it's harder to hotfix errors, and you sometimes have to support older APIs for longer. With a web app, a user can visit the site and the entire app bundle can be downloaded after a cache bust.
At least then it would not compromise the security of App Store / Test flight. As more meta-data was extracted/tagged with these containers you could imagine Apple reviewers start to care less about the code inside the container and more the interfaces (does it use health kit? apple pay? etc) and whether they are likely to be reviewed again. Could also look at size of binaries changes and things like that, or perhaps at LLVM byte code level for more detail.
Your users need to hack their OS to be able to use your app though ... OS's need to find a way to contain apps that don't need full system access. Maybe by higher level user-mode so that apps need to ask for permission before using API's.