Long term roadmap for Tuist

[pepicrft]

I'd like to share on this issue some ideas that I had for the long term work of the project. So far I was a solo maintainer so kept most of those ideas for myself. However, with more people maintaining the project now, we should make all that information transparent and involve maintainers to elaborate and prioritise the work.

Feel free to add yours and comments on anything. I'd like to sort them based on what you think it'd be the most priority thing to do.

Potential areas of work

Not sorted yet

• Support for SwiftPM dependencies: SwiftPM will have soon support for non-macOS dependencies. This opens the door for Tuist to have some sort of integration. We should evaluate this and make it possible for developers to define external dependencies in their project manifest.
• Include Swift files in manifests: One of the advantages of using Swift as the language for defining the manifest is that we can leverage the compiler and the type system. For instance, Tuist could provide a mechanism for importing/including Swift files from the manifest files allowing developers to extract reusable elements into other files that would be shared across several manifests.
• Support for extensions: Tuist doesn't support extensions. They require some build phases that Tuist would need to set up to make the usage of extensions convenient.
• Reusable project generation tuist project generator library #205: There's been some interest on being able to reuse and extend one of the core components of Tuist, the project generation.
• Better schemes support: Schemes are not configurable at the moment. We'd like to provide a more configurable interface here where developers could override (or perhaps extend) the default schemes that are generated by Tuist (one per target). We'd be entering a territory of configuration over convention so we should be cautious when tackling this to not end up replicating the Xcode project attributes into Tuist.
• Support more configuration Support for more build configurations #160 : This is already being worked on by @ollieatkinson. We only support Debug and Release currently, which is limiting for some projects that have other configuration flavours. The idea is providing an interface for projects to define their custom configurations. If no configuration is specified, Tuist'd fallback into the default configs.
• Support for React Native: Facebook's React Native framework has poorly managed Xcode projects. That resulted in RN updates breaking Xcode projects or developers not knowing how to link a new native dependency. I think Tuist could help a lot in that area. One could indicate that an app depends on RN and some other node_modules dependencies. It'd configure the linking and any extra build phase required by RN to work.
• Signing: Signing continues to be a problematic thing, even after all the work that Apple has done in the recent years. Fastlane did a good job there with Match, but Tuist can go one step further. Given that we understand the projects and have control over its generation, we could sync the app entitlements and the provisioning profiles to match the project configuration. The certificates and provisioning profiles could be included encrypted in the project repository. They'd be decrypted and installed at the time the project is generated. If we implement this properly a developer new on iOS wouldn't have to understand how signing works. They'd have to just provide an Apple account and that's it.
• Build command: Since Tuist knows the project in the current directory, it's in the position to infer how to build the project with the minimum number of arguments. For example, one could execute tuist build MyTarget or tuist build all and we'd run xcodebuild under the hood. By doing that we'd remove the need of having to maintain scripts or DSL sort of files that end up being huge and unmaintainable sometimes.
• Test command: Similar to the command above. In this case, if you are testing a target that runs on a simulator, we could use a default simulator if any is given. Moreover we could support defining a list of default simulators at the project level.
• Run command: This is something that xcodebuild doesn't have an it'd be relatively easy to implement after we have the build command. The idea is once the build completes, we could detect if an app has been built, and asks the user in which simulator they'd like to open it.
• Release: I think Tuist could potentially be able to compile and upload the apps to Testflight without any scripting around the app. We could use the transporter tool to upload the app.

[kwridan]

Thanks for sharing this detailed roadmap!

I grouped the suggested items by the some form of theme to help comment on them + merged in some of @ollieatkinson's suggestions from slack

Project Generation

• Support for extensions
• Reusable project generation
• Better schemes support
• Support more configuration

Project & workspace generation is the area that drew me to contributing to Tuist 🙂 It’s an area of much pain for larger projects and Tuist has a lot of potential to grow further and excel here.

Other suggestions under this theme:

• Supporting resource targets + Unified resource access and code generation: this is an area Xcode doesn’t have a good story around is great candidate for a tool like Tuist to solve. Dynamic frameworks can host resources, Static frameworks (ones’s with MACH_O_TYPE = staticlib) can’t. Developers have to either keep their frameworks dynamic (and incur additional startup time overhead as the number of frameworks grow) or start leveraging resource bundles, ensure they include them in the final app target and access them correctly via code. Managing this would be incredibly helpful, this would allow seamlessly switching between dynamic and static (or vice versa) as requirements change (e.g. new apps / extensions)

Manifests Enhancements

• Include Swift files in manifests

