Builds App Store Release Guide

This guide explains how OMIA build outputs are prepared for Android, Windows, and Mac release workflows. It covers what files you receive, what security details are exposed in the build interface, and what you still need to do before public distribution.

Android

Android builds are released as AAB/APK outputs together with the keystore details used for that build and the downloadable keystore.jks file. After the build completes, those details become visible from the dropdown inside the build card, along with the package name.

Your keystore.properties values are double encrypted in transit and on our servers and are only decrypted for display in your interface.

What you receive after the build finishes

• The generated AAB or APK artifact.
• The package name used for the build.
• The keystore details shown in the build-card dropdown.
• The keystore.jks file for store signing and verification workflows.

How to extract the SHA-256 fingerprint

You can extract the signing certificate fingerprint for Play Console or other Android store integrations with the keystore.jks file and the values from keystore.properties. The safest workflow is to read the alias from the properties file and let keytool prompt you for the store password instead of placing secrets directly in your shell history.

keytool -list -v \
  -keystore "/path/to/keystore.jks" \
  -alias "YOUR_KEY_ALIAS"

When prompted, enter the store password from your keystore.properties file. The output includes the SHA256 fingerprint you can paste into the Android store or API provider that requires it.

Installing APKs directly on Android devices

APK builds can be installed directly on Android devices by approving the standard platform warning for installs from outside the Play Store. The exact wording varies by device vendor, but it usually means enabling installation from the current browser, file manager, or installer and then confirming the install.

OMIA runs antivirus checks as part of the build process, and most APK installer flows already include their own scanning or Play Protect-style checks. If you want additional assurance, you can run the APK through a trusted targeted antivirus tool before distribution or local installation.

Windows

Windows builds are delivered as zipped Flutter unsigned executable outputs. You can use the included executable as-is for direct distribution, or use it as the basis for packaging into MSI, MSIX, or other Windows installer formats.

For the most up-to-date packaging workflow, refer to the Microsoft Windows packaging documentation: Windows MSIX Packaging Tool Overview.

What to expect when launching the EXE

Most Windows systems will launch the generated executable with minimal blockers. On some systems, SmartScreen or third-party antivirus tools may warn on first launch because the build is an unsigned executable. Those warnings are environment-specific rather than evidence of malicious content.

If your distribution target requires cleaner install UX, package the executable into a signed MSI or MSIX release before shipping it publicly.

Mac Builds

Mac builds require notarization for the smoothest launch experience on end-user devices. For public distribution, you need an active Apple Developer account and a valid signing identity. For local testing, macOS can still open an unsigned or unnotarized app if the user explicitly allows it from the Privacy & Security section of System Settings.

OMIA provides Mac builds as a zip containing the .app bundle plus the Release.entitlements file. That gives you what you need to sign the app with sandboxing enabled and then package it into a DMG or PKG for release.

Sanitized signing and notarization commands

Use placeholders for your application name and Apple credentials. Replace each placeholder with your own values before running the commands.

codesign --deep --force --verify --verbose \
  --sign "Developer ID Application: YOUR_COMPANY_NAME (YOUR_TEAM_ID)" \
  --timestamp \
  --options runtime \
  --entitlements "Release.entitlements" \
  "YourApp.app"

hdiutil create -volname "YourApp" \
  -srcfolder "YourApp.app" \
  -ov -format UDZO \
  "YourApp.dmg"

xcrun notarytool submit "YourApp.dmg" \
  --apple-id "YOUR_APPLE_ID" \
  --team-id "YOUR_TEAM_ID" \
  --password "YOUR_APP_SPECIFIC_PASSWORD" \
  --wait

xcrun stapler staple "YourApp.dmg"

Mac release notes

If you run into notarization problems, use Apple's notarization troubleshooting reference: Resolving common notarization issues.

• Use your own Developer ID certificate for distribution.
• Keep the provided Release.entitlements file aligned with the app you are signing.
• DMG is usually the simplest format for direct distribution, while PKG may fit managed enterprise environments better.
• If you skip notarization during internal testing, users can still allow the app manually from System Settings, but that is not ideal for production release.

Release retention and security summary

• Build details and stored artifacts are retained in OMIA cloud storage for up to 7 days.
• All builds are Flutter apps generated against the latest stable libraries in the active build pipeline.
• Android keystore properties are double encrypted in transit and at rest and only decrypted for your interface.
• OMIA runs antivirus checks during build processing, but you can still run a trusted targeted scanner before distribution if your release workflow requires it.

Final release checklist

1. Download your build artifacts and any signing files before the 7-day retention window expires.
2. Verify package names, keystore details, and release metadata inside the build-card dropdown.
3. For Android, extract the SHA-256 fingerprint before connecting store or API integrations.
4. For Windows, decide whether direct EXE delivery is enough or whether you need MSI or MSIX packaging.
5. For Mac, sign, notarize, and staple the DMG before public distribution.