eas-cli icon indicating copy to clipboard operation
eas-cli copied to clipboard

EAS Workflows not submitting to the corresponding iOS app

Open hot2eatorg opened this issue 6 months ago • 8 comments

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:

Image Image

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

hot2eatorg avatar Oct 18 '25 19:10 hot2eatorg

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 avatar Oct 21 '25 16:10 fireinnti

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

fireinnti avatar Oct 22 '25 22:10 fireinnti

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

eas submit --platform ios --profile production

hot2eatorg avatar Oct 22 '25 22:10 hot2eatorg

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 avatar Oct 22 '25 22:10 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 avatar Nov 06 '25 15:11 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 avatar Nov 06 '25 16:11 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.

fireinnti avatar Nov 10 '25 15:11 fireinnti

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.

Github issue

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

fireinnti avatar Dec 09 '25 02:12 fireinnti