We are starting to work on helping teams with their automation needs. I created this topic as a scoped channel to share updates and create a space for organizations and developers to get involved in sharing feedback.
Remote execution of macOS-dependent tasks has traditionally been associated with Fastlane and CI. However, it’s a powerful tool to build better developer experiences. The Tuist team has a strong appetite for commoditizing it, solving some persistent challenges, and exploring new ideas from other ecosystems.
It sounds ambitious, doesn’t it? We know… so we are going to make this work incremental. We’ll first focus on rolling out tuist xcodebuild and tuist workflows. The former is an xcodebuild wrapper upon which we’ll build remote-execution capabilities, and workflows are a new Swift DSL and CLI APIs to define custom workflows (i.e. like Fastlane).
In parallel, we’ll develop the technology and prepare the infrastructure to support running that automation remotely. How? You might guess… It’ll just be one flag away:
tuist xcodebuild {...xcodebuildargs} --vm local:macos-sequoia-xcode-16
tuist workflow run release --vm local:macos-sequoia-xcode-16
# Or remote
tuist xcodebuild {...xcodebuildargs} --vm local:macos-sequoia-xcode-16
tuist workflow run release --vm local:macos-sequoia-xcode-16
This a pre-requisite step before we support triggering those workflows as a consequence of a Git event, something that most of you refer to as “continuous integration”. If you think about it, all it really means is some kind of set of steps that run as a result of a Git event or manual action taken from the UI.
I asked in Slack if anyone would be interested in helping us shape and test the work that we do in this front, and the response was quite positive. I’m pasting here some interesting responses that I believe will be valuable in the shaping:
@kelvinharron talks about how tricky it is to use selective testing with Xcode Cloud (although this will be solved soon), and the lack of information to understand how things are evolving.
We’re all in on Xcode Cloud here with a tuist project and we haven’t been able to make use of Selective Testing as a result, and understanding the duration, averages and regressions in build time is very challenging
@waltflanagan on the benefits of using Gym/Scan (from Fastlane):
imo, (potential hot take) the main benefits from gym/scan are a more approachable interface to xcodebuild and they have a small bit of convenience in chaining things together by recording some state from prior invocations into global environment state so a another fastlane step can easily access it
e.g so that one could then call upload_to_testflight without passing the output of a prior step to find the right file to upload
And @apps4everyone on the amount of content that exists on the internet regarding common issues/needs that teams face:
Also a lot of content in google search, you can find easily what you need, same as GitHub actions vs. TeamCity where it’s more close (enterprise) documentation only
Also a huge advantage of fastlane is that everyone knows it, it’s same as GitHub actions, it gets teached in school, open source uses it… so it’s not just the language syntax, it’s also the learning/success curve to accomplish a task