Skip to main content
Since May 1st, 2024, Apple requires all iOS apps to include a privacy manifest. For more details, 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. There are many ways to set it up on a server, and there are many programming languages that you can use. Feel free to use any that is comfortable to you. 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 should not 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.
⌘I