Subscribe
Share
Share
Embed
Mohammad Azam (aka Azam Sharp) talks about RealityKit and how to get started as well as his recent article exporting large-scale SwiftUI app development.
Guest
Related Episodes
- Episode 144 - Yak Shaving with Tim Mitra
- Episode 142 - Mobile System Design with Tjeerd in 't Veen
- Episode 135 - Behind the Scenes of SwiftUI with Aviel Gross
- Episode 121 - Server-Driven UI with Mohammad Azam
- Episode 82 - Game Development with Tammy Coron
We talked about
Social Media
Twitter Leo - @leogdion
Twitter BrightDigit - @brightdigit
LinkedIn - @leogdion
GitHub - @brightdigit
GitHub - @leogdion
TikTok - @brightdigit
Mastodon - @leogdion@c.im
Youtube - @brightdigit
Twitter BrightDigit - @brightdigit
LinkedIn - @leogdion
GitHub - @brightdigit
GitHub - @leogdion
TikTok - @brightdigit
Mastodon - @leogdion@c.im
Youtube - @brightdigit
Credits
Music from https://filmmusic.io
"Blippy Trance" by Kevin MacLeod (https://incompetech.com)
License: CC BY (http://creativecommons.org/licenses/by/4.0/)
Thanks to our monthly supporters
"Blippy Trance" by Kevin MacLeod (https://incompetech.com)
License: CC BY (http://creativecommons.org/licenses/by/4.0/)
- Holly Borla
- Bertram Eber
- Edward Sanchez
- Satoshi Mitsumori
- Steven Lipton
Creators & Guests
What is Empower Apps?
An exploration of Apple business news and technology. We talk about how businesses can use new technology to empower their business and employees, from Leo Dion, founder of BrightDigit.
Leo Dion (host): Thank you for joining me for another episode at Empower Apps.
I'm your host, Leo Dion.
Today I'm joined by as Azam thank you so much for coming back on the show.
Mohammad Azam (guest): Thank you so much for having me.
Leo Dion (host): I'll let you go ahead and introduce yourself for those who don't know.
Mohammad Azam (guest): Sure.
My name is Azam and I work as a coding bootcamp instructor for digital crafts.
I teach web.
But I also do iOS development on the side, and I am very active on YouTube as
well as udemi for publishing different courses and also speaking engagements.
Last was, I believe, 360iDev in Denver.
Leo Dion (host): Yeah.
Yep.
Yep.
That's last time I saw you in person.
We'll have links to your YouTube channel somewhere here and in the show notes for just listening.
So definitely check that out.
We've been talking a lot on the show.
We'll be talking later about Swift architecture for large apps later, but
the other thing we talk about is the rumor mill of VR and all that stuff.
And I was really impressed with your presentation at 360iDev.
We'll hopefully have a link to that here as well.
Where you talked about RealityKit actually using RealityKit.
I was so I'll just tell you I was surprised.
I wouldn't say.
Super easy, but it seemed like it was a lot more simple than I thought it was gonna be to get started.
Is that kind of your impression when you first got started learning how to use it?
Mohammad Azam (guest): Yeah.
Yeah.
I started with the AR kit when it came out.
I believe it was a 2017, and it felt very natural at that time
because it was based on, I believe it was based on Matao Framework.
Which Apple bought or something similar framework I think that they bought.
And it was similar to Sprite Kit and Scene Kit because that's what it was using underneath.
And when RealityKit came out probably in 2019 with iOS 13, then it was a little bit different
because the underlying system was, the rendering system was different for RealityKit.
They were not using Scene Kit or Sprite kit, they had their own.
But the examples and all the videos that were provided by wwdc, like creating basic shapes and loading
different models into the augmented reality world, I think they were, they made it quite simple.
So definitely simple stuff is very easy to do.
But yeah, if you're doing like a very hard stuff, then all the math and calculus they come into.
Leo Dion (host): Okay.
Okay.
That's what I was, that's what I was wondering about.
Could you briefly explain the difference between the different framework?
So I get like Sprite kits 2D based, I believe.
, yes.
But then there's AR kit, scene kit and RealityKit, and I don't know
any other 3D based ones, but what's the difference between all these.
Mohammad Azam (guest): So AR kit, when it came out in 2017, they didn't really have their own rendering engine.
They were using the rendering engine from scene kit and Sprite.
Kit scene kit is like a three-dimensional if you want to create
those kind of game, like or tonal game like Zelda and Sprite.
Kit is more of a two-dimensional games like Mario and Pacman kind of things.
Okay.
So they were using those things to render.
And they were not really using any, I guess they were not using, really
using any hierarchy of trees and that kind of a structure to render things.
They were just using SCN nodes and Sprite kit nodes to render all the stuff.
And all the stuff that a AR kit was doing was based on what was provided by scene kit and.
Sprite kit.
So it was just leveraging the power of that.
But when RealityKit came out in 2019, they had their own engine.
They were, the top layer was still AR kit, like the AR view and everything, the gestures, they were all there.
But the underlying engine was very different with I think they were using their
own material stuff, the geometry physics, collision detection, and all those stuff.
In RealityKit and also all the different elements that you are adding.
They, I think Apple was automatically making them more metallic based, so they were lightning lighting system.
That was really nice in Realitykit,
Leo Dion (host): what do you think is like the biggest hurdle you had to get over when you were learning reality?
.
. Mohammad Azam (guest): I think the biggest hurdle for me was mostly based on
collisions, collisions with different shapes and one thing can collide with other
things can collide with this, but all of this was based on mostly about bit masking.
Basically you have to assign some sort of a bit mask to each of these shapes
that can collide with something and they cannot collide with other stuff.
I think that was the only small hurdle.
I wouldn't say it was a big hurdle.
I faced the same issue in AR kit and it was same thing, you have
to do big masking or category masking to do for that to work.
But that was not really big.
It was, it was like a small hurdle which which was fine.
But overall, since I already had experience with AR kit and I made courses on a AR kit and gave presentation
and all and wrote a book on a AR kit, I think for me it was a more of a smooth transition into reality.
Leo Dion (host): One of the things, and I don't know if this was with AR kit as well, but one of
the things that I liked that it I understood the convenience of what RealityKit brought to the
table was this idea of anchors where you can like, say I want this thing to anchor on the wall.
And then that way the camera automatically picks side up and puts your object on the wall.
Do you wanna explain that a little?
Where like the history of it,
Mohammad Azam (guest): yeah.
In reality, kid, if you want to add anything to the real world, you have to create an anchor.
You can think of an anchor, like a stationery it doesn't have to be stationary,
but an anchor is just a point in the real world where you will attach something.
Virtual and those anchors can be many different types.
You can have a plane anchor, like a horizontal or vertical.
So whenever a plane is detected, like you are looking at your ground or the carpet or a table, it'll create
an anchor for you and then you can put something on or attach something to that anchor so that like you
will have a glass or a coffee mug right on that anchor, which it's placed on the table automatically.
So that's one of the anchors.
RealityKit does provide you with face anchor, so something on your face, maybe
a mask you're wearing camera, anchor object, anchor image, anchor, body anchor,
and also world anchor, which means you can just put anchor anywhere in the world.
. One
Leo Dion (host): thing that I started playing around with getting ready for this call was Reality Composer.
Like that opened up a whole world for me.
I used to do, is it 3D Studio Max and what was the other one?
Maya I used to do that stuff in college quite a bit, so I'm a little bit familiar with 3D stuff.
But Yeah, reality Composer definitely gave me a little bit of those vibes, but it's definitely more
geared towards RealityKit, especially when you, like you said, you talk about anchors and stuff.
Do you wanna explain why someone would want to use Reality Composer?
Mohammad Azam (guest): Yeah.
Reality Composer is a design time or design oriented virtual, a, like a graphical user
tool or a graphical UI that allows you to create these experiences without writing.
many lines of code because you are just using drag and drop, you're importing
your own models, or you're using existing models, you're putting their animations.
Basically, you can do the anything you want.
So let's say that you're building a augmented reality zoo, which different animals.
So you can just create the whole zoo in reality, composer, and then you can
import everything into your project, like a RealityKit project and code against.
. So it allows you to create these experiences really quickly without having to,
for you to say, oh, the elephant, it'll be on axis is this, and Y axis this?
You just place it anywhere you want using Reality Composer and
using a design time tool, and it will, it'll just appear like that.
So it's really good for creating these AR experiences without having any knowledge of the underlying implementation,
Leo Dion (host): what's the, what do you get out of it?
What's what is an export?
Mohammad Azam (guest): I think it's a RealityKit file.
It is the, yeah, it's a composer file.
And then the good thing is that you can attach some events right inside your reality composer files
and you can get list or listen to those events in your code and you can do the other direction also.
So that's cool that if you tap on That's awesome.
Something that's awesome.
So if you tap on something, then.
Your code can handle that stuff.
So that's
Leo Dion (host): getting cool.
I'm getting interface builder flashbacks.
It's yeah, you could set up IB actions and yeah.
It's similar to that.
Yeah, totally.
Do you, what do you think is like missing out there when it comes to vr, ar apps?
Mohammad Azam (guest): I think we are still waiting for Apple glasses or apple goggles for at least for the ar
because some of these experiences might be okay on a phone, if you have a measuring app or these kind of things.
But it still creates that kind of it, it's not seamless experience.
, once you wear those glasses or goggles, whatever, apple is gonna come out.
And then you will be able to see instantly what's going on in the AR world.
You can create some timers, maybe you can have a virtual display and you don't really need big screens anymore.
So everyone will be wearing glasses and looking at a.
A hundred inch TV or something.
Leo Dion (host): Have you tried creating like your own productivity, like todo app using RealityKit and
just see if you could mount your to-do list on the wall using your, with your phone or anything like that?
Mohammad Azam (guest): I did the measuring app and I did the graph like creating like a chart bar chart graph.
Okay.
And that looks, that looked really cool.
Yeah.
3d.
Yeah.
Leo Dion (host): Yeah.
I think, yeah.
I was gonna ask you about The future, but you answered that already.
Do you I don't wanna go, I don't wanna jump too far, but was , this is probably a silly
question, but I'm gonna ask it anyway since we're gonna talk about architecture later.
Was there.
Did you try anything complicated as far as architecture?
Like when it came to your RealityKit stuff and oh, I want this to listen to this,
and then I wanted to pull this information from a database or anything like that.
Mohammad Azam (guest): For RealityKit, I think for ar kit codes, I did try
a lot of complicated things like even persisting the location of the object.
Okay.
So you can just persist the actual location and you can.
Close your app, kill your app, start again, and your furniture will be right there.
Okay?
And Apple.
Apple does provide that.
The api, it's not.
. It's not as nice as I would like to be.
But fire based platform also provides similar a api, but that's like slow because it's in the cloud,
still it's not perfect, but yeah, it's definitely, and then I made like those racing car games.
So you're controlling a virtual car in augmented reality.
and you're just moving it up and down and all that stuff.
That was cool.
Leo Dion (host): so yeah, let's talk about something else you've been working on recently.
You've been doing I don't know, research, I guess you could call it, into Swift UI architectures for large apps.
, because those of us in the real world don't just build donut shops and smoothies.
We need something a little bit more complicated.
What's been your, first explained what you've been doing and then what's been your
biggest takeaway from what you've been looking at as far as SWIFT UI and architecture?
Mohammad Azam (guest): Yeah, so for the past, I would even say eight to 12 months for the past one
year, or when Swift UI actually got announced in 2019, just like everyone else, I jumped on the
MV VM bandwagon and I wrote books on it and articles, and I start publishing a lot of stuff on it.
And I was not really never happy with the end result because even for a very small app for four or five
screens, I would create that eight or 10 different view models inside view models and something crazy and.
It was just not working out.
So I started to talk to other people who were having the same issues and
they were talking about the same thing, that this is not the right approach.
And I already told them that I invested a lot of time into this.
I wrote books on it so I could take courses on it.
So it's weird for me to go that route.
But eventually, yeah, I, I looked at Apple samples, read some posts online, talked
to a lot of people, a lot of, much smarter people than me, and they like guided.
, look at like how things are in different worlds.
If you see React, if you see Flutter, if you see any other reactive platform, they don't believe or they don't do this M
V M stuff because their view itself has a capability of binding, using state binding, state object, environment object.
So you don't really need that extra layer in most cases.
So once I got into that, I looked into Apple.
Sample codes also, which is Fruita app and food truck app.
And I started creating hundreds of prototypes.
So over the course of maybe three years, I created more than like
150, 200 prototypes, different apps just to play around with.
And once I start using, just removing the view model there and just talking model and the view.
It started to make a little bit more sense.
Now, just to be clear, I know a lot of people will be like you're putting your logic in the view.
No, that's not the MV pattern.
That is a container pattern.
So you, you're mistaken in that point.
And container pattern, by the way, is very common and in react JS applications.
So that's perfectly fine to use if you want to use that.
So my research and I wrote a really long article also about building.
These kind of large applications.
One of the things of my researcher, the biggest takeaway is that don't fight with Siri.
Because if you are fighting withs UI or if you're fighting with any framework,
you are gonna get into trouble and you're gonna end up writing more and more code.
So a lot of people I talked to, they were like, we are not gonna
use this fetch request, property wrapper section fetch request.
We're not gonna use environment.
We're not gonna use this and that, and they have to write hundred and
200 lines for every single thing that Fetch request was already doing.
And we had, I think, the presentation from N Spain also, they did the same thing.
They said, we went to the our own route, we created our own architecture.
But then we came back because Apple told us our app is like a
hundred times or 10 times more, like slower than the competition.
So those were my biggest takeaways.
. And I think another thing to note over here is that for, you can't just mold your app with one single
architecture, but you can, you can design your app in a way that it works best with certain architectures.
Like for client server application, I usually just use, which I like to call MV pattern.
I don't think that's official.
, but I use MV pattern.
But for code data only application, I try to use active record pattern because
it feels more natural to me but it might not feel natural to other people.
For simple apps, you can just use container pattern, which is no view models, no models.
Just write the code.
In the views and pass the data down to the child elements.
So that is what my takeaway from my research indicates.
And I'm pretty happy with the stuff that I'm doing now because it's much more, streamlined much more nicer.
And it is another crazy thing that now I see a lot of people moving in similar direct.
We have YouTuber, I don't know if I should say names or not, but we have
YouTube YouTuber, like Stuart Lynch, who's a YouTuber, very famous YouTuber.
He's also moving into that direction.
If you see his latest videos, he's moving into a direction of no
view models, just talking to the right, talking to the, data store.
I think he calls it Data Store, but if you see his latest videos, he's also doing the same.
underscore.
David Smith, very famous podcaster and developer also said similar
things like, don't try to fight the system, don't fight the framework.
John Nel also in his latest podcast, said the similar things about not using too many view
models, and then I think another YouTuber flow write code or something he's going with more of.
view only, which is basically a container pattern.
So everyone is realizing eventually that they might be writing a lot of
code to achieve less, and that's why they're also researching into this.
So
Leo Dion (host): like you have here a store model, . So I just wanna clarify a few things.
So is the store model, is that your model or your view?
Mohammad Azam (guest): So people like to, yeah, some people can call it like a view model or
something, but I just like to call it a model or aggregate model because Okay, if we are, but the
point over here, and that's an important point, is I will not have a different view model for every.
because whenever people look at store model, they're like, oh, you just name your view model to store model.
So that's it.
That's what you did.
No, that's not what you did.
What we did, or what I did is I completely removed 10 or 12 view models that you will create, and
I just replaced it with something I call aggregate model, and that will be used by all the views.
So that's a very important part.
.
Leo Dion (host): Okay.
So that's
I don't know cuz I, I think like I'm moving away from having a singleton, environment model in my app.
What I've found is going back to one of the biggest takeaways you had was the modular modularization part.
Is I had a hard time breaking.
that apart when it has to do a lot of things in an app.
. But I'm not sure, like I, I'm, I think what I'm saying is probably not what you're
doing, but like sometimes you can have too much of a singleton if you know what I Yeah.
In an app when it tries to do too much stuff, , would you do like maybe multiple
environment models within your app, or how would you handle something like that?
Mohammad Azam (guest): Oh yeah.
So in my latest article, which is for building modular application, like for large scale of.
I started with one store model, but then eventually I talked about this is not gonna work in large apps
because what about a store can do shipping and handling and catalog and inventory, fulfillment, payments.
Where you gonna put all that stuff?
Yeah.
Okay.
You can put it in one file.
So that is where your domain expert is gonna help you out and break these things into multiple models.
Like a catalog model.
A catalog model will be giving you.
the products and the product line and yeah, that's what I'm saying here.
Something about the product.
Leo Dion (host): But goes back domain, domain driven design.
Domain driven is where you have each model, each of you model, aggregate
model, whatever you wanna call it, broken up into each domain and then Okay.
Yeah.
How do you communicate between each of the models if you need to?
Mohammad Azam (guest): So each of these models or aggregate model, they don't directly communicate with each other.
But since they are using a service, let's say the client service application, some sort of a web
service or a client, they will just ask the client to get the data and they will get the data.
Okay.
And if the view needs catalog or if the view needs stuff from two different aggregate.
Then the view can use two different environment objects or state objects, whichever one it needs.
I'm just giving example for state environment object.
But it can be a state object also.
That's fine.
Leo Dion (host): Yeah.
Yeah.
What I was gonna ask that, so sounds like you use an environment object just cuz . There's a lot of
convenience that comes with that because once you do it once in your app, it's used throughout the app.
Did you see any benefits of going with a state object in some cases?
Oh yeah.
Memory wise or optimization wise?
Mohammad Azam (guest): So state object or even removing the state object.
Sometime you can even use just the state, meaning like just the state at state which React actually does that.
And we can also do that.
So if you have a.
Just one view and it's that view is saying I'm just gonna list you all the
inventory items, and that's the only place where you are gonna display that.
Then just fetch it inside the task modifier, using a call to
whichever service, and then put it in a state and you're done.
So that is perfect.
Yeah.
Or you
Leo Dion (host): could just fetch it.
Fetch it, and toss it into another view as a let struck, and then you don't even have to do a state or a va.
Yeah.
Yeah.
That's a good point.
Yeah.
So I think depends like , when we d.
We did our episode with Aviel.
I don't know if you saw his talk too, but one of the things is
keeping things as simple and as minimal as possible that you need.
If you're not gonna write to it, there's no point in using any property wrapper on it.
And if it's only gonna be used within your thing, and that's where you're getting at state object.
State, yeah.
Yep.
Absolutely.
Okay, so here's the hard one.
I didn't see any combined.
There was a lot of tasks.
, use of tasks in your app.
Did you try combine?
What was the shortcomings there?
Was it just too complicated for what you need or what or do you see for you it's oh, I
just prefer using async in a way with tasks and some cases combined might be a better.
.
Mohammad Azam (guest): I think there were some cases where you can use combined, not in the examples that I
have posted over there on the article, but I was using mainly Async and weight and inside the task modifier.
That was perfectly fine.
I think one of the re one of the ways, or one of the places
where I used combined was I believe when I was trying to access.
an event that was generated from my so UI application into my UI kit application.
So that is where I was using sync functionality of combined to hook, hook it up like some sort of an event.
But in daily programming or when I'm writing apps, I usually don't use Combine unless it's necessary in those situ.
. Yeah.
Okay.
Leo Dion (host): What I want to talk a bit about what's your opinion is like the difference between a screen and a view.
I wasn't totally clear.
On that.
Is it that you like, it's a screen more of a composite of multiple views and a view Yes.
Is just an individual object attached to a state?
Is that kind of the idea?
Mohammad Azam (guest): Yes.
Yes.
So screens.
In react terms, they call it like a container, I guess a container view.
And views are just reusable views, so screens basically will be movies, lists, screen screen that lists the movies.
But inside that, you might have a movies view where you pass in an array of movies.
And the movies view display the movies.
So if you have a filter or something that will go in the movies list.
And then filter it and then pass it down to the movie's view.
Okay.
Leo Dion (host): Yeah.
Yeah.
I mean it's like I've done VJs and it's the same idea with like page and cbo.
Yeah.
Is the same idea or page and whatever it's page and yeah.
We're like, It's just a collection of views and like we've talked about, you wanna keep your view as simple as possible.
If you have more than, I don't know, what's a good number three property wrapper
wrapped properties in your Swift UI view, you probably need to split that up.
In my opinion, I think that's maybe a good code smell there.
. One thing I've been dabbling with is air handling.
. I think you have a pretty good.
Example in your thing where you use air wrapper.
I've started playing around with using alerts.
Alerts.
I think it's an iOS 16 natively support a localized error, so it'll automatically display the error for you.
I don't know if you've looked into that, but I really like what you did here with
with kind of just having an error view and then you have a shared error state.
Is it a shared error state throughout the whole applic?
.
Mohammad Azam (guest): Yeah.
So I usually just inject it as an environment object.
And in the app file, which is like your starting point of your SwiftUI it is
at that point I use a sheet or some sort of a overlay to display the error.
So I have one place to display the error only.
Yeah.
Leo Dion (host): And that displays it over the whole app
universally as opposed to having an error display in each of you.
Okay.
Yeah, I really like that idea.
That's really clever.
Yeah.
I wanna talk about something new from this year.
And that's navigation.
Oh yeah.
Did you work on this before the updates to navigation or afterwards?
Mohammad Azam (guest): On the article I worked.
Yeah.
Yeah, I worked this article, I think it's focuses also on I 16 navigation api.
Leo Dion (host): Yeah.
Yeah, because I, yeah, I was really happy to see that.
And the article was all the navigation stack stuff.
, did that change a lot or help a lot with what your research was showing you,
Mohammad Azam (guest): no, I have been doing the same navigation,
like for iOS 16
Mohammad Azam (guest): that's as early as when it came out.
So the, in the article I mentioned that I'm doing more of a global, we start with a
small navigation okay, one enum with home log, login and register, or something like that.
But what about larger screens or larger apps where you have a nested
navigation, like a catalog home and catalog product and all that.
So you just have to structure your enum in such a way that you can go from one navigation to the other.
And I think in the article I mentioned that how to do programmatic navigation.
So you, anywhere in your code you can.
, add something to the navigation path and it'll go there.
And so
Leo Dion (host): Do you have like just a you have an en enum in those larger apps
where you have associated values for the catalog product item or a particular thing?
Or do you use a pro, like a protocol and then store that in array?
How?
I'm not familiar with all the new stuff with navigation slack, so I'm really curious how you broke that out.
Mohammad Azam (guest): Yeah, I think in my article I have a base enum, like the parent Enum.
Okay.
Which contains some other enums.
I don't think they need to contain other enums, but they contain I think we have routes and
that contains some other enums like catalog routes and inventory routes and all that stuff.
So you will eventually have an array of route.
and since Route is an enum, which can contain other cases or other enums.
Then other cases like catalog and inventory, then you can manage to go to those places also.
So in the end, I have an array of routes and when I add a route to it, it goes over there.
That's it.
Okay.
Leo Dion (host): So basically it could be, you could navigate anywhere, like
within your route you could go from a catalog item to an inventory item to Yeah.
Back to home.
Okay.
Interesting.
That's cool.
I like that.
And that, that's, that array is the navion, literally the navigation stack or the nav?
The, an old parlance yes.
Navigation controllers.
List of view controllers.
Yeah.
That's a navigation stack.
and that's stored as a, either a state object in the app or an environment object stored throughout The application.
Mohammad Azam (guest): Yeah.
I'm storing it as an environment object, but I think if you have a
very large app and if that app has a catalog part and fulfillment and.
Some other part, then you can inject it in that particular root
of that view instead of the complete root of your, the whole app.
So you can do that also, but for the sake of simplicity, I just injected it in the root of the whole app.
Leo Dion (host): Yeah, that makes a lot of sense.
What do you think, one thing I want to talk about, and I think something you, you talk.
And I think it's really important is testing.
, what do you think are some big things that people are missing when it comes to testing large Swift UI apps?
Mohammad Azam (guest): I think one of the things that is available in Flutter and is available in React
GS and it's not available in Swift UI, is how to test the views without writing and end-to-end test.
In Flutter you can do widget testing.
In React, you can do view testing.
I think that's what they call it, react view testing.
You can just mount the.
And test it out, but we cannot really mount the view and test it out.
So we have to write the whole end-to-end test to do those kind of tests.
Now, one of the things I noticed, if you have logic in your view, like which is
only for the view itself, you can quickly test those logic just by export previews.
So most of the time you don't have to, do something complicated to make it testable.
You just write your logic.
UI Logic in the view, if you want sorting and filtering, you can do that over there, depending on the case.
Sometime you can do it in the model itself, but you can quickly test
it out in the export previews, and that also works in some situation.
Now, if you're filtering or sorting is very complicated because it's based on so many different
options, probably it'll be a good idea to move it into the model object and to write the test.
Leo Dion (host): Yeah just going back to talking about combined and stuff that's where I've
moved My testing is I test my combined to see and unit test, I'll test my combined there.
But it's interesting to note like how flutter and react test, test the views.
I've never I've never understood how that would be, but that would be
really, I would be really curious in, in that perspective on how that.
.
Mohammad Azam (guest): Yeah.
For, I think for React, I think there's, they just mount and they create a
shallow copy of the view and then they can click a button or whatever they want.
It's like a view inspector in the end, I guess you can say that.
The View Inspector tool, it's similar to what React Andra are doing, but it's official.
Is it like you,
Leo Dion (host): is it anything like UI testing?
No, it's
Mohammad Azam (guest): next.
No, it's basically it's basically the view inspector tests are mostly like unit testing.
So you are basically performing a unit test on the UI without launching the whole app and all that stuff.
So it's much quicker.
But I would, yeah, if I have to do a.
Then I would, depending on what I'm writing, obviously you should unit test
your models and if you're using view model unit test review models, yeah.
But if you want to unit test or if you want to test your ui, then the UI test is a much better choice
because that is actually going to click a button, actual button and not simulate clicking a button.
So that's definitely helpful.
Yeah.
Leo Dion (host): Was there anything else you wanted to talk about when it comes to Swift UI architecture?
Mohammad Azam (guest): I think that's yeah, I think we covered a lot and use the best architecture.
I think I'm just gonna say use the best architecture for your needs.
When I was doing MV pattern and I tried to apply it to my core data applications, although it was
working and I have a course out for Reminders app that's using that, but it didn't feel right.
It was just a feeling that, oh, code data, like an om, I know it's not an o r.
, but maybe active record pattern would be a much better choice.
So maybe I should do it that way.
So it's all about the feel.
Yeah.
Leo Dion (host): I think too, like people are too stuck on oh, this is architecture.
I'll use it throughout the app.
That's not how architectures work, especially on large apps.
It's in this part we'll use mv or in this part we'll use this, and in this
part we'll use this pattern and you connect all those pieces together.
I think once you've understood that I think it just, it becomes a lot easier.
Yeah.
And for me it's like testing.
Can you test it?
If you could test it, that's a pretty good, that's a pretty good start on our architecture pattern.
Sure.
. We'll post a link to your article.
Definitely check that out.
Lot of great tips.
Awesome.
Was there anything else you wanna talk about before we close
Mohammad Azam (guest): out?
I think that's pretty much it.
Thanks.
Again, for having me.
I had it was a lot.
Leo Dion (host): Yeah.
Yeah.
Thank you for coming on again.
It's good to see you.
Hopefully I'll see you in person soon.
People can find links to your RealityKit stuff and that article.
Where else can people find you online?
Mohammad Azam (guest): Yeah, you can find me on Twitter.
I am at adams sharp, a v m f h a r p, and you can visit my website.
Aum sharp.com.
Leo Dion (host): Thank you oum.
Again, people can find me on Twitter at Leo g Dion.
At Leo g Dion C Im on Macedon, Leo g Dion on LinkedIn.
Bright Digit, the name of my company.
Please, if you're watching this on YouTube, I can subscribe.
I'd really appreciate it, and if you're listening to this on a podcast post a great review.
If you, there's something you wanna come on and talk about, or there's something you want me to talk about, let me know.
Feel free to DM me.
I hope you have a good rest of your day and we will talk to you later.