Often, during an automated iOS test, it could be helpful to use WEBVIEW contexts in order to faster execute your tests. WEBVIEWs load DOM elements faster than when in a NATIVE_APP context, which dramatically speeds up the process.
The crux comes when your application does not detect multiple contexts or does so inconsistently.
What you can do is provide an additionalWebviewBundleIds capability in your test to resolve this issue. This is only applicable for automated Simulator tests, as Real Devices do not seem to suffer from this problem.
To better understand this (if you are satisfied with this, feel free to stop reading), take a look at the logs snippet below:
On line 14 you can see a list of bundle identifiers that Appium is attempting to search for within the applications available through the web inspector.
On line 10 you can see the bundleId of the webview from the Awesome application. Furthermore, you can see that it is different than the application's bundleId.
com.awesome.awesome.debug != process-awesomeAppDebug
By inspecting the Appium log output under “Current applications available:“ a user can determine the additional bundleId which they must provide to Appium in order to see their WEBVIEWs show up properly in the Appium contexts.
Namely, for the Debug build of the Awesome app, you must provide the following capability (although it may look different if you are not using the Java Appium client):