Bring Android parity to the copy changes

_source/android/02_path_configuration.md

@@ -56,12 +56,11 @@ Hotwire.loadPathConfiguration(
 )
 ```
 
-`Path Configuration` will always load locally available configurations first. When providing both a bundled file and a server location, load order is as follows:
-
-1. The bundled file
-2. The cached server file (if a successful download has previously occurred)
-3. The downloaded server file
+If you provide both a file and a server location, the path configuration will be loaded asynchronously in the following order:
+1. The local file bundled with your app.
+2. A locally cached copy of the server configuration (if a successful download occurred on a previous app launch).
+3. A newly downloaded copy of the server configuration. (Once this has downloaded successfully, it will be cached and used in step 2 on the next app launch.) 
 
 Providing a bundled file and a server location will cause the path configuration to immediately load from the bundled version and – if it exists – a cached version of the server file. Then it will begin downloading the server file. Once the server file is successfully downloaded, it is loaded and cached for further use.
 
-The [path configuration reference](/reference/path-configuration) provides more information including all the behavior Hotwire Native provides out of the box.
+The [path configuration reference](/reference/path-configuration) provides more information, including all the behavior Hotwire Native provides out of the box.

_source/android/04_native_screens.md

@@ -9,7 +9,7 @@ description: "Integrate fully native Kotlin screens in your Hotiwre Native app."
 
 To render a native screen on Android you need match an identifier in the [path configuration](/overview/path-configuration) with your fragment.
 
-First, match a URL path pattern and set the `uri` property. This path configuration routes all URLs ending in `/numbers`. You can also set a `title` to set the native title when the fragment is presented.
+First, create a URL path pattern and set its `uri` property. This path configuration routes all URLs ending in `/numbers`. You can also set a `title` to set the native title when the fragment is presented.
 
 ```json
 {
@@ -28,7 +28,7 @@ First, match a URL path pattern and set the `uri` property. This path configurat
 }
 ```
 
-When a link is intercepted by Hotwire Native, it will go through its usual process of matching the link's URL path to all rules in the app's Path Configuration. When it matches the above rule, it will propose a `visit` and will find the matching `HotwireDestination` whose `uri` matches `"hotwire://fragment/numbers"`.
+When a link is intercepted by Hotwire Native, it will go through its usual process of matching the link's URL path to all rules in the app's Path Configuration. When it matches the above rule, it will propose a `visit` and resolve the matching `HotwireDestination` whose `uri` matches `"hotwire://fragment/numbers"`.
 
 Create a new fragment and provide a matching `HotwireDestination` annotation.
 
@@ -51,7 +51,7 @@ Hotwire.registerFragmentDestinations(
 
 In a purely native app, if a new screen presented an issue you'd be unable to react immediately. The usual process would be to rush out bug fixes and hope for a quick review. If the bug was severe or your team needed more time to fix a critical issue, you'd have to rollback to a previous app version and submit that to the Play Store for review.
 
-Since even native screens are routed through Hotwire Native, the Path Configuration is a powerful ally when it comes to rolling out your native screens. If you were to find a critical issue with your native screen, you could easily update your remote Path Configuration and either point to your web-content so users don't lose functionality, or immediately disable the screen altogether – no app review required for these measures.
+Since even native screens are routed through Hotwire Native, the Path Configuration is a powerful ally when it comes to rolling out your native screens. If you were to find a critical issue with your native screen, you could easily update your remote Path Configuration and either point to your web content so users don't lose functionality, or immediately disable the screen altogether – no app store review required.
 
 Simply remove the `"uri"` property and Hotwire Native will stop using your native screen, instead presenting a web view controller which loads `"/numbers"`: a web page you fully control.
 

_source/ios/02_path_configuration.md

@@ -55,6 +55,7 @@ let pathConfiguration = PathConfiguration(sources: [
 
 let navigator = Navigator(pathConfiguration: pathConfiguration)
 ```
+
 If you provide both a file and a server location, the path configuration will be loaded asynchronously in the following order:
 1. The local file bundled with your app.
 2. A locally cached copy of the server configuration (if a successful download occurred on a previous app launch).

_source/ios/04_native_screens.md

@@ -9,7 +9,7 @@ description: "Integrate fully native Swift screens in your Hotiwre Native app."
 
 If you need to go fully native, we've got you covered: it's easy to integrate native screens to Hotwire Native's navigation flow. Even though you may be tempted to get a reference to Hotwire Native's navigation controller and push/present yourself, we strongly advise against it. It's better to leverage the power of Hotwire Native's [Path Configuration](/ios/path-configuration), even for native screens.
 
-First, conform your view controller to `PathConfigurationIdentifiable` and provide a matching `pathConfigurationIdentifier`. When Hotwire Native intercepts a link, the identifier is used to quickly work out that a native view controller was requested.
+First, conform your view controller to `PathConfigurationIdentifiable` and provide a matching `pathConfigurationIdentifier`. When Hotwire Native intercepts a link, the identifier is used to resolve that a native view controller was requested.
 
 ```swift
 class NumbersViewController: UITableViewController, PathConfigurationIdentifiable {