Your App Was Rejected for Code Signing. Here Is the Certificate Problem

App store submission rejections from code signing issues almost always have the same root cause: the developer used the wrong type of certificate for the target distribution channel. Every major platform has multiple certificate types for different purposes, and using the wrong one produces a rejection that can look like a general ‘signing failed’ error without clearly explaining which certificate type was expected.

This guide covers the specific certificate type required for submission to the Apple App Store, macOS outside the App Store, Google Play, and the Microsoft Store. For each platform, the most common certificate type confusion is identified and the exact correct certificate is named.

At a Glance: Certificate Type by Platform and Distribution Channel

iOS App Store: The Distribution vs Development Certificate Confusion

The most common iOS signing rejection is submitting a build signed with a Development certificate instead of a Distribution certificate. These look similar in Xcode’s interface and both are issued through the Apple Developer Program, but they serve completely different purposes.

Development certificate

A Development certificate (also called an Apple Development certificate in newer Xcode versions) allows you to install and test your app on specific physical iOS devices that are registered in your developer account. The devices must be explicitly added to a Development provisioning profile. Development-signed builds cannot be submitted to the App Store.

Distribution certificate

A Distribution certificate (also called an Apple Distribution certificate) is required for App Store submission. When you archive your app in Xcode and upload to App Store Connect, Xcode signs the archive with the Distribution certificate associated with your team. App Store Connect validates this signature before processing the submission.

If you receive a rejection message like ‘The app was signed with Development certificates’ or ‘Invalid Code Signing’, the app was archived with a Development certificate instead of a Distribution certificate. In Xcode, go to the Build Settings for your target, find Code Signing Identity, and ensure that for the Release configuration it is set to Apple Distribution (or iOS Distribution in older Xcode versions), not Apple Development.

Provisioning profile mismatch

Even with the correct Distribution certificate, a provisioning profile mismatch causes rejection. The provisioning profile must be an App Store Distribution profile (not Ad Hoc, not Development) and must be associated with the Distribution certificate being used. The Bundle Identifier in the provisioning profile must exactly match the Bundle Identifier in your app’s Info.plist.

Xcode’s automatic signing typically handles this correctly when properly configured. If you manage provisioning profiles manually, regenerate the App Store provisioning profile in the Apple Developer portal, download it, and explicitly select it in Xcode’s signing settings.

macOS: App Store vs Direct Distribution (Developer ID)

macOS has the most confusing certificate landscape of any platform because there are two completely separate distribution paths that use completely different certificate types that are easy to mix up.

Mac App Store distribution

Apps submitted to the Mac App Store must be signed with a Mac App Store Distribution certificate and use a Mac App Store provisioning profile. This certificate is specifically labeled for Mac App Store distribution in the Apple Developer portal.

A common mistake: developers use their Developer ID Application certificate (for direct distribution) to sign an App Store submission. This produces a rejection because the App Store distribution path specifically validates for the Mac App Store Distribution certificate type. Developer ID certificates are explicitly not accepted for App Store submissions.

Direct distribution (outside Mac App Store)

Apps distributed outside the Mac App Store as direct downloads must be signed with a Developer ID Application certificate. This is a completely separate certificate from the App Store distribution certificate, also issued through the Apple Developer Program.

Additionally, since macOS Catalina (10.15), apps distributed outside the App Store must be notarized: submitted to Apple’s automated notarization service, which scans for malware and checks code signing requirements. Apple returns a notarization ticket that must be stapled to the app before distribution. Gatekeeper checks for this ticket when users open the app. Without notarization, macOS shows a warning that the app cannot be opened.

Installer packages outside the App Store

If you distribute a macOS installer package (.pkg) outside the App Store, it requires a Developer ID Installer certificate, which is different from the Developer ID Application certificate used for the app bundle. Both must be present: the app inside the package is signed with Developer ID Application, and the installer package itself is signed with Developer ID Installer.

The macOS certificate confusion is often compounded by trying to use the same certificate for both App Store submissions and direct distribution. This does not work. App Store Distribution and Developer ID Application are distinct certificate types for distinct distribution channels. If you distribute both through the App Store and directly via your website, you need both certificate types, both issued through the same Apple Developer Program account but distinctly named.

Google Play: APK Signing Scheme and Play App Signing

Android app signing for Google Play involves two separate concepts that developers frequently conflate: the APK signing scheme version and Google Play App Signing.

APK signing scheme version requirements

Android supports multiple signing scheme versions. Google Play has enforced minimum signing scheme requirements that have tightened over time. As of current Play policy, all new apps submitted to Google Play must use APK Signature Scheme v2 at minimum, and v3 is strongly recommended. Apps signed only with Signature Scheme v1 (JAR signing) are rejected.

Scheme v1 uses JAR signing (META-INF directory entries). Scheme v2 and later sign the entire APK as a single block, providing better security against file modification after signing. Scheme v3 adds per-signer rotation support. Scheme v4 enables Android 11’s incremental delivery.

