Ideas for Tuist

I’m starting a new topic to list ideas that I believe they should eventually be implemented into Tuist. If you have any other ideas, feel free to reply to the topic describing them. Here is my list:

  • Selective builds: Diff the changes against the previous commit (or the default branch if it’s CI), and use the list of changes to determine which targets should be built. Then build just those. Translated to the CLI, I see something along the lines of tuist build --only-changes.
  • Selective tests: Similar to the point above, we can use git information to determine which tests should be ran instead of running the entire suite. That should improve the feedback time on CI and the make the iterations faster locally.
  • Documentation generation: For any project, developers should be able to run tuist doc, and get a documentation website dynamically generated and launched. Cargo, the package manager of Rust, does exactly that. We can replicate Apple’s documentation styles.
  • Code linting: Developers should be able to run tuist lint code and the code that is part of the project would get linted automatically. For that, we can add Swiftlint as a dependency, and use the APIs directly. That way developers don’t have to make sure that the tool is installed in the system. Moreover, we can allow developers to customize their styles by placing a Swiftlint configuration file under the root /Tuist directory.
  • Caching: Tuist should be able to compile all frameworks that are part of the dependency graph as .xcframework and store them in a local and remote cache. Then tuist generate would leverage the cache to replace transitive dependencies with their precompiled framework instead. That’d save a lot of compilation time, both locally and on CI.
  • Insights: Tuist should collect information from both the build and the output artifacts for every target that is built by Xcode. That information would get sent to a server that would do some processing and post relevant and actionable information on the PRs.
  • Secrets management: Instead of placing the secrets in the repository, or figuring out how to configure an Xcode project to have access to secrets that are exposed as environment variables, Tuist would take care of pulling the secrets, decrypting them and providing projects with a Swift interface for accessing those.
  • Certificates management: Tuist should be able to encrypt and decrypt certificates and provisioning profiles so that they can be stored in the repository, and also configure the projects with the right build settings to ensure that the apps can be signed.
1 Like

If I think about it as an iOS dev of a medium/big app, I’d rate them like this - from top (more interesting) to bottom (less appealing):

  • Caching
  • Selective tests
  • Selective builds
  • Insights
  • Documentation Generation
  • Secrets management
  • Code Linting