Welcome to another episode of Empower Apps. I'm your host Leo Dion.

Today, I’m excited to be joined by Mohammad Azam.

Mohammad, thank you so much for making the time to come on.

Thank you for having me, Leo.

You're otherwise known on Twitter as Azam Sharp,

but I'll let you go ahead and introduce yourself before we get started.

Sure. I started programming awhile back with asp.net, .Net, and all this stuff.

But for iOS world, I joined in 2010 when my colleague introduced me to Mac

and iPhone, and all those cool things with Objective C.

And from there on I started learning Objective C with all those memory management,

manual memory management stuff with 3.2 or 3 point something at that time.

Fast forward to today I have been teaching online on Udemy as well as on YouTube.

But my main job is to be a coding bootcamp instructor for a company called Digital Crafts where I teach web development

which includes JavaScript, Node, Express, React, Redux, PostgreSQL, and all these kind of things.

So that's what I'm doing these days.

Awesome. I'm so glad to have you on.

Today we're going to be talking about one particular thing that you've been...

You have a new Udemy course I believe on server-driven UI.

Do you want to explain what that is before we get started and jumping into how it works?

Sure. The main concept behind server-driven UI is that instead of only the data coming from the server

which you can just display on your iPhone app,

you are also be getting data plus the components that you want to display on the UI.

You may want to say that the server is going to send a carousel control or a carousel

framework or anything like that, like a JSON respond which includes carousel.

You want to display a carousel and the server can decide that

I want to display a rating control which will go from 1 to 5, or 5 to 10, or whatever.

The main idea of the server is not only in charge of the data that your app will display

but also the components, the views, the actual small widgets that you want to display in your application.

So that's the basic gist of it.

So if I’m understanding this correctly like...

Is there a certain use case where this might be a good fit as opposed to others?

Sure. This is a very good question because this is not for all the different apps that you're going to design.

This is only for very, very particular kind of apps that require a dynamic interface

that needs to be changed quickly without going through the trouble of app review and all those things.

It’s also very, very beneficial for those apps that are available on many different platforms.

So if you are a very big company and we can take example of Uber, Airbnb, and Spotify

and they have apps on iOS, Android, and web.

And they want to update the apps all of them at the same exact time instantly

then they can use this approach without publishing one version on iOS app store,

one version on Android, and one deployment for web.

They can simply change the structure the server is returning

and all of the clients (iOS, Android, and web) will immediately be updated.

So it's very small set of apps that will need this kind of feature.

I'm not saying that your app may not be the one because maybe some parts of your app will also need this feature.

So it doesn't have to be 100% meaning your app doesn't have to be 100% server-driven.

Maybe parts of the app are server driven and parts are just normal app.

It seemed based on some of your content, and Airbnb was the big article

I saw on medium where they had really proposed this idea.

It seems to me like a good situation is where you have tons of dynamic content that you kind of have...

For instance, Airbnb is a great example. We'll use that.

But you might have a place you want to rent out and you might want to add a widget for certain rentals.

That might make sense to where you code the widget in Kotlin, HTML, or Node, or Swift.

And then, you have the server side just give you, “Hey, we need this particular widget here”,

and then it knows how to render that widget out on each individual operating system.

That’s it where you large amount of content and where you want to customize, have a template,

and then each individual OS designs it, or platform I should say, renders that out correctly

based on when it gets back from the server. Does that sound about right?

Yeah. Just one thing to keep in mind is that all the widgets or components which you're trying to render

they should already be part of the binary that you distributed to the app store.

Because all that's... Basically what you're simply changing is that...

The server is simply saying that, “Oh, on this particular page now I don't want to display the rating control.

I want to display a drop down list control.” But that drop-down list and the rating control

must already be part of the binary that you have deployed to the app store.

So you're basically changing the ordering, changing the color or some features,

so those things you can do on the remote side meaning the server.

What got you interested in this particular topic?

I've always been a server or a back-end developer with my days in asp.net and back-end development with all the stuff.

And these days also I do Node development, Express, and all of that. Vapor also with the server-side Swift.

I was always interested in these cases. And if you can believe it we actually implemented this

back in 2005 and 2006 but not using JSON.

- We did it in a very weird way. It didn't really work out because we're actually...
- XML?

XML. We were storing XML I think for part of it there were some pages that were just pure HTML.

They were in databases and it was very hard to obviously edit when you have pure HTML in there.

But, yeah, we did it in XML.

