Signing certificates for Android apps are a seemingly simple thing, but it can get a little more complicated when you develop apps for a client. If you’re not familiar with signing, you may want to read Google’s instructions on signing Android apps. Read on for a few things to look out for when you build apps for a client.

Why signing keys are important

First, the obligatory reminder: Back up your keystore–without it, you can never update an app on Google Play again. You would need to create a new app and start over. This is because once an app is released to Google Play, all future updates must be signed with the exact same signing certificate. No exceptions, no excuses.

Now, backing up your keystore may be easy when you’re developing apps for yourself, but what about when you’re building apps for a client? What if you have a very large number of clients, each with a different certificate?

The same rules apply, so a client will need to have access to that signing certificate if they want to release updates. Since the keystore cannot be recreated later, this should be resolved in advance. You may need to manage the set of certificates for your clients, or negotiate a hand-off plan for the keystore.

Additionally, since a key can’t be easily changed after creation, it is best to create a key specifically for the client, using their contact information, before the app is released. You wouldn’t want to hand over a signing key and password that is used for other clients, would you?

Items tied to the signing key

If your app is more complex, there may be a few more things that are baked into the app before the unsigned Android application package file (APK) is created. This can complicate getting the app ready for deployment.

First, if your app uses the Google Maps API, you’ll need to get an API key. This key is tied to your signing certificate and a Google account when you generate it. You’ll create a separate API key for your debug signing certificate as well.

Changing the signing certificate requires changing the API key, so you need to know which signing certificate will be used before the unsigned APK is created. This also means that you need to change from the debug API key to the one tied to the signing certificate when you create the APK for deployment.

Next are the credentials used for in-app purchasing. While these are not directly tied to the signing key, they are tied to the developer account and must be baked into the app before the unsigned APK is created.

How is this related to signing keys? Implementing in-app purchasing uses a key tied to the developer account that publishes the app. When testing in-app purchasing, the app must be signed and uploaded to the Google Play Developer Console before it can be tested. If the signing certificate changes between this test build and the final release, you will need to delete and recreate the app from the Developer Console, including any setup you have done for this app.

Take the time to get it right before deploying

There’s no going back–the same signing certificate must be used for every update for an app. For this reason, it is worth a little extra effort to get things right early on rather than fixing complications later.

This might be a good time to make a plan for how you will handle signing certificates for clients, and possibly discuss this with clients to ensure they understand how the keys will be handed off or maintained by you.