This is a really interesting one (both technically and as a feature). Perhaps as a suggestion this could be generalized as finding ways or techniques to help reduce repetition by including or sharing manifest definitions etc…

Suggestions under this theme:

• Scheme definitions / conventions:
  Allowing users of Tuist the ability to specify or define the schemes they’ll need for their generated projects

Integrations

• Support for SwiftPM dependencies
• Support for React Native

Integrating with SwiftPM is worthy of exploring or at least keeping an eye on (#215) as it’s an area that is gaining more adoption by the community.

Sadly I can’t comment much on support for React Native as I haven’t personally tried this before. Perhaps for this it’s best if it’s driven by contributions of React Native developers as they would have more context and knowledge in this domain.

Suggestions:

• Carthage / CocoaPods integration: This could potentially allow users with existing projects that use Carthage or CocoaPods to benefit from using Tuist. That said, CocoaPods might be a challenging one to keep up with as it modifies the Xcode project / workspace.

Developer Workflow

• Build command
• Test command
• Run command

Having the ability for those commands is a cool idea (the equivalent of swift build ). This will work if the entire workspace and projects are generated by Tuist, however for anyone partially adopting Tuist to generate a subset of projects and include them in their existing workspace this won’t be as useful.

In fact this is something worth considering as adoption techniques, i.e. Tuist could welcome users wishing to generate all or part of their workspace (i.e. it doesn’t have to be all or nothing) - this will help with incremental adoption on any size project new or old!

Release Workflow

• Signing
• Release

Is the idea purely for uploads? Perhaps and alternate could be providing the ability to integrate with fastlane? That way Tuist doesn’t need to cater for all the various use cases fastlane has developed and solidified over the years. App release / signing is a large (painful) domain and seriously a big kudos to fastlane for taking it on and making our lives that much easier 🙂

[ollieatkinson]

* _Supporting resource targets_ + _Unified resource access and code generation_

I'm not sure if you've read the in-progress proposal for SwiftPM relating to this topic, but I think it's a good direction and something we should try work alongside: https://github.com/abertelrud/swift-evolution/blob/package-manager-resources/proposals/NNNN-package-manager-resources.md

[marciniwanicki]

Impressive and ambitious list! Looks like it might make us busy for a while.
I know Tuist can do much much more but I like to think about it as some higher level bridge between human-friendly project descriptor and IDE / build system descriptors (currently Xcode), that can support projects of any size. I think this domain is not well-explored yet, although the demand grows every year. I am particularly happy to see all the areas enhancing the variety of supported projects and configurations, making Tuist even more powerful and universal. I'd definitively prioritised them over any of the ideas I listed below.

Some other areas maybe worth considering in the future:

• Scaffolding - To generate new modules or files/folders structures inside a particular module. We could have some template descriptor to bootstrap simple structures like View-ViewController-ViewModel. i.e tuist new mvvm UserDetails. Maybe we could leverage Sourcery.
• Tuist/.xcodeproj diff - To compare existing Xcode project with the one generate by Tuist. That would simplify migration from checked in, manually maintained projects. All to ensure we don't accidentally regress during the migration period.
• Exporter - Try to generate build files for different build systems like Buck or Bazel. I'd also try to export to podspec and/or carthage, possibly even to SwiftPM
• Importer - Try to generate Workspace.swift, Project.swift for existing Xcode projects. Point places that cannot be imported and guide users how to fix them.
• Inspector - To provide metadata about the project. Could give us json reports (with paths to the files) like "All C++ or Swift source files in the target", "All resources in the target", "All tests in the target", "All files that are not visible by the Xcode project", etc. That would help people to gather metrics.
• Watchdog - My default workflow while working with SwiftPM based project is that I usually add files in Xcode and hope I attached them to the right targets:), then I build it in Xcode. From time to time (at least before push) I build and test everything via SPM, generate the project and check the structure of the project in Xcode. Similar workflow can work for Tuist, however it can probably enhance it, as anyone who has not experienced this workflow before may struggle. I guess we could have a background process checking if the manually applied changes are compatible with changes that would be generated by Tuist, and in case of mismatch, Tuist could trigger a notification or some other kind of signal. In same cases it would even auto-correct the project. Attaching a new source file to multiple targets is error prone, missing one or selecting one target that is not needed can be a common problem. Same if people start playing with settings in Xcode, would be good to notify them that those might not last long:).

[ollieatkinson]

It's obvious that there's a need for a tool to manage projects and workspaces for iOS, tvOS, watchOS and macOS projects. Countless other solutions exist in their own little domains, CocoaPods and Carthage are the biggest ones.