One of the big use cases like you said is the cross platform ability too.

And I agree completely. We did an episode on cross-platform development with Rob Kerr a couple of years ago.

To me this is the ideal. Instead of React necessarily or whatever other flutter you might be using,

this might be the best fit for a cross-platform situation just based on what I've seen so far.

Are there any other good use cases besides that that you can think of?

I think the other use cases for this apart from being able to change the interface remotely

and able to deploy instantly on different platforms it definitely helps with AB testing.

Because all you need to do is to simply

view a different version or change the URL and now the client, meaning your iOS, or Android, or web apps,

they will be getting a completely different look and feel.

You can test it out without deploying or doing those weird things that you do with AB testing

like deploying two different versions and all those kind of if checks and all that stuff.

Without doing all of that you can simply change the version URL and now

two clients will have two different view of the same thing and you can test it out which one works much better.

What are some cons that you can think of with going into…?

What would you say to someone who's like I really want to do this?

Well, there are some things you should think about before you jump into doing server-driven UI.

Yeah. One of the things that is very important with server-driven UI is that

your different teams have to work very, very closely together.

If you have a server team which is completely different from your Android team, iOS team, and web team,

now all of those teams should have team meetings together because they have to come up with some sort of a template

that the server will be returning. And that has to be approved by the server team, iOS, Android, and web team

because all of them will be using the same exact template.

So that has to be constructed and that is one of the things that will take a lot of time

to construct this generic page template.

I want to deep dive into that a little bit more.

What are some other things that teams should be aware of when they're managing something like this?

You said having the same template language, right?

Your JSON has to be a specific way and the server has to spit it out and

and the Android, the web, and the iOS folks all have to be able to parse that correctly.

Is there anything else you can think of?

I think from my… When I was working and obviously I was only working with the iOS apps,

my main concern was the decoding strategies that I will have to use to decode those things.

Because there were a lot of cases where

the template that was being returned from the server, and I was controlling the template also, it was...

You can't really decode it to like a string and any because any is

you can't decode that part because any can be anything.

- Right.
- For that I have to create a

completely a different type like a JSON type or any decodable type which will decode it to some other type.

That was a little bit of a hard part to implement those custom decoding strategies. So those have to be done.

The other thing I was thinking of was doing an enum with an associated type.

So you have widget A is something and then you will one way or another

you're going to have to do some work with manually setting that up.

Yeah, yeah.

What other architecting tips do you have for something like this?

I think the first thing to understand if you're planning to go with this approach

you don't have to take the deep dive into just okay we're just going to do everything, the server-side Swift.

You can't completely think about what portions of your application are supposed to be server-side.

So one of the examples that I always use is that

whenever you're displaying some data especially the read-only data maybe you're displaying some

pet store with some pet adoption pictures, and those kind of things with advertisement on the top,

or some ratings and everything. The read-only portion is a very good example of

that can be done easily with server side because it's just read-only.

You can move up and down. But whenever you go into taking input and processing that input

especially with the SwiftUI with bindables and binding and passing state values

then it becomes close to impossible to do those kind of things because if it's...

It’s basically you’re just rendering those controls that your server is returning you

and you just don't know which control will take what. Some controls maybe just

presentation controls while other controls take a binding expression and that's just not possible to do.

So mostly I have used it for read-only views where you're just dynamically changing the view order.

And that's one of the things that I was thinking about too is there's a granularity to this, right?

You cannot really code this to the tee as far as how much control you give to the server

and then you could also just, like you said, take a step-by-step approach to migrating it over.

Oh yeah. I mean, another example that I implemented in the course also is the list example.

A very simple list but each cell of the list can be very different and that is controlled by the server.

So one cell can be just a text row meaning it just displays the text information

but the other cell of the same list can be the one with the image and the rating and some other stuff.

You can go to that small granular level if you want to.

But the more you go there it becomes more complicated because now the server needs to return different types

and you need to make sure that you conform to what server is returning.

And what your HTML client can do, your web browser can do, what Android can do.

Like you said, you want to take a really basic approach.

I like the idea of doing the read-only stuff first and just hammering that out.

If you’re going to do this today,

would you choose UIKit? Would you choose Swift UI?

What are the benefits or drawbacks of taking each approach in iOS development?

I think you can use either UIKit or Swift UI. But if I had to do it I would choose Swift UI because

the declarative nature of Swift UI just makes it much easier to create those very small one thing to do components.

That's why I would always use or I would use pretty much Swift UI for these kind of things.

