NativePHP Mobile 4.3: Upgrade and Device Checks

A mobile upgrade can install successfully while leaving a visible problem on the screen. NativePHP Mobile 4.3 is a useful reminder to check both the PHP application and its native shell: the release includes fixes around bundling, development refreshes, and system interface spacing.

NativePHP announced Mobile 4.3.0 on August 28, 2026 in its official release post. The instructions explicitly run native:install between updating Composer dependencies and launching the app so the shell receives the new package.

Rebuild the native side of the application

composer update nativephp/mobile
php artisan native:install
php artisan native:run

That is the release’s documented command sequence. Composer resolves the version allowed by your project constraints, so inspect the resulting lock file before describing the build as 4.3. A project pinned to another major version needs its upgrade requirements reviewed first.

Start from a committed application state and record the package version you actually built. Keep generated native changes visible in the diff and investigate unexpected changes before packaging. When a teammate reports a device issue, the PHP dependency version alone is insufficient context; include the native build and operating system version too.

Record the baseline before updating

composer show nativephp/mobile
git status --short
git diff -- composer.json composer.lock

Save the installed version and the working-tree status in your upgrade notes. If there are unrelated local edits, account for them before continuing so that a generated shell change cannot be confused with unfinished feature work. After the update, repeat the version command and inspect the lock-file diff. Record the exact resolved version, including the patch number.

Use a representative screen from your product as the baseline. For a reading app, that might be a book editor with a title input, a multiline note, and a bottom tab bar. Populate it with a long title and enough text to require scrolling. Capture how the keyboard, save control, and bottom navigation behave before changing dependencies. This gives the upgrade review a concrete comparison.

Target the fixes with concrete checks

The 4.3 notes cover UTF-8 bundle filenames, seeding the Vite hot file when watch mode starts, an iOS background-color issue affecting keyboard helper windows, and an Android bottom bar overlapping system navigation. These are specific fixes, so the most useful verification recreates those situations.

On iOS, open an editable screen, show the keyboard, switch focus between inputs, and check the surrounding background in both supported appearance modes.
On Android, visit a screen with bottom navigation and confirm that the lowest controls remain visible and tappable above system navigation.
If your app bundles filenames containing emoji or non-ASCII characters, open the corresponding asset from the installed build.
Start your normal development watch workflow and confirm a visible edit reaches the simulator without a manual file-copy workaround.

Example: verify an iOS editing session

Open the book editor, focus the title, and then move to the note field while the keyboard remains open. Scroll to the final line, edit it, dismiss the keyboard, and save. Reopen the record and confirm that the final line persisted. This exercises the visual region affected by the release while also confirming that the interaction still accomplishes something useful.

Repeat with the app background your product actually uses. A white form on a white keyboard surround may conceal an unwanted painted region that becomes obvious on a dark screen. Capture a screenshot with the keyboard visible and another after dismissal. If the save control disappears beneath the keyboard, document the exact viewport and focused field before changing CSS or native configuration.

Example: verify Android bottom navigation

Start on the first tab and tap every destination in the bottom bar, including the outermost items. Return to the original screen and confirm that the selected state matches the visible content. Where supported by your test devices, repeat with gesture navigation and three-button navigation. The amount of system UI can differ, so evidence from one setting should not be treated as proof of the other.

Check both visibility and touch behavior. A label can remain readable while its touch target extends into an area reserved by the system. Record whether a tap navigates on the first attempt and whether a system gesture is triggered instead. Use the same navigation items and translations as the shipping application; placeholder labels often hide the layout pressure of real content.

Collect evidence of a completed interaction

Take a screenshot before and after each affected interaction. A screenshot of the landing screen says little about a keyboard problem. Capture the focused form with the keyboard present, and capture the Android screen while the system navigation area is visible.

Add a short result beside each image: device, operating system, app build, steps taken, and expected behavior. For a bottom bar, describe which item was tapped and the destination reached. This turns a picture into reproducible evidence rather than a decorative item in a release report.

Also try long labels, larger text, and the smallest supported screen. A spacing change can look correct with three short English labels while exposing clipping with a longer translation. Choose examples from your own navigation and forms so the test represents what customers will actually see.

Separate development refreshes from release verification

A successful hot reload is a development check. The release build should be installed through your normal signed distribution workflow and launched with the development server stopped. Open the app after terminating it, navigate to the affected screens, and verify that required bundled assets are available.

If your product supports offline use, test that documented behavior with connectivity disabled. If it requires a connection, check that its normal connection error screen is usable. Avoid inventing alternate data or silently replacing failed operations just to make a demonstration appear successful.

Use an evidence template that another developer can repeat

Scenario: Edit the final line of a book note
Package version: [resolved nativephp/mobile version]
Build identifier: [installed application build]
Device and OS: [physical device or simulator, OS version]
Appearance and text size: [settings used]
Steps: Open book, focus note, edit final line, dismiss, save, reopen
Expected: Keyboard region is clean; final line persists
Observed: [record the actual result]
Evidence: [before image, focused image, saved image]

Leave the observed result blank until the interaction has actually been checked. A copied checklist with every item marked passed creates confidence without evidence. If a failure is intermittent, keep the successful and failed attempts together with their build identifiers. That distinction helps determine whether the issue depends on startup state, navigation history, or a particular device setting.

Diagnose a failed upgrade at the failing layer

If the package resolves correctly but the old visual behavior remains, first confirm that the installed application is the newly built shell. If an asset fails only in a packaged build, inspect whether it was included and whether its filename survives extraction. If only development updates fail, reproduce watch startup independently of the release build. Each observation narrows the problem without hiding it behind unrelated layout changes.

Keep a known working build and its matching source revision available while reviewing the upgrade. A release decision should name the devices and workflows checked, plus anything still unresolved. Do not describe simulator evidence as physical-device verification, and do not describe a debug launch as a signed release test. Those distinctions make the report useful when deciding whether the update is ready for users.

Treat 4.3 as a defined release to verify, rather than assuming a patch makes every mobile problem disappear. The strongest upgrade report combines the resolved dependency version, a reviewed native diff, and photographs or screenshots of the exact interactions that the release changes.