There are lots of native features that we want to build into our apps, but there's one important feature that almost every application is gonna need, and that is secure storage. This uses the device's, native APIs for storing important data safely and securely in an encrypted key store or key chain that makes it really, really safe. The important reason why this is necessary is that if you ship credentials with your application,

The important reason why this is necessary is that if you ship credentials with your application, they can be discovered by anybody who knows where they're looking. So we don't want to ship things like API keys with our application. We shouldn't have them in our M files and that kind of thing. We need to strip those out. A native PHP actually helps you to do that.

We need to strip those out. A native PHP actually helps you to do that. It will strip out anything that looks like it might be a key or a token or anything like that by default. And so you might find it unusual when you're building your applications to see that some of those things just don't work, and that's because they get stripped out. But that's for a good reason. It's so that you are kept safe.

But that's for a good reason. It's so that you are kept safe. You can configure all of that through the native PHP config file, which gets installed when we install native PHP. There's a whole section on environment keys being cleaned up. You can add to it, you can take away from it, but you should definitely be familiar with the kind of things that are being done in here.

but you should definitely be familiar with the kind of things that are being done in here. So then it begs the question, how do I get my secure credentials, API keys and things like that to my users? So it might be that you build your own API service. It might be that you build something in Laravel. You could use Laravel sanctum or Laravel Passport or a number of other auth services and tools that are available

or a number of other auth services and tools that are available and you want to authenticate your user and then you're gonna receive a token. Now, we don't have time to build the whole auth service and set that up somewhere, so we can't demonstrate this functionally, but what we can do is write some kind of pseudo code to demonstrate the principles of it. And for that, I'm just going to assume that we've got a service that we pull in.

And for that, I'm just going to assume that we've got a service that we pull in. So we'll imagine here that we've got an API service that's being type hinted into this function when we press the button and we will then go and fetch from that service an API key. So it will pass, let's say we pass the username and and password over an encrypted HTTP s connection to our API server. So we'd have a, the username

to our API server. So we'd have a, the username and password may be coming from our ui, and then we get back from it a token. So I'm just gonna make up this token here. We can just say whatever we want. This is a secure token. When we hit this button, the request that goes to the PHP side of our application runs the toast action and then it finishes.

to the PHP side of our application runs the toast action and then it finishes. And so everything that's stored in memory here is gone. And we can prove that by running another request. So let's just create a different function and let's just do check token. So I'm gonna say, so let's put this token into, uh, property on this class. So we're just gonna say private token. That means that it's not gonna be stored in Livewire State.

So we're just gonna say private token. That means that it's not gonna be stored in Livewire State. It's just gonna be stored in the class when it's set, when we're using it. And then in this, in this function, we're going to try and get the token out and put it in an alert. So we'll take this token, we'll change this back to an alert and we'll just say Token and give us our token back. So now we just need the UI for that.

and give us our token back. So now we just need the UI for that. So we'll add another button to say get Token, And we'll say Check Token. I think that was the method name that I said, wasn't it. And now we've got two buttons side by side. So we'll hit the Toast Me button to make sure that we've supposedly set our variable. And then just to check what the value of it is,

supposedly set our variable. And then just to check what the value of it is, we'll hit the get token button and see what we get back an error. And that's saying that we've called the dialogue alert function with a message that's null. And that should be a string. And that means that token is null. It's not persisted across the requests in PHP. And that's expected. That's what we want it to do.

It's not persisted across the requests in PHP. And that's expected. That's what we want it to do. So we know that PHP is operating in the same way that it normally does. Great. So how do we get this value back? We can store it in session. So let's try doing that. So session token, this token. And then in our check function, we, instead of calling this token, we can

And then in our check function, we, instead of calling this token, we can do session token Like that. So let's put it in session and then let's get it out of session. Great. We got our value. But what happens when we quit our application, The state of our application has, has now been completely reset.

The state of our application has, has now been completely reset. And that's because we are using debug mode. Our debug mode always pulls out the bundled avva application that's bundled inside, in this case, the Swift application, and installs it over the top of whatever's in place outside of Swift. And to get really small and really fast bundles, we need to zip up your Laravel application as small as possible.

