Shipping an app to a store rarely fails at the build. It fails in the layer between the last commit and the store listing: certificates, signing identities, store accounts and identifiers that all have to match exactly. That layer tends to live on individual machines — a keystore in someone’s downloads folder, a certificate in a colleague’s keychain. As long as the same person cuts every release, nobody notices. The moment somebody else takes over, the hunt begins.
As of 1 August the platform covers a wider set of release paths and keeps those credentials in one place.
Native project types in the wizard
The project wizard now offers native iOS apps in Swift and native Android apps in Kotlin as project types of their own, alongside Flutter and Expo — for cases where a cross-platform framework is not the right fit, such as an app that reaches deep into platform APIs, or an existing native codebase that carries on.
Pick a native stack and the platform proposes matching tooling: Xcode for iOS, Java for Android. Kotlin is also available as a tech stack for packages, useful for a shared library several apps depend on.
macOS: four release paths, configured separately
On macOS there is no single way to ship: an internally distributed app has different requirements from one in the Mac App Store. Four things are configured independently: Developer ID signing, notarisation, Mac App Store distribution and a public download. An internal tool can be signed, notarised and offered as a download without touching the store.
For Windows, the Microsoft Store and Azure Artifact Signing are available as connections.
-
App StoreApple releases with prepared metadata and assets.
-
Google PlayPlay Store listings populated automatically.
Link store accounts instead of retyping identifiers
When you link an App Store or Play Store account, the platform loads the apps that already exist there, and you pick the bundle identifier and package name from a list instead of typing them in. It sounds like a detail, but mistyped identifiers are a common way a release goes wrong: a single character is off, and the build runs the whole pipeline before the upload step reveals it.
Imported Android upload keystores can also be downloaded again, so the key stays available even when the local copy is missing.
Builds run in CI, releases go out through Fastlane
Builds happen in CI, with macOS machines available for iOS, so no dedicated Mac needs to sit in the office. Releases go out through Fastlane, so a release is no longer tied to one workstation — anyone with the right permissions can trigger it.
Related topics
If your work is mostly Flutter, nothing about that changes — see Flutter CI/CD. The native project types sit next to it, not in place of it. For the bigger picture of how a commit turns into a store listing, see app store automation.
