Whenever you duplicate a scheme in XCode, if you do not make any changes the the scheme configuration (‘edit scheme’ in XCode), XCode will not create a separate .xcscheme file for the new scheme.
This, apparently, causes
eas build to complain about not being able to find the scheme:
✔ Linked to project @****/****
Error: scheme '****' does not exist, make sure it's marked as shared
Notice that the scheme exists, and is marked as shared at this point. As soon as you click ‘edit scheme’ in XCode, even without changing anything, the .xcscheme file is created, and eas can find the scheme at this point. I haven’t had this problem before with fastlane (that I used to build this project with before swtiching over), so apparently it is possible to detect if a scheme exists in a different way (or maybe fastlane doesn’t check, and just passes it to xcodebuild, I don’t know).
Thanks for trying out EAS Build and reporting the issue.
Notice that the scheme exists, and is marked as shared at this point.
I tried to repro your issue but when I duplicate a scheme in Xcode, it’s not marked as shared by default. Can you tell me what Xcode version are you using? I have 12.5.1.
I clicked the
Duplicate Scheme button
newscheme scheme is not marked as shared by default.
Only after I checked the
Shared checkbox, the
.xcscheme file was created
I think this is actually not a bug:
- EAS CLI relies on the
.xcscheme files to find the appropriate scheme configuration. The warning is explicit about the fact that the scheme needs to be shared.
- Until you mark a scheme as shared, Xcode stores the data about the scheme in
ios/*.xcodeproj/xcuserdata. This directory is almost always git-ignored for iOS/Xcode projects. This means if your teammate opened the same project in their Xcode, they wouldn’t see any scheme that wasn’t shared.
- In my opinion, relying on a file that is not checked in to the repository would be error-prone so I don’t think we want to copy the fastlane behavior.
@dsokal Thank you for looking into this. However, the behavior I’m seeing is different. The crucial difference is exactly what I described. You have the ‘edit scheme’ window open when you select ‘duplicate scheme’. As I mentioned, opening that window creates the scheme file for me. Now try these steps instead:
In the main window (where you see the project and targets, right mouse click on a shared scheme in the targets list, and click duplicate.
Go to Product > Schemes > Manage Schemes and verify that the new scheme is marked as shared there.
Check your git status (or your local file structure) and see that NO scheme file has been created at this point.
XCode seems to only create the scheme file, when you go in to edit the scheme (at which point the configuration could start to differ from the other scheme, hence a separate scheme file is needed at this point only)
Ah, I think I know what’s the problem. We you right-click on the target name and then select
Duplicate, you’re not duplicating the scheme, you’re actually duplicating the target. I guess this is one of the Xcode quirks. Like you pointed out Xcode seems to generate the scheme file when you open its settings.
Unfortunately, I don’t know if we’re going to change this behavior soon. Do you have any reasonable use case for duplicating the target instead of the scheme?
Hmmm… that’s peculiar, because when duplicating the target, the scheme does show up in the ‘Manage schemes’ dialog after all, and is even marked as Shared there. So, at least according to the UI in XCode, there is a scheme at that point.
xcodebuild -list -project myproject.xcodeproj also list both the Target and the Scheme. So for all intents and purposes, it does exist. And when I share this with other people in my team, they see it too (even after deleting the scheme manually from the userdata file still, the xcodebuild list command still sees it as a scheme, so it doesn’t depend on gitignored local data either).
Because there is a workaround, which is to go in and edit the scheme, it isn’t a huge deal anymore, but it’s a little more than ‘just an XCode quirk’, as native build tooling is able to use a scheme created this way (xcodebuild).
I guess it does make sense though to stick to your current detection mechanism for simplicity, it might not hurt to mention this scenario somewhere though, as I can’t imagine I’m the only dev in the world that duplicates a target like this
Again, thanks for looking into this.
Unfortunately, I can’t agree with you
See the output of the command that you shared. I followed the steps from your previous post. I duplicated the
turtleapp target -
turtleapp copy was created. However, the Scheme list doesn’t contain the
turtleapp copy target. This means that it’s not a schema even for
However, when I open the scheme settings (and the scheme file is generated), the scheme show up in the list:
I guess this is the problem with the UI of Xcode as it merges the targets and schemes in the list in the “Manage Schemes…” dialog. Previously, you pointed out that it’s marked as share and I suspect it means the target is shared, not the scheme (as it does not exist at this point).
I list my current targets and schemes
I duplicate the ‘MySpecialTest copy’ target in XCode, and don’t touch anything else
I run the exact same command again
What am I doing differently?
Facing exactly the same issue but in my case I cannot move forward despite editing the scheme.
"eas build --platform ios" for the first time on an “expo managed” app and I get the following error"
Error: We did not find any schemes in the Xcode project, make sure that at least one
scheme is marked as "shared" in Xcode, and that it's listed in the output of "xcodebuild
I can see my scheme and it is flagged as “Shared”. Even if I edit it and then run the command I still get the same error.
If I run the old command
expo build:ios it works as usual and creates the build.
Any idea please?