Channel integrity
Pinning decides which certificates your app trusts instead of delegating that to the system trust store. Done well it shuts out interception; done badly it bricks the app the day you rotate the certificate.
By default an Android app trusts any certificate signed by one of the authorities in the system store. That includes CAs a user or an administrator may have added, which is exactly how interception proxies work.
With pinning, the app additionally checks that the server certificate is the one it expects. A proxy presenting a valid but different certificate can no longer read the traffic.
It is worth being precise about what pinning does not do: it protects the channel, it does not vouch for the client. An attacker who reverse-engineers your app and talks to your API from their own code walks straight past pinning, because pinning only looks toward the server. Authenticating the client is what mTLS is for.
A pin baked into the APK can only be changed by shipping a new version and waiting for users to update. If the certificate expires, or has to be reissued urgently before that happens, older installs stop connecting and there is nothing the server side can do about it.
The two measures that prevent that scenario are well known and belong together: always ship at least one backup pin, matching a key pair already generated and held for the next rotation; and be able to update the pin set without recompiling the application.
ShieldCert delivers the pinning configuration alongside the client certificate, so rotating does not require publishing a new version to the store. It is the same mechanism that makes short-lived certificates usable without turning every renewal into an incident.
Request access to the closed beta and try both on your app.