Leo Dion (host): Welcome to another episode at Empower Apps.
I'm your host, Leo Dion Today I'm joined by Pedro Piñera Pedro,
thank you so much for coming on.
Pedro Piñera (guest): It's my pleasure.
Nice to, it's nice to be here.
Leo Dion (host): Yeah, I've been wanting to have you on to talk about the
wonderful product you work on, Tuist and we had some announcements at WWDC this
year that we might want to talk about.
So I think it's perfect timing.
Before we begin, I'll let you go ahead and introduce yourself.
Pedro Piñera (guest): Cool.
Yeah, I'm Pedro.
I'm based in Berlin.
Although I'm originally from the south of Spain.
I consider myself a tooling developer.
I like building Siemens for developers.
Basically things for making them productive to make sure that when I,
when they, when they build with these tools, they, they have fun using them.
And for the past years, I've been working as a tooling
developer at Shopify.
I initially a, as a mobile tooling developer eventually I became
more generalist type of tooling developer, and very recently I was
let go from the company and I took that as an opportunity to go back
to Swift, to work on, on Tuist full time and some, I had some ideas for
projects that I wanted to build.
So I'll use this time to basically do Swift build for
Apple again and have fun doing it.
Leo Dion (host): Well, I know a lot of people who appreciate your
work and appreciate Tuist a lot.
Before I, I've known several companies that use Tuist that, that love it
and have find it to be a perfect fit.
For those who don't know, you want to explain what Tuist is exactly.
Pedro Piñera (guest): Yeah, sure.
So I started building Tuist because if you work on a modular Xcode project with
many targets or workspace with multiple projects, You probably know that it's
a nightmare to maintain, especially when you start changing dependencies,
adding other moving targets and so on.
Some of the changes, for example, if you have some dynamic framework,
somewhere in the graph, it has some cascading effects.
And usually what I found when I started building trees is that
there's usually a few people that really understand how to do that.
And then the others that one day they change something and everything breaks.
And I was like, there needs to be an easy, way, easier way of doing this.
Then the way I saw this was with a project generator.
So basically you described your project and we generat it for you.
That was the original idea.
Eventually when I had the.
Project information because in the end, like users described you
their projects and you can generate the Xcode project that they can
use for working, for editing, for compiling and for everything.
I realized that it was also, it was a good foundation for like doing things
like caching and optimization checks.
Something that we could focus, which is.
Like, if I plan to focus on one target of my project, I don't want the other
elements to be included in my project.
And because of that code also works faster, things like that.
And when I build it, I, I was looking at what Swift Package Manager was doing,
especially the Swift tsl, the interface.
So I, the interface that you use in, in, in Tuist is very similar to that.
You have a Swift Swift file where you described your project.
You run a command, you get your Xcode project and you work with it.
And then medium to large sized companies really like Tuist because
especially for GI conflicts, for having a nice interface for describing
your projects for caching as well.
And also studios that are building white label type of apps find
it very convenient because they can easily generate multiple
projects easily with the tool.
Leo Dion (host): Yeah.
So for my smaller indie projects, I use XcodeGen by Yonas but for
anything that's not indie and a big company like Tuist is, is the tool.
And.
It's, I feel like it fills in the blank where you have, you've had
this slow migration away from weird file types that apple like like
storyboards and ex core data models.
And it feels like they're slowly moving away from that over to Swift
and like you've already done that with Xcode projects, which is awesome.
And it's basically, yeah, you create the whole project in workspace.
In Swift and you don't have to check in the project in a workspace.
You don't have to deal with merge conflicts, which that's I've seen a
big, a big problem with, with checking in Xcode projects and workspaces.
Pedro Piñera (guest): on the on XcodeGen when I was building this
tool, I had to build this other library called Xcode Approach.
Which existed in Ruby Cocoapod s building was basically for reading
parts and writing Xcode projects.
That was, so I started working on that first.
That's when I met Jonas.
He was thinking also building a generator.
He focused on the generation part with YAML as an interface.
I think he also supports like other schemas.
So if all you need is getting rid of gift conflicts and, and have a
generation tool, For that XcodeGen is amazing and I know a lot, a lot of
companies are building their own tools on top of XcodeGen As a generator,
I decided to take like a different approach, so different and also like
be more than just a project generator.
So depending on your needs, for example, for small projects,
XcodeGen might be more suitable.
I'm actually working now on a web, on a new website where we
explain better what Tuist is.
Which is, I think it's very challenging to explain what it is
and why it might be useful for you.
But yeah, we both collaborated a lot, Yonas and me on, on that
approach library, and I owe a lot to, to him because of his
input, feedback and contribution.
So, yeah
Leo Dion (host): Yeah.
So let's jump into dub what have you looked at as far as dub yet?
Pedro Piñera (guest): So I think the merger of libraries
is a very interesting one.
Because this is something that we cannot solve with Tuist Like, if
you want to switch from dynamic to static, you can easily change it
in your Tuist project definition.
And then we make the necessary changes so that the project
continues to compile.
We do that at generation time and it's nice to see Apple basically
moving that to compilation time.
So now they're able to switch from static to dynamic depending on
what type of build you're doing.
I think that's very cool and very necessary for, for big companies
that have modular code base.
The other thing that I liked, because I was before focusing
again on Swift, I was doing eir and EIR has macros which allowed very
interesting things like building DSLs.
I don't think the Swift micros are will allow to do that maybe in the future.
But one thing that I like is like it's able to include in, in the
final binary elements, otherwise will be loaded at runtime.
For example, in the context of Swift on the server, you will be
able to take the JavaScript bundle if you end up serving a bundle and
like include in the final binary.
That's one thing that I think is gonna be super cool in the case of Elixr I
don't know in the case of Apple if they will be able to do something like that.
But what they do is because at compilation time, the assertions
when it comes to testing, they can analyze the abstracts syntax.
Three, the error messages that you get when the test fail are
much better than just saying.
Full is not equal to bar.
It is.
They analyze the entire object and they show you the entire.
So I think Apple can use all this and they, they are using it with some
features that I saw being presented, like compilation time information
to enhance the user experience.
And I think that's gonna be very exciting to see.
Leo Dion (host): So I'll probably ask that question next.
So I'm gonna go ahead and do that.
So you mentioned static and dynamic libraries and how you
could switch between the two.
Is that kind of related to the whole Mergeable libraries thing?
Pedro Piñera (guest): Exactly.
Yeah.
Leo Dion (host): Okay.
Pedro Piñera (guest): So the, you probably know that they've
used a lot of dynamic libraries.
It compiles faster, but at the cost of it, the app takes longer to start.
And I, it's nice that they are able to basically at compilation time,
generate information that basically in development compilation is fast
because it's what you want in the end.
Like you don't want Developers Three was in their time and in production.
You're also able to launch the app fast because of this new improvement.
I think that's very nice.
Back when I was, when I started Building Tuist when I was working
at SoundCloud And because we had many dynamic frameworks, it was it
was taking a long time to start and that's not a great user experience.
So I think you should never compromise the user experience to have a better
developer experience, which is what you get when you have faster compiler time.
So I think that features basically that allows you to have a good balance there.
Leo Dion (host): Yeah.
So like how does that work that it automatically knows whether to
do whether to automatically do a dynamic library or a static library?
I.
Pedro Piñera (guest): I didn't look into it in, in, in a lot of
detail, but there's a bill setting that you can set and then based on
the bill setting and based on the type of flavor of bill that you're
building just one or or the other.
And I think it generates some compiled time information that is necessary for.
Later on, like statically comp, like compiling everything for, for release.
So yeah, build settings and depending on the flavor, it changes.
Flavor.
Config is color.
Yeah.
Config the bag or release it does one thing or another?
Leo Dion (host): What I'm just trying to think like, should you always
be using Mergeable libraries now?
Pedro Piñera (guest): Hmm.
That's a good question.
I think it really depends like.
Leo Dion (host): I guess.
Pedro Piñera (guest): It, it really depends on how your app is modularized.
For some, for some targets, it might be interesting to, to give something
as dynamic so that there is only one copy of that thing in the, in the app.
Because if you have like multiple targets that are studied and then you
compile a transitive, Target statically, you will end up having a larger binary.
So this is another thing that you need to keep in mind when
like you shouldn't go crazy with, oh, now everything is mergeable.
No.
You need to understand your project graph and like, keep the, the
binary size in mind as well when it comes to making these sessions.
Leo Dion (host): You mentioned modularity, and I
want to ask this question.
I've kind of shifted to Swift packages for most of my projects.
Like what, what's the benefit of like Swift packages versus frameworks versus.
Separate projects versus like, how would you do it and how or
how would you make that decision?
Pedro Piñera (guest): That's a good question.
I wish I knew what Apple is planning with the Swift package manager there.
Because I think it, it really feels like people are, Using package Swift
for something that wasn't designed for.
Of course it works like you can say, I have a Target, this is an
app, and I have multiple frameworks.
Starting from the name, it doesn't really.
Align with what people are using it for, but I think Apple will eventually
evolve that manifest file, that package adjacent to be also your
interface for a declaring project.
So I think it's totally reasonable that you start using that like.
Package suite package manager for defining your projects.
I think depending on your project, you might find some limitations, like
you might wanna do something that you can do with an Xcode project that you
cannot do with a suite package manager.
So if it see as a standard package graph or target graph, it's all fine.
But maybe you need some kind of build setting or build phase that you cannot
define in your Swift package manager.
So like, reach that point.
You have to decide if you wanna, I don't know, open an issue and like
wait for Apple to implement the thing or like switch back to Xcode projects.
I think we'll eventually, like everything that you can do in Xcode
projects, you can do it in the Swift package manager in the interface.
And I think Apple will move towards that direction.
It's hard to tell, but with all the community starting to use the
tool for something else it really tells Apple, you know, like, This is
something that you should consider.
And I think when they do that, there will be a lot of overlap with
what Tuist is doing versus what Swiss Package Manager is doing.
And maybe it doesn't make sense to maintain Tuist anymore at some point.
It's kind of similar to what happened with cocoa boats.
Like the community had a need for bringing the dependencies.
They build this tool and eventually Apple says, you know, like,
now it's time for us to give an official tool to to developers.
And the nice thing about Apple doing things is that they can
integrate all these different pieces.
Into the Xcode ui.
So if they introduce, if they integrate the Swift Packet manager into Xcode all
of a sudden you have this beautiful UI on the side where you see the different
packages, how they're being resolved.
I have things in Tuist that I kind integrate into Xcode code.
So on my API with into Xcode is build faces.
But what you see, what you can modify as a user.
So I'm kind of limited in that sense.
Apple is not, they own the whole tool and the bill system.
Leo Dion (host): Yeah.
When you said build settings, what?
What specifically do you get out of an Xcode project as
opposed to a Swift package?
Pedro Piñera (guest): So the one thing that I don't think you can define with
packages, I might be wrong, but for example, you wanna customize schemes.
You know, like, I have this scheme that builds this thing
and tests this other thing.
This type of customization is something that you don't get exactly.
Leo Dion (host): is no schemes in Swift Package Manager,
Pedro Piñera (guest): there you go.
So I think they're slowly moving towards that direction.
What else?
Build faces.
I don't think you need them.
Then you have sources, resources.
I think Swift package Manager is enough for, I don't know,
maybe 90% of the projects.
If you're a big company where the very best spoke set up, I don't
think it's package manager is gonna be enough today, but maybe in one or
two years, most likely it will be.
Leo Dion (host): Yeah, like the way I do it now is I'll have XcodeGen file where
I define a project with the targets being like the specific Xcode stuff,
UI tests, iOS app, watchOS app, things that like you definitely cannot do.
And I'll have like one, one file in the project that like, Just a skeleton of a
app implementation, and then everything else is in the Swift package manager,
and that's, that's worked out so far.
I've been impressed with Xcode 15 as far as handling that, like
Swifty y previews are solid.
Like it's, I'm really impressed with, with Xcode 15 in that regard.
So yeah, I could definitely see like Apple moving towards Package Swift
or Project Swift to do, to do that.
At some point.
Pedro Piñera (guest): it must have been a challenge for Apple to integrate
because three package manager has its own bill system outside of
Xcode which has another bill system.
integration that the resolution happens when you open the Xcode project.
So that is some kind of a synchronous task.
While that thing is being executed, you cannot compile, you cannot do anything.
And the, the.
The deeper the graph is, the more packages you have, the longer it
takes, and if it fails, then you're left with this Xcode project that you
cannot compile and you have to retry.
Remember, remember in the first versions, you could not retry.
I guess they fixed that recently, but that is very annoying.
And also if you're on a.
Flight and then you clean and then that also cleans all the
suit package manager information.
And you are left with this project that not no longer compile.
I'm more on the, on this camp of, you know, like when I open
my project, I want it to be ready to start compiling it.
And if something needs to happen before, I would like to run a
command to do the whole resolution.
But that's more of a preference type of thing.
Maybe some people prefer the Apple way, but I.
Leo Dion (host): Have you tried running like Swift package, re resolve,
and then opening the Xcode project?
Do they share?
Do they share the the cash or do they end up disagreeing on where the
build folder should be for the cash?
Pedro Piñera (guest): The last time that I tried, I think it was
using its own custom directory.
But maybe that has changed.
I, I, I would expect some kind of Xcode Build saying Packages
resolved, like at ran, this would be the port install type of thing.
And then there's one thing, and the second part is when I clean,
I would like to have the option to only clean my project artifacts
and not the, the Swift packages.
So having multiple ways of cleaning the directory.
Exactly.
Leo Dion (host): Yeah.
Yeah.
I think we've all.
Reset package cash at least once in our life trying to troubleshoot.
So yeah, I totally get it.
I've, I do think it's helped that they added the universal cash which helps
a lot, make that go a lot faster.
They, but the weird, the weird stuff with like branches and how it'll
cash at branch and you'll have to like delete the branch, the cash.
The cash branch if you don't use a tag.
And I've had that issue before where I've had to like actually
clean the universal cash, which you should never do because then it
has to download everything again.
But yeah, I totally, I think a lot of people agree that
that's, that's a big issue is the whole package resolution thing.
So, yeah.
What was I gonna ask next?
Oh yeah.
Did you catch any of the stuff regarding c plus plus now being
Pedro Piñera (guest): Not yet.
Leo Dion (host): I won't touch that.
But I know that's been a long time coming, so that's great.
We talked about the future.
We talked about merge libraries.
Let's talk.
I'm gonna, I'm gonna hop back, I'm gonna talk about
something that they mentioned.
See if, I mean, I don't know if you, you saw the video on the open API generator.
Did you happen to see that one?
What, what's your thoughts on it and where might Tuist fit into that?
Pedro Piñera (guest): I, I think like being able to generate covid app com,
compile time is amazing, especially when you have something like open api.
Same goes for GraphQL, like there's.
There are a bunch of queries on the schema, and then I would like
the Swift code to be generated.
So having a way to do that is kind of nice.
I learned about, how is it called?
Like Swift Package Manager plugins.
I didn't know that thing existed.
And I think it's very cool, like, that you're able to provide a plugin
that does this completion time.
Thing, the one thing that I, maybe I misunderstood, but I saw
that when they added this open api, Kind of manifest file, the
compiled ones to get the types.
And then with the types they were able to use the types.
I, I wish there was some kind of integration such that you modify the,
the adjacent or the YAML it was a YAML And then the language server protocol
is able to, to obtain the types and give me the completion and everything be
without me having to compile the project because that is an extra step that I
need to take and I don't want to be.
Taking that step, I would like to, for my editor, to automatically
recognize that I changed that, like generate the type.
So instead of just doing it at compilation time, also do it
at while editing, without me having to compile the project.
Leo Dion (host): Yeah.
Yeah, yeah.
I, I could see how that'd be a, a challenge.
But yeah.
Did you, so we had talked about Yonas Did you see that Yonas is killing
his Swift, his swaggen project that was generating Swift code
Pedro Piñera (guest): Ah, yeah, yeah.
With, yeah, yeah, yeah, yeah.
From OpenAPI that's true.
Yeah.
I think.
Leo Dion (host): Yeah.
Which was unfortunate because before dub I'd been working on a project to use
swag gen to develop, to generate Swift libraries from YAML files, open api.
So I don't, I don't know if that killed that project, but it probably did.
I think it's an interesting paradigm that you can, like, you generate
everything from the YAML file.
Like the server as well as the client.
So I, it'll be interesting to see the future of that and where that goes.
Pedro Piñera (guest): Yeah, I think like my opinion is that
developers wouldn't be spending time on things that computers can do.
And I think giving you Swift code from, from the definition of an
API is something that we shouldn't have to be doing ourselves.
But the same goes for SwiftData I think it's called where you declare your data
needs, and then at compilation time, all the details about what does it mean
in terms of tables and database and stuff like that is all inferred for me.
So that is because in then I wanna focus on two things.
When I'm building an app, I wanna focus on the data that I need For
my app, I wanna focus on the ui.
And the, the, the business logic, like some apps are just presentation,
but the ones that have business logic, that should be my focus.
Everything seems like, oh, like how do I map this data to a table?
And then what is the core data stack that I need to set up?
And all the lines of code, like, what if you do that for me at compilation time?
And I just focus on, on, on building my thing.
So I think seeing Apple leverage in this.
Compile time Features like open a, open api, generators or SwiftData
compile time, generational things.
That is, that is very cool.
That's, I think it's gonna be amazing for developers productivity.
Leo Dion (host): So I, I guess you are a fan of SwiftData as opposed to being
a sqlite engineer, I would assume.
Is that correct?
Pedro Piñera (guest): That's correct.
I've been doing a lot of server side things with Ruby on Rails and Elixr
here and their ca in their case, I mean, you still need to define
the tables but they all give you this or That you can interact with.
And I really like when the APIs feel very ergonomic, like
users dot all do something.
And like I touch the database as little as possible, only when I have
to defend the schema and the migration.
And that's it.
Like from that moment on, give me an interface that is very.
Ergonomic users dot all dot something.
Boom.
I have my data and then I, I use it.
And Core data really, I used it like a year ago and, and it felt very verbose.
Still like, oh, you, you need to set up the stack or you need to know
about this persistent coordinator.
And data,
Leo Dion (host): the
Pedro Piñera (guest): the context and all of that.
It's like, yes, allow me to persist data, and that's it.
So, I think it's nice to see Apple kind of abstract in that way.
And I think it's important that they, I'm sure they thought about
this, but provide the skip patches so that if you need to go one level
deep, you can do it easily and switch data doesn't get in your way.
Like it's nice for 90% of the use cases for the remaining 10%.
You can always go into deeper layers and interact with the database directly.
Leo Dion (host): Yep.
So, one, one place where I really like the ORM is, Server-S ide Swift,
specifically vapor and fluent.
Especially now that we have like property wrappers.
I can't even imagine what they're gonna do with macros and how much they're
gonna make it even easier with that.
Have you, have you done any server sites?
Swift
Pedro Piñera (guest): no, but we are starting to do
some in Tuist we build this,
Leo Dion (host): Yeah, you wanna explain that?
Pedro Piñera (guest): yeah, we, we build this server side.
Extension of Tuist because there are some features that require a server.
One of them is remote caching.
So we implemented what we call Tuist Cloud, but we decided to implement
it in in Ruby on Rails because of it, not that many contributors contributed
to it because they, they come to the project with Swift background, so they
wanna do Swift and we thought it would be a better idea to re-implement that
in, in, in Swift we're gonna use paper.
We are gonna deploy it to, to fly, do io.
It's very convenient for deployment and yeah I think it's gonna be amazing.
I'm very excited about this because Because I've been doing a lot of
web development in the recent years.
I can bring a lot of ideas and expertise into, into Tuist Cloud as a project,
but also like to vapor to the framework.
Like if I see some ideas for things that I could implement, I'm gonna
contribute to, to those projects with packages, for example.
Thing that, that I notice is that many web frameworks outside of the
Swift ecosystem have tools for, they call it like build pipelines for.
Processing JavaScript and like giving you a bundle at the end,
or like processing a, a like SaaS type of CSS and like giving
you standard css as an output.
And when I was looking at vapor docs, there isn't
anything like that or tailwind.
Like what if I wanna do tailwind in my project?
Like how do I set up tailwind in, in this, in this project?
There isn't really a way of doing it.
Like you can do it.
You can,
Leo Dion (host): Let's, let's chat about that after the
call cuz I have, I have things
Pedro Piñera (guest): So things like that, you know, like what are the
things that are missing or I was trying to do, I was defining the database
schema and then I was like, there was a command for migrating the database.
And I was like, I need a command for dropping the database.
For creating the database.
And like someone listened to me, it would say, well, you can just
go directly to post script or by.
My SQL and run the command yourself.
But I'm like, I'm a person that really wants to have a nice CLI that
gives me everything that I need.
For example EIR and Phoenix have this framework called ecto
for interacting with databases.
And you can do db, I think it's DB set or something like that, or
ecto set up, and then that's it.
Configures the database drop and it deletes the database and I can do so.
I would like to see these things directly from them.
Through the vapor cli like, give me everything that I
need or print the schema of my database here in my terminal.
I wanna see it.
So I think Vapor is very cool.
Like all the foundation and everything, the ups the people put a lot of
effort into, into making that amazing.
The cli I would like to contribute.
So I, I wanna check like how to contribute to the project
and all the ideas that we.
Half while we work on, on Tuist Cloud, then we'll contribute them
to, to vapor directly or like build packages that the community can use.
Leo Dion (host): One thing you mentioned was playing around
with distributed actor models.
How does that fit in with Tuist cloud?
Pedro Piñera (guest): I don't think, I don't think it's
gonna be necessary for, or.
Cloud necessarily.
This is something that Elixr has plus another thing that
makes it very powerful.
And it makes it super easy to scale your system to say, I have this other.
Server running Swift or running Elixir, and then I can interact with
the server without really knowing that I'm calling another server.
I, I just call it a Swift interface.
I think Apple took the inspiration from, from Elixir, from their actor model,
and they're bringing that to Swift.
I think on the, on the context of the server, not for Tuist Cloud,
I don't think we're gonna need it for Tuist Cloud because we can
initially scale the whole thing.
Vertically with more CPUs and more and more memory if needed.
But if someone is to build assistant that that has, I don't know, another
server doing some kind of background processing, it is nice that you can just
do a wait something, a wait to function and that function will run in the
other server and give you a response.
So I think Apple abstracting that away with their Actor
model, I think is very cool.
I guess Cinca wait was the first step, and I think the next natural step is,
If I'm waiting for something, I don't really care if that thing is leaves in
this server or leaves somewhere else.
So if you're building a system that has multiple servers doing different things
like this one for processing images or this one for, for example, maybe for
Tuist Cloud, I was thinking that we can have some kind of Signing functionality
like you give me the binary and you and I provide you an interface to
orchestrate releases to the app store.
If I need to sign as part of that, I can have a server dedicated to signing.
I go to the app store Connect, I get the provisioning profile
certificate, I sign, and then when everything is signed and I upload
it and from my server, I can talk to that other server, just calling.
Yeah, that's very nice.
Leo Dion (host): Let's talk a little bit more about Tuist cloud.
How has that gone, I guess, when did you start it and then how has
the development usage of it been?
Like what?
What's been the biggest challenges maintaining it?
Pedro Piñera (guest): So we started building it when we built cash and
we thought, well, if we are able to cache this locally, we can push
the same binaries to a server.
And that way you share cash across multiple environments, across
developers in your team, between local and CI or whatever environment.
Then we started building it also open source in the same repository.
It was mainly one person in the team building it, and some
companies started using it.
They basically started self-hosting the project.
So there were two options.
They self-hosted it themselves or they used our hosted version, but
they give us the, their Google Cloud storage or S3 accounts.
We store the artifacts in their servers.
That was the foundation.
That was the first feature.
But because we had a server, we started thinking about, you know,
like, Wouldn't it be cool if we have this feature and this other
feature and that other feature, which are also used for at, at a scale?
So we started to envision cloud not just as a cash server, but as a
kind of like your companion thing.
The thing that will give you the, the things that the Xcode don't give you.
We are gonna give them to you.
What things like things that annoy me back when I was an
I developer, for example, and I'll give you some examples.
One is someone changes a build setting in your project.
Everything is green.
On ci.
You merge the pr and two weeks from now you realize that the built ends
are twice slower than two weeks before, and you're like, how did that happen?
Well, we have to go back in in time until we find the build setting
that was responsible for that.
Imagine if in that PR we, so we build your project, we
get kind of like a report.
We compare that with a baseline and if we see anything weird there, we post a
comment on the PR saying, oh, This is the build insights and this is what we
detected kind of what people do with LinkedIn and they report everything
on the pr, but that with build times.
And for that we need to store the information from the
baseline, from the branches.
We need to do the ding.
We need to be integrated with GitHub to be able to,
to post the report on the pr.
So that's one idea that I have.
The other one is I think this, this would be super cool to have,
like let's say you're building something in your environment and
you're like, Damn, like this thing that I implemented is so, so cool.
I wanna show this thing to someone else.
Traditionally you, well, people do two things.
Either they push everything to remote and then someone checks out
the branch and then compile with.
Takes time, or you push something to some kind of remote branch
where you have a pipeline set up, and then it will go through test
flight or somewhere else, and then someone will install the app.
That also takes time, but you have the binary locally in your simulator.
It's right there in your laptop.
Why don't you share that with someone else?
So Tuist share, share.
We get the binary, we upload it, we give you a url, you share that
with someone, and the other person says, Tuist run, paste the url,
and it opens in the simulator.
So, As Cici as that, and you need a server for all these things.
And imagine like you have this year, RL and, and anyone in the organization
has Tuists installed and they're able to do Tuist run and test.
Imagine what that means for collaboration, not only developers,
designers as well, blue install Tuists Tuist run, whatever, and
they're able to share to run bills that developers share with them.
Leo Dion (host): That's awesome.
Yeah, I mean, anything else as far as Truist Cloud, where it seems
like there's a lot of, there's a big future for Truist Cloud and a
lot of things you want to do with
Pedro Piñera (guest): Yeah, so we are, so a few things.
We are gonna redesign the website to better convey what the
tool is for, why is it useful.
Second thing is better docs.
We need some tutorial there as well to, to help people migrate.
And the third piece is, is.
Tuist cloud and we're gonna implement this plethora of tools
that organizations can use.
My dream.
So I, I think that when I think about the future of,
and the ecosystem, I think.
I hope like all these things that we explored that we can explore because
we're a small project and we are not.
We can take risks.
We can make these decisions of why if we try this share feature
that eventually they make their way into, into apple's tooling.
So eventually like Tuist will won't be necessary, but I think
someone needs to basically go ahead with, why don't we try this?
Is it useful?
So yeah, that's what I want to see.
Like all these ideas, all these things that Apple doesn't.
Help organizations with that?
We do.
And then eventually all of them land on, on Xcodert
Leo Dion (host): Yeah.
Yeah.
That's awesome.
Pedro, was there anything else you wanted to mention as far as the
future of Tuist before we close out?
Pedro Piñera (guest): No, no, no.
That was all, like if anyone has, like right now, when you go to the
website, it is kind of confusing.
So if anyone has questions about the tool or wants to jump on a call to
talk to me about their projects or whatever, like, I'm all here so they
can just send me a DM on Twitter and I will be happy to, to help.
Leo Dion (host): Awesome, and we'll provide links to that as well.
Pedro, thank you so much for coming on the show.
I really appreciate it.
Pedro Piñera (guest): Thanks a lot.
It was my pleasure.
Leo Dion (host): Where can people find you online?
Pedro Piñera (guest): They can find me on Twitter ma or yeah, Twitter.
Basically my handle is, well, we'll, we'll put a link on the,
on the description by Twitter.
Mainly.
I use it actively.
Leo Dion (host): Okay, cool.
Cool.
Yeah, we'll have links to all of your social media accounts,
links to Tuist of course.
And yeah, it was fantastic.
So happy to have you on today.
Thank you
Pedro Piñera (guest): You're welcome.
Leo Dion (host): People can find me on Twitter at Leo g Dion.
My company is bright digit.
Take some time to like and subscribe.
If you're watching this on YouTube and if you're listening to this on a podcast
player, please post a positive review.
If there's any topic you want me to talk about, especially with regard
to WWDC this year, let me know.
I'd love to appreciate to get any feedback from you.
Thank you again, and I look forward to talking to you later.
Bye everyone.