Forem: Michael Ishri

Bundle Google Fonts with your NativePHP Mobile application

Michael Ishri — Mon, 17 Nov 2025 21:10:07 +0000

If your NativePHP mobile application is using Google Fonts, you can improve the speed of your application by bundling the fonts with your application rather than relying on an internet connection.

The simplest way I've found to do this is to use the log1x/laravel-webfonts composer package.

First install it as a dev dependency.

composer require log1x/laravel-webfonts --dev

Then use it's nice TUI to select your font and it's variants.

php artisan webfonts:add

As specified in the documentation, it will download the font, then extract it to your resources/fonts folder and it will also create a resources/css/fonts.css file with the correct (relative) imports.

Finally, you can simply add this to the top of your resources/css/app.css file.

@import './fonts.css';

Now when you build,

the font files will be copied to the public/build/assets folder
the css imports will be bundles as part of your app.css file

I found the log1x package to be better suited to NativePHP mobile applications because of how simple it makes bundling with Vite and the fact that it uses relative imports for the fonts. These two points are the main pain points with the spatie/laravel-google-fonts for this use case. I'm sure it's just my inexperience, but I found I had to do a heap of custom Vite plugin stuff to make everything work (with the Spatie package).

If you choose to use the Spatie package instead, just note that it doesn't spit out relative paths for the fonts (it will hard code your APP_URL). This is fine for applications running on the web but on NativePHP Mobile we don't want that. Knowing this is important because it took me a long time to realise this was slowing the boot time of my NativePHP Mobile application. Essentially, using the import provided by the package, it was trying to load fonts from http://localhost:8000 and eventually timing out then fetching from Google directly. So any subsequent boots would be fine since it had already been cached. But once I figured out that NativePHP applications "run" on http://127.0.0.1, it was never going to be able to fetch the fonts locally. Once I fixed this, my boot times went from 2-5 seconds to instant.

Please note, I'm not trying to throw shade at the Spatie package / team. I love those guys and the work they do for our community. I'm simply trying to help others that may run into the same problem that I did and to provide a better solution for this use case.

Hijack the Back button on Android in NativePHP

Michael Ishri — Thu, 06 Nov 2025 09:00:43 +0000

While testing my NativePHP Android application, I noticed that the back button / action wasn't behaving the way I would expect for a regular "native" application.

I realised that it was behaving like a browser with it's history stack. If I navigated into sub-menus using the UI then started using the back button / action it would just take me back through my history instead of up the menu tree like a regular app would, so I thought I'd look into how to fix that behaviour.

After a quick Google search, the answer ended up being a simple, single line change. By adding the following to your MainActivity.kt file, we can instead emit an event in JavaScript which can then be reacted to.

webView.evaluateJavascript("window.dispatchEvent(new Event(\'native:backpressed\'))", null)

Caution: If you take this approach, you need to make sure that EVERY page includes a way to handle the back button / action otherwise you could lock your user in a screen without being able to escape (except by killing the app or going to the Android home screen).

Let's we take a look at the original method surrounding this.

onBackPressedDispatcher.addCallback(this) {
    val webView = binding.webView

    if (webView.canGoBack()) {
        webView.goBack()
    } else {
        finish()
    }
}

Then the modified one.

onBackPressedDispatcher.addCallback(this) {
    val webView = binding.webView

    if (webView.canGoBack()) {
        webView.evaluateJavascript("window.dispatchEvent(new Event('native:backpressed'))", null)
    } else {
        finish()
    }
}

Now in all my Blade views, I can simply add.

<script>
    window.addEventListener('native:backpressed', function(event) {
        window.location.href = '/home'
    });
</script>

Caveat

There is one big caveat to making this change. Whenever the NativePHP team push updates, we may need to run native:install --force which will overwrite the changes.

So to workaround this issue, I've created an Artisan console command that can perform the replacement automatically which you would need to run after native:install.

// app/Console/Commands/InterceptBackButton.php

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminate\Support\Facades\File;

class InterceptBackButton extends Command
{
    public $replaced = false;

    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'android:intercept-back-button';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Changes the default behaviour of the Android Back button.';

    /**
     * This helper replaces the default behaviour of the back button on Android.
     * Instead of behaving like a browser, this will instead emit a JavaScript event in your application which can be reacted to.
     * You may listen for the `native:backpressed` event.
     */
    public function handle()
    {
        $files = collect(File::allFiles(base_path('nativephp/android/app/src/main')))
            ->filter(fn($file) => $file->getFilename() === 'MainActivity.kt')
            ->map->getRealPath();

        foreach($files as $file) {
            $contents = File::get($file);

            $updated = str_replace(
                'webView.goBack()',
                'webView.evaluateJavascript("window.dispatchEvent(new Event(\'native:backpressed\'))", null)',
                $contents
            );

            if($contents !== $updated) {
                File::put($file, $updated);
                $this->info("Success, performed replacement in: $file");
                $this->replaced = true;
            }
        }

        if($this->replaced == false) {
            $this->error('Fail, replacement of intercept code couldn\'t be performed');
        }
    }
}

