Starting May 1, 2024,
Apple requires all iOS apps to include a privacy manifest.
For more information, see Privacy manifest.
Don’t embed search-only API keys on mobile
When running your app with the search only key embedded in your app, you might notice the following warning:
Be sure to not include the search API key directly in the source code.
You should instead consider fetching the key from your servers during the app's startup
This follows the mobile security recommendations as people can potentially have access to this key. Moreover, having your key on your server gives you more flexibility as you would be able to make changes to it if needed without having to deploy a new app version to the AppStore.
Implementation
What you have to do is have your API key in one of your servers,
and then fetch it through a network request when the app starts.
You can set this up in many ways on a server, and you can use many programming languages.
Choose whichever you’re comfortable with.
For example, here is a tutorial
on fetching a remote configuration file.
Secured API keys
Mobile applications represent significant security risks to your API keys,
and the inflexibility of mobile applications make secure operations more difficult.
API keys shouldn’t be hardcoded in the shipped mobile applications.
They should always be dynamically retrieved from the application backend.
The reason behind this recommendation is that users might not update your application as often as it would be desired.
When you then rotate your API key as part of the security workflow or the key leaks and you need to revoke it,
the installed application stops working.
It’s also important to keep in mind that the application,
which might look secured,
can be easily opened by existing tools and your API keys extracted from it.
Therefore, don’t give your mobile application API keys more privileges than is necessary and use Secured API keys with expiration times.Last modified on February 10, 2026