Add ios-like-diagnostics support

docs/core/deploying/native-aot/diagnostics/ios-like-platforms.md

@@ -10,24 +10,68 @@ ms.date: 11/11/2024
 
 ## Observability and telemetry
 
-TODO
+Tracing of .NET applications on mobile platforms is enabled through [dotnet-dsrouter](../../../diagnostics/dotnet-dsrouter.md) which connects diagnostic tooling with .NET mobile applications running on iOS-like platforms over TCP/IP. However, Native AOT is currently not compatible with this scenario as it does not support EventPipe/DiagnosticServer components built with TCP/IP stack.
 
 ## Development-time diagnostics
 
-TODO
+The .NET CLI tooling (`dotnet` SDK) offers separate commands for `build` and `publish`. `dotnet build` (or `Start Debugging (F5)` in VS Code), uses Mono by default when building or launching .NET MAUI iOS (or MacCatalyst) applications. Only `dotnet publish` creates a Native AOT application, if this deployment model is enabled in the project file. Publishing your app as Native AOT, produces an app that has been ahead-of-time (AOT) compiled to native code. As described in this document, not all diagnostic tools will work seamlessly with published Native AOT applications.
+However, all applications that are trim and AOT-compatible, i.e., that do not produce any trim and AOT warnings during build time, shouldn't have behavioral differences between Mono and Native AOT.
+Therefore, all .NET development-time diagnostic tools (like Hot Reload) are still available for developers during mobile app development cycle.
+We recommend developing, debugging, and testing the applications as usual and publishing the working app with Native AOT as one of the last steps.
 
 ## Native debugging
 
-TODO
+When you run your .NET MAUI iOS (or MacCatalyst) app during development, like inside VS Code, or with `dotnet build -t:Run`, it runs on Mono by default. However, if `PublishAot` is present in the project file, the behavior is expected to be the same between Mono and Native AOT when the application is not producing any trim and AOT warnings upon build. This characteristic allows you to use the standard VS Code managed debugging engine for development and testing, if your application fulfils the mentioned requirement.
+
+After publishing, Native AOT applications are true native binaries. The managed debugger won't work on them. However, the Native AOT compiler generates fully native executable files that you can debug with `lldb`. Debugging a NativeAOT MacCatalyst app with `lldb` is straight-forward, as it is ran on the same system, however, debugging NativeAOT iOS applications require a few extra steps which are covered in the following subsection.
+
+### Debugging .NET MAUI iOS applications with NativeAOT
+
+MAUI applications which are compatible with NativeAOT and are properly configured and published with this deployment model as described in the official [documentation](https://learn.microsoft.com/en-us/dotnet/maui/deployment/nativeaot?view=net-maui-9.0#publish-using-native-aot), can be debugged in the following ways.
+
+#### iOS
+
+1. Publish your app with Native AOT targeting `ios-arm64` and store the following information:
+
+    - Application name - referenced bellow as `<app-name>`
+    - Bundle identifier - referenced bellow as `<bundle-identifier>`
+    - Path to the published application's archive *.ipa* file - referenced bellow as `<path-to-ipa>`
+
+2. Discover physical device ID - referenced bellow as: `<device-identifier>`
+
+    ```bash
+    xcrun devicectl list devices
+    ```
+
+3. Install the app on your physical device
+
+    ```bash
+    xcrun devicectl device install app --device <device-identifier> <path-to-ipa>
+    ```
+
+4. Launch the app stopped on your physical device
+
+    ```bash
+    xcrun devicectl device process launch --device <device-identifier> --start-stopped <bundle-identifier>
+    ```
+
+5. Open `lldb` and connect to your physical device
+
+    ```bash
+    (lldb) device select <device-identifier>
+    (lldb) device process attach -n <app-name>
+    ```
+
+After successfully completing previous steps you are all set to start debugging your Native AOT MAUI iOS application with `lldb`.
 
 ### Importance of the symbol file
 
-TODO
+By default, debug symbols are stripped from the application's binary file into *.dSYM* files. This file is used by debuggers and post mortem analysis tools to show information about local variables, source line numbers, recreate stack traces of crash dumps etc. Therefore, it is essential to preserve it before submitting your application to App Store.
 
 ## CPU profiling
 
-TODO
+[Xcode Instruments](https://developer.apple.com/download/) can be used to collect CPU samples of a Native AOT application.
 
 ## Heap analysis
 
-TODO
+Currently not supported with Native AOT.