docs(mobile/v4): reorganize sections and make docs version-neutral

- Move Architecture to just below Getting Started (before The Basics)
- Move Device, Dialog, File and System from SuperNative into The Basics; place Dialog below Native UI
- Remove version-specific phrasing ("in v4", "as of v4", "v3.1 introduces") so the docs port cleanly to future versions
- Convert hard-coded /docs/mobile/3 and /docs/mobile/1 links to relative, version-portable paths

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: simonhamp

package-lock.json

@@ -1,4 +1,4 @@
 ---
 title: Architecture
-order: 80
+order: 10
 ---

resources/views/docs/mobile/4/architecture/_index.md

@@ -3,8 +3,8 @@ title: About the New Architecture
 order: 10
 ---
 
-Since v1, NativePHP for Mobile has run your Laravel app on the device itself — no server, no network round-trip. In
-v3 and earlier, your app's UI rendered as HTML inside a web view. That model is productive and familiar, and it's
+NativePHP for Mobile runs your Laravel app on the device itself — no server, no network round-trip. Traditionally,
+your app's UI rendered as HTML inside a web view. That model is productive and familiar, and it's
 [still fully supported](../super-native/introduction#is-the-web-view-still-an-option). But it puts a browser between
 your app and the platform, and some things can only feel truly native when they *are* native.
 
@@ -68,7 +68,7 @@ app faster. If your app is happy in the web view, it will keep working exactly a
 
 ## Should you use it today?
 
-SuperNative is **the default** in v4: new apps render native screens from the very first route. It's in beta, so
+SuperNative is **the default**: new apps render native screens from the very first route. It's in beta, so
 expect rapid iteration — and if you'd rather wait, [opting out](../super-native/introduction#is-the-web-view-still-an-option)
 is one route and one component.
 

resources/views/docs/mobile/4/architecture/about-the-new-architecture.md

@@ -7,7 +7,7 @@ Definitions for the terms used throughout the Architecture section.
 
 ## SuperNative
 
-The engine behind native rendering in NativePHP for Mobile v4. It spans everything described in this section:
+The engine behind native rendering in NativePHP for Mobile. It spans everything described in this section:
 components, the render pipeline, the shared-memory boundary and the platform renderers.
 [About the New Architecture](about-the-new-architecture) is the best starting point.
 

resources/views/docs/mobile/4/architecture/glossary.md

@@ -4,7 +4,7 @@ order: 1
 ---
 
 Welcome! This section is a look under the hood of [SuperNative](../super-native/introduction), the engine that powers
-native rendering in NativePHP for Mobile v4. It explains how your Blade templates become real SwiftUI and Jetpack
+native rendering in NativePHP for Mobile. It explains how your Blade templates become real SwiftUI and Jetpack
 Compose views, how state flows between PHP and the screen, and why the whole thing is fast.
 
 <aside>

resources/views/docs/mobile/4/architecture/overview.md

@@ -24,7 +24,7 @@ When writing migrations, you need to consider any special recommendations for wo
 For example, prior to Laravel 11, SQLite foreign key constraints are turned off by default. If your application relies
 upon foreign key constraints, [you need to enable SQLite support for them](https://laravel.com/docs/database#configuration) before running your migrations.
 
-**It's important to test your migrations on [prod builds](/docs/mobile/1/getting-started/development#releasing)
+**It's important to test your migrations on [prod builds](../getting-started/deployment#releasing)
 before releasing updates!** You don't want to accidentally delete your user's data when they update your app.
 
 ## Seeding data with migrations
@@ -117,7 +117,7 @@ If anything, you should provide a client key that **only** allows client apps to
 authenticated your user, you can pass an access token back to your mobile app and use this for communicating with your
 API.
 
-Store these tokens on your users' devices securely with the [`SecureStorage`](/docs/mobile/1/apis/secure-storage) API.
+Store these tokens on your users' devices securely with the [`SecureStorage`](../plugins/core/secure-storage) API.
 
 It's a good practice to ensure these tokens have high entropy so that they are very hard to guess and a short lifespan.
 Generating tokens is cheap; leaking personal customer data can get _very_ expensive!

resources/views/docs/mobile/4/concepts/databases.md

@@ -83,7 +83,7 @@ NativePHP manages the worker lifecycle natively on both platforms.
 
 ## Things to Note
 
-- The queue worker requires [ZTS (Thread-Safe) PHP](/docs/mobile/3/getting-started/changelog), which is included by default in v3.1+.
+- The queue worker requires ZTS (Thread-Safe) PHP, which NativePHP includes by default.
 - Only the `database` queue connection is supported. This uses the same SQLite database as your app.
 - Jobs are persisted to the database, so they survive app restarts.
 - If a job fails, Laravel's standard retry and failure handling applies.

resources/views/docs/mobile/4/concepts/queues.md

@@ -188,7 +188,7 @@ Older Android versions ship with older WebView engines that may not support mode
 For example, Tailwind CSS v4 uses `@theme` and other newer CSS features that are not supported on older WebView
 versions. If you are targeting a lower `min_sdk` to support older devices, consider using Tailwind CSS v3 or another
 CSS framework that generates compatible output. You can configure your minimum SDK version in your
-[Android SDK Versions](/docs/mobile/3/getting-started/configuration#android-sdk-versions) settings.
+[Android SDK Versions](../getting-started/configuration#android-sdk-versions) settings.
 
 Always test your app on emulators running your minimum supported Android version to catch these issues early. You can
 create emulators for older API levels in Android Studio's Virtual Device Manager.

resources/views/docs/mobile/4/edge-components/web-view.md

@@ -65,7 +65,7 @@ php artisan native:watch {platform?} {target?}
 
 <aside>
 
-As of **v4**, the Vite dev server is **opt-in** — pass `--vite` to `native:run`/`native:watch` to start it. It
+The Vite dev server is **opt-in** — pass `--vite` to `native:run`/`native:watch` to start it. It
 was previously started automatically; the old `--no-vite` flag still exists but is now redundant. See the
 [Upgrade Guide](upgrade-guide).
 

resources/views/docs/mobile/4/getting-started/commands.md

@@ -47,7 +47,7 @@ latest code without needing to bump a version number by hand.
 
 You only need to change this when you're cutting a release build for distribution. Rather than editing your `.env`
 manually, use the
-[`native:release` command](/docs/mobile/3/getting-started/commands#nativerelease), which bumps the version (and build
+[`native:release` command](commands#nativerelease), which bumps the version (and build
 number) for you.
 
 <aside>
@@ -68,7 +68,7 @@ you see your latest changes.
 
 ## Persistent Runtime
 
-v3.1 introduces a persistent PHP runtime that boots Laravel once and reuses the kernel across all subsequent requests.
+NativePHP uses a persistent PHP runtime that boots Laravel once and reuses the kernel across all subsequent requests.
 This dramatically improves performance — from ~200-300ms per request down to ~5-30ms.
 
 The `runtime` section controls this behavior:
@@ -131,7 +131,7 @@ to function and bloat your downloads.
 
 ## Orientation
 
-NativePHP (as of v1.10.3) allows users to custom specific orientations per device through the config file. The config
+NativePHP allows users to custom specific orientations per device through the config file. The config
 allows for granularity for iPad, iPhone and Android devices. Options for each device can be seen below.
 
 NOTE: if you want to disable iPad support completely simply apply `false` for each option.