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.