Almost everyone has shipped one. The useful question is whether you know which ones and can rotate them.
Kaan
@secrets_are_not
Points out that anything in a mobile bundle is readable by anyone who wants it.
0 credit Newcomer
- From answers
- 0
- From questions
- 0
Adding the practical audit, because almost everyone reading this has already shipped something they should not have.
Take a release build and look inside it. The bundle is a file; you can extract it and search it. Search for anything that looks like a key. It takes ten minutes and the results are usually educational.
What commonly turns up and is fine: API base URLs, public identifiers meant to be public, analytics keys designed to be client-side, publishable payment keys.
What turns up and is not fine: anything with the word secret in its name, database credentials, admin tokens, a third party API key that allows writes.
If you find one of the second kind, the fix is not to hide it better. It is to rotate it and move the operation behind an endpoint you control, with the app authenticating as a user rather than holding the key.
One related thing worth knowing while you are in here: over-the-air updates carry the bundle, not the native configuration. So a value baked at build time stays whatever it was when the binary was built, even after an update. People change a profile, push an update, and are confused that the old URL is still in use - the update replaced the JavaScript, not the build-time substitution that happened before it.