Mobile Veröffentlichung vorbereiten

Mobile Release Checklist

Prepare the repository; do not upload, submit or publish builds. Report what a person must do in the store consoles.

Versioning

• Bump the user-facing version (iOS CFBundleShortVersionString, Android versionName) following the repo's scheme, usually semver.
• Increment the build number (iOS CFBundleVersion, Android versionCode) for every uploaded build; it must exceed every earlier upload.
• Change versions where the repo keeps them: app.json or app.config (Expo), pubspec.yaml x.y.z+build (Flutter), Info.plist or xcconfig, build.gradle. Keep platforms in sync.
• If EAS autoIncrement or a CI script manages build numbers, do not bump them by hand.

Signing

• Never commit keystores, .p12 or .p8 files, provisioning profiles or their passwords. Reference them through env vars, CI secrets or EAS credentials.
• Release builds use the release signing config, never debug. The bundle ID / applicationId must match the store record.

Assets

• App icon in all required sizes: 1024x1024 iOS marketing icon without alpha; Android adaptive icon (foreground, background, monochrome).
• Native launch/splash screen configured so there is no white flash; dark variant if the app supports dark mode.

Permissions and privacy

• Every iOS permission used has a specific NS...UsageDescription explaining why. Remove unused permissions, including Android manifest entries merged in from libraries.
• iOS privacy manifest (PrivacyInfo.xcprivacy) declares collected data and required-reason APIs, covering third-party SDKs.
• Google Play Data safety form and Apple privacy labels must match what the app and its SDKs collect. List that data for the person filling them in.
• Target API level meets the current Google Play requirement; iOS builds with the required Xcode and SDK.

Store metadata

• Screenshots for required device sizes showing the current UI; title, subtitle, description, keywords, support and privacy policy URLs.
• Release notes: user-facing changes in plain language, for each store locale.
• Demo account and reviewer notes if login is required.

Quality gates

• Test the release build on real devices: oldest supported and latest OS on both platforms, small and large screens.
• Test a fresh install and an upgrade from the current store version (migrations, stored session, cached data).
• Crash reporting (Sentry, Crashlytics) active in release, with dSYMs, mapping files and source maps uploaded by the build config.
• No debug logging, dev menus or test endpoints in release; production API endpoints and flags set.

Rollout

• Recommend a staged rollout (Play percentage rollout, App Store phased release) and watching the crash-free rate before 100%.
• Know how to pause the rollout; keep the previous build available.

Before you finish

• Version and build number bumped consistently on every platform.
• No signing secrets committed; release signing config used.
• Icons, splash and permission strings complete; unused permissions removed.
• Privacy manifest and data safety details match actual collection.
• Release build tested on real devices, including the upgrade path.
• Release notes and the manual store steps reported.