That's great but how do you prevent release configuration from building when you're building your package's tests as part of another scheme that uses an Xcode configuration called "Testing"?
I hope you can see how the current inability to use a custom build configuration in a Swift package is extremely limiting.
I think this is a good point. Regardless of the larger discussion of having a more sophisticated feature, we should document the heuristic, so that it's clear how it works.
Our app has a configuration called "Testing", but the heuristic decides to build "Release" for this (which has testability disabled). It would be nice if the heuristic could at least be patched so it could recognize the word "test" in the configuration name and enable testability... maybe this could happen sooner than full support for custom config names.
BTW I was able to find a workaround for this issue.
Namely, renaming our custom "Testing" configuration to be called "Debug_Testing" results in SPM building the packages in Debug mode (where testability is enabled by default). Evidently having the name of the configuration start with the word, "Debug", is enough to trigger the above-mentioned heuristic not to build in "Release" configuration.
Hope this workaround is helpful to someone else. I thought I'd posted it here already, but I guess I am thinking of a different thread elsewhere.
Sorry for refreshing this issue but i think it's still relevant.
Whole week i've been investigating the same kind of problem with build configurations due to switching from cp to spm and i must admit that these conditions doesnt work as expected.
We had similar issue with custom conditions being embedded within our packages which makes up the whole app (we have about 15 packages with different features/kits etc, these are mandatory because our other apps are based on them).
In our app there are couple of schemes: App Beta (release), App Dev Beta (debug), App UITests (debug) etc. Some are used only on CI env. Each scheme have it's configuration based on requirements/endpoints so App Beta have configuration named "Beta" which sets beta env settings and it's a release clone, while App Dev Beta has "Dev" configuration (clone of debug). These have
appropriate conditions ex: PROD, BETA, TESTING, MOCK etc
So basically we had to change all nested conditions to Debug/Release because other than that are useless, because we are not able to link conditions to schemes/configurations.
We agreed that this inconvenience is acceptable and should proceed to change that, but... while working on it we discovered that even when specified DEBUG/RELEASE conditions within packages manifests doesnt relates with debug/release configurations with our app. Example: I'm on the App Beta scheme which has beta configuration (clone of a release) and some packages enters DEBUG condition which is not expected and irrational tbh. We don't know how it gets recognized because it is not documented anywhere and we can't rely on these conditions how we wanted to.
These conditions seems to be also cached somehow because quick switch between schemes for different configurations without cleaning project enters condition for previous one on launching. Above solution to prepend with Debug_ seems not to make any difference in our case as well as switching to xcode13.
So, is there any documentation available by now?
Or maybe a way to just define if package dependencies should be build with debug or release config instead of relying on the heuristic to do its magic? Could be just "yet another Build Setting" in my target config.
facing the same issue, spm is just not ready for production level applications
At the moment we are using XcodeGen with custom build configurations Debug, Release, DemoDebug, DemoRelease, Naked, Test, ProfileOptimizedForSpeed, ProfileOptimizedForSize, ProfileWithSymbols.
We tried to use SPM. But we can't fine tune build settings for at least performance testing (the custom build configurations shown above with Profile prefix).
We will continue to use XcodeGen.
I don't really using custom configurations a lot. But for me there are 2 things, which missing, before I can fully switch to SPM.
Until these 2 or theor replacement implemented, I had to stick to swift package generate-xcodeproj, XcodeGen or plain xcode project, depending on project.
If you're using a Swift Package in Xcode, you can still use schemes, and you can include environment variables in your schemes.
There are few issues with using schemes the way they are now.
swift run
So, it will be nicer to have proper way, when schemes generated based on my files or package.swift.
And in this case same config might be used if I do swift run.
TBH, I understand that now I can use json file, which I will use as default values if nothing exist in env, but this sounds more like workaround, especially, when we involve tests, which expect some env to be overridden. So I have order ENV > TestEnv.json > EmbeddedEnv.json
A filename that starts with "." indicates that the file shouldn't show up in finder, not that it shouldn't shouldn't be checked in to source control. In fact, the [package folder]/.swiftpm/xcode/xcshareddata folder is checked in to git by default. Make sure to check the "shared" checkbox so that the scheme shows up in this folder, as opposed to [package folder]/.swiftpm/xcode/xcuserdata.
This is false. The name of the scheme can be whatever you want. You will, however, have to re-add the targets to the scheme.
How do this work?
re-add target to scheme, delete old one. But result the same, I will need to do 2 separated editing. This might lead to a mistake.
To be honest - it sounds weird - make files hidden in finder, but add them to your source control. They did hidden for a reason. Reason - they are generated and maintained not by user. So I still do not like idea to add such files to git.
gitignore - I see that here github by default commented .swiftpm folder. But I still prefer not to add such folder to a git
When app starts, it read specific file and populate values from there. Let's call it EnvironmentService. When someone in app want to read env variable, they do subscript on it, and inside you implement logic, on try to find in actual env, if nothing there - return default from embedded json. Alternatively, you can have it in harcoded struct with your desired settings in code, and switch values depending on type of run and run parameters.
Vapor already load env files - https://docs.vapor.codes/4.0/environment/
How often are you renaming your targets? Do you do this so many times that it becomes inconvenient to change your schemes to include the correct targets?
It's very bizzare to want to add a folder to source control but then to not do so just because of some subjective preference for never adding folders than begin with ".". If you need a file in source control, add it to source control, regardless of the name. Otherwise, you're just making things harder for yourself.
Also, in this case, the folder that contains the schemes ("xcshareddata") does not have a "." in it; only the intermediate directory ".swiftpm" does.
This is false. Although Xcode does auto-generate schemes for you, they are maintained by the user. When you edit your scheme, you are maintaining it.
Do you know if this is now documented somewhere? Would like to understand what is the heuristic used.
We were using .define("DEBUG", configuration: .debug)) to inject custom configurations into our packages and, in our case, this only broke when upgrading to Xcode 16.1. We had to prefix our Configuration with "Debug".
I'm not sure if this is something that changed on xcodebuild or in Swift Package manager itself. But since I see people complaining about this on 2021, I'm confused now.