Development and Deployment

Author: simonhamp

resources/views/docs/mobile/2/getting-started/packaging.md renamed to resources/views/docs/mobile/2/getting-started/deployment.md

@@ -1,11 +1,89 @@
 ---
-title: Packaging
+title: Deployment
 order: 300
 ---
 
+Deploying mobile apps is a complicated process — and it's different for each platform! Generally speaking you need to:
+
+1. **Releasing**: Create a _release build_ for each platform.
+2. **Testing**: Test this build on real devices.
+3. **Packaging**: Sign and distribute this build to the stores.
+4. **Submitting for Review**: Go through each store's submission process to have your app reviewed.
+5. **Publishing**: Releasing the new version to the stores and your users.
+
+It's initially more time-consuming when creating a brand new app in the stores, as you need to get the listing set up
+in each store and create your signing credentials.
+
+If you've never done it before, allow a couple of hours so you can focus on getting things right and understand
+everything you need.
+
+Don't rush through the app store processes! There are compliance items that if handled incorrectly will either prevent
+you from publishing your app, being unable to release it in the territories you want to make it available to, or simply
+having it get rejected immediately when you submit it for review if you don't get those right.
+
+It's typically easier once you've released the first version of your app and after you've done 2 or 3 apps, you'll fly
+through the process!
+
+<aside>
+
+#### Need help?
+
+This page is here to help you _configure and use NativePHP_ to prepare your app for release; it is not a guide around
+the stores. You should consult the [App Store Connect Help](https://developer.apple.com/help/app-store-connect/) and
+[Play Console Help](https://support.google.com/googleplay/android-developer/?hl=en-GB#topic=3450769) documentation for
+detailed and up-to-date guidance on how to prepare your app submissions and listings.
+
+If you want more hands-on support, we happily work with our [Partners](/partners) to support them releasing their apps.
+
+</aside>
+
+## Releasing
+
+To prepare your app for release, you should set the version number to a new version number that you have not used
+before and increment the build number:
+
+```dotenv
+NATIVEPHP_APP_VERSION=1.2.3
+NATIVEPHP_APP_VERSION_CODE=48
+```
+
+### Versioning
+
+You have complete freedom in how you version your applications. You may use semantic versioning, codenames,
+date-based versions, or any scheme that works for your project, team or business.
+
+Remember that your app versions are usually public-facing (e.g. in store listings and on-device settings and update
+screens) and can be useful for customers to reference if they need to contact you for help and support.
+
+The build number is managed via the `NATIVEPHP_APP_VERSION` key in your `.env`.
+
+### Build numbers
+
+Both the Google Play Store and Apple App Store require your app's build number to increase for each release you submit.
+
+The build number is managed via the `NATIVEPHP_APP_VERSION_CODE` key in your `.env`.
+
+### Run a `release` build
+
+Then run a release build:
+
+```shell
+php artisan native:run --build=release
+```
+
+This builds your application with various optimizations that reduce its overall size and improve its performance, such
+as removing debugging code and unnecessary features (i.e. Composer dev dependencies).
+
+**You should test this build on a real device.** Once you're happy that everything is working as intended you can then
+submit it to the stores for approval and distribution.
+
+- [Google Play Store submission guidelines](https://support.google.com/googleplay/android-developer/answer/9859152?hl=en-GB#zippy=%2Cmaximum-size-limit)
+- [Apple App Store submission guidelines](https://developer.apple.com/ios/submit/)
+
 ## Packaging Your App
 
-The `native:package` command creates signed, production-ready apps for distribution to the App Store and Play Store. This command handles all the complexity of code signing, building release artifacts, and preparing files for submission.
+The `native:package` command creates signed, production-ready apps for distribution to the App Store and Play Store.
+This command handles all the complexity of code signing, building release artifacts, and preparing files for submission.
 
 <aside>
 

resources/views/docs/mobile/2/getting-started/development.md

@@ -138,15 +138,7 @@ Full hot reloading support for Livewire on real devices is not yet available.
 
 </aside>
 
-### Order matters
-
-Depending on which order you run these commands, you may find that hot reloading doesn't work immediately. It's often
-best to get the commands running, get your app open, and then make a request to a new screen to allow your app to pick
-up the `hot` file's presence and connect to the HMR server.
-
-<aside>
-
-#### Hot reloading config
+### Configuration
 
 You can configure the folders that the `watch` command pays attention to in your `config/nativephp.php` file:
 
@@ -163,58 +155,19 @@ You can configure the folders that the `watch` command pays attention to in your
 ]
 ```
 
-</aside>
-
-## Releasing
-
-To prepare your app for release, you should set the version number to a new version number that you have not used
-before and increment the build number:
-
-```dotenv
-NATIVEPHP_APP_VERSION=1.2.3
-NATIVEPHP_APP_VERSION_CODE=48
-```
-
-### Versioning
-
-You have complete freedom in how you version your applications. You may use semantic versioning, codenames,
-date-based versions, or any scheme that works for your project, team or business.
-
-Remember that your app versions are usually public-facing (e.g. in store listings and on-device settings and update
-screens) and can be useful for customers to reference if they need to contact you for help and support.
-
-The build number is managed via the `NATIVEPHP_APP_VERSION` key in your `.env`.
-
-### Build numbers
-
-Both the Google Play Store and Apple App Store require your app's build number to increase for each release you submit. 
-
-The build number is managed via the `NATIVEPHP_APP_VERSION_CODE` key in your `.env`.
-
-### Run a `release` build
-
-Then run a release build:
-
-```shell
-php artisan native:run --build=release
-```
-
-This builds your application with various optimizations that reduce its overall size and improve its performance, such
-as removing debugging code and unnecessary features (i.e. Composer dev dependencies).
+### Order matters
 
-**You should test this build on a real device.** Once you're happy that everything is working as intended you can then
-submit it to the stores for approval and distribution.
+Depending on which order you run these commands, you may find that hot reloading doesn't work immediately. It's often
+best to get the commands running, get your app open, and then make a request to a new screen to allow your app to pick
+up the `hot` file's presence and connect to the HMR server.
 
-- [Google Play Store submission guidelines](https://support.google.com/googleplay/android-developer/answer/9859152?hl=en-GB#zippy=%2Cmaximum-size-limit)
-- [Apple App Store submission guidelines](https://developer.apple.com/ios/submit/)
 
 <aside>
 
 #### Skip the prompts
 
-If you are tired of prompts, you can run most commands - like `native:run` - with the arguments and options that will
-allow you to skip through the various prompts. Use the `--help` flag on a command to find out what values you can 
-pass directly to it:
+If you are tired of prompts, you can run most commands - like `native:run` - with arguments and options that allow you
+to skip various prompts. Use the `--help` flag on a command to find out what values you can pass directly to it:
 
 ```shell
 php artisan native:run --help