Why Do People Want Code Push So Much?

There is an article I wrote that talks about why I think Flutter is better than React Native.

I posted it. It appeared to be well received. And then an army of React Native fanboys descended on that post. And apparently, they can’t even read so they see a heading that says ‘Hot Reload’ and they’re just like ‘Bro…’. I had to rename that heading and remove one paragraph so it’s more clear.

Now, to be perfectly clear it’s perfectly fine to like React Native. In fact in some situations like web React Native is the better choice. But most of the complaints in the comments of that post are nonsense. They sound impressive but when you think about them they’re just a hacky fix on a much deeper problem.

That’s why I like Flutter, it was designed from the ground up to do things properly. It’s a lot more work, you have to draw each individual pixel and reimplement tons of accessibility fixes from scratch. But the upside is you don’t get a mess that is frankensteined together on ancient web technologies.

But there is a complaint about Flutter I couldn’t shake so easily: code push.

Code Push

Code push is simply put, a way to update an app without going through the app store review process. This way you can ensure everyone gets the update, not just people with automatic updates turned on. It’s pretty simple. React Native uses Javascript and Web elements so just make the user download new Javascript files replacing the native content. Although, it’s not literally Javascript you’re uploading. It’s some sort of patch file.

And then if you think about it that way there’s no reason Flutter couldn’t support code push too. I’ve seen people saying how Flutter is compiled so it can’t do it. Not true, the technology behind code push is the same behind something like DLC for a video game. Anyone can do it.

So if it’s not some secret React Native sauce. But if it’s not exclusive to React Native why do more frameworks not implement it? Well, there are a few reasons.

App Stores Would Prefer You Not To Code Push

I was going to name this section ‘It’s Against App Store Rules’. But I looked into it and it’s actually not as I talked about in this post.

However I think Google and Apple only reluctantly allow it. They realized that once a developer makes a web view they have no way to control what your app does anymore. So they put out a section allowing code push. And it applies specifically to interpreted code, AKA HTML/Javascript. Geez, I wonder why.

Also some people still get rejected for trying to implement code push.

I wouldn’t really want to do something that could get me in trouble. And for what?

Is It Really Necessary?

So when people defend code push they always talk about bugs. What if there’s a bug that you didn’t catch and needs to be patched? Now I have encountered bugs like this in the past and they are very embarrassing. But the only time I published a bug that completely broke an app was when I was very new to app development.

Now when I push out an update I go through a few basic manual tests to make sure everything is working before I push the update. And in addition to this I have quite a few automated tests. And since then I have not actually pushed out a broken build.

There have been some minor bugs. But these only affect a few users and they are never that bad. The app is still usable. Certainly nothing that has to be fixed ASAP.

And app stores now let you roll out updates gradually. Both Google Play and Apple allow you to do this. This allows you to catch issues early and halt a release if you notice issues.

The more I think about it the more I think that code push is just an excuse for poor testing practices.

We Can Already Code Push

I said at the beginning of this post that anyone can do code push. And, in fact, someone has already done it with Flutter. A company called ShoreBird has got it running.

And apparently there’s this package that can get it running too.

Plus if you’re using a database nothing is stopping you from changing the behaviour of your app based on what you put there. In fact this is the idea behind Firebase Remote Config.

You could argue that you are inherently limited in what you can do with things like Firebase Remote Config. And you’d be right. But you’re also limited by what you can do with code push.

It’s Limited

You can’t do everything with code push. Especially given the app store restrictions. Apple and Google both make it clear: interpreted code only. So that means if you want to, I don’t know, add a permission to your app you’re going to have to go through the app stores.

Also Apple and Google don’t want you making major changes with code push. You can do this, but I wouldn’t.

This means that code push is really only intended to fix bugs. Something that you really don’t need if you’re properly testing and rolling out your updates.

Security

There is actually a statement the Flutter team made a while ago regarding code push:

This was previously on our roadmap for 2019. After investigating this in greater detail, we have decided not to proceed with this work for now. There were several factors that led us to this decision:

- To comply with our understanding of store policies on Android and iOS, any solution would be limited to JIT code on Android and interpreted code on iOS. We are not confident that the performance characteristics of such a solution on iOS would reach the quality that we demand of our product. (In other words, “it would be too slow”.) - There are some serious security concerns. Since these patches would essentially allow arbitrary code execution, they would be extremely attractive malware vectors. We could mitigate this by requiring that patches be signed using the same key as the original package, but this is error prone and any mistake would have serious consequences. This is, fundamentally, the same problem that has plagued platforms that allow execution of code from third-party sources. This problem could be mitigated by integrating with a platform update mechanism, but this defeats the purpose of an out-of-band patching mechanism. - There is currently no out-of-the-box open source hosting solution for patching applications, so we would either have to rely on people configuring their Web servers accordingly, or we would have to create integrations for proprietary third-party services, or we would have to create our own bespoke solution. Hosting patches is a space we are not eager to enter. Having people configure their own server leaves them open to making mistakes with potentially serious implications as explained in the previous point about security. Depending on third-party services puts Flutter in an awkward position of having to pick winners and exposes us to the risk of those projects themselves making policy changes that would affect this feature.

We prefer to spend our engineering effort on other issues for now. We expect to keep experimenting in this space and will probably become serious about this again in the future (for example, we will probably need an update solution for desktop applications), but probably not this year.

So in summary: it would be slower and there are configuration/security concerns.

Now the slower complaint I didn’t get. At the time the comment was posted. Flutter is fast enough. In fact Flutter Web is currently running interpreted code. But now it might have a little more merit because there’s shader support.

Shaders are magical pieces of code whose inner workings are only known to a few qualified programmers. They run on the GPU which means they can’t be interpreted. Or at least I’ve never heard of an interpreted shader before. It would probably run terribly.

Security is a much more serious point. If you can update your app remotely it means an attacker can too. Now you could argue that it’s a solved problem: just don’t share your signing key. And yeah, but it’s possible that an attacker could get ahold of that. Just look at all these ransomware attacks. In fact this exact thing happened with MSI.

If an attacker got access to your signing key and your server it could be very very bad. Possibly bad enough to get your developer account banned.

Conclusion

So I don’t really think code push is worth adding to my app. I mean, I don’t think code push is a bad feature. If Flutter added it I wouldn’t complain. But I think it’s more of a crutch for bad development practices.

It might seem nice to add code push. But then you have to consider the added complexity of setting it up, its limitations, the reduced code execution speed, and the possible vulnerabilities it opens you up to. It’s just not worth it in my opinion.

If you liked this article consider following me on one of my publications: Lost But Coding (for programming content) or The Rest Of The Story (for everything else). You can do so with my RSS reader available on iOS (and Apple Silicon Macs) and Android.