The rejection message for scheme version issues typically appears during upload to Play Console as a validation error: ‘Your APK or Android App Bundle needs to be signed.’ Ensure your build configuration enables v2 signing. In Gradle, this means signing configs with v2SigningEnabled = true.

Google Play App Signing

Google Play App Signing is Google’s system for managing app signing keys separately from developer upload keys. When enrolled:

• Upload key: You sign the APK or App Bundle with this key before uploading to Play Console. Google verifies this key matches your registered upload certificate. If the upload key is lost, Google can help reset it.
• App signing key: Google holds this key and uses it to sign the APK before distributing it to users. Users’ devices verify this key.

Common rejection cause after Play App Signing enrollment: the developer signs the submission with a key that does not match the upload certificate registered with Google. If you switch development machines, regenerate your keystore, or use a different signing key, Play Console rejects the submission because the upload certificate fingerprint doesn’t match the registered one.

If you have lost your upload key and cannot match it to the registered certificate, use the Google Play Console’s key reset process (available in App Integrity settings) to update the registered upload certificate. You cannot submit without either the original key or completing the reset process.

App Bundle vs APK signing

Google Play now prefers Android App Bundles (.aab) over APKs (.apk). App Bundles are signed the same way as APKs: with your upload key before submission. Google then repackages and signs the APKs delivered to users with the app signing key. If you are submitting App Bundles for the first time, ensure Play App Signing is configured in your Play Console account and the bundle is signed with your registered upload key.

Microsoft Store: Publisher Name Must Match, Microsoft Signs for Distribution

The Microsoft Store signing model is different from all other platforms: for apps distributed through the Microsoft Store, Microsoft signs the distributed package. Developers do not need a separate commercial code signing certificate for Store distribution.

What developers do need: an MSIX or MSIX bundle package where the Publisher attribute in the Package.appxmanifest matches the Publisher identity associated with the Microsoft Store account. This Publisher identity is assigned when the Store account is created and cannot be changed. Any mismatch between the manifest Publisher and the Store account’s Publisher identity causes rejection.

For the submission itself, the package uploaded to the Store should be signed with a certificate whose Subject matches the manifest Publisher. Microsoft’s Partner Center validation checks this. The certificate used for upload can be a self-signed certificate as long as the Subject matches: Microsoft re-signs the distributed package with their own certificate chain.

In Visual Studio, when packaging for the Microsoft Store, the wizard automatically associates the project with the Store app and updates the manifest Publisher with the correct Store Publisher identity. If you are packaging manually or using a CI/CD pipeline, retrieve the Publisher identity string from Partner Center (Account Settings, Developer Info, Publisher ID in the CN=xxx format) and ensure it appears character-for-character in your Package.appxmanifest Identity Publisher attribute.

Common App Store Rejection Messages and Their Code Signing Causes

Frequently Asked Questions

Do I need a commercial code signing certificate for iOS App Store submission?

No. iOS and macOS app signing uses certificates issued by Apple through the Apple Developer Program, not commercial code signing certificates from public CAs. Apple issues Development, Distribution, and Developer ID certificates directly to enrolled developers. Commercial code signing certificates from companies like DigiCert or Sectigo are not used for Apple platform app signing. To submit to the iOS App Store, you need an Apple Developer Program membership ($99/year), and Apple provides the Distribution certificate through the program.

Can I use one certificate for both App Store and direct distribution on macOS?

No. Mac App Store distribution requires a Mac App Store Distribution certificate specifically. Direct distribution outside the App Store requires a Developer ID Application certificate. These are distinct certificate types issued for distinct distribution channels through the same Apple Developer Program account. If you distribute through both channels, you need both certificate types. Using a Developer ID certificate for an App Store submission results in rejection; using a Mac App Store Distribution certificate for direct distribution does not work because macOS Gatekeeper looks for a Developer ID certificate on directly downloaded apps.

My Android upload key was lost. How do I submit to Google Play?

If you enrolled in Google Play App Signing (which Google now requires for new apps), your app’s distribution signing key is held by Google. Your upload key is used only to authenticate submissions. If the upload key is lost, go to the Play Console for your app, navigate to Setup, App Integrity, and request an upload key reset. Google provides a new upload certificate. This process requires verification of your identity and account ownership. For apps not enrolled in Play App Signing (legacy), losing the signing key means you cannot update the app on Play; you would have to publish as a new app with a new package name.

Does Windows require a commercial EV certificate for Microsoft Store submissions?

For apps distributed through the Microsoft Store, no commercial EV certificate is required. Microsoft signs the package distributed to users. For the upload to Partner Center, the package needs to be signed with a certificate whose Subject matches the Store’s Publisher identity for your account. This can be a self-signed certificate. Commercial code signing certificates (OV or EV from public CAs) are required for Windows software distributed outside the Microsoft Store as direct downloads, not for Store-distributed apps.

Gloria Bradford

Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.

Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.