and really fast bundles, we need to zip up your Laravel application as small as possible. And then when the application first runs, we unzip it and we put it in a place where it can execute from. And that gives us a whole load of future possibilities. But it also means that our Hot Reloaded edits have gone, we've lost them. So we need to bring all of that back with native PHP. Again, this is straightforward. We don't need to stop our hot reloading service

Again, this is straightforward. We don't need to stop our hot reloading service that's still running here and that can stay there. And we don't need to restart the simulator. We've just rebooted our application. But what we will need to do is resave all of the files that we've changed so far. So we need to resave this view and we need to resave this livewire component class. Now, we don't want to hit the Toast Me button

and we need to resave this livewire component class. Now, we don't want to hit the Toast Me button because that's going to set our token back in the session. But remember that we were trying to test the Get token button after we've reloaded our application. So now that everything's fully reloaded, we want to just hit the get token button to see if the value is in session. And you can see again, we get an error. And that's because the session isn't persisted once

And you can see again, we get an error. And that's because the session isn't persisted once our application has quit. In fact, you shouldn't really rely upon Sessions for very long at all. They're very limited in the mobile environment, and they don't really serve that much of a purpose because everything is sort of long lived. Anyway. Sessions in PHP and in Laravel are one of these concepts

Anyway. Sessions in PHP and in Laravel are one of these concepts that has really been brought about to maintain some idea of state between a detached server and client. And it's something that we don't really need or want to use in this environment where the server and clients are right next to each other. In fact, there's no server and there's no client. The app is all in one, and it's just the PHP code and the PHP engine.

The app is all in one, and it's just the PHP code and the PHP engine. And it's bringing those two things together. There's no network involved, so we don't really need a concept of sessions. You might find them useful at times, lean more on persisting data in databases in the file system or the secure storage. So let's refactor this to use secure storage instead.

So let's refactor this to use secure storage instead. So we're gonna do secure storage Set, and we just want a key name and its value. So we'll do that. We just need to import that class. So use native mobile facades, secure storage. Good. And then we want to fetch it outta secure storage. That's it. We've refactored everything

to fetch it outta secure storage. That's it. We've refactored everything to use secure storage now. So let's run the Toast Me function again, and in theory that's put this value in Secure storage. And then let's get the token and it's there. Now let's quit our app and reopen. We have to do the same dance again, so save, save. And now remember, session hasn't been involved at all,

so save, save. And now remember, session hasn't been involved at all, so we're not relying upon the session that doesn't exist. If we get token again, it's still there. The really important thing to note with secure Storage is that it's storing that data securely. That's why it's called secure storage. But that's really, really important for data like API keys. When we are storing that value, we need it to be in a safe place.

When we are storing that value, we need it to be in a safe place. And Secure Storage uses the device's own key store or key chain to encrypt the data and decrypt it on the fly when we request it. And it's all based around the hardware and what's made available through things like Face ID and the PIN and how secure the device actually is in terms of capturing data and encrypting it. And that means that when we put things in secure storage,

of capturing data and encrypting it. And that means that when we put things in secure storage, they're very, very safe. No other applications can access that data. And if an attacker is trying to hack into somebody's phone, they're not going to be able to get the data because it's encrypted by a strong key that's protected usually by something like Face ID or Touch id or a strong Pin. Even better is if you can have individual keys

or Touch id or a strong Pin. Even better is if you can have individual keys for individual users. And that's where tools like Sanctum and Passport coming because they allow you to authenticate an individual user and get a token for them, even a token for a specifically short period of time, which requires you to go and refresh it or recreate it every so often. That's a nice summary of one of the most important native features that we've got available.

That's a nice summary of one of the most important native features that we've got available. Now, I know it might not be the most exciting one. I'm gonna let you work out how to use some of these other native features. Don't forget to go and read the documentation on Secure Storage and all of these other features. Also, be sure to check the concepts section of the website for more details on how and why some of these things are

for more details on how and why some of these things are set up the way that they are. Make sure that you have a good thorough read through all of the documentation. It's not very long and it will probably only take you an hour or so to have read everything, and it's well worth having a deep understanding of all of these features.

and it's well worth having a deep understanding of all of these features. We've built our first real feature into the application, and it's time to pause. We're gonna step back and we're gonna spend a few minutes now talking about what's actually going on under the hood of native PHP. How does this all work and how have we made it possible for you to run PHP natively on your phones?

and how have we made it possible for you to run PHP natively on your phones?