Capacitor Live Updates: Signing vs Encryption

If you compare live update solutions for long enough, you will run into a security claim that sounds decisive: "end-to-end encrypted." It suggests that solutions offering encryption are more secure than solutions that "only" sign their updates. That framing mixes up what the individual security controls in an update pipeline actually do. In this post, we walk through the threat model of live updates (also known as OTA updates or CodePush): what HTTPS already protects, what code signing guarantees, what encryption adds on top, and which of these properties matter for your app. By the end, you can evaluate the security of any live update solution based on facts instead of buzzwords. Key Takeaways HTTPS protects update bundles in transit. It does not protect against a compromised update service, storage bucket, or CDN. Code signing with a developer-held private key guarantees authenticity and integrity all the way to the device: even a fully compromised update infrastructure cannot inject code into your app. Encrypting bundles adds confidentiality only. It provides no additional protection against malicious updates. Client-side encryption cannot keep app code secret, because the decryption key must ship inside the app binary. The React Native maintainers state it plainly: "Code on the client is not secret." If bundles must stay confidential, for example in privately distributed enterprise apps, self-hosting them is a stronger control than encrypting them. The Trust Chain of a Live Update Every live update passes through the same chain: you build a web bundle in your CI/CD pipeline, upload it to an update service, the service stores and serves it (usually through a CDN), and the Live Update SDK in your app downloads and installs it. Security along this chain means three different properties: Authenticity : The update genuinely comes from you. Integrity : The update was not modified on the way. Confidentiality : No third party can read the update's content. For code that