doc: prepare for commonmark

We are still using Pandoc’s Markdown parser, which differs from CommonMark spec slightly.

Notably:
- Line breaks in lists behave differently.
- Admonitions do not support the simpler syntax https://github.com/jgm/commonmark-hs/issues/75
- The auto_identifiers uses a different algorithm – I made the previous ones explicit.
- Languages (classes) of code blocks cannot contain whitespace so we have to use “pycon” alias instead of Python “console” as GitHub’s linguist

While at it, I also fixed the following issues:
- ShellSesssion was used
- Removed some pointless docbook tags.

1 files changed, 9 insertions, 8 deletions

diff --git a/doc/languages-frameworks/ios.section.md b/doc/languages-frameworks/ios.section.md
index a162e8d19fd..04b013be12e 100644
--- a/doc/languages-frameworks/ios.section.md
+++ b/doc/languages-frameworks/ios.section.md
@@ -20,8 +20,8 @@ Hydra.
 
 The Xcode build environment implements a number of features.
 
-Deploying a proxy component wrapper exposing Xcode
---------------------------------------------------
+## Deploying a proxy component wrapper exposing Xcode {#deploying-a-proxy-component-wrapper-exposing-xcode}
+
 The first use case is deploying a Nix package that provides symlinks to the Xcode
 installation on the host system. This package can be used as a build input to
 any build function implemented in the Nix expression language that requires
@@ -55,8 +55,8 @@ lrwxr-xr-x  1 sander  staff  61  1 jan  1970 xcodebuild -> /Applications/Xcode.a
 lrwxr-xr-x  1 sander  staff  14  1 jan  1970 xcrun -> /usr/bin/xcrun
 ```
 
-Building an iOS application
----------------------------
+## Building an iOS application {#building-an-ios-application}
+
 We can build an iOS app executable for the simulator, or an IPA/xcarchive file
 for release purposes, e.g. ad-hoc, enterprise or store installations, by
 executing the `xcodeenv.buildApp {}` function:
@@ -99,6 +99,7 @@ xcodeenv.buildApp {
 ```
 
 The above function takes a variety of parameters:
+
 * The `name` and `src` parameters are mandatory and specify the name of the app
   and the location where the source code resides
 * `sdkVersion` specifies which version of the iOS SDK to use.
@@ -151,8 +152,8 @@ the `xcodeenv.composeXcodeWrapper {}` function takes. For example, the
 `xcodeBaseDir` parameter can be overridden to refer to a different Xcode
 version.
 
-Spawning simulator instances
-----------------------------
+## Spawning simulator instances {#spawning-simulator-instances}
+
 In addition to building iOS apps, we can also automatically spawn simulator
 instances:
 
@@ -213,8 +214,8 @@ xcode.simulateApp {
 By providing the result of an `xcode.buildApp {}` function and configuring the
 app bundle id, the app gets deployed automatically and started.
 
-Troubleshooting
----------------
+## Troubleshooting {#troubleshooting}
+
 In some rare cases, it may happen that after a failure, changes are not picked
 up. Most likely, this is caused by a derived data cache that Xcode maintains.
 To wipe it you can run: