Hi @Philippe
First of all, thanks for posting in the community forum. It makes discussions more public to the Internet, which will make it easier for anyone to find them.
Answering to your question. Most recent versions of Tuist don’t require you to be more implicit about the declaration of dependencies. It includes a new command which you can use to detect implicit imports through static code analysis, which are recommended to minimise for the reliability and determinism of the build system and the editor. But I think this is a bit unrelated to the topic you are bringing up.
Static or dynamic, framework or library… There’s no right and wrong answer, and it really depends on your project’s graph. We plan to come up with a flow chart that helps people decide, but since the scenarios that we are coming across are so broad, it’s a bit difficult to do so. I’ll provide some guidelines:
- Static is preferred in release builds (fast launch time), while dynamic is preferred in development (faster compilation). We recommend using dynamic configuration to change between one or the other at generation time. This is recommended over embeddable frameworks, which add some build-time complexity and potentially non-determinism.
- But… you might find constrained by the dependencies that you use (e.g. some of them might come precompiled as static or dynamic) or your own graph (e.g. I need to share code across an app and a extension).
- So within those constraints, try to make as many targets as dynamic in development (i.e. the
.frameworkor product in the case of iOS) and.staticLibraryin release. Note that iOS does not support static frameworks, so you’ll have to use synthesized accessors to decouple the accessing of resources from the underlying product type. - The above is the ideal, but comes with some burden (i.e., reasoning about your graph), which we can’t prevent you from doing. So what we find most people do is making everything dynamic. It’s not ideal, specially if there’s a large percentage of users in your user base with old iOS versions and devices, where the launch of the app might take longer, but if that’s not a problem for you, then lean on the side of your convenience. If it is, then I’d recommend to think through the graph.
Tuist unfortunately can only take the role of ensuring the linking is done right, decoupling the access of the resources from the underlying product type, and letting you know if some linking might lead to side effects (e.g. duplicated symbols or increased binary size). Whether something should be static or dynamic is something that you’ll have to decide based on the knowledge that you have over your project and your users.