Can I use my preexisting Laravel application to build an A mobile application and a desktop application all in one code base? The simple answer is no, you shouldn't do that. And here's why. Four, one, the application that you've already built is probably been built for the web. It's gonna have code that applies really only in a server environment. It's gonna have a different context,

that applies really only in a server environment. It's gonna have a different context, it's gonna have a different database, it's gonna have different expectations. So that application is already built for a web server that's a web application. Now, just because you could technically add the native PHP packages into that existing AVVA application doesn't mean that that's the right thing to do. Think of your applications as separate.

that that's the right thing to do. Think of your applications as separate. Trying to get that one application to serve all of these different purposes and different contexts is gonna make it really complicated. You're gonna end up with code that runs on the server that's built for a mobile device or for a desktop, and you just don't need that code in that environment. Not only is it kind of just hanging around and taking up space, the risk factor is that you actually

Not only is it kind of just hanging around and taking up space, the risk factor is that you actually try to access that code and try to do things with it that that environment doesn't know how to handle. And so that behavior is really uncertain, and that could lead to crashes in your applications. It could lead to security risks. So you shouldn't do that really. And if you think about it from the other side,

So you shouldn't do that really. And if you think about it from the other side, you almost certainly don't want your server side business logic to be shipped with your applications onto users devices. You don't want your users to have access to all of that logic and code, and it's probably not gonna make sense to have that on their device. And this leads to a general principle about

to have that on their device. And this leads to a general principle about how we think about shipping software to our users. When we're dealing with our own applications on our own servers, we kind of don't really care how big they get, especially with PHP and Composer and all of the loading that we have. That makes it very simple for our applications to cut out the code that they don't really need or use. But when you are shipping software

to cut out the code that they don't really need or use. But when you are shipping software to your users on their devices, which may have constraints in terms of memory or disk space, then you really want to minimize what you are shipping to your users. You wanna bring that down as small as it can possibly be. You want it to be really efficient software so that you're not taking up their bandwidth, their battery, and their precious space.

that you're not taking up their bandwidth, their battery, and their precious space. Shipping all of your application with every instance of it to every device is not the way to do that. Now, that presents a challenge because if we've got Laravel over here and Laravel over there, surely we want to bring those together because it'll be simpler. Now, I'm not saying that you can't put them into a single repository and manage these different things,

Now, I'm not saying that you can't put them into a single repository and manage these different things, but you don't want to cross the boundaries between each of those applications. It's much simpler if you keep them as separate. So this can be a Laravel application, and this can be a Laravel application, and that's fine. The fact that you've gotta manage two or three Laravel applications is not going to be a big deal. You've probably been managing a few Laravel

or three Laravel applications is not going to be a big deal. You've probably been managing a few Laravel applications already. The other thing that this enables you to think about is the boundaries of the context that you're in. When your users are using your application, if they're using your mobile application, then you know exactly what the boundary is here because it's clear if they're using your server application,

then you know exactly what the boundary is here because it's clear if they're using your server application, you know what the boundary is because it's overhearing this application. And keeping those things separate helps to reinforce that natural separation that already exists. So keep your application separate. That means if you are looking to build a native PHP application for a desktop or for a mobile, then you probably want to be reaching for

a native PHP application for a desktop or for a mobile, then you probably want to be reaching for that Laravel new command. So Laravel new for each new context. That's the simple rule. Now, what about installing native PHP for desktop and mobile into the same Laravel application?