
CodePush by Microsoft - onra87
http://microsoft.github.io/code-push/
======
sudhirj
Was reading somewhere that you're free to do on the fly updates of any
interpreted code - so JavaScript is fine. Only compiled code can't be updated
on the fly.

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.

~~~
lostintangent
This compelling opportunity is what made us decide to build CodePush!

~~~
bsimpson
That landing page is the most hipster thing I've ever seen come out of
Microsoft.

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."

~~~
lostintangent
I may be misinterpreting you, but I'm taking this as a huge compliment :)

------
neves
Wow! I want to see how Apple and Google will treat this hole in the wall of
their walled gardens. Updates that don't go through their app stores.

~~~
ChuckMcM
Apple will no doubt disapprove any App that uses this. Google has always been
"ok" with apps that install directly so presumably it won't really bother
them. Obviously Microsoft will support it in Apps they sell through the
Windows 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.

~~~
blazespin
Apple has already given permission to update anything that uses
HTML/JAVASCRIPT. Which react native does.

------
netinstructions
If you're looking to update React Native apps on iOS in a similar fashion
(without going through the Apple Store), AppHub[1][2] looks to be tackling
this as well. Not affiliated, just saw it mentioned in one of the React Native
PRs[3] to help enable some of the functionality.

[1][https://apphub.io/](https://apphub.io/)

[2][https://github.com/AppHubPlatform/apphub-
ios](https://github.com/AppHubPlatform/apphub-ios)

[3][https://github.com/facebook/react-
native/pull/3189](https://github.com/facebook/react-native/pull/3189)

~~~
chambo622
Interesting, it looks like AppHub gets a bit pricey. It's not hard to build a
basic version of this from scratch (just a basic update service running on a
Droplet, and a routine in the app to check for new js bundles on launch and
fall back to the last known good bundle or the shipped bundle in case of a
failure). It's an interesting niche but I'm not convinced of the value at
these price points.

------
bmy78
Wow, a Microsoft product that doesn't reference other MS products! I'm so used
to the 'click a button' in Visual Studio to publish your C# / ASP.NET code to
access SQL Server in the cloud supported by Azure.

~~~
blazespin
Visual studio is pretty awesome these days. Try it out

~~~
JBiserkov
See also Visual Studio Code:
[https://code.visualstudio.com](https://code.visualstudio.com)

I love and hate that name at the same time :-)

~~~
cableshaft
I use VSCode for my python scripting on my super cheap and lightweight laptop
I got for my outings to Starbucks, and VSCode works pretty darn well for that.
I also like the integrated support for Git.

------
a_soncodi
This is great. Between updates/hydration and browser APIs like web push
notifications, camera, geo etc.. the app stores are just glorified CDNs.
Building 'natively' for these platforms offers few advantages, but adds
overhead, deployment delays, and vendor-specific concerns. Choosing to release
on an app store should be a config setting, not a business model.

~~~
blazespin
Not on iOS until can you install from something other than the App Store. You
still have to get a cert and you can still lose it.

------
sudo_bang_bang
I've been looking at trying out AppHub
[https://apphub.io/](https://apphub.io/), which is comparable to CodePush.
I'll have to try this.

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.

~~~
lostintangent
As a team of web devs who love mobile, we definitely wanted to help bring as
much of this kind of update experience to client apps as possible. I look
forward to hearing any feedback you may have after giving us a try :)

------
stephenr
Doesn't this go against Apple's rules?

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?

~~~
ckluis
FAQ - [http://microsoft.github.io/code-
push/faq/index.html](http://microsoft.github.io/code-push/faq/index.html)

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)

------
joshuahornby
This can also be done in React with out the need of a 3rd party deploy tool as
such. [http://joshhornby.co.uk/blog/react-native-and-continuous-
dep...](http://joshhornby.co.uk/blog/react-native-and-continuous-deployment/)

------
enos_feedler
I wonder if Apple will ever release an API that allows apps to do this kind of
hot updating natively. I could imagine breaking up an application into
multiple containers and then orchestrating some kind of update process by
calling out to the system APIs.

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.

------
drdaeman
From an user perspective, that's awful. [ _Edit_ : if there's no way to force
all updates to be manually confirmed, seems that suggested workflow is that
they are:
[https://news.ycombinator.com/item?id=10517193](https://news.ycombinator.com/item?id=10517193)]

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).

~~~
Nadya
_> From an user perspective, that's awful._

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.

~~~
drdaeman
Obviously, I don't have any statistics, but I think over the years I saw _a
lot_ of outcries when there were visible changes in various applications.

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.

~~~
scrollaway
Poor understanding of your users' needs and wants in an update has little to
do with how the update is delivered.

~~~
drdaeman
I think it's more in area of respecting user freedoms. Either users can have
an opinion whenever they like the changes or not. I just happen to prefer to
be asked explicitly in a lot of cases.

The issue is not silent updates (an option to have unattended upgrades in some
places are godsend!), but in not generally having an option to prevent those
and not having a way to roll unwanted ones back.

------
vyrotek
Perfect! I wish we had this 2 years ago when we first started with Cordova.
We've since "hacked" our own similar system to dynamically load cordova
content into our mobile app.

~~~
ptarjan
Could you open source your code?

------
sb8244
Ionic has a product called Deploy which is currently in Alpha (production use
not recommended).

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.

[http://docs.ionic.io/docs/deploy-binary-
versioning](http://docs.ionic.io/docs/deploy-binary-versioning)

~~~
lostintangent
Thanks for bringing this up! We definitely need to do a better job raising
this point in our docs. That said, I hope this limitation doesn't make it "too
good to be true". From the many Cordova/React Native devs we've spoken with,
being able to update JavaScript, CSS, images and other content assets, enables
handling lots of fixes/updates, before hitting the need to update through a
store. We look forward to hearing more feedback on this topic though!

~~~
sb8244
Good point. Too good to be true referring to only dealing with the App Store
once.

~~~
lostintangent
Yep that's true. I'll add this point to our docs so it doesn't seem like we're
trying to manipulate the value of the service. Thanks for the feedback!

------
vbezhenar
That's kind of double-standards for Apple. I can update JavaScript without
approving, but I have to wait for days or weeks to update native app.

------
davej
I wonder could this potentially be used with Electron or nw.js?

~~~
lostintangent
We've only just initially added clients for Cordova and React Native, but we
plan (and would love to work the community) to build clients for other
platforms, so dynamic updates of code and/or content could be easier.

------
z3t4
The Cardova tech is very exiting and advancing fast. Today it's almost as easy
as making a web app.

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.

------
michaelchum
I wonder how Apple is going to react to this. This basically allows developers
to issue app updates and bypass the Apple App Store verification process.

------
pmalynin
Or just use Meteor.

------
hoodoof
It's a strange thing that this targets react-native

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...](https://facebook.github.io/react-
native/docs/linux-windows-support.html)

""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.

~~~
spicyj
(I work on React.)

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&.](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.

