EAS Workflows not submitting to the corresponding iOS app

[hot2eatorg]

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

[fireinnti]

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.

[fireinnti]

If I then do submit from the cli on the same build it submits correctly.

[hot2eatorg]

Yeah ive tried to submit from the cli and works fine:

eas submit --platform ios --profile production

[fireinnti]

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.

[fireinnti]

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.

[fireinnti]

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

[fireinnti]

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.