Tuist
139 subscribers
5 photos
1 video
29 links
✉️ Get updates about Tuist and tips to learn how to use the tool and scale up your Xcode projects
Download Telegram
How does binary caching works with Tuist 4 and Tuist Cloud
You might have seen us talking a lot about binary caching and wonder: what does it mean in practice? It's hard to picture the workflow when Apple doesn't provide anything like that built into Xcode, and for that reason we've made a video of how binary caching works with the Tuist project itself. The process goes like this:
1. Clone the repository
2. Run tuist cloud auth to authenticate if you haven't already
3. Install dependencies with tuist install if they are absent.
4. Generate the project with tuist generate.

Tuist detects automatically that there are binaries available, pulls them lazily, and then generates a project with them. Smooth, isn't it?
https://www.youtube.com/watch?v=LDpvYNQqZkU
Channel photo updated
What’s ahead for Tuist
It might seem that after 7 years of work we have reached the limit of challenges that we can solve with Tuist. Many developers still think that we are a simply a project generator. But we are just getting started. We are becoming weirdly obsessed about how much data teams lack to ensure that their projects grow healthily. Nor they’d be able to define what healthy means.
But we are in a unique position to define what a healthy project means, help teams gather the data necessary to measure the healthiness, and present it to them in an actionable and meaningful way. There are many tools in the community for that, but they are not made user friendly. We want you to have a beautiful interface to your project state so that you can make informed decisions. You should be able to know how flaky the tests or a target are, or which target became a compilation bottleneck.

Why isn’t Apple providing that?

We don’t know… but Tuist will surely do
Tuist 4 and Tuist Cloud
We are thrilled to announce a new major version of Tuist, Tuist 4. Towards Tuist 4, we had a strong focus on building a foundation based on project generation upon which we could help all of you overcome the challenges that you face with Xcode. You all love it! There's nothing like the feeling of seeing your team confidently participating in evolving the project. But this growth in popularity also led to an increase in the cost of maintaining the project. As a free good, we started to suffer from resource starvation. To prevent that and continue to provide you with the best tool in the space to work with Xcode projects, we built a complementary product, Tuist Cloud, that solves challenges that arise at a larger scale, like CI turnaround times or projects' health. We aim for Tuist Cloud to become the source to fund the development on Tuist.
To know more about all the changes, you can check out our announcement blog post:
https://tuist.io/blog/2024/02/07/unveiling-tuist-4-and-tuist-cloud/

We are also live on Product Hunt 🙂
https://www.producthunt.com/posts/tuist-4
Tuist 4.1.0
Apple's tooling is well known for making things convenient by resolving implicit configuration at build-time. While that's great at a small scale, it causes a lot of headaches at large. The Swift Package Manager is no different. It was released as a tool to share Swift code, but soon after its release library developers asked Apple to support the distribution of Objective-C code.
Guess what? Instead of exposing an explicit API that would leak Objective-C details in the DSL, like the concept of "modulemaps" or "umbrella headers" they decided to go down the path of conventions and implicitness resolved at build time. Because of it, the integration of Swift Packages through Tuist's method caused so many headaches to users. It was one of our long-standing issues that users were often complaining about.
But luckily, they won't have to complain anymore because we've release a new version of Tuist, Tuist 4.1.0, that mitigates the issue. We ported over the Swift Package Manager logic and run it at generation time. Now all the targets depending on your Objective-C Swift Packages should have the right build settings.

Enjoy the release!
https://tuist.io/blog/2024/02/12/tuist-410/
The missing language
When we talk to Tuist users, a common denominator of the conversations is that they enjoy describing their projects using Swift 🐦. It might seem like a subtle thing but it’s very empowering using the same language that you use for coding your app also for describing your projects. We elevate concepts from Xcode projects to Swift and take the opportunity to conceptually compress those that are more intricate, like the implementation details of dependencies. You can describe “what depends on what” using a language that mimics your mental models about dependencies.

A simple language means that anyone can take part in describing the project, not just a platform team, who knows the intricacies of a YAML spec, or a Bazel configuration file. And through project description helpers, platform teams can build their own language upon ours and leverage the compiler to define rules without having to implement additional tooling. It’s magic.

