NativePHP Mobile 4.3: Upgrade the Shell and Check the Real Screen
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:runThat 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.
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.
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.
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.