Overview

Firstly, Rapise uses the open-source Appium API to connect to devices to automate them, this is similar to how you can access a web browser on a Desktop computer using the Selenium WebDriver API.

When you want to record and/or execute a test against a web application running on mobile Safari (that is itself running on an Apple iOS device) you are essentially using Rapise together with Appium to connect to the device and then using the "Web Context" (vs. Native Context) to send WebDriver commands to the mobile browser.

Limitations

Due to the nature of how Appium works, plus some restrictions imposed by Apple, there are some limitations you should be aware of:

Cross-domain iFrames

Same-origin policy prevents Appium from automating iFrames that have a different domain to the parent. In addition, we found in our testing that it actually does not work for any kind of IFRAME, same origin or different origin.

Subdomain workaround

If the parent and the iFrame share the same domain (e.g. site.com and shop.site.com), you can set document.domain on both the parent and each iFrame to a common domain. This solves the same-origin policy issue and allows automation. For example:

Parent:

<html>
  <head>
    <script>
      document.domain = 'site.com';
    </script>
  </head>
  <body>
    <iframe src="http://shop.site.com" width="200" height="200"></iframe>
  </body>
</html>

Child iFrame:

<html>
  <head>
    <script>
      document.domain = 'site.com';
    </script>
  </head>
  <body>
    <p>This is an iFrame!</p>
  </body>
</html>

General IFRAME Issues

In our testing with Rapise on some complex applications that use multiple nested IFRAMEs, we also found that regardless of whether they are same-origin or cross-origin, Appium with iOS was not able to access the objects, therefore Rapise was also not able to access the objects.

So you should ideally ask your developers to avoid using IFRAMEs as much as possible if you want to be able to reliably test them using Rapise when running on mobile iOS Safari.