CodePush by Microsoft | Hacker News Reader

CodePush by Microsoft

microsoft.github.io

266 pointsonra8782 comments

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.

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

Yes, been waiting for this for quite awhile. Great job guys. Msft is definitely building exciting stuff these days. Hope it's converting into revenue at some point.

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

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

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.

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.

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

Wrong. Many apps that have been in the app store for years use this technique. Apple in fact explicitly allows this.

Apple at least already allows this for Javascript based apps, particularly Meteor as an example: http://info.meteor.com/blog/apple-hot-code-push-mobile

When talking about Apple, I find it easier to think of just two state for apps (that use this): Rejected and not-yet-rejected. Also, there aren't App Store _rules_, they're just guidelines. Apple is still able to pick and choose that they enforce and reject apps for their own reasons.

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.

As always, the App Review Team gets the final say on a case-by-case basis for whether you'll get through or not.

Why cynical? Apple specifically added a carve out for JavaScript. A big update is fine as long as you arent changing the purpose of the app.

Because "purpose" is totally open to [Apple's] interpretation.

Not cynical, just realistic and speaking from past personal (and others) experience of Apple rejecting apps for whatever reason they feel like (if any).

IMO, Apple specifically carved out the exception for JS for WebKit/WebViews, to make using web views in apps possible. I'm quite certain they didn't have in mind React Native[1] auto-downloading JS bundles to bypass App Review. Apple wouldn't be a fan of that.

Now, the complete opposite of this is their favoured tech for developing new Apple TV apps, TVML, explicitly allows and is designed for updates bypassing App Review. In fact, most of the app logic and UI is delivered from your own server.

[1] Actually, the guidelines mentions 'WebKit framework'. Does React Native use 'WebKit framework'? Edit: It uses JavaScriptCore which I guess is a part of WebKit http://trac.webkit.org/wiki/JavaScriptCore

This isn't really a hole. This has existed forever. Apps could always embed webviews and load files from the local filesystem.

You weren't allowed to update over the wire until last year. The JavaScript carve out is particularly important.

You could, and still are, able to download html/javascript/css to the phone, and then load those files in a web view.

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/

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

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

there's also a cool company called Primer that does the same for mobile onboarding screens on iOS

https://goprimer.com

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.

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.

We have that button on our backlog! ;)

Visual studio is pretty awesome these days. Try it out

See also Visual Studio Code: https://code.visualstudio.com

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

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.

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.

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.

I've been looking at trying out AppHub 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.

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

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?

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

They already have blessed hot-code pushes; see Meteor: http://info.meteor.com/blog/apple-hot-code-push-mobile

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

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.

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]

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

You must hate Chrome.

I prefer Firefox (although it has its share of issues), but generally GNU/Linux distributions come with Chromium, with ripped-out auto-update mechanisms in favor of "classic" updates through a package management system.

Anecdotally, my dad, which happened to run Chrome on Windows, didn't fancy most of visible changes.

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

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.

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

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.

E: Scrollaway makes a good point in a sibling response.

========

An easy way would be to use telemetry to measure how many of your users change default settings. ;)

I only have this from 4 years ago [0]. But is also something I've observed.

> I think over the years I saw a lot of outcries when there were visible changes in various applications.

Visual changes are typically seen as unwarranted. It's a huge risk with minor gains (UX of new users) by alienating old users and hoping 'they'll adapt'. But to touch on this a bit...

Unhappy people are also the loudest. If a platform has 1,000,000 viewers and 1% change their settings and you screw with those settings - you're going to have 10,000 people who are pissed off and venting. Which can seem massive - and out of the 990,000 others maybe 2 or 3 might voice their approvals/thanks for the update?

This is why many game studios ignore their forums. Forums are typically only a minority of the overall fan base, even if they're typically the most outspoken/loyal fans.

[0] https://www.uie.com/brainsparks/2011/09/14/do-users-change-t...

True.

I got a Windows 10 laptop recently and took a look around the OS. Relevant to the discussion, one thing was just brilliant - user satisfaction feedback buttons (the smiley/frowny faces in some apps). Hope such things help debiasing feedback.

Philosophically I like the idea of the user being able to choose any version of the client, but that doesn't seem sustainable: while it's generally _nice_ to support old versions of your app and avoid breaking changes to the protocol, sometimes the cost to the developer would just be way too high.

For many apps that communicate with a remote service, you're gonna have to eat _some_ update somewhere down the line.

A silent updater with good updates is far better than a noisy updater.

I'm so sick of update notifications that I've muted the Play Store on my android. There are just so many of them each day that I don't care to keep track of it. Most of these native apps are just improved versions of web apps anyway, and you don't get to choose when a web app updates.

