# Native iOS and Android Apps: More Ways to Ship a Release

> Native iOS apps in Swift and native Android apps in Kotlin are now project types, together with fine-grained release options for macOS applications.

> Source: https://www.application-platform.com/en/blog/native-app-releases/

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 or Kotlin for Android. A shared library for several apps is published as a Dart, NPM or other supported package – Composer, Maven and Kotlin packages come next.

## 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.

{{< visual type="stores" caption="Publishing to the App Store and Play Store from the same pipeline." >}}

## 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](/en/stacks/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](/en/solutions/app-store-automatisierung/).