Although it can be done with anything.

And if you're using Swift UI you will get one step closer for web apps if you're using React

because React with UI kind of like the same.

And if you're using Android or you're using Flutter for Android then you're

pretty much in the same gist of it because React, Flutter, and Swift UI,

they're pretty much the same structure that they work together.

I mean, not work together but the same thing declarative nature.

It’s composable. What’s the thing in Kotlin for doing Reactive development?

I forgot what it's called. Composable UI or something?

- I think Jetpack.
- Jetpack. Jetpack Compose.

Jetpack Compose you can use that which is similar to Swift UI and all of that stuff.

Definitely all of them will be declarative nature. I think another thing which I forgot to mention is navigation.

Because in Swift UI, navigation is one of those things that people don't like

that they have to put the navigation embed in the navigation somewhere.

So using the server-driven UI you can actually change or control the navigation from the server

so you can say that, “When I click a button I don't want to go from A to B. Now I want to go to A to C."

This particular view, A to C.

And you can do that. You can even change the navigation type.

Meaning, do I want to perform a push navigation, or do I want to perform a modal navigation, or a sheet navigation.

So you can control. You have those things you can control from the server which is actually pretty cool.

Yeah, I was going to ask about that. Because that's one of the biggest drawbacks

I've seen with people is the lack of dynamic navigation in Swift UI.

You haven't seen a lot of friction as far as that's concerned using Swift UI and server-driven UI for that?

For Swift UI in general and not talking about the server-driven UI, yes.

As you said there is no correct way of doing a navigation thing.

It always comes in the way because there's no central place like Flutter or React

that you can put all the navigation part.

There are a couple of different ways you can do it in Swift UI if you just keep your components very much

rudimentary or very basic. It always gives the parent the control to where to go or where to perform the navigation.

You can do on those cases but the amount of code you have to type increases 10x whenever you have to do that.

Now, with the server-driven UI, all the navigation, everything which we call actions are on the server

and they are translated to navigation links and all that stuff which is already in Swift UI

so we are able to change that from the server.

That makes sense. One of the things I saw in your YouTube course preview

was the use of type erasure and having to do any view.

Was there a reason why you had to do that when it came to server-driven UI?

Yeah, I had to use any view because I didn't know what view is it going to, or which component as we call it

in server-driven language, which component or view is going to return.

Because we had different kind of views like rating view, list view, grid view, and some other view.

You can try to use view builder if you want to but that approach didn't work out over there.

Okay. When I've done stuff with Combine I've always ended up having to do type erasure because

if I start sticking with the actual type name, it's going to be a mess because of all the different generics.

I think I understand where you're coming from when it came to Swift UI and server-driven.

It’s like, yeah, you could specify some view and do it that way but now you have to like

carry that type, and it's a pain in the neck. Yeah, okay, I get where you're coming from.

What are some gotchas when it came to server-driven UI as you were developing with it?

I think one of the things which I didn't solve or wasn't able to solve was the same thing that we mentioned.

I mentioned with the binding part of it.

Meaning, if one of your views takes in a hat binding expression which changes the binding

which will reflect or trigger something in the parent.

There's no correct way to pass binding because it's literally in the server-driven UI it's

it's just a loop running and it's just rendering all the components without passing anything to anyone.

So that was one of the main things that I wasn't able to figure out.

And the other part which is very important is versioning.

What will happen if you add controls or you change your JSON or the server changes

or sends you a different JSON but the client is not supported.

You have to think about those cases. Now, there are many ways that you can solve that.

One of the best ways I think is the server will know what version the client is running.

The client will only request that URL and the server will only give the client those components

or controls that are okay and accepted for that particular client.

- Okay.
- Yeah.

Do you like...

How do you set up a new component?

Because you'd have to make sure everything is in sync with the app store and deployment on the server.

How do you arrange that mechanic?

Yeah. If you are creating a new component, let's say, I'm adding a new carousel component

then I will physically have to deploy the app to the app store.

Once the client downloads or updates to the new version, they will get that component

and their version number will get updated from one to two or whatever.

So that we know that this person is on version 2. We should give this person all the components which are supported.

Okay, the other thing, I was thinking about this is like fail safely.

If they have a component that you don't support just don't show it.

That was kind of my thought too. Because you have to make sure, okay, I deployed on the server quickly.

Hit the release button or release the version of the app before the component is like...

Yeah, right, it's tricky for sure.