Our language co-exist with other languages, like the one proposed by the Swift Package Manager, which it became clear we need to know how to speak to integrate the worlds developers are moving in.

This language is a foundation not just for you, users of Tuist, but also for us to understand your projects and give you powerful tools to interact with your projects, understand them better, and optimize them.

Some users are concerned about depending on this language that we created, but at the end of the day, we stay very close to the language we build upon, the one proposed by .pbxproj, and the others that we integrate with, the SPM’s 📦, which makes Tuist a very future-proof solution safe to build upon.

It took us years to get to this point, and like any language, it’s something alive because Package and Xcode project capabilities evolve, and we need to evolve with them too. Seeing their evolution and spotting the opportunities to conceptually compress complexities to help you scale is one of the most exciting challenges we could have ever imagined.
Tuist 4.7.0
Tuist 4.7.0 was just released! Among some small issues and improvements, it introduces an interface to allow specifying destinations for Package.swift products. We are getting ready to support Package.swift as a DSL that we can integrate with!
https://github.com/tuist/tuist/releases/tag/4.7.0
TravelPerk achieved 98% faster build times with Tuist Cloud
As more companies adopt Tuist Cloud, we are starting to have some real numbers of the impact that the tool can have in organizations' workflows. Today, TravelPerk just published a blog post sharing that they were able to achieve impressive improvements after adopting Tuist Cloud:

- ⬇️ Clean builds with third part dependencies cached: ~3 minutes–down 70% from the original reference build times
- ⬇️ Re-builds without any code changes: ~10s — down 98% from the original 7 minutes rebuilds

If you would like to give Tuist Cloud a try, you can get started for free. You can also book a call with us to get a walkthrough and chat over how could impact your project. Just book some time with us using this link: https://cal.com/team/tuist/cloud

https://builders.travelperk.com/tuist-ing-travelperks-ios-app-for-faster-build-times-4796dcfa7809
Slowing down and thinking long-term
With the release of Tuist 4, the project went through a lot of changes, some of which might have impacted you through the breaking changes, or indirectly through regressions introduced. Moments like this are unusual, but happen sometimes as part of the project’s maturing process. We think it’s time to slow down a bit regarding adding feature to focus on the project’s stability and performance and gain a fresh perspective on how the project should evolve.

One of the ideas that we’ve been pondering, and that seems a natural evolution of the project, is extracting the project generation logic and the graph into a Tuist-agnostic piece of code that Tuist depends on (and other project generators, why not?). This might seem like an unnecessary change, but unlocks something that everyone has been asking for, a proper answer to extensibility.

As you know... we don’t support the full-breath of things that you’d like Tuist to do for you. We think that’s great because it keeps the tool simple, but bad if there’s no answer to extensibility. For example, Xcode is an example of a tool that evolved to do too many things instead of keeping things simple and let the community extend it, like Visual Studio Code does.
Our answer to extensibility was confusing, incomplete, and very rigid. If you tried to build a plugin, you probably ran into some hiccups along the process.

We want to change that, and we are approaching the time where we can provide a reliable solution for that. First, it’ll require that we extract the project generation logic and graph from Tuist making it Tuist-agnostic and always backward compatible. This is something we couldn’t have done before because those models were not mature enough. The Tuist-agnosticism should lead to a better architecture and APIs, allow other developers to build their generation-based tools upon a logic that we have developed for many years, and most importantly, expose the whole graph to plugin developers.

Once we have that extracted, we’ll overhaul the plugin development experience from the ground app. We want to push Swift’s extensibility beyond its limits drawing inspiration from go-plugin to enable structured extensibility using system processes and inter-process communication. We’ll open source any development in this area to allow other developers to extend their CLIs too.

The final goal with all of this is to give developers and incremental path to extensibility:

- 90% of users find everything that they need in Tuist
- 9% of users need more and they resort to plugins for that
- 1% of users will build their own generator upon our generation primitives

Note that this is a long-term direction that we want to start moving towards later in the year. For now, the focus is on stability, and also preparing for any announcements that might come out in WWDC this year. This time we want to be faster, and should be faster, at supporting any announced new features.

