EAS Workflows not submitting to the corresponding iOS app
Build/Submit details page URL
https://expo.dev/accounts/michal.hot2eat/projects/hot2eat/workflows/0199f876-de12-7031-9c1a-f3fdf367d5f9
Summary
Hey, I'm using the EAS workflows to build and submit my apps. In Android everything works as expected but in iOS, the submit job keep submitting my build into another Apple Store Connect app.
I currently have 2 different apps, one for preview and one for production. The workflows with the preview environment works fine. But the production one also submits the app here instead to the production app.
I can see that all the values in the submitting logs are right, like sku, profile and ascAppId.
The prod ascAppId is 674**24054. I can see its being submitted:
[11:08:25]: Creating authorization token for App Store Connect API
[11:08:25]: Ready to upload new build to TestFlight (App: 674**24054)...
[11:08:25]: Going to upload updated app to App Store Connect
[11:08:25]: This might take a few minutes. Please don't interrupt the script.
[11:09:36]: --------------------------------------------------------------------
[11:09:36]: Successfully uploaded package to App Store Connect. It might take a few minutes until it's visible online.
But the app ends up here:
I'm specifying everything I can in the eas.json file so both apps get submitted to the right place.
Here is my eas.json
{
"cli": {
"version": ">= 10.2.4"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"preview": {
"environment": "preview"
},
"production": {
"environment": "production"
},
"e2e": {
"environment": "preview",
"distribution": "internal",
"developmentClient": false,
"channel": "e2e",
"android": { "buildType": "apk" }
}
},
"submit": {
"production": {
"ios": {
"appleId": "info@****.com",
"ascAppId": "674**24054",
"appleTeamId": "**********",
"sku": "com.hot2eat.app"
},
"android": {
"track": "alpha"
}
},
"preview": {
"ios": {
"appleId": "info@****.com",
"ascAppId": "67**973422",
"appleTeamId": "**********",
"sku": "com.hot2eat.app.preview"
},
"android": {
"track": "internal",
"releaseStatus": "draft"
}
}
}
}
And here is my ios-production-build.yml
name: iOS Production Build
on:
push:
tags:
- "v*"
- "!v*-preview*"
jobs:
build_ios_production:
name: Build iOS app
type: build
params:
platform: ios
profile: production
submit_ios_production:
name: Submit to TestFlight
needs: [build_ios_production]
type: testflight
params:
build_id: ${{ needs.build_ios_production.outputs.build_id }}
profile: production
I've also tried to remove the profile from the submit params but the outcome is the same.
Managed or bare?
managed
Environment
expo-env-info 2.0.7 environment info:
System:
OS: macOS 15.6.1
Shell: 5.9 - /bin/zsh
Binaries:
Node: 23.3.0 - ~/.nvm/versions/node/v23.3.0/bin/node
Yarn: 1.22.22 - ~/.nvm/versions/node/v23.3.0/bin/yarn
npm: 10.9.0 - ~/.nvm/versions/node/v23.3.0/bin/npm
Watchman: 2025.05.26.00 - /opt/homebrew/bin/watchman
Managers:
CocoaPods: 1.16.2 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 25.0, iOS 26.0, macOS 26.0, tvOS 26.0, visionOS 26.0, watchOS 26.0
IDEs:
Android Studio: 2024.2 AI-242.23339.11.2421.12550806
Xcode: 26.0.1/17A400 - /usr/bin/xcodebuild
npmPackages:
babel-preset-expo: ~54.0.0 => 54.0.3
expo: ^54.0.10 => 54.0.10
react: 19.1.0 => 19.1.0
react-native: 0.81.4 => 0.81.4
npmGlobalPackages:
eas-cli: 16.20.0
Expo Workflow: bare
Error output
No response
Reproducible demo or steps to reproduce from a blank project
I second this, I have a workflow that creates 2 builds and I have followed the handover to the submit step and its submitting the same app for both.
If I then do submit from the cli on the same build it submits correctly.
Yeah ive tried to submit from the cli and works fine:
eas submit --platform ios --profile production
I had a single workflow for two apps, (two bundle id's) and even pulling those apart and having two seperate workflows I still run into the same issue. Very confusing.
I tried to combine the workflows, where it goes from first app build to first app submit, and then from second app build to second app submit. However, I still encounter issues where the first app submission is showing on App Store Connect as a failed submission, stating it's using the second app bundle ID. I've verified that the build and submit jobs are logging the correct information, but the submission is consistently failing. I'll be trying to do a custom job instead of the prepackaged jobs. The prepackaged jobs have seemed less reliable than using the CLI directly. It's somewhat surprising that I need to resort to so many custom jobs to replicate the prepackaged ones, as they are often buggier or lack relevant features.
Hope to get someone to look at this at some point, but not holding my breath, have to work with what we've got.
Heads up for others, found a fix perusing the other issues in this repo. This issue mentions a bundleIdentifier property in eas.json bundleIdentifier in the submit step. I set the bundle Identifiers there, and it seems to have resolved my issue. However, I agree with the original person from February that this feels like a bug, as it's not correctly capturing the bundle identifier from the build. The workflow is also misleading in the logs, claiming to submit the correct bundle identifier, but App Store Connect reports otherwise. But yeah, just setting that property has fixed my issue.
Hopefully, this helps someone. Here's expo documentation about it https://docs.expo.dev/eas/json/#bundleidentifier
Following up on this, the fix I mentioned earlier hasn't fully fixed my issue. Feels like every once in a while, it still messes up. Might try doing a custom job, which is sad as I wasn't wanting to do that as that feels like circleCI a bit.
I did a custom job and it was still having issues, so actually the error seems to be on Apple's side with the new altool its shipping with xcode 26. Per a user in this thread it seems that its fixed on xcode 26.1 so once the workers start shipping with that, this bug should be fixed.
By doing a custom fastlane job I'm able to use some flags to utilize the old altool to get around this.
That link describes my issue perfectly, if expo/eas people want to upgrade their vm to utilized xcode 26.1 I would love that!
Potentially, if you set the macOS image to macos-sequoia-15.6-xcode-16.4, it might work like it should, since it would be utilizing the old altool.
Here is the syntax for that. Here