We kind of covered this but were there gotchas on the server end that you recognized

when it came to supporting something for multiple platforms?

From the server side, I think the main thing was always been to design a very generic template.

That was the main and the hardest part because it has to be approved

by the iOS, Android, web team, all the team, the server team.

and you've to come up with some sort of a URL as well as some sort of a template that you'll give to the client.

Apart from that and apart from the versioning issues which can be solved on the server as well as on the client,

the server becomes the easy part to implement in these cases since it’s a…

Well, I guess another question which came was if you're returning the UI

meaning which components you want to render as well as the data associated with those components,

should we make two calls or should we make a single call?

I ended up making one single call which will return you not only the components that you want to render

but the data associated with those components already filled out.

- Ah, yeah.
- Yeah.

Well, it almost gets a little like what is the component and what is the data, right?

You are like what's really the separation there as far as like...

Well, I guess the question that I was going to ask is how do you make sure when you design your app

on each platform that it's still not designed in too generic of a fashion?

If you know what I mean, like, you want your server-driven UI to be agnostic enough

to where whatever info it gives the client

if it is iOS, maybe in some cases you want to toggle in the web, maybe you want a check box.

Like it's being agnostic enough to where your design is still looking as it's supposed to

as opposed to being way too generic.

You have one of those iPhone apps where you're like, “Okay, yeah. They built this in React native

without really thinking through how it's supposed to look on the iPhone and what are the best practices”, right?

Yeah. I think that's, as you said, that's the one of the best things that I found about

server-driven UI is that server is only returning you the JSON. And the client,

meaning the React app or Flutter app or Android app.

they're the ones building, consuming the JSON, and then deciding that, "I need to create a rating control."

"I'll create it the way that I want to create it."

So those components will be...

native to the web platform, and Android platform. Whatever they're implementing.

Yeah. And that's something you probably want to circle your design team into if you have one,

“Hey, by the way we have this component for rating. How should it look on Android?

How should it look in iOS? How should it look in the browser?"

Yeah, absolutely.

What other errors might you run into besides versioning issues that you should probably think about?

I think one of the most common is what happens if...

in no WI-FI situation or the server isn't responding correctly?

Meaning, it's just down or being updated.

In those cases, the fallback is only you can display some sort of a local template

which is saying that a local view which is unable to connect to WI-FI

or things like that because there's nothing you can do.

Unless your app is caching that particular JSON or for some reason the actual template

then you can revert back to that. But obviously it will be displaying some old information

and may not be relevant in the case that you are implementing the app.

You obviously don't want to display

stale stocks or cryptocurrencies information or some sort of these time sensitive information.

Right, right. Or at least have last updated app, right? Something that indicates.

What made you want to… So I watched the really good course that people should definitely check out.

One of the things is you developed it using Node and Express.

What made you to make that decision and what were some interesting things that you found

as you were developing using that for your server-driven UI?

Yeah, great question. I mean, you can use any server platform that you want.

You can use Vapor or Ruby on Rails, Django, whatever you want.

I chose Node and Express because that's what I teach every day to my students.

- I'm pretty familiar with that.
- Okay.

I also chose Node and Express because it's a very mature framework

as compared to, let’ say, Vapor. I mean Vapor, is great.

But I would choose Node and Express over Vapor at this point because Vapor is still continuously changing

which is a good thing but if you're implementing or you're creating your data, I mean the back end,

you want something a little bit more not that fast-changing thing.

But you can use Vapor if you want. I simply chose Node and Express because I teach it every single day.

I'm familiar with it. It's very easy to deploy.

Actually, you can write the old Node and Express app on glitch.com

which is already deployed basically so that's a good thing.

And one of the things which you may have already seen in the course

is that I started with creating a very simple app using Node and Express,

but then I quickly switched to just a local JSON file so that I can do iterations,

multiple iterations much faster instead of consuming or doing those HTTP calls.

One of the things I've been thinking about is…

So I redesigned the Bright Digit website by the way pretty recently.

People should definitely check it out. I designed it, I wrote in Publish.

Sundell’s static site generator. And one of the things I've been thinking about is,

what if I have it output just a JSON file and then I build an app that consumes that,

and it is a Bright Digit app, right? So you can almost convert it from a

website to an app just using this but without the dynamic web calls because it’s just a JSON file.

That’s been in the back of my head as something to play around with as well.

We talked a little bit about decoding. Was there anything else you wanted to mention?

