LaunchLint Academy
The short answer
The bundle ID and Android application ID are the app’s durable technical identity. They must match the store record, signing setup, capabilities, OAuth configuration, and uploaded artifact.
- Keep the user-facing version separate from the internal build number, increment every technical counter correctly, and verify which identity choices become effectively permanent after the first upload.
Evidence required for release
Do not review app identity, signing, and versioning as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Keep three evidence layers separate for app identity, signing, and versioning: statically visible project configuration, behavior on a clean device, and external settings in Apple Developer, App Store Connect, or Play Console. The review is reliable only when those layers describe the same release candidate. Give every mismatch an owner and a stop condition instead of assuming a default will be correct.
Evidence required for release
- Production value for choose the technical app identity identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
1. Choose the technical app identity
Use reverse-DNS identifiers that can remain with the product and your developer account. The display name and technical identity are separate.
Do not review choose the technical app identity as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Evidence required for release
- Production value for choose the technical app identity identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
2. Match the Apple bundle ID
CFBundleIdentifier, App ID, and App Store Connect record must match exactly. The bundle ID is not a marketing name that can be replaced after upload.
Do not review match the apple bundle id as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Evidence required for release
- Production value for match the apple bundle id identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
3. Understand Android applicationId
Separate applicationId, package declarations, and the Gradle namespace. Google Play treats the published application ID as permanent identity.
Do not review understand android applicationid as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Evidence required for release
- Production value for understand android applicationid identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
4. Verify signing ownership
Review Apple team and provisioning plus the Android upload key and Play App Signing. Document recovery and ownership before access depends on one person.
Do not review verify signing ownership as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Evidence required for release
- Production value for verify signing ownership identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
5. Separate version and build number
The visible version describes the release to users. buildNumber and versionCode identify technical artifacts and must advance for new uploads.
Do not review separate version and build number as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Evidence required for release
- Production value for separate version and build number identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
6. Resolve framework configuration
Do not stop at app.json or YAML in Expo, Flutter, or Capacitor. Plugins, flavors, and environment variables can alter native values.
Do not review resolve framework configuration as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Evidence required for release
- Production value for resolve framework configuration identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
7. Map identity-dependent integrations
Push, universal links, app links, OAuth, keychain groups, and payment services often use bundle ID, team ID, or application ID.
Do not review map identity-dependent integrations as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Evidence required for release
- Production value for map identity-dependent integrations identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
8. Approve the signed candidate
Compare store record, binary metadata, signature, version, and installed app. Record the exact artifact being submitted.
Do not review approve the signed candidate as an isolated switch. Connect it to app identity, signing, and versioning, the signed production artifact, and the values in the store console. Record which file produces the setting, whether a framework or plugin can alter it during the build, and how you inspected the resolved value. A plausible entry in source control does not prove that the uploaded binary contains the same configuration.
Evidence required for release
- Production value for approve the signed candidate identified
- Responsible project file or store setting linked
- Resolved native configuration inspected
- Signed artifact checked on a clean device
- iOS and Android differences recorded
- Every mismatch has an owner and stop condition
Frequently asked questions
Can I change the bundle ID after the first upload?
Not as a display name within the same app record. A different bundle ID represents a different app identity.
Are package name and namespace identical?
They can match, but modern Android projects use them for different purposes. applicationId identifies the published app.
Can a build number be reused?
New uploads require valid, usually increasing technical versions. Read the specific store error and increment the correct value.
Can LaunchLint validate certificates?
It can detect configuration and contradictions. Private keys, store ownership, and the complete signing chain remain outside static project analysis.