Leo Dion (host): Welcome to another episode of Empower Apps.
I'm your host, Leo Dion.
Today I'm joined by Stefano Medino thank you so much for coming on.
Stefano Mondino (guest): Yeah, it's a pleasure for me.
Thank you for inviting me in into the show.
Leo Dion (host): bEfore we get started, I'll let you go
ahead and introduce yourself.
Stefano Mondino (guest): Yeah, sure.
Hi everyone.
I'm I'm Stefano.
I am from Italy.
I work for a company named synesthesia in Torino, Italy.
You may for a few people that may know me, you may probably have
seen me in swift Heroes, which is iOS event as with event that
we host from my company to Reino.
anD yeah, we are a software house.
We develop work for third parties.
And today I'm here to discuss about our, what I call agency work, even
though we are not a classic agency.
But you it's the kind of work I am more familiar with.
Leo Dion (host): So, unfortunately you're a little bit under the weather.
You got covid, but I think we will make it through.
This isn't Covid of the few years ago.
It's funny, I was just thinking like, I've spoken at Swift Heroes before
and it was remote, like was last year, the first time it was in person.
Stefano Mondino (guest): No.
We, it's, it was the second time in person, but you were, the
first time we met was the online only in 2020, I guess, where,
Leo Dion (host): Yeah.
Right,
Stefano Mondino (guest): it was impossible to meet.
Leo Dion (host): yEah.
So again, you have Covid we're, I'm out.
So we'll pull through this today.
Stefano Mondino (guest): Yeah.
Leo Dion (host): But yeah, I loved your talk on Murray,
which we'll get into by the end.
But before we get into that, you wanted to talk we talked briefly before
recording just about like the work that Synesthesia does, and we don't
hear a lot and in blogs or talks about the kind of work that Synesthesia does
that I think, and I said this before I think a majority of folks who are
doing development are in this space.
And that, that would be kind of, you kind of call it like kind of agency
work, but basically people hire Synta to put together a website an app, whatever.
And you guys put it together.
What do you think is the big difference between that kind
of work and product work?
Stefano Mondino (guest): Well, it's fun that you said you never
read that much about our work.
And the reason behind that is that usually we are not allowed to discuss,
Leo Dion (host): right,
Stefano Mondino (guest): the k not the kind of work, but the kind
of customers because usually it's big projects that comes from third
parties that have strict NDAs, so usually are not able to discuss.
And if we were probably synesthesia would have the chance to be even more
known in the field because the project we work on are so big and incredible
that it's hard to believe to me usually.
But yeah, usually the kind of work we do I usually compare it to the
work they do in product companies.
So, we have to repeat or start from scratch.
The same work many times, countless times.
And the fun part about our work is that sometimes you start let me say on a
sports app, we work on many sports app.
And the next day maybe you need to work on something related to, I dunno,
agriculture, finance, or, I don't know.
I went through so many apps in the past years.
I lost count of of it.
But the fun part of our job is that we get to, to work on many different
scenarios and learn a different stuff that you may never think about.
Currently I'm working on an app about a sport I barely know existed.
But also I was able to find that it's one of the most
important sports in the world.
But yeah, it's stuff that, that happens in our work.
But what I've tried to do as tech leader for the last 12 years it was fun because
when I started I'm still at my first job actually, as I was telling you about
10 minutes ago when I started, I was the leader of myself because we were
five or four people working on both Android, iOS, and web and stuff in 2012.
Today we are more than a hundred people between employees and consultants.
So, it was fun to see the company grow in my shoes and also to be
able to contribute And to get to the point, what I really enjoy to
do is to be able to start different projects from very different
scenarios with the same architecture.
And the same approach in the in the US development.
Leo Dion (host): I Mean, that's a big deal if you have more than one
person maintaining the app and also are maintaining multiple projects.
So like, yeah.
I mean, consistency would be a big deal.
Is there, what are some consistencies that you have
found between different projects?
Regardless of like industry?
Stefano Mondino (guest): Well, the team was made in some periods.
I think we reached 18 people in the iOS team alone on many multiple
projects because we have to scale, get consultants to help out in peak
periods, and then reduced the team, of course, when it's not in it anymore.
But yeah the, what I tried to do was to first focus on a pattern that
was good enough for for the app.
And of course not to change.
I dunno, I didn't want to start with I'm going to use a
word I forbid myself to use.
Because I hate it.
I not start with Viper one project and then the next day another part.
I hate Viper, but I never understand it.
Sorry.
And I shouldn't use the word eight, but seriously, Viper.
Why?
Anyway I found myself working with MVDM back in the days where that saint
man of es farro put out some, I dunno if you know him put out some very
interesting tutorials about MVVM in Objective C back in 2013, I guess it was
it was the first time I heard about it.
Reactive cocoa with MVVM.
It was a very cool tutorial and a project, demo project.
I took a lot from him in, in, back in the days and been working on
the same kind of architecture.
Back then up until today, where we switched over from Objective C to Swift
and from UI key to SwiftUI, et cetera.
But the approach was always the same.
Business logic in one place, model logic in another one,
and then deal with the view.
Leo Dion (host): Regardless of the quality of Viper is like
just you have to be consistent it like across your team.
And if you're gonna go with React reactive, Objective C, then you
still have to stick with it.
And like, 'cause the team's gonna have to manage multiple
projects, so it makes total sense.
Do you do any like, shared libraries across your applications?
Stefano Mondino (guest): Yeah, so we do we, we start every
project with a skeleton app.
And the reason why sorry, let me finish the flow.
We have a skeleton app connected to a shared library that is called
Boomerang, which is it's open source on GitHub, and it's a very basic
library used to implement MVVM in UI for UIKit and reactive projects.
Basically, we wanted to avoid every time to write the logic to bind UI
collection view or UI table view to a view model and a list of view model.
So we kind of implemented a shared logic that may abstract
this contact this concept, sorry, and reuse it everywhere then.
On top of this library, which is open source.
I I think not many people are using that.
Some project is using it, but not that many is using it.
On top of that, we built a skeleton, which is a empty project
full of utilities that you can change and you can tweak on every
project you kick you kickstart.
This is why something, in my opinion, should stay in a shared library.
You get updates and new features as you develop the library,
but some other parts should go in, some kind of boilerplate.
You can change in the project itself.
You kickstart it and then you change it, some small details.
It's an approach that that work.
Leo Dion (host): how do you maintain booing if like something comes up
when you're using it, that like throws things off or causes issues?
Stefano Mondino (guest): Usually, and I know that it's not the best
way of handling this, but we have to survive somehow at the end of a
project or when we release the first version, we try to, put an eye on the
entire project and extract all the features, the small details that may
be skeletonized and put together in the original skeleton for the next
project that that's about to start.
So the older one, after the QA phase and after they launched
they kind of stay on their own.
And they do not get updates because they're already working and it'll
be hard to keep everything in sync.
Sometimes.
We it happened that we rewrote the architecture from scratch
keeping the same the same approach, but improving it.
Like, I don't know.
When we moved from Objective C to Swift, or in the last year when
we moved from UIKit to SwiftUI.
Leo Dion (host): right,
Stefano Mondino (guest): This is the approach that I host sessions with
the team explaining what's changed and what is going to change in the
next project that's going to start.
And we iterate over this concept.
And every time the new the new app is better than the one before,
because we learn from the process and we improve it from the new one.
For the new one.
Leo Dion (host): Right.
Right.
What are what are some of the most strange or peculiar
projects that you've worked on?
Both subject matter wise that you can disclose of
course, and development wise?
Stefano Mondino (guest): Well, let me, development wise there's a small
app, but it's peculiar for my city and for the approach we we used.
So you've been in terrain.
All right.
We have a very important monument in the city.
It's called the Mullen on Eliana, which is, some kind of a big tower with a cup.
I don't know.
In English, how you, you say that it's the coverage made of a,
like, like a cone on at the top.
It's very tall.
It's the most important monument in the city.
So this top part of the monument has foresight.
And at night, in summer since inside the monument, we have the Cinema Museum,
which is very important in Italy.
They do projection of short films and stuff from indie movie
makers stuff like that for the festivals we have in summers.
So the Cinema Museum asked us to create some kind of mechanism to
synchronize the music of these huge projections visible all around the
city so that with your mobile app, you could have in your phones, the
audio in every part of the city.
More or less synced with what you were were seeing in in the monument.
And the fun part about it is that we only have, I think about 12 to 15 days
to implement it in both iOS and Android.
And when we did the estimation and the economics and stuff to the customer,
we forgot about the server part.
We forgot to include it because it happens when you're in a hurry.
I'm not pretending we are perfect.
Right?
So
Leo Dion (host): Yeah.
Stefano Mondino (guest): So I stepped in.
Yeah, it happens all the
Leo Dion (host): Yes.
Stefano Mondino (guest): So
Leo Dion (host): That's why they invented multipliers.
When you do estimate.
Stefano Mondino (guest): E e, exactly.
So what I did was to step in since I'm a very huge fan of the
far base work I created myself.
I know a little of JavaScript not that much, and not that I'm proud
of, but still you have to survive in the computer science works.
Just kidding.
Of course.
So I created some kind of mini web server with APIs in less than a day
with the far base cloud function and the remote database, et cetera.
And we were able to the projection the company in charge of projecting
the videos had the chance to WebBook their start and the end of
the video to an external server.
So I was able to create it in, in that amount of time.
And the application was used and was working.
Actually the synchronization was accurate up to I think 200
milliseconds because there's some delay
Leo Dion (host): Yeah.
Wow, that's really good.
Stefano Mondino (guest): yeah, it was nice.
It was it was fun.
Not the huge, the biggest project I worked on, but since I was
born in the city, I'm really tied to the city emotionally.
So it was nice to see this working in place.
Leo Dion (host): That's interesting.
So when do you like.
How do you decide things like, oh, we're going to like say Scri, let's
just do Flutter or React native.
Do you ever get in those situations, I mean, obviously you
have like React native heroes,
Stefano Mondino (guest): And also Flutter Heroes.
We have both.
We have all the euroes, we and we have Android Con for Android because we
are we have the license for the name.
So otherwise it would probably hear be Android, Heroes, I don't dunno.
But yeah, we also have AI, Heroes just from past week, first edition
for I mean, we, we hero everything.
The question was to Flutter and React native.
Yes.
We have a team, two teams smaller than the native ones dedicated to such apps.
And we had big success for especially for React Native, because it's.
It's been there for a longer time in in big applications.
Usually we it's a com when we decide to go on a technology or another.
It's a combination of budget, of course.
If the customer usually there may be scenarios where a customer cannot afford
a double a double development phase.
But also it's a better I mean if the application is going to be lots of
native integrations, like, I dunno, lots of background processing Bluetooth
or whatever it, or you have to implement, I dunno, widgets or WhatsApp
connected to the main app or whatever.
It's.
Usually better to go with the native approach.
If it's just list detail, a quick app we usually suggest to go with
the native approach because it's more effective with the customer.
I prefer to go always native, but I have to be realistic and to be I
mean, keep my feet on the ground.
And sometimes nobody not everyone can afford to go with a double
Leo Dion (host): Totally.
Stefano Mondino (guest): Phase
Leo Dion (host): Yeah.
Stefano Mondino (guest): Usually the multiplier for us, it's multiply
by two, the development phase of the estimate for the native one and 1.3
for the hybrid solution, more or less,
Leo Dion (host): that makes sense.
And I mean, we can, as Swift native developers, we can go on and on
about the benefits of developing in Swift, but sometimes those
benefits aren't worth it to a client.
So, yeah.
Yeah, I'm like working on a project right now where it's React native
and they're adding a watch app and like I am learning all the
intricacies of trying to integrate a watch app into a React native app.
And I can confirm I like doing Native Swift development.
But yeah it's interesting trying to do that.
Yeah.
Have you ever gotten into a situation where you picked up a reactor flutter
app project and had to update it and had to integrate native features?
Stefano Mondino (guest): We did I didn't do that myself in first person,
but I helped out and it's not always the most straightforward process.
We also tried to, to integrate React Native in a, in the opposite
way, but was more of a mess.
It's something that technically you could do because you need
to integrate the framework.
And then the advantage of React native against Flutter is that
they are still native view.
They are RCT views, I think it's called the components.
So technically just for fun, one time I've integrated multiple RCT views in
a native UI collection view, just to prove that you can mix the two of them.
You can have a complete native view.
And then at some point, like Facebook was doing back in the days, I don't
know if they are still doing it, the feed was React native and the
other pages were more of a native
Leo Dion (host): Okay.
Okay.
I didn't know that.
Oh, I mean, I'm not surprised it came out of Facebook, but I didn't
know that's how they did it.
Okay.
So let's talk a little bit about your workflow.
So we talked a little bit about your skeleton.
I, should we get into the skeleton?
I feel like we're already hinting at it.
Or should we start off talking about the other tools you use?
Let's hold off on that 'cause I don't wanna spoil it, but
what other tools do you use?
'cause you got here tourist and Exco and which I'm a big fan of.
Sorcery.
Well, let's table that.
And then Fastlane, which I'm a big fan of, I just released Bushel.
And I used ex Cogen and Fastlane like crazy among other things.
Yeah, you wanna explain how those tools help integrate with
your teams and your projects?
Stefano Mondino (guest): So, let's start by to orgen.
One, one thing that I honestly don't know how people can
deal with probably later.
They're using directly SPM, but conflicts in git with my team, were
a huge problem in the past years, uh, especially on a file that for any other
kind of developer in the world doesn't exist, which is the Xcode project file.
Right.
So if you open X Android studio
Leo Dion (host): it's the last vestige of like horrible get merge issues.
We've gotten rid of storyboards, thank God we've gotten rid of, to this year.
We got rid of core data models.
Thank God.
So now we have like, the last thing is Xcode projects, right?
Stefano Mondino (guest): And honestly, since every time I, I hear about people
not using some kind of tool helping out the process itself I honestly don't
know how can can, they can deal with it.
Because once I've started the first time with Xcode gen, because back in the days
I only knew Xcode Gen, I couldn't go back ever because it's just a YAML file.
You put inside all the definition of your project.
You hit a command in in the terminal, and then it builds your project.
You don't commit ever again, your project in source code and it's fine.
I probably developed lots of lots of projects also modularizing
them in different sub frameworks.
Or the other side.
Having a white label project, meaning that it's a a monolithic project,
but with many different colors and brandings for different for different
Leo Dion (host): Yeah.
That's so perfect for tourist or exco.
John, do you use both or do you use,
Stefano Mondino (guest): IUI started with Exco, Jen with a YAML file.
Then two years ago at Swift Heroes, I was talking with one of the
speakers, ra sfa, which is, I dunno, probably you met in in last one.
I told him, ah, you have a talk about Tuist.
I've heard about it, but I prefer xcodegen he's a very rough
guy when you talk with him and told me, oh, you're an idiot.
Use Tuist.
So, of course, yeah, it kind of, I, the first time I approached
Tuist, it was not that easy to understand because if you start from
scratch, they force you to use their structure and they didn't like it.
After talking with with this guy I went back to it and tried to apply
it to my structure and being able to use zw files instead of YAML
files and to code my pro, my project structure was such an improvement
that I never went back to Xcode gen.
Also because xcodegen is maintained by a single person.
It's a very super cool guy but is alone while Tuist is made of a community.
And this is looking forward both of a super pro, also a con
because sometimes you may not agree with what the community is
deciding for the project itself.
They are privatizing some of the features of Tuist later on.
And this, it, this could become a, an issue for you if you're using it
as a, an open source project, but it's a total other topic to discuss.
Leo Dion (host): Right, right.
I mean, those private pro pieces are like hooked for posting reasons
and cloud and things like that.
So it makes total sense.
Yeah, I'm like.
I use xcodegen.
I've talked to, I've praised about xcodegen on and on, on this show.
And we've I'm probably getting closer and closer to
maybe going with to us soon.
I find that xcodegen does pretty much everything I needed to do.
It's when you have to like really customize the way that
libraries are compiled and things like that, and already have
a ton of swift files anyway.
So it's like, why not just go with Swift?
Stefano Mondino (guest): One thing I
Leo Dion (host): we have.
We have a, we did an episode with Pedro a few months ago, so
yeah, definitely check that out.
But the stuff he's doing is amazing with tourist.
Stefano Mondino (guest): It's it's really incredible and also just,
I don't want to be misunderstood.
I know why they are going private on some parts for the cloud.
I follow the whole situation and I think it's super good that they're
trying to survive basically.
So I totally understand that,
one thing I wasn't able to do with with Xcode Gen besides the syntax, and
beside the fact that they are using yamo instead of code, an actual code,
is that I was able to have a single source of truth for both my projects
and Fast Lane because moving to the Fast Lane subject having many different
environment for the app, usually for us, usually you go with the dev on your
own developer portal when the production environment goes to the customer's.
One.
Being able to drive all this logic from both the app and Fastlane
wasn't that easy because you have to duplicate the team ID or the
bundle identifiers in many places.
Leo Dion (host): Okay.
Stefano Mondino (guest): what I did was to use the templating engine
of source of, sorry, of Tuist.
To create a JSON file that it's u that it's driven with logic
from from the SWIFT files.
So I have a configuration finding in Swift with all the data for my project.
It's creating my project, but it's also creating json file
that it's used by Fast Lane to create the actual final pipeline.
So in this way, I am only placing the logic of my global
environment in a single software.
Yeah, and this is u useful for replicating also the logic
for the pipelines, for the continuous integration and
delivery from in my skeleton.
So in the single starting point without dealing with pipelines every time
rewriting that from from scratch.
So I have a single fast lane file.
It's working okay for all my projects.
And that's it.
Leo Dion (host): What do you use for ci by the way?
Stefano Mondino (guest): Well, mostly everything.
I've tried to our how can I say?
We work for sometimes for, directly, for, with our choices,
meaning that the customer, the final customer is directly on us.
So we have inhouse two or three Mac minis.
They are more cheaper.
It's more cheaper to buy a Mac Mini and also inhouse rather
than have it in the cloud.
We have a
Leo Dion (host): That's what I do.
That's why I bought a Mac
Stefano Mondino (guest): They are so cheap and so powerful.
So it's it's easier.
So we ask them in-house.
We have a Jenkins hypervisor to sync between them.
Also because they are shared between Android, react native and Flutter,
which it will be harder to maintain on external platform of for cis.
And then we also have agents agents.
From we use Azure DevOps.
I know that in our community, saying the word Microsoft is usually not the
best thing to do, but Azure DevOps,
Leo Dion (host): as bad as it used
Stefano Mondino (guest): it's it's really amazing compared
to the cost it has per seat.
So if you were to put together a git, whatever it is, a Wiki, a Jira,
or whatever you may want to use for tasks and stuff like that altogether,
and pay for that, it will be less, more way more expensive compared to
what you can do in in Azure DeVos, which has everything in one place.
It's really powerful and I encourage everybody to at least try that Then.
Be able to say, okay, I don't like it, but it's something that shouldn't
be underestimated in my opinion.
It has pipelines.
You can install agents for that.
Usually we, we configure the Azure pipelines.
It goes to Jenkins and then goes to the notes for the make mini for the builds.
When we don't have access to our Jenkins, we just replicate the same
logic on the agents of our third party customer whenever it's needed.
So we try to I have a make file in the, in my, in every project
that has two or three comments.
I only need to launch them for what, from whatever pipeline I have in
Leo Dion (host): Yeah.
That's so nice.
Yeah.
Stefano Mondino (guest): And that's the approach I usually do.
Leo Dion (host): I mean that's the problem with Xcode Cloud is like
everything is so tightly integrated.
If you can move it to a script and then you could run it anywhere,
that's like the way to go.
And then with the big complaint I've had with Azure DevOps and with
the whole Microsoft CI system, and I say that because I'm including
GitHub is the problem that they never update their macOS version.
But it sounds like you're running this all on Gore machines, so
you don't have that issue, right?
Stefano Mondino (guest): no you basically on DevOps it works like this.
You can decide if the machines are going to be hosted by Microsoft in,
in their cloud, in Azure Cloud, or you can have the self-hosted agents
and you can have whatever you want.
The only problem with that is that they make, they're making you pay.
For concurrency of pipelines at the same time.
So you have to pay $10 extra just to have a concurrent job.
Working at the same time for now we are paying, I think three or four jobs.
It's not a big deal.
We have more than a hundred projects in our Azure DevOps, because we
also have webs and stuff, web.
But it's way less expensive than having everybody on Jira
on GitHub paid GitHub and so on.
It's $8 per month per seat, and you get task, you get gi,
you get Wiki, you get whatever.
Leo Dion (host): Yeah.
I've worked with a client that used Azure.
So yeah, we geeked about it in Turin, so I remember being like,
oh yeah, xcodegen, tourist, Azure, like all good stuff.
So yeah, I'm quite familiar with that, that, what is it called?
Stack.
Thank you.
Okay, so we talked about skeletons, so let's get into it.
We geeked out about your talk and a tool that I've been using
quite a bit, and it's open source and available on GitHub.
The humorously titled Murray.
First of all, explain the Murray reference because there's very
few people who played Sierra games in the nineties, who probably,
Stefano Mondino (guest): Y Yeah I mean, I mean, in, I think it was
97, I was 12-year-old back in days.
And they gifted me the course of Monkey Island, the third one
the third chapter for Christmas on my very old PC back in 97.
So you can imagine how PCs were of probably 98.
I don't remember.
It's the same.
Not a big deal.
So there was this little annoying skull called Mare.
And I decided to name the tool after him because I used this tool to create
skeleton and to coordinate skeleton.
And by adding a small piece of of stuff, I'm going to explain this in a moment.
So when it came to my, when I was thinking about giving the skeleton
a brain, like I had to coordinate, I could either call the tool skull.
But felt like a little bit too much Halloween or stuff like that.
Then I remember about this what is the first skull,
talking skull I can imagine.
And I remember ma, I tried to, yeah, let's it's short, so it's nice to
write it down in, in the terminal.
Probably there wasn't any other tool command line tool named like that.
So I didn't risk any collision.
And if Lucas Arts actually Disney won't sue me for copyright infringement,
then I think we can go to with that.
No, of course.
Just kidding.
So yeah we went for this tool, because I tried to, to use Xcode template.
Every other web tool has scaffolding features, meaning that you need
to add a controller or a model or whatever to your view or
to your, sorry, to your code.
Yeah.
Leo Dion (host): to me, like the classic one is Ruby on Rails.
Like when I saw how Ruby on Rails worked, I was like,
okay, yeah, this is awesome.
Like that to me is the prototype scaffolding setup.
Stefano Mondino (guest): E exactly.
I am I've I worked on Ruben Rails back in the days a little bit.
And this is exactly where the Murray idea comes from Ruben Rails.
They have this generate tool where you can, since they, they
went with an approach called convention over configuration.
It's which was the approach it was common to have small boilerplates, small
pieces of codes that went to in, in the appropriate places of the of the code.
So, when I search for something similar in Xcode, I found out s code
templates, which is the native feature available in Xcode that probably even
Apple forget about, forgot about in the later days, in the latest years.
They're cool, they're integrated, but it's super mess to configure them.
You have to go through pill list, like everything in Apple ecosystem.
They have a list for everything and
Leo Dion (host): I don't even know how you would install
an Xcode template, like
Stefano Mondino (guest): Yeah, had a script to download it.
Yeah, they, you just have to copy that in a hidden folder in the library
Leo Dion (host): hidden folder.
That right there is like, you're already gonna, that's 80% of people aren't
gonna know what to do or how to get to the library folder or whatever it is.
Yeah.
Stefano Mondino (guest): Exactly.
That's a huge red flag in my opinion.
So I'm not saying that Mari, it's the easiest solution to this
problem, because I know for sure that it's quite hard to understand
how to start working with it.
But at least you get a terminal.
You should always have a terminal open when you're
developing apps, in my opinion.
Again, I'm not endorsed by Microsoft, but I found myself really happy using
Visual Studio Code because you have
Leo Dion (host): Okay.
Stefano Mondino (guest): file structure, also the files that are
not included in Xcode, you can how can I say explore them and select
them, and at the same time having a terminal already in the proper
folder where you can launch comments.
So I'm I'm using that all the time.
Leo Dion (host): Yeah.
I have it open right now, so trust me, I use Visual Studio Code all the time
Stefano Mondino (guest): Yeah.
Leo Dion (host): Mean it's got really good swift integration now.
So thanks to the server dev team.
So yeah, I lo I love Murray.
So the problem I ran into is, so the way I scaffold my app
is I'll do I'll do xcodegen.
So I'll have a project YAML file, and then I'll have one,
one Swift file in my project.
And then everything else is in SWIFT packages.
And the problem I ran into was, I was constantly, like, the way I
was doing it was I was like copying a file and doing it that way.
I don't know if you've ever tried creating a new file in a Swift
package in Xcode, but it sucks.
It like.
It's a mess.
So I was looking for a way to just constantly do,
like, easily create a file.
It'll know exactly where to put the file.
It'll have a template and like that was it, like Murray was ideal for,
it was like exactly what I wanted.
And it's great 'cause I could just go right into Xcode and create a new swift
file and it's automatically added to the package and to the application.
So yeah, that's what I loved about it.
Stefano Mondino (guest): Yeah, it also integrates nicely with with
Xcode or or Tuist because I, it has the the power of launching commands
before or after creating your file.
So what I usually
Leo Dion (host): That's right.
Yeah.
Stefano Mondino (guest): you to create a multiple file and the
end of the procedure just launch.
For me it's make project, but orgen generate or Tuist generate or whatever.
Leo Dion (host): yeah.
Stefano Mondino (guest): you automatically see that appearing in your
project, in a matter of a few moments.
I use it a lot with Tuist for creating new sub-projects.
I don't use this with package for in my, repository for
sub features of of my app.
I use Subprojects because I don't know why, but it worked.
It was my original approach.
And I've scaffolded entire folders with Murray, with lots of boiler plates.
Like, the already created the folder for the components, the
one for the view controllers, the one for the repositories, the use
cases, the data sources, et cetera.
And the module configuration itself where the dependence injection happens.
And I simply run Marray, create a new module, and I I launch it
and I have it already in Xcode.
So it's it's really powerful.
Of course, it took me a while to to create all the scaffolds and I
think it's the biggest issue at the moment with with Maori in my opinion.
It's hard to get to a productive point.
It's the same issue that Tuist have that Exco Jane have.
So you are also
Leo Dion (host): I mean, have you looked at creating like a, well,
you have a MurrayKit, don't you?
Stefano Mondino (guest): Yes you can, you, you can have it there.
It's going to create the first file, but it's made of concepts.
So you have to first study those concepts.
And this is probably a too steep learning curve for most of people.
So you have to really understand what Murray is about and what are
the benefits that you can take out of it before starting using it.
And in my opinion, probably I'm not good enough to explain that this to people.
What I'm planning to do for next year is to create something similar
to what she of Zaki did for sorcery, which is the Sorcery Pro, which is
the an editor where you can create everything for MA and also see
a preview of what you're doing.
So ma in at a lower level is made of a common line interface.
Small module and then something called Maki, which is the actual
core of it, the 95% of the code.
So, I designed this I designed it like this because I want to be able
to pick this Maki and put it into a Mac s application with graphical user.
Yeah, so it's as soon as I have time for it I'm going to I would
also love to make these open source as well with our skeleton maybe.
So, our skeleton is what I didn't say, it's an app that it's already outta the
box available for the four platforms.
There should be five now, but I let's pretend Vision OSS doesn't
exist yet because I'm a little behind schedule with it, but it's
made using Tuist, thanks to Tuist in a way that every Submodule can be
created and integrated for only me, oss only iOS, uht, oss, and watch
us, or only a sub a subset of them.
So, I'm planning to release it as soon as I have time which is not
not something that's going to happen soon, but it's something I want to do.
Definitely.
Leo Dion (host): I'll link to your talk you did at Swift Heroes, where you
introduced Murray as well, so people might get a good idea from that as well.
You mentioned briefly, was there anything else you
wanted mention about Murray?
Stefano Mondino (guest): nO.
Besides that, it's every, everything that's, if anybody has something
to say about about Murray, please reach out to because I
would really love to improve it.
It's, I think it's useful.
It's saving us a lot of time.
I think it could deserve a little bit more of how can I
say, being most more famous.
I dunno how to say it in, in English, but I really suck at being this public
and sponsor it every everywhere.
But usually I use this Swift Heroes to talk about it.
By the way, we are hosting a new event in April 18 and 19, April of 2024.
So reach out to me if you want to participate to the
News with Heroes in Torino.
Next year will
Leo Dion (host): Yeah.
Yeah.
It's awesome.
And I love Turin, so I'm a huge I loved it.
It was amazing city.
So yeah, I highly recommend checking it out.
When our CFPs do?
Stefano Mondino (guest): I Think they're already open.
I don't know when they're closed.
But it's going to be plenty of time.
Usually.
I think it's going to be end of January or February.
I don't know, honestly, I, but I, there's time.
Don't worry.
Leo Dion (host): yeAh definitely take an opportunity.
Fantastic conference.
So, yeah.
Stefano Mondino (guest): So we have food, so it's
Leo Dion (host): you could say that again.
I wanted to, you talked about, so what's a templating
engine that you use in Murray?
Stefano Mondino (guest): Yeah, we are using stemc cell because
apparently it's the only it's the most used templating engine available.
Recently I also integrated the support for I think it's
called with Sensoril kit.
There are some kind of extensions to the base stencil language.
buT it's yeah it's that engine.
It's fine For what is the normal usage of of ma?
It's the same used by sorcery.
Although with sorcery, if anybody has ever used it, since it's more
of a coding approach, rather it's a template, but you need to code a lot.
So when you write a sorcery template, you usually end up
writing up micros and functions stencil that are not so easy to use.
But for Murray, it's it's more than enough because you don't need
that much logic in your templates.
You just need to have 90% swift and a 10% variables that needs to be
scaffolded when you launch the command.
Leo Dion (host): What have you done a lot with sorcery, in
Stefano Mondino (guest): I I've done I've done a bunch of things basically
for mocking automatically some kind of implementation of protocols I'm
using with dependence injection.
They have a.
For unit testing.
When we do that, uh, we don't usually, we don't always do unit
testing in our project because sometimes there's no budget for it.
So we, we became good.
Leo Dion (host): say that it's okay to be public about that.
Stefano Mondino (guest): No I actually, I am I'm proud of it because we became
good not doing common mistakes and we, em, we empowered our skeleton
so that it's robust enough, it's solid enough to not have the usual
Leo Dion (host): the skeleton has the unit tests.
Stefano Mondino (guest): Yeah.
And every time you create with Murray a new feature, a new view controller
or a new view model, whatever, it comes with a template of an empty unit test.
You can decide and always the pipelines are running unit
test, even if they're empty.
You can decide for very critical part of the application if you
want to add unit test or not.
That's the best thing I could came up with.
Leo Dion (host): what was the name?
Boomerang, I assume has unit tests too, so it's like.
Stefano Mondino (guest): yeah.
It has some unit tests, but well, the thing with Boomerang is that now that
we are moving to SwiftUI and there's not that much need of using it anymore.
We have stuffed Boomerang with a dependency container not to be, to
avoid including every times we inject or DDIP or other external libraries
for doing dependency container and dependency injection, which we use.
So it's inside Boomerang in a single file and a bunch of other
properties, like the definition of the protocol view model.
Or something like that.
But besides that, all the extensions we used back in the days with RxSwift, now
we move to combine or the extension for table views and collection views are
not needed anymore because SwiftUI has a data binding at its score natively.
So we don't need this tage for binding the view model to the collection
Leo Dion (host): No, that makes total sense.
Stefano Mondino (guest): So yeah, you could use a unit testing, but probably,
I mean, we are, I'm not saying that we are dropping the library itself, but
we're using even way less than before.
So
Leo Dion (host): Yeah.
If you're going all swifty, I can, come on.
It makes sense.
I'll ask, even though you might not know have you done anything with macros?
Stefano Mondino (guest): Not yet.
Leo Dion (host): Okay.
Stefano Mondino (guest): I'm planning to do something with macros, but at
the moment I am I'm way behind with it.
I'm not I'm not familiar with it.
I know what they are, but,
Leo Dion (host): here.
Stefano Mondino (guest): Didn't have the chance so far.
Leo Dion (host): Are you seeing anything about it that's like,
opens up opportunities for more co-generation, I suppose, and like
how restricted are you on like de like what os you're deploying to.
You know what I mean?
Stefano Mondino (guest): Ooh, that's, yeah.
I'm fighting to have at least I, US 15 on new projects.
Leo Dion (host): Okay.
Stefano Mondino (guest): On the one I'm currently working
on, they gave us a green light.
So we are working on iOS 15.
Otherwise, our standard in our offers when we are proposing new
apps to new customers, it's 14, but at least we don't have to, well, we
don't have to deal with 12 anymore.
And also with 13, it's I guess it's not a big
Leo Dion (host): What where do you feel like your hands are
really tied in those cases?
Stefano Mondino (guest): well, on 13, we don't have the, basically
it's you cannot use this with ui.
Yes, it's supported, but you don't have grids.
It's full of bugs.
So not a big deal on iOS 15, you compared to the 14, you have something
more for scroll views and you have marked down support and something more,
something like that.
So I don't remember exactly why I was fighting to have 15 there.
There was a specific thing that I don't remember
Leo Dion (host): fourteen's a big thing though.
Like you said, like SwiftUI is basically unusable on 13 and
I've totally seen that as well.
Stefano Mondino (guest): The only part where I found usable on 13 was for
for watch oss because for watch OSS applications, it was ready from day one.
But you need to do, actually, it was you could do more things with
UI compared to the older watch kit.
It, which was a really awful experience in my opinion.
So, I only did two apps, uh, one with watch kit and one with two Eye.
And there's no match between the two of them.
I mean, it's.
Leo Dion (host): can all commiserate about doing development with Watch Kit.
I think we should have a
Stefano Mondino (guest): You are forced to use storyboards, but you
don't have the concept of view, so you can add or remove sub views.
You need to have everything in the storyboard.
I mean, too
Leo Dion (host): Is weird.
Like the way you did tables and it's just, it was so strange.
So strange.
Anything else you wanna talk about before we close out?
Stefano Mondino (guest): Well, I think I talked enough like, like I usually do
you have to shoot me to make me stop.
But yeah, no, I think I covered mostly everything, so if anybody
has any questions about Murray you can find me on Twitter.
And I'm really glad for being here.
And thank you so much for hosting me.
Leo Dion (host): Thank you for coming on, Stef.
It was great to finally talk about these subjects.
I know we geeked out last time, so Yeah.
And I'm a big fan of Murray, so that's been super helpful to me.
Thank you again and maybe I'll see you, maybe I'll see you
Stefano Mondino (guest): Whenever you want.
Leo Dion (host): Yeah.
Yeah.
And take a time to check out.
We'll have links to Swift Heroes and the CFP, so please take some time,
buy some tickets, fill out a CFP.
It'd be fantastic.
It's a great conference.
Can't say anything better and tour's.
Beautiful.
So, yeah, it's fantastic.
People can find where can people find you online?
First of all?
Stefano Mondino (guest): Well, I'm on Twitter on GitHub on GitHub.
I'm Stefan Monin on Twitter.
I have my old old school nickname, which is Punto, uh, which yeah,
I will never get rid of it.
But anyway, you can find me on Twitter and,
Leo Dion (host): cool.
And people find me on Twitter at Leo g Dion.
My company is Bright Digit.
If you are a fan of this podcast, please consider being a member of the Patreon
to get early access to these episodes.
I post them pretty much right away, so definitely check that out.
I can't plug this enough, but bushel, I'll be doing a whole episode on
Bushel, so take some time respond to me on Twitter about what questions you
have about the development process.
Bushel is available for pre-order, so you can go check that out, get
Bushel app, and I'll be talking about how I did some stuff like
using Xcode Gen and Murray and all that fun stuff in Fastlane.
So I'll have more details to spill on that.
In that episode coming up.
Again, check out Get Bushel app for more details.
If you like this, please if you're watching this on
YouTube, like and subscribe.
I'd really appreciate it.
And if you're listening to this on your favorite podcast player,
please go ahead and post a review.
Thank you so much and I look forward to talking to everybody later.
Bye everyone.