> and you don't get to choose when a web app updates That's why I prefer autonomous applications to webapps any day.

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.

But if you don't upgrade, you're even more likely to find that things that used to work are suddenly broken. The developers are only going to support so many old versions of their product, and eventually they'll break the server API your app depends on. And if you contact support for any reason, they'll assume the bugs are fixed in a newer version and that you should upgrade.

The value provided isn't necessarily silent updates, but making updates available without jumping through the app store. It's still up to the app developer whether they prompt the user before installing the update. In fact, the Cordova plugin provides a single function that shows a "apply or ignore" popup when an update is available, so the user can choose: https://github.com/Microsoft/cordova-plugin-code-push#codepu...

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)

Oh. Then it's fair - if developers actually conform to the suggestion, of course. Sorry, I guess I've got a wrong idea what it does.

I work on the CodePush team and we are simply interested in helping devs engage more closely with their end-users, by delivering value more quickly and hopefully less obtrusively. We by no means want to prescribe poor and/or annoying update practices.

As was mentioned, our existing API surface actually leans towards the use of "active updates" that present the option to install or ignore to the end-user. That said, I think there are numerous scenarios where silent installs could be valuable as well, and you could even imagine an app having a user option to disable that or not.

We want to provide the primitives and services necessary to create these experiences, without imposing any specific opinion to how devs should cater to their respective userbase. Compelling user experiences are absolutely priority one!

I'm actually okay with this. It's not my app. The designers know more about UX than I do. It's not like you can change device permissions through this. I've been learning digital UI's all my life, I can handle things shifting around and changing features. I'm happy with anything that gives devs more agency over how much they can improve their product. My only worry is that it might be too easy to push updates, so less testing may go into updates because the threshold to do so is low. Kind of like what happened to video games once you could patch things.

We definitely don't want to encourage "abusing" the service by producing poorly tested updates. We're planning to do some work/docs to help incorporating a CodePush deployment into a CI workflow that can choose to rely on tests to ensure quality, and also use multiple environments to be able to manually test an update in staging before pushing it out to users.

Yeah, that really failed for Salesforce and every website ever. And I agree, I really hate it when bugs get fixed without me having to click an update button. That is sooo annoying.

Seriously, how is this the top voted comment???

I'm more on your side on a personal side, but think if Word 2k3 to 2k7 was an automatic update? All the support requests coming in.

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

The problem with incremental updates is it's easy to convince yourself they're all beneficial. Most people won't leave your service or app if a new change is slightly annoying. Without attrition, you may not realize the change was essentially negative. Over time these build up and you end up with people that are essentially begrudgingly using your stuff. You can probably grind out a business that way, but it gets hard to upsell or introduce a new product that way. Death by a thousand cuts and all that.

I know a lot of people that are tired of UI changes constantly coming down the pipe in SaaS. But when it's the only game in town, there's not a whole lot you can do about it. There's also a lot of fatigue around release notes that are just "bug fixes and performance improvements." I'll refer you to the massive comment thread about Twitter changing stars to hearts, a change which obviously reached a breaking point for a lot of people.

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.

Video games have been doing this for years on iOS. Try any game from EA for example.

Many phone apps already do that anyway websites do that

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.

That kind of "power user" experience would totally be possible using CodePush. Thanks for mentioning it, since we should have a sample to illustrate how it would look!

If that's the case you must have a really hard time using the Internet

What's the real difference between an "native HTML5 app", and an "app" that's just a website loaded in an embedded webview, which also takes advantage of HTML5 features to continue to work when you're offline?

You'd expect the latter to change whenever they update the server—so why not the former?

These aren't necessarily HTML5 apps. React Native, for instance, is just a framework that lets you drive your app from JavaScript (native views, no HTML) instead of compiled code.

So you must hate also websites, too.

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.

Could you open source your code?

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

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!

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

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!

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.

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

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.

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.

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.

Or just use Meteor.

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

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

I'm not sure why you think that Facebook should support other platforms? It's open source and free of charge to you. Doesn't it make sense that they are going to support only the platform that they use and are mostly interested in?

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

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.

We added CodePush support for React Native because we think it's an extremely compelling platform and so do many of our customers. I actually respect Facebook's pragmatic approach to software development prioritization, and they work so closely with the community to allow other objectives/goals to be achieved (e.g. Windows support) That seems like a great way to run an OSS project to me.

I think it's pretty clear that this is aimed at mobile, not desktop development (note they are pushing Cordova).

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.

Reply on news.ycombinator.com