I've also extracted the JavaScript portion into the following Blade component.

{{-- resources/views/components/return-to.blade.php --}}

@props(['route'])

<script>
    window.addEventListener('native:backpressed', function(event) {
        window.location.href = '{{ $route }}'
    });
</script>

Which you can use in your view like this;

    ....
    <x-return-to route="{{ route('home') }}" />
</body>

Conclusion

This is really just a proof-of-concept, I haven't performed extensive testing and it may need more work to make it more robust (for example, how do you exit the app once you can't go back any further), but the concept is out there now.

This exercise has really opened my eyes to the possibilities which is really exciting.

How to sign your NativePHP Android App for the Google Play Store

Michael Ishri — Thu, 06 Nov 2025 00:31:29 +0000

This article explains the basics of getting your NativePHP application to the Google Play Store.

Before you begin, you will need to register for a Play Console developer account. It has a one time fee of $25 (at the time of writing). It may take a few days to get approved on Google's side.

Once you have been approved and your NativePHP application is ready to be uploaded, you need to do the following things.

Generate a keystore file
Configure NativePHP to use the keystore file
Publish your application

Generate your keystore file

You keystore file is a Java thing which is essentially a bag that can hold a bunch of things. In our case, we want it to hold our signing keys for our application (but it could hold many things).

In a terminal, run the following command (this assumes you already have a JDK installed which comes with the keytool cli).

keytool -genkey -v -keystore my-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-key-alias

my-release-key.jks will be the filename
my-key-alias is an identifier for your key

For simplicity, I would recommend you just call both the name of your application.

Follow the prompts:

Enter keystore password: Create and confirm a strong password. This is your password to the keystore file and we'll need to use this later.
What is your first and last name?
What is the name of your organisational unit?
What is the name of your organisation?
What is the name of your city or locality?
What is the name of your state or province?
What is the two letter country code for this unit?
Type yes when prompted to confirm
Enter key password for <my-key-alias>: You can press Enter to use the same password as the keystore password or you can create a separate, unique password. This is your Key Password

You'll get an output similar to this:

Generating 2,048 bit RSA key pair and self-signed certificate (SHA384withRSA) with a validity of 10,000 days
    for: CN=Norman Osborn, OU=Research & Development, O=Oscorp, L=New York, ST=New York, C=US
[Storing goblin.jks]

IMPORTANT: Store this file somewhere safe! It is used to sign every version of your app. If it is lost, you will not be able to update your app. If you have multiple apps, you should generate a new keystore file for each application.

Configure NativePHP

Now that you've got a keystore file (with your signing key inside it), we need to configure NativePHP to use it whenever you build a bundle version of your app.

There are several ways you can configure NativePHP to use this. If you're just building on your local machine the easiest is to place the following keys in your .env file.

ANDROID_KEYSTORE_FILE=/Users/normanosborn/dev/goblin-app/goblin.jks
ANDROID_KEYSTORE_PASSWORD=your-keystore-password-from-earlier
ANDROID_KEY_ALIAS=your-key-alias-from-earlier
ANDROID_KEY_PASSWORD=your-key-password-from-earlier

# Then build your application
npm run build && php artisan native:package android --build-type=bundle

If you're using some sort of automation (CI/CD perhaps), you can pass the same values as parameters to the native:package command.

php artisan native:package android \
  --build-type=bundle \
  --keystore=/Users/normanosborn/dev/goblin-app/goblin.jks \
  --keystore-password=your-keystore-password-from-earlier \
  --key-alias=your-key-alias-from-earlier \
  --key-password=your-key-password-from-earlier \
  --output=./artifacts \
  --no-tty

or as environment variables

export ANDROID_KEYSTORE_FILE="Users/normanosborn/dev/goblin-app/goblin.jks"
export ANDROID_KEYSTORE_PASSWORD="your-keystore-password-from-earlier"
export ANDROID_KEY_ALIAS="your-key-alias-from-earlier"
export ANDROID_KEY_PASSWORD="your-key-password-from-earlier"

php artisan native:package android --build-type=bundle --output=./artifacts --no-tty

Please check out the NativePHP docs for the latest info on this.

Publish App

Once you've run the native:package command, a window will pop up to the folder where your .aab file is stored. This is your bundled and signed Android application which you can upload to the Google Play Console.

Conclusion

Once you know, it's pretty straight-forward to build and publish your application but I'm just new to this and there may be some things that I've missed. So I will update this article as I learn more.

Don't expose your database to the world

Michael Ishri — Fri, 04 Jul 2025 04:10:22 +0000

