Substitute values in project.pbproj with configurable variables

[UNIDY2002]

This is part of the effort to mitigate the pain in configuring and upgrading project.pbproj.

Take the upgrade from 0.67 to 0.68 as an example (reference: #528 (comment)). The value for CLANG_CXX_LANGUAGE_STANDARD is updated to c++17, and the build phase scripts are also changed, which are both hidden among the diffs and hard to notice.

Another example is the upgrade from 0.68 to 0.69. The value for IPHONEOS_DEPLOYMENT_TARGET (which occurs 4 times) is updated from 11.0 to 12.4, and the build phase script is also updated.

My plan is to use a separate .xcconfig file to define some variables in plain text, so that during upgrades, (ideally) only the .xcconfig file requires modifying (which is also easier to diff), and the project.pbproj can be left untouched.

---

You might argue that the values I listed above rarely change, and that it is hard to predict which values might get changed in the future. Then I would like to describe another case where this design is worthwhile.

With this design, we can move variables like MARKETING_VERSION and PRODUCT_NAME into a separate file, which are often modified during development. Developers can therefore update these values without opening Xcode, or within the CI process. It can also reduce the occurrence of the APP name (e.g. RnDiffApp), which is beneficial for maintenance (possible reference: #546 (reply in thread)).

The major change of this design is only a new .xcconfig file, and I believe that it will bring many potential benefits.

---

Possible points for discussion:

• Whether this idea is worthwhile
• What variables to move into the new .xcconfig file
• Is there a better way to improve the dev experience when upgrading the ios part

[cipolleschi]

Hi @UNIDY2002, thank you so much for starting this discussion. It would be the best place to keep all the opinions and suggestions together.

Moving toward the current proposal, I don't think it is the right solution to this problem unfortunately. The .xcconfig files can help with static variables like PRODUCT_NAME and custom flags, but they are not a solution for the build scripts, for example.
Furthermore, we would have to maintain 2 files: the xcodeproj, that will still be there, and this new .xcconfig file. Although we would be able to move several configuration to the .xcconfig, we could still have conflicts in the project.

For context, we are aware of the problem and we are already working on improving that. For example, many changes are automaically applied when you reinstall the dependencies. That's what is happening with the CLANG_CXX_LANGUAGE_STANDARD flag: it is applied here and this is the code.
In other cases, we are providing some utility functions you can use in your app so you can forget about these details. This is what happening with the IPHONEOS_DEPLOYMENT_TARGET flag: by using the min_ios_version_supported function in your podfile, you can forget about this value. An example of usage is here.

---

Talking about a more long term solution, the idea would be to get completely rid of the xcodeproj file altogether, for apps.

One of the best tool to do so is tuist.io. This replace the xcodeproj with a swift file/project (type-checked and customizable) that should be easier to maintain and to diff for the upgrade-helper. This should avoid conflicts and should make it easier to upgrade. More and more companies and apps are moving toward this solution.

This change requires a bit more work, we would also have to update the CLI, but overall will provide a better experience for everyone and reduce the maintenance nightmare.

---

I'm curious to hear what you think about this idea and the changes we are introducing to simplify the upgrade experience.

[UNIDY2002]

Thank you very much for your dedicated response! It brings me a lot of information about your efforts under the hood, and now I have gained a deeper understanding on the xcode part.

I am also impressed with the tool you introduced, and I believe it is the ultimate solution to the problem. I sincerely hope that the team will improve the experience in the future.

I am quite interested in the development experience, and I would like to try it out when the team makes progress on this issue.

Finally, really appreciate your efforts!

[cipolleschi]

I don't know why Github is bumping this discussion, but I recently opened this RFC, if you'd like to have a look at it.