Best practice for EAS build with alternate bundle identifiers (bare workflow)

[lauc]

Hello,

I’d like to have 3 versions of our app: development, staging, and production. I’m able to use EAS Build profiles to setup the build with different environment variables and release channels, which is great. But I’d also like to be able to install the different versions on the same device at the same time.

I have been researching this and am unsure what the best practice would be for a bare workflow. I found this discussion for the managed workflow:

EAS Build Alternative Bundle Identifiers

I am using EAS build to create different app versions for different environments (production, staging etc) using profiles which is working well. I would now like to use different bundle identifiers to allow different versions to be installed simultaneously. In short, my question is how can I do this? I am using managed builds and I have tried setting the bundle identifier using ios.bundleIdentifier in app.config.js loaded from an environment variable set in eas.json. At the same time I set the …

I also found this git commit showing that you can’t set the bundle identifier in app.config.js anymore:

simplify app identifier management

I’m imagining that the right way to do this is to set an environment variable for the build process itself and tell Xcode to reference that, but I’m unsure. Thoughts?

Thanks.

[wkozyra]

You need to create 3 separate xcode targets and 3 separate schemes (one scheme per target). In Xcode you can specify different bundle identifiers for each target and in eas.json build profile you can define which scheme should be built.

[lauc]

Thanks for your quick reply. I think this sent me in the right direction, but I’m now getting an error on EAS Build:

Cannot set property ‘DevelopmentTeam’ of undefined

I have 3 targets setup, 3 scheme’s, and can build and install all 3 on the simulator. Any thoughts on why EAS Build is failing?

[wkozyra]

It looks like this section does not have an entry for the target.

This is the code that is failing expo-cli/ProvisioningProfile.ts at master · expo/expo-cli · GitHub . Previous step did work so target exist, it might be some change in how xcode is storing

Can you share your pbxproj file and xcscheme?

• xcscheme can be found ./ios/[project].xcodeproj/xcshareddata/xcschemes/[scheme name].xcscheme
• pbxproj can be found ./ios/[project].xcodeproj/project.pbxproj

[lauc]

Thanks for that. I seem to have gotten past that error by manually adding all of the targets to the TargetAttributes section of project.pbxproj:

TargetAttributes = {
					13B07F861A680F5B00A75B9A = {
						LastSwiftMigration = 1120;
					};
					ABF986F3273CBF0900BA7963 = {
						LastSwiftMigration = 1120;
					};
					ABF9870F273CBF1500BA7963 = {
						LastSwiftMigration = 1120;
					};
					ABF9878D273D3FF600BA7963 = {
						LastSwiftMigration = 1120;
					};
				};

Next I was getting ** ARCHIVE FAILED ** in the FastLane build. The original “Dev” target worked. This lead me to see that pods were not being created, so I modified the podfile to have a section for each target (as far as I can see, nothing in Xcode would do this automatically). Now the iOS build process seems to be working.

Now I am working on doing the same with Android. I have setup 3 productFlavor’s with 3 different applicationId’s. This is working locally. To get EAS Build to do this, it sounds like I need to override the gradleCommand (as shown here: Adding multiple targets and product flavors - #10 by wodin).

Would that just be :app:assembleStageRelease, for example? I will give it a try…

[wkozyra]

I seem to have gotten past that error by manually adding all of the targets to the

pod install would probably do that after defining targets there,

• if you are using dev client make sure to copy dev client config for all targets even if you don’t intend to use them as dev clients, toherwise dev client might be included in production builds
• if you see output duplicated few times when you running pod install you can wrapp everyting in abstract target

abstract_target 'common' do
  // all config should go here, targets bellow should be  empty

  target 'production' do
  end

  target 'staging' do
  end

  target 'dev' do
  end

Would that just be :app:assembleStageRelease, for example? I will give it a try…

Yes, btw specify applicationId per flavor with applicationId key, using applicationIdSuffix won’t work with eas

[lauc]

Reopening this, as I am now working on using this setup with EAS Submit (just for submitting the production version). Starting with iOS, when I try to submit (with eas submit -p ios --profile production --latest) I get the error message:

Multiple schemes and targets found in Xcode project, bundle identifier couldn't be resolved.

In eas.json, I have

    "production": {
      "ios": {
        "bundleIdentifier": "my.production.bundle.id"
      }
    }
  },

Is there anything special needed to use EAS Submit when you are using multiple schemes and targets, as described previously in this thread?

[wkozyra]

it looks like it’s a bug, you should get a better error message

you need to provide

        "ascAppId": "123456789",
        "appleId": "myappleid@gmail.com"

and set EXPO_APPLE_APP_SPECIFIC_PASSWORD env

or

        "ascAppId": "123456789",
        "appleId": "myappleid@gmail.com"
        "ascApiKeyPath": ''
        "ascApiKeyIssuerId": "",
        "ascApiKeyId": """

Configuring EAS Submit with eas.json - Expo Documentation