In some apps there is a need to have very different settings in Info.plist depending on build configuration. One example could be different settings in NSAppTransportSecurity
to support self-signed certificates during development, which can be common in internal test environments. Currently when defining a target in Tuist we can only define one InfoPlist
per target.
The motivation for introducing per configuration InfoPlist
in a target is to avoid adding build phases for doing the same thing.
In many cases, xcconfig
settings or Info.plist
preprocessing can solve the issues described.
Info.plist even supports #if DEBUG
style statements, with the unfortunate side effect that Xcode can no longer read the file properly. 😆
So these approaches all work up to a point before we need separate files to be generated/used in order to ensure the app works as expected.
Introducing per-configuration support for InfoPlist
would streamline the use of Tuist for some of these more complex use cases.
One suggestion would be to extend the InfoPlist
enum with a new case perConfiguration([CustomConfiguration: InfoPlist]
. This might lead to the enum having to be indirect
and could potentially have side effects for the Codable
conformance.
The INFO_PLIST_FILE
build setting would also need to be updated to point to the correct generated file for each configuration.
Adding a new case
to the InfoPlist
enum "shouldn't break™️" any existing Tuist projects, however it could increase the complexity of the feature itself and its maintenance.
If the users does not define an Info.plist for a specific configuration, how should that be handled? This might require more logic to see that each configuration is included in the Dictionary.
It is perhaps not a common use case and as such could be considered an edge case.
As a an additive feature, I don't think it impacts how most Tuist users begin to learn how to use Tuist.
An alternative solution (that we've used in our company) is to generate different files in a pre-action script and then point INFO_PLIST_FILE
to the generated files. The solution is somewhat cumbersome but does the job.
I think it should be possible to introduce as a non-breaking change.
Updated example perhaps?
Is adding another case to the InfoPlist
enum a valid approach?
Pay now to fund the work behind this issue.
Get updates on progress being made.
Maintainer is rewarded once the issue is completed.
You're funding impactful open source efforts
You want to contribute to this effort
You want to get funding like this too