I'm so excited. I explored NativePHP when I first heard about it for the desktop but I didn't really have a need for it at the time. I had a few ideas but nothing I was sure I wanted to spend a heap of time building. But when they announced support for iOS I was intrigued, then they quickly followed with Android support. I was in!

I would consider myself a hobbyist, Laravel developer. I work for a large enterprise that is crusty and old and has no interest in modern tooling, so I'm stuck with what they dictate, so Laravel is just a thing I do out of interest. Having said that, I've worked in enterprise environments for a long time and understand a bunch about good architecture / practices.

I forget that sometimes. That not everyone has my experience. So this post is for those that are exploring NativePHP on mobile and think that they need to connect their mobile application directly to a MySQL/Postgres database.

Short answer, please don't!

When you're developing a "regular" Laravel web application, your application will typically get deployed onto a web server which has a direct (and reliable) connection to your database server / service. Since your web server is considered a "secure" server, it is fine to have your database credentials somewhere your application can read from and use. Essentially it's a closed loop between your web server and database server.

Database connections are typically stateful connections, meaning you connect to the server with your credentials then a session is established without having to re-authenticate again on subsequent operations. The network protocol to talk to your database server (engine) is designed to work in this way. Stateful connections are more sensitive to packet loss and are typically "heavier" than stateless connections (like HTTP). This is because both the client and server need to maintain the sessions, instead of closing the connection after the response has been sent (like in stateless connections). So the trade-off is usually speed (stateful) vs resilience (stateless).

There is an exception to that speed argument when using a stateful connection model on unstable networks (such as mobile networks). Since there's overhead when re-establishing sessions.

Having said all that, PHP is slightly different, because every request is a new request. In PHP, a new connection to the database is established for each web request, so even though the connection remains stateful, it is short-lived...typically (we could veer off here and discuss connection pooling and persistence, but those topics are for another day). This is probably why you don't run into connection limit issues (too many connections to the database server), because PHP will release/close the connection gracefully.

When building you NativePHP mobile application, you can't guarantee a safe, secure, reliable environment (if it's being distributed publicly). So you should have a layer of abstraction in-between your application and the database server. When working with Laravel, this would usually be a REST API.

So essentially, you would build REST API endpoints which require authentication, that return JSON to mobile application which is then consumed by your application.

From a user flow perspective,

The user installs your application
The user provides their credentials to log into your application
After successful auth, an API token is generated and sent to the user's device and stored securely on the device
This API token is then used under-the-hood to interact with your API

This means you don't need to expose your database to the outside world. You continue to just expose HTTP to the outside world which is easy to secure. You can easily set up key rotation on the server side (if you want to automatically expire the API token after a period of time). It's a stateless connection so able to recover on flaky connections plus a whole bunch of other benefits.

This API token approach is just one way to handle this, there are other ways such as using JWT's, but in my opinion, when working with Laravel, this is the simplest. Check out the Laravel Sanctum docs to understand how to implement this in your application.

If we didn't take this approach, let's quickly imagine what could happen.

You would need to figure out a way to store your database credentials on the client device. Just putting this in writing is making me scared...It's just a bad idea. We can't assume the client device is secure or will remain secure. We don't want hundreds of users making direct connections to your database server with the same credentials. If those credentials are compromised, then your database could get leaked. Since everyone would be using the same credentials, then everyone would have access to everyone else's information and because it's a direct connection to the database, it means your database would need to be exposed to the outside world. Once you have those credentials, you can just open MySQL workbench and start running arbitrary SQL queries. There are just too many issues to list with this scenario.

So then lets assume you have some way of creating a new user account on the database server for each user of your application. You would still need to expose your database server to the outside world and if your user figures out their credentials to their database user, they could then again use MySQL workbench to just run arbitrary SQL queries. Let's hope you've set up the correct access levels for your user. You would need to implement row level access which is extremely granular and again, this whole thing is just a bad idea.

The thing is, Laravel just makes building and securing API's so easy, there's little reason to not use it. I can only think of one example where you would need to store your database credentials in the client application. If you were building a database management tool like TablePlus and you wanted to have an "auto-login" feature for your user. That's it really.

So, please don't expose your database server to the outside world. Keep it behind a secure network and use a REST API instead. Have authentication on your API and only send data your application needs, nothing more (avoid sending internal ID's, timestamps, sensitive data, etc).

Initial Commit

Michael Ishri — Fri, 04 Jul 2025 02:32:24 +0000

I'm new to this.

I'm not new to the tech industry or to knowledge sharing or even documenting my experiences. In fact, I've been working in tech over 20 years now, but I am new to sharing my experiences publicly. I've always wanted to but have always felt that maybe I wouldn't have anything interesting to share or that I wouldn't be able to find the time to be consistently sharing so why bother starting.

But I just need to start, today, right now!

So here I am, I've started. Stay tuned for more.