For common issues and solutions, check also Troubleshooting the Mobile Apps Generation.
After you start building your apps with MABS 6, you may experience some breaking changes and known limitations. Check this document for more information about the issues and how to fix them.
The most significant change in MABS 6, compared to MABS 5, is the introduction of WKWebView, which makes you mobile apps compliant with Apple's requirements for publishing the app in the App Store. This implies dropping support for iOS 10.
Here is the list of MABS 6 breaking changes, with the instructions on how to fix the issues that may result from the changes.
XHR / Fetch requests to OutSystems servers don't work
XHR / Fetch requests to OutSystems servers fail.
outsystems:// and not
https://, so the
outsystems://hostname.domain. All requests to
https://hostname.domain are considered cross-origin because the
protocol is different between the origin and the target. This makes WKWebView enforce CORS, which is currently not implemented by OutSystems servers. The XHR / Fetch requests to other servers depend on whether those servers implement CORS.
You can try these workarounds:
- Use a Server Action. Starting with MABS 6 with WKWebView, Server Actions calls are made through the native code instead of XHR and they're not subject to CORS validations.
- Implement CORS on the server. If you have access to the backend configuration, ensure that CORS is implemented correctly and that the application origin header value is allowed.
- Use a Cordova plug-in such as cordova-plugin-advanced-http to "proxy" the HTTP requests using native code (outside WKWebView), as this bypasses CORS altogether.
Cookies from OutSystems servers aren't accessible from document.cookie
Cookies from the OutSystems servers aren't accessible from
document.cookie is not available in MABS 6, use the internal API to display cookies:
RedirectToURL Event fails
The RedirectToURL Event fails on MABS 6.
Because the iOS applications from MABS 6 load with
outsystems://, and not
https://, redirects with the absolute URLs to another OutSystems app fail.
You can try these workarounds with RedirectToUrl:
- In MABS 6: for iOS use the custom scheme
outsystems://, for Android use
- In MABS 5.X: and earlier: use
https://for both iOS and Android.
- If you're targeting different MABS versions and platforms, implement custom logic that checks platform in use (MABS 6 or earlier) and sets the correct URL (
Additionally, use the relative URLs whenever applicable.
As a best practice, open URLs by using the InAppBrowser plug-in, as this way you maintain the context of the current app. Note that when using the InAppBrowser plug-in you should always use
https:// for both Android and iOS, independently of the MABS version.
Here are the MABS 6 known limitations.
Web Inspector doesn't show Network information
Safari Web Inspector doesn't show Network information about Server Actions requests.
Since January 2020, MABS 6 comes with the network inspector feature. Rebuild your apps and use this feature to troubleshoot the app network issues in iOS.
Images don't render in iOS when using Content Security Policy
After generating a mobile app with MABS 6, some or all images, fonts, videos, scripts, or stylesheet resources, don't load when running the app in iOS. Upon inspection in Safari, you can see one or more error messages similar to this in the console:
Refused to load the image 'http://subdomain.example.com/path/to/image' because it violates the following Content Security Policy directive: "img-src 'self' data: subdomain.example.com blob:".
Due to some changes in MABS 6 that require mobile apps to load using
outsystems:// when running in iOS devices, some less strict Content Security Policy (CSP) directives such as
img-src 'self' data: subdomain.example.com are now violated when loading resources from such hosts. The violations don't occur when running in Android because the Android still loads applications using
https://, just like in MABS 5.
You can fix this issue by updating the CSP configuration for mobile apps and ensuring that all URL expressions are prefixed with
https://. You can find some examples in the document Apply Content Security Policy.