With SwiftPM growing in size and popularity it really lends itself to us to be able to support it natively out of the box. I often get asked "Why tuist, won't SwiftPM replace it" - in some aspects yes, but others no. SwiftPM is a tool for managing swift packages, it doesn't have any support for Xcode (yet) when it does it means we can look to deprecate parts of tuist to favour SwiftPM. tuist still has a life, it's job is to simplify the process of working with Xcode projects.

I have thought about some of the points raised, especially around signing and weather or not that's something which we should handle. Fastlane is quite a mature tool which solves that problem, instead of solving it again I think we should adopt Fastlane.

I'm really happy with the general direction we are thinking of taking this project - we have lots of work and won't run out anytime soon :D

[pepicrft]

It's obvious that there's a need for a tool to manage projects and workspaces for iOS, tvOS, watchOS and macOS projects. Countless other solutions exist in their own little domains, CocoaPods and Carthage are the biggest ones.

Agree. Carthage and CocoaPods have been mainly focus on the dependencies domain. They do a pretty good job there. We overlap with CocoaPods in the project generation but we are less opinionated regarding how the dependency projects should look.

With SwiftPM growing in size and popularity it really lends itself to us to be able to support it natively out of the box. I often get asked "Why tuist, won't SwiftPM replace it" - in some aspects yes, but others no. SwiftPM is a tool for managing swift packages, it doesn't have any support for Xcode (yet) when it does it means we can look to deprecate parts of tuist to favour SwiftPM. tuist still has a life, it's job is to simplify the process of working with Xcode projects.

And we could integrate seamlessly with our manifest because we'd just need to link against the ProjectDescription framework when compiling. We could list SwiftPM dependencies as project dependencies and find a way to merge the graphs.

I have thought about some of the points raised, especially around signing and weather or not that's something which we should handle. Fastlane is quite a mature tool which solves that problem, instead of solving it again I think we should adopt Fastlane.

I agree we shouldn't re-invent the wheel when there are other tools already doing it, but I'm not quite sure if we should find ways to adopt or integrate with Fastlane because it's a different programming language that requires the environment to be properly configured (Ruby, Bundler...) for things to work. It'd be a really bad experience if Tuist failed because the developer's Ruby environment is messed up.

I'm really happy with the general direction we are thinking of taking this project - we have lots of work and won't run out anytime soon :D

Me too. I'm very happy to see the project consistently evolving and tackling inconveniences that projects face when using Xcode at scale.

[pepicrft]

Moved the ideas into this document. Feel free to add your comments to the document.

[mollyIV]

👋 Just wanted to share some thoughts on the project:

Importer - Try to generate Workspace.swift, Project.swift for existing Xcode projects. Point places that cannot be imported and guide users how to fix them.

I love it ❤️ I believe being able to migrate from existing Xcode projects to tuist by using a tool instead of doing that manually would be a huge adaptation booster. When an Xcode project is quite complex, the manual migration is very risky. Thoughts? 🤔

I often get asked "Why tuist, won't SwiftPM replace it"

It was the very first question that came to my mind when I saw this project. By having a look at the current state of SPM, we might expect that it is not gonna happen anytime soon(ish). The need of simplified process of Xcode project management is real. When you introduce a modularization and quite a few dependencies, the project management gets messy quite quickly.

Fastlane is quite a mature tool which solves that problem, instead of solving it again I think we should adopt Fastlane.

fastlane is wonderful tool, I do love it ❤️ At the same time supporting things like building the project, signing it, testing and deploying to App Store Connect / TestFlight by tuist would cover a whole lot of the cases. No need for extra env setup would be great 👍

🙇 🙇

[pepicrft]

I love it ❤️ I believe being able to migrate from existing Xcode projects to tuist by using a tool instead of doing that manually would be a huge adaptation booster. When an Xcode project is quite complex, the manual migration is very risky. Thoughts? 🤔

Agree it'd help a lot with adoption, but I'm not 100% convinced on this being a good idea for Tuist. The reason is that it's impossible to do this reliably, and because of that the generated projects that developers would get won't likely compile. They'd expect Tuist to do it right and they'd be frustrated instead of motivated for using Tuist. What do you think?

fastlane is wonderful tool, I do love it ❤️ At the same time supporting things like building the project, signing it, testing and deploying to App Store Connect / TestFlight by tuist would cover a whole lot of the cases. No need for extra env setup would be great 👍

I recommend reading this blog post that I wrote and where I touch a bit on Fastlane and why I believe a standard CLI for Tuist would make sense.

[pepicrft]

We can close this one in favor of this issue