Artisan Build
Start a project

What I Want to Solve Next Week

Ed Grosvenor

In the coming week, my focus is going to be on improving the ergonomics of developing mobile apps with NativePHP

What I Want to Solve Next Week

So far, I'm really enjoying NativePHP. It still feels almost magical to write Laravel and have it bundled up and delivered to my phone with a single command. The biggest pain point is the time it takes to get changes onto the device. Hot reloading helps, but often changes require a full rebuild, and occasionally a hard reinstall. It's fine, but it's a lot more friction than we're used to when developing for the web.

We are always stretched very thin. Our client roster is full, we have internal projects with pretty serious deadlines, and we're seeing increasing interest in ad hoc consulting. When I hand this NativePHP app off to my team, I need them to be able to move as quickly as they would in a Filament project. That means finding and patching as many little potholes in the development workflow as I can before the race starts.

The way I want to solve it is to make it easier to develop the majority of an app in the browser and only reach for the simulator when we're working specifically with the mobile APIs. Since this is a Livewire 4 app, the new Blade directives added in version 2.1 will go a long way toward making this happen. NativePHP is actually set up pretty well for this workflow, but there are a few points of friction that I plan to address in the coming days:

EDGE Components are truly mobile-only - If you rely on EDGE components for your app navigation (you should), then you don't have navigation when working in the browser. This one is going to be pretty easy to solve. I'm going to create a Livewire component that renders the EDGE components on mobile and falls back to Flux in the browser. I'll define my navigation in an array, so I don't have to keep editing separate files whenever something changes.

SecureStorage is mobile-only - The app I'm building reaches out to an API. After I log in, I throw my token into LocalStorage. But in the browser, I need to keep it somewhere else. My first draft had me checking for the existence of SecureStorage all over the code, so I've created an abstraction that simply uses SecureStorage when it's available (on a mobile device or simulator) or the session() helper in the browser. It needs a little work to feel more like Laravel.

Herd share is unreliable - The NativePHP docs recommend using Herd or ngrok to wrap your local API. The reason this matters is because Herd's .test domains, when secured, use self-signed certificates, whereas ngrok and expose (Herd's sharing infrastructure) use proper certificates. I solved this one by simply ignoring certificate problems in my Saloon SDK's connector if the target domain is in the .test TLD. I think this is the right solution, but I haven't lived with it long enough to be sure.

This is by no means an exhaustive list. I'm sure I'll come up with some other edge cases as I work through this stuff. But by the time I hand this app off to my team to take over the finish line next week, I want to be able to tell them to just build it in the browser and just reach for the simulator often enough to know things are still working as expected.

Let’s talk

Tell us about your product, timeline, and what success looks like. We’ll reply with a concise plan of attack.

  • Calm, predictable cadence
  • Accessible, testable components
  • Transparent reporting & demos

Ready to start the conversation?

You can book a quick intro call or send us an email. No pressure, no forms — just a friendly hello.