📱 App Signing Explained: Keystores, Certificates, and Provisioning Profiles (Without the Headache)
If you've ever tried to publish a mobile app and found yourself drowning in terms like "keystore," "provisioning profile," "certificate," and "signing identity" — you're not alone. These concepts confuse developers at every level. This post will break them all down using plain language and everyday analogies, and then explain how Expo (a popular React Native framework) handles all of this for you.
Let's start from the very beginning.
🤔 Why Does App Signing Even Exist?
Imagine you receive a letter in the mail. How do you know it's really from who it claims to be from? In the physical world, you might look for an official letterhead, a notary stamp, or a wax seal. These things prove authenticity — they confirm the letter came from a legitimate source and wasn't tampered with on the way to you.
App signing works the same way. When you install an app on your phone, your phone needs to answer two questions:
- 👤 Who made this app? Is it really from the developer it claims to be from?
- 🔍 Has this app been tampered with? Has anyone modified the code since the developer built it?
App signing is the technology that answers both of these questions. Every app you publish must be "signed" — essentially stamped with a unique digital seal — before the app stores (Google Play and Apple App Store) will accept it, and before users' phones will trust it.
🕯️ The Wax Seal Analogy
Think of app signing like a medieval wax seal on a letter.
- The seal mold (your private key) is unique to you. Only you have it, and you keep it secret.
- The wax impression (the digital signature) is stamped onto the letter (your app). Anyone can look at it and verify it's yours.
- The coat of arms (your certificate) is the publicly recognized design on the seal — it proves who the seal belongs to.
If someone breaks the wax and reseals the letter, the new seal won't match the original impression. Similarly, if someone tampers with your app, the digital signature will no longer match, and phones will reject it.
🔑 Key Concepts, One at a Time
🔐 Private Keys and Public Keys
At the heart of app signing is something called public-key cryptography. Don't let that phrase scare you — the idea is simple.
Imagine a special padlock that has two keys:
- One key locks the padlock (the private key). Only you have this.
- A different key opens it (the public key). You can give this to anyone.
When you sign your app, you use your private key to create a unique "stamp" on it. Anyone can then use the corresponding public key to verify that stamp came from you — without ever learning your private key. Your private key is the crown jewel. Lose it, and you're in serious trouble. Share it, and someone can impersonate you.
🪪 What Is a Certificate?
A certificate is like an ID card for your private key.
Your private key is just a long string of numbers. On its own, it doesn't tell anyone who you are. A certificate wraps that key in identity information — your name, your organization, your email — and gets it stamped by a trusted authority who says, "Yes, we verified this person, and this key belongs to them."
In the real world, this is like a notary public. You don't just take someone's word that a document is legitimate — you want a recognized third party to verify and stamp it.
Apple acts as that trusted authority for iOS apps. Google has a more flexible approach, as we'll see.
🤖 Android App Signing: The Keystore
🏦 What Is a Keystore?
On Android, everything lives in a file called a keystore. Think of a keystore as a safe deposit box at a bank. Inside the box, you store your most important items — in this case, your private keys and certificates.
The keystore file itself is protected by a password (the keystore password), and each individual key inside it also has its own password (the key password). So even if someone steals the keystore file, they can't use it without the passwords.
A keystore contains one or more key entries, and each key entry has:
- A private key 🔏 (your secret signing tool)
- A certificate 🪪 (your public ID card associated with that key)
- An alias 🏷️ (a nickname to identify that particular key inside the safe)
⚙️ How Android Signing Works
When you build your Android app for release, here's what happens behind the scenes:
- 📦 You build your app into an APK or AAB file (think of this as the "package" of your app).
- ✍️ The build tool takes your private key from the keystore and uses it to generate a digital signature.
- 📎 That signature gets attached to the app package.
- ✅ When Google Play or a user's device receives the app, it checks the signature using the public certificate. If it matches and hasn't been tampered with, the app is trusted.
⚠️ Why the Keystore Is Sacred
Here's the critical thing about Android: Google does not re-sign your app. Once you publish an update to Google Play, every future update must be signed with the exact same key. If you lose your keystore, you literally cannot update your app ever again. You'd have to publish it as a brand new app and ask all your users to reinstall.
This is why many developers have a horror story about losing their keystore. Treat it like a passport 🛂 — make multiple secure backups.
💡 Note: Google Play now offers a feature called Play App Signing, where Google stores a copy of your signing key. This is a safety net — even if you lose your local keystore, Google can still sign your app. It's strongly recommended to opt into this.
🍎 iOS App Signing: A Slightly More Complex World
Apple takes a more hands-on approach to app signing, involving a few more moving parts. But once you understand the pieces, it all makes sense.
📜 Certificates (Again, But Apple's Version)
Just like Android, iOS apps need a certificate. Apple issues two main types:
- 🛠️ Development Certificate: Used when you're testing the app on your own device. It's like a "work in progress" badge.
- 🚀 Distribution Certificate: Used when you're ready to publish to the App Store. It's the official, final stamp of approval.
You generate these through Apple's Developer portal. Behind the scenes, you create a private key on your Mac, send a "certificate request" to Apple (which includes your public key), and Apple sends back a signed certificate — your ID card.
🎫 What Is a Provisioning Profile?
This is where Apple gets unique. A provisioning profile is essentially a permission slip that ties several things together:
- 👤 Who is allowed to sign the app (your certificate)
- 📱 What app it applies to (identified by a Bundle ID, like
com.yourcompany.yourapp) - 📍 Where the app can be installed (specific devices, or "any device" for App Store distribution)
Think of a provisioning profile like a backstage pass at a concert 🎵. The pass lists your name (certificate), the event name (your app's Bundle ID), and which venues it's valid for (specific test devices or the App Store). Security at the door (your iPhone or the App Store) checks all three pieces before letting the app in.
There are different types of provisioning profiles:
- 🛠️ Development: For running the app on your own test devices during development
- 🧪 Ad Hoc: For distributing the app to a limited set of test devices (like beta testers)
- 🏪 App Store: For submitting to the App Store
- 🏢 Enterprise: For distributing internally within a company (requires a special Apple program)
🏷️ The Bundle ID
The Bundle ID is just a unique name for your app, usually written in reverse-domain format: com.yourcompany.yourappname. It's the "ID number" of your app in Apple's system, and it must be unique across all apps on the App Store. Everything in Apple's signing system — certificates, provisioning profiles, push notification configs — gets tied to this ID.
🪜 How iOS Signing Works (Step by Step)
- 📝 You register your app's Bundle ID in Apple's Developer portal.
- 📜 You create a Distribution Certificate (Apple gives you this after verifying your identity).
- 🎫 You create a Provisioning Profile that links your certificate + Bundle ID + distribution target (App Store).
- 🔨 When you build your app, Xcode uses your private key and provisioning profile to sign it.
- ☁️ When you upload to App Store Connect, Apple verifies the signature and provisioning profile.
- ✅ When users download your app, their iPhone checks that everything is in order before running it.
⚖️ Side-by-Side Comparison
| Concept | 🤖 Android | 🍎 iOS |
|---|---|---|
| Key storage | Keystore file (.jks or .keystore) | Keychain (on your Mac) |
| Certificate | Inside the keystore | Issued by Apple, downloaded from Dev portal |
| "Permission slip" | Not required | Provisioning Profile |
| App identifier | Application ID (e.g., com.company.app) |
Bundle ID (same format) |
| Who signs | You (or Google, via Play App Signing) | You, with Apple's certificate |
| Lose your key? | Can't update your app | Apple can reissue a new certificate |
⚛️ App Signing in React Native with Expo
React Native is a framework for building iOS and Android apps with JavaScript. Expo is a toolset built on top of React Native that makes development much easier — including handling app signing.
😰 The Old Way (Without Expo)
Without Expo, you'd have to:
- 🤖 Manually generate a keystore for Android
- 🍎 Manually create certificates and provisioning profiles on Apple's portal
- ⚙️ Configure your build tools to use all of these
- 🗂️ Keep track of all these files and passwords yourself
For a new developer, this process was famously painful.
🚀 Enter EAS Build (Expo Application Services)
Expo's answer to this complexity is EAS Build (EAS stands for Expo Application Services). EAS is a cloud build service that can handle the entire signing process for you, including generating and securely storing all your credentials.
Think of EAS like hiring a professional courier service 🚚 instead of delivering packages yourself. You hand them the package (your code), and they handle all the logistics — including the official seals and customs paperwork (signing credentials) — and deliver it to the destination (the app stores).
🤖 How Expo Handles Android Signing
When you run eas build for Android, Expo can:
- 🔑 Automatically generate a keystore for you if you don't have one.
- 🔒 Store it securely on Expo's servers, encrypted, so you don't have to worry about losing it.
- ✍️ Use it to sign every build automatically.
You can also provide your own existing keystore if you prefer to manage it yourself. Either way, Expo's eas.json config file lets you specify how signing should be handled for different environments (development, staging, production).
If you want to keep control yourself but still use EAS, you can run eas credentials to manage your credentials interactively — view what's stored, download your keystore, or replace it.
🍎 How Expo Handles iOS Signing
iOS is more complex, but EAS Build handles it beautifully. When you build for iOS, EAS can:
- 🔐 Log into your Apple Developer account on your behalf (with your permission and credentials).
- 📜 Automatically create a Distribution Certificate if you don't have one.
- 🎫 Automatically create a Provisioning Profile for your app.
- 💾 Store both securely on Expo's servers.
- ✍️ Use them to sign your app during the cloud build.
This is genuinely magical ✨ the first time you see it work. What used to take hours of fumbling through Apple's developer portal now happens in a few minutes automatically.
📄 The eas.json File
This is the configuration file that tells EAS how to build your app. Here's a simplified example:
{
"build": {
"production": {
"android": {
"credentialsSource": "remote"
},
"ios": {
"credentialsSource": "remote"
}
}
}
}
credentialsSource: "remote" means "use the credentials stored on Expo's servers." You can also set this to "local" if you want to manage your own keystore and provisioning profile files.
🗺️ The Flow: From Code to App Store with Expo
Here's the full picture of how an Expo app gets signed and submitted:
🤖 For Android:
- You run
eas build --platform android --profile production - 🔑 EAS retrieves your keystore from secure storage (or creates one)
- ☁️ Your app is built in the cloud and signed with that keystore
- 📦 You download the signed AAB file (or use
eas submitto send it directly to Google Play)
🍎 For iOS:
- You run
eas build --platform ios --profile production - 🎫 EAS logs into Apple, retrieves or creates your certificate and provisioning profile
- ☁️ Your app is built in the cloud and signed
- 🚀 You use
eas submitto upload the signed IPA directly to App Store Connect
The entire signing and submission pipeline can be automated, meaning once it's set up correctly, publishing an update can be nearly a one-command operation. 🎉
📡 What About Over-the-Air (OTA) Updates?
Expo has another trick: EAS Update, which lets you push JavaScript code updates to users without going through the app store review process. These updates are signed with a different kind of key — a code signing key pair — that ensures the update came from you and wasn't tampered with. The concept is the same (private key signs, public key verifies), just applied to updates instead of the full app binary.
🚨 Common Mistakes and How to Avoid Them
😱 Losing your Android keystore. Back it up in at least two secure locations — a password manager, an encrypted cloud backup, a USB drive in a safe. No exaggeration: losing this file means losing the ability to update your app.
🔀 Using the same certificate for everything. Apple limits the number of active certificates per account. Keep development and distribution certificates separate.
⏰ Letting provisioning profiles expire. Apple provisioning profiles expire after one year. If yours expires, your app won't build. Set a calendar reminder to renew them.
🛡️ Not opting into Play App Signing. Let Google store a backup copy of your Android signing key. It's free insurance.
🙈 Sharing private keys. Never email your keystore or share your private keys. If a team member needs to sign builds, use a signing service (like EAS) rather than passing around key files.
📖 Quick Reference Glossary
🔏 Private Key — Your secret digital stamp. Never share it.
🔓 Public Key — The counterpart to your private key. Anyone can have it; it's used to verify your signature.
🪪 Certificate — An ID card that links your identity to your public key, vouched for by a trusted authority.
🏦 Keystore — An Android-specific file that stores your private keys and certificates in a password-protected container.
🏷️ Bundle ID / Application ID — The unique identifier for your app (e.g., com.yourcompany.appname).
🎫 Provisioning Profile — An iOS-specific "permission slip" that ties together a certificate, an app ID, and the allowed installation targets.
☁️ EAS Build — Expo's cloud build service that automates signing for both Android and iOS.
🛡️ Play App Signing — Google's service to store a backup copy of your Android signing key, protecting you if you lose it locally.
✍️ Code Signing — The overall process of applying a digital signature to software to prove its authenticity and integrity.
🎯 Wrapping Up
App signing sounds intimidating, but at its core it's just a system of trust — making sure that the app users install is genuinely from you, and that no one has messed with it along the way. Android uses a keystore file. iOS uses certificates and provisioning profiles. Both rely on the same underlying idea: a private key you keep secret, and a public key anyone can use to verify your work.
Expo's EAS Build takes most of this complexity off your plate. Instead of manually wrestling with Apple's developer portal or safeguarding your own keystore, EAS can generate, store, and use your credentials automatically — so you can focus on building the app, not the paperwork.
The most important things to remember: 💾 back up your Android keystore, 🙅 don't share private keys, and 🚀 let EAS help you if you're working with React Native and Expo.
Top comments (0)