Let us know on Slack if you have any questions or feedback 😊
Tuist Cloud Open Source Program
We are excited to announce our new program for open source projects. If you have an open source project that uses Tuist, either directly through the Tuist DSL, or with other supported DSLs like Package.swift, you can get access to the service for free. Yes! You'll be able to cache your dependencies as binaries and share them across environments to speed up your build and test times. You'll also have access to selective-testing to only run the tests of the targets impacted by your changes.
https://tuist.io/blog/2024/04/25/tuist-cloud-free-for-open-source/
The challenges of using Xcode at scale
Did you know that targets can import targets implicitly, leading to graphs that are hard to optimize and reason about? Or that using the Swift Package Manager as a project manager leads to projects that become unusable for 15 seconds after adding or removing files? These and a handful of others are challenges that we uncovered through our work on Tuist and that we shared in this talk that we gave at the Seoul iOS Meetup

https://www.youtube.com/watch?v=rh7gDpvXH2I
App.swift
We're launching a monthly newsletter packed with cool packages, dev tricks, and hard-won wisdom from our years in building tools for Apple developers.

Let's build some awesome apps together!

Join us: https://newsletter.tuist.io/subscription/form
Tuist Tests
Test flakiness can be a huge source of wasted time. Imagine waiting for half an hour for a compilation to complete only to realize that it failed because of a flaky test. How annoying is that? Unfortunately, teams don't have the tools to detect, prevent, and disable them. Luckily, we are going to change that.

If you are using Tuist, you can start using it in your projects. All you need to do is create an account and plug your project into the Tuist server.

We'll continue to invest in testing-related features, which we call Tuist Tests, and we'll follow up with tools to prevent and disable flakiness in your suite.
CocoaPods Security Vulnerabilities
Some security vulnerabilities have been discovered in CocoaPods. If you use it as a dependency manager in your projects, we recommend doing a thorough security review and lock your dependencies right after. You can read more about the vulnerabilities here:
https://www.evasec.io/blog/eva-discovered-supply-chain-vulnerabities-in-cocoapods
New dashboard layout
We just rolled out an iteration of the dasbhoard layout with the following improvements:
- We introduced two layouts, one for accounts, and one for projects.
- We included a breadcrumb at the top to navigate between projects and accounts easily.
- We made the UI mobile-friendly.
- We removed references to Tuist Cloud, it's just Tuist.

In the following days we'll roll out a new documentation structure, and unveil the plans (spoiler: every plan will give all organizations and developers access to all the features).

You can can sign in with "tuist cloud auth" to start using it in your projects. You can also check Tuist's public dashboard at https://cloud.tuist.io/tuist/tuist
Building better apps faster
What is Tuist? What should Tuist be? We've been asking ourselves that question a lot for the past months, and we recognized that we stretched Tuist's original scope too much without adjusting its vision accordingly. Therefore, we decided to revisit the project vision and I'm happy to share what we landed on with all of you.

Going forward, Tuist is going to put the focus on empowering everyone to build better apps faster. Our focus broadens to support developers since the moment they have an idea, until the moment they publish the app helping them with every challenge along the way. To get there...

- 👩‍💻 We'll meet developers where they are, adopting their tools and languages, and reaching other services like Slack, GitHub, or GitLab where developers also spend their time. URL will be our unit of collaboration, and Swift our language
- 🌱 Openness will be at our DNA. From the software that we build, to how we operate the company. The best companies that we aspire to be (e.g. GitLab, Posthog, Supabase) are open companies. We are working on establishing a path and timeline to open-source everything.
- ⭐️ We are allergic to complexities. Therefore, we made our pricing simple and open for anyone. Every user will have access to everything without having to reverse-engineer a complex pricing model (you can check it out in our website)

As part of the above effort, we've released a new version of the CLI, 4.21.0, and also updated our documentation website, https://docs.tuist.io. You'll notice references to Tuist Cloud are gone. It's just Tuist a Swifty toolchain that spans from the client to the server.

We'll start working on collaboration features, local and remote automation (and a new plugin system as part of that), and roll out a new website that embodies this new project vision.

You can read the announcement blog post for for information, and ask me any questions that you might have:
https://tuist.io/blog/2024/07/16/empower-teams-to-build-better-apps-faster/