The framework you use to build your app shapes how you create the deployable package. After that, the publishing process is identical regardless of framework — same developer accounts, same review criteria, same compliance requirements.
But the path from source code to a signed, uploadable binary is different for each. Here's what actually changes — and what stays the same.
The Key Insight: Framework Affects the Build, Not the Publish
All three frameworks produce the same end artifacts: a .ipa file for iOS and an .aab bundle for Android. Once you have those, you upload them to App Store Connect or Play Console the same way regardless of how they were built.
What differs is the toolchain you use to produce those artifacts — and the specific gotchas each framework has at the build step.
Flutter: What to Know at the Publishing Step
Flutter compiles to native code — there's no JavaScript bridge or intermediate runtime. This generally means good performance and smaller binary overhead, but Flutter apps can still be large if assets aren't managed carefully.
Building the iOS Package
Flutter doesn't integrate directly with Xcode's archive workflow the way native Swift apps do. You build and archive using Flutter's CLI:
flutter build ipaThis requires your code signing credentials to be configured in Xcode first — the App ID, Distribution Certificate, and Provisioning Profile must all be in place before the Flutter build command will produce a signed .ipa.
A common mistake: running flutter build ipa before configuring signing and getting a build that uploads to App Store Connect but fails processing. Configure signing in Xcode under Signing & Capabilities first, then run the Flutter build.
Building the Android Package
Flutter produces an .aab through:
flutter build appbundleBefore running this in release mode, create your keystore, configure the key properties file, and update your app-level build.gradle with the signing config. Store your keystore file securely.
React Native and Expo: What to Know at the Publishing Step
React Native apps can be built locally using Xcode and Android Studio, or remotely using Expo's EAS Build service. For founders without a Mac — which is required to build an iOS app locally — EAS Build is the practical path to iOS distribution.
Using EAS Build
EAS Build handles the entire build process in the cloud. You configure your project with eas build:configure, connect your Apple Developer account, and EAS manages credentials, certificates, and provisioning profiles on your behalf. The build output is a downloadable .ipa or .aab that you then upload to the respective store.
One important decision: EAS can store your credentials in Expo's infrastructure, or you can configure it to use local credentials only. If account security is a priority — and it should be — local credentials give you full control over where your signing keys live.
Over-the-Air Updates and Review
React Native apps can use over-the-air (OTA) update services like Expo Updates to push JavaScript bundle changes without going through app store review. This is a legitimate and commonly used feature. The important boundary: OTA updates cannot change native code, add new permissions, or alter app behavior in ways that would require review. Apple and Google both explicitly prohibit using OTA updates to circumvent review for changes that would normally require it.
Native Swift and Kotlin: The Standard Toolchain
Native apps built with Swift or Kotlin use the standard Apple and Google toolchains — Xcode for iOS, Android Studio for Android. There's no additional build layer to configure. The archive and distribution workflow is well-documented and stable.
The tradeoff is development time: two separate codebases to maintain, two separate build processes, two sets of platform-specific knowledge. For teams with dedicated iOS and Android developers, this is fine. For solo founders or small teams, the cross-platform frameworks above typically make more sense.
What's the Same Regardless of Framework
Once the binary is built and signed, the rest of the process is identical across all frameworks:
- Developer accounts: same Apple Developer Program and Google Play Console
- Code signing: same Distribution Certificate and Provisioning Profile for iOS, same keystore for Android
- Store listings: same metadata, screenshot, and description requirements
- Compliance forms: same Data Safety and Privacy Nutrition Label requirements
- Review process: same guidelines, same reviewers, same rejection reasons
- Froxi AI guides: work identically regardless of framework — the guide covers the publishing layer, not the build layer