Sounds like you did more of a string any type and I mentioned associated enums.

Anything else that you ran into when it came to decoding your JSON?

No. I mean, that was a little bit of a hard part because when you're returning from the server

your keys will be in string. We already know that or most of the cases. But the value can be anything.

I could have used your technique with the associative types.

I use like a creating any decodable type, or struct, or something and

and you have to do a manual decoding process which was kind of painful

but it worked out in the end just fine because it was able to decode anything you give it.

It will decode it to a dictionary, and then from the dictionary I can convert it to any type I want.

What are some ways that you would recommend approaching testing with this stuff

both on the server side and on your individual client side?

For the client side it's recommended that instead of starting with the server you start with a local JSON file

so that you can come up with a nice template or generic template for your

result that your JSON service is going to send you.

So instead of implementing the service just come up with a template.

See if it works. It will be obviously much faster because

it's a local file as compared to HTTP requests to a server.

And you will go through those iterations much quicker.

Now, when you're comfortable with the first version of your JSON structure or whatever you're going to return

then you can move on to the server part. And from the server part I think the only thing you have to

apart from sending the right data and the right content like the components or structure of the components,

you have to just make sure that the URL that you're using that makes sense for your server.

And also you have to make sure that the versioning is correct and you're sending

the correct components and the correct response for the client that is requesting.

So if a client is version 1 don't send that client components that are only for version 5

because that's not going to work. It's not going to show anything.

Right, right.

And then just make sure your app doesn't crash if it gets a component that doesn't work.

- Oh yeah. Definitely.
- That's the last thing you want to deal with.

Absolutely.

I remember a while ago. I don't know if you remember this. I don't know which app it was.

but somebody had put out a library that you can design the whole entire app on the server.

I think they essentially had it like take down by Apple in the app store.

What I remembered about that was

they had it down to where the whole entire app could be designed on the server

and all the app, the actual app code did was just render it out. And I think like

a big difference between this is the app doesn't really change. It can't be just changed on the server.

It's more or less the components are already pre-defined on the app

as long as you're giving Apple the consistent experience you're pretty much okay.

Is there any other app store gotchas you might want to worry about going with this approach?

No. I think you nailed it. You're absolutely right because

we're not really changing any logic or anything of the app.

The logic is already built into the binary which is already on the app store.

The only thing we're changing is we might be single instead of 3 rating stars. We might want to see 5 rating stars.

Or we might be changing the ordering of the view or the navigation part.

But anything the navigation is doing to the views and the ordering that already exists

in the app binary which is already deployed and approved by Apple.

So you should not have any problems with sending this to the app store.

I mean, app store review process should not have any restrictions on these kind of things. I mean, we have

Spotify, Uber, Airbnb, Flipkart, and so many different

- Yeah, they are all doing that.
- companies doing that same thing.

I don’t know. If you have an app where you have a log in you need to set up for your app store reviewer

just make sure when they log in they have basically the same experience your typical customer would have.

And I think you're good to go as far as the app store review is concerned.

Before we close out a couple of questions I wanted to ask you. What are you working on right now?

I'm working on a couple of things. I'm trying to finish out my book

of how you can become a developer by attending coding boot camps.

Uhm, it's....

It's written from the angle of my 5 years of experience as teaching at coding boot camps and graduating 250+ students.

But it's also for self-taught developers who can read this book and not attend the boot camp but just read the book

and they will get a lot of tips and tricks of, you know,

how to microtask or how to design different things.

It's not a coding book per se but it's more of what goes behind the coding part of it.

Do you have a link we could post in the show notes?

I'm still writing so I’m still not done.

- Yeah.
- Okay.

No preview link or anything like that?

Yeah. I don't have a preview link.

And the other thing that I'm working on which hopefully should be done before WWDC

is a new brand new course on Udemy for RealityKit and Augmented Reality using RealityKit.

That is something that I'm working on slowly. Hopefully, that will be done before WWDC. But we'll see.

I have a few ideas of why I've not done RealityKit or AR Kit and why I'm intimidated by it.

To me it's, A, I have to write all this tree. I have to build out these models and then I have to

get machine learning stuff involved.

It seems really intimidating when it comes to those frameworks.

What do you recommend for somebody who wants to get started on those?

How they should approach it I guess?

Uhm, so it's...

I know that some people think that they to be a math genius or something. It doesn't.

I mean, you don’t have to know a lot of math to begin with RealityKit or Augmented Reality.

And for as you said about models, I don't know how to create any 3D models. That's a completely different skill.

but I'm good in finding different models either from Sketchfab, or TurboSquid,

or even Apple models which are available on Apple's website.

I do already have courses on ARKit but that's obviously a little bit old now.

I think it's like 3-4 years old and those I created. But uh...

But RealityKit, if you want to start beginning, I mean start to learn about RealityKit,

I would definitely recommend the books from Ray Wenderlich’s website to introduce RealityKit,

or some just general YouTube videos on RealityKit, and obviously the WWDC

which will introduce RealityKit part of it.

But if you're thinking that it's too much math involved. I have to learn Calculus and all that stuff.

It's not that. It's just instead of two axis now obviously there are three x, y, and z,

and you just play around with those things. It's kind of fun, yeah, but not much math involved for most cases.

- Alright. You're encouraging.
- Yes.

So before we close out I want to chat a bit about WWDC.

We'll start off with what do you expect is going to happen this year?

As far as maybe what the big things are going to be?

I usually don't expect. I mean, I know that it's going to be...

My expectation and I think my wishes for WWDC are pretty much the same

which is Swift UI improvements especially on the part of Map Kit because Map Kit is quite limited.

Testing, a little bit more testing infrastructure for Swift UI even though you can test Swift UI views

but maybe we want it to better support a little bit more.

I know that there have been talks about some core data replacement frameworks online

but I don't think that's going to build out. But something related to that called Swift Data or something.

And one wish that I had for several years which is going on for at least 5 or 6 years

is some sort of a server-side Swift framework from Apple so that other people who are

not back-end developers they get a chance to experience a back-end and to create

services and server-side pages or server-side APIs.

Because once Apple pushes out something it gets more traction.

What do you think like...

I mean, Vapor is probably the most mature of the ones out there.

What would be the benefit to Apple to doing a different one I guess since Vapor is already out there.

But also they're not really even though they try to they're not really a server side company,

you know what I mean, other than Cloud Kit.

How could you see that scenario play out I guess?

I think it will definitely help other people to use the server side framework from Apple

because once Apple pushes out something, like they pushed out Combine,

and now everybody's jumping switch from RxSwift to Combine and to functional programming.

And now they're introducing async and await and all those things that they introduce so everyone is using that.

But I think it will definitely help people get off the paid platforms

or third-party platforms which may or may not exist in the future.

So you're thinking they'd host something?

- Yeah, yeah.
- Okay, okay.

Once they develop it, I mean, the framework also like a Swift Air or something so that they can write...

- Swift.
- I like that name.

So they can write a server side back end in Swift using Apple framework

and then they can deploy it on Apple or somewhere else if they want to.

Yeah, almost like if they could make it easier. I mean, they don't even have to write their own framework.

They could just be like, “This supports every Swift-based framework

here's a library for deploying it on our servers or AWS and be good to go.”

And they don't even have to write their own so there's such a server-side Swift community out there already.

It's like here's a library for deploying whatever server-side Swift thing you have

and you're good to go and that would be fantastic. Yeah, I agree.

That would be really be cool. I mean, the thing to me that always is they've really tried to

increase their revenue on services. And to me like

if you're going to do services, it's not just about having major league baseball.

But Amazon makes a ton of its money off of AWS. That's where their money is.

And if you want to do services, that's where the money is at like

hosting a server, like a more advanced Cloud Kit or deploying server-side Swift apps.

- But, yeah, that would be fantastic. Yeah.
- Absolutely.

So that's my small wish list and obviously improvements for Xcode so it can run

multiple previews or export previews for multiple devices at the same time.

- That would be definitely helpful.
- Yeah.

Yeah, yeah. Totally.

Anything else you wanted to mention before we close out?

I think we covered pretty much a lot of stuff and hopefully it will give a little bit of guidance

and ideas to people if they are interested in server-driven UI.

And, yeah, I think that's great.

Well, thank you so much, Mohammad for coming on the show.

I really appreciate it. I’m really glad to have you on.

Where can people find you online?

I'm on Twitter. I’m very active on twitter so you can follow me @azamsharp.

Awesome. Thank you so much. I really appreciate it.

Yeah, people can find me on Twitter @leogdion. My company is Bright Digit.

Please take some time to post a review on Apple podcast, Google, Spotify, wherever you're listening.

If you're watching this on YouTube like and subscribe please

and I look forward to talking to you again. Have a great day. Bye.

You too. Bye. Thanks!