Forge Platform v2.8

Both Android “Q” and iOS 13 are now in beta and we’ve begun the process of updating the Forge Platform to support the releases.

We’re trying something different this year and will be making early access releases available right at the start of development.

Be warned though, this means things are likely to break more often than not! :slight_smile:

The final v2.8 release will be in Q4 2019, probably shortly after Apple releases the iOS 13 GM to the public.

Until then you’ll be able to find the release notes for the latest Alpha/Beta versions of Forge v2.8 here:

We’ve also started working on the migration guide which you can find here:

When reporting issues, please include:

  • Your application’s src/config.json and src/identity.json files.
  • Your host operating system. (e.g. macOS, Windows)
  • Details of the hardware you are testing on. (e.g. iPhone XR, Pixel 3)
  • Which version of Android/iOS you are testing on (e.g. Android “Pie”, iOS 12)
  • Any log output leading up to your issue. (e.g. output from the forge command, the contents of forge-error.log and/or any relevant output from adb logcat )
  • Any sample code we can use to replicate the error.

This is great news, thanks for being proactive about these platform updates. Hope we can get into some testing soon :slight_smile:

Hi Antoine,

I am using the

“platform_version”: “v2.8.1alpha-4”,

to create an app for IOS, and I noticed in the Release notes that during alpha-2 this note: * Minimum iOS version supported is now: iOS 11.4

When I attempt to use

“minimum_version”: “11.4”,

in my config.json file, I get the following error when Packaging for IOS:

[ERROR] Forge API call to app/a7f492b8610411e3b0831231392b77b0/build went wrong: Value u’11.4’ for field ‘minimum_version’ is not in the enumeration: [u’10.0’, u’10.1’, u’10.2’, u’10.3’, u’11.0’, u’12.0’]

If I try to use 11.0 I get a different set of errors, and if I try to use 12.0, Apple will not accept this as a minimum version. Can you help?


<< schnip (please include large files as attachments to posts rather than pasting) >>

Identity.json file:

<< schnip (please include large files as attachments to posts rather than pasting) >>

I am using macOS on an macMini to build.

We’re in the process of deprecating the minimum_version field.

Can you please try leaving it out entirely for the time being?

If that doesn’t work, can you please provide more detail of the errors you get when setting it to 11.0?


I removed the minimum_version and was able to forge, but Apple rejected the file with the following comment:

ITMS-90111: Invalid Toolchain - Your app was built with a beta version of Xcode or SDK. Apps submitted to the App Store must be built with the GM version of Xcode 9 and the SDK for iOS 11, tvOS 11, watchOS 4, or macOS 10.13 or later.

I have followed the Migration Guide v2.8 and found that images don’t cache in iOS 13.

Our app caches images with the file module, which I updated to version 2.24 as instructed in the Migration Guide. In iOS 13, images are not being cached and therefore don’t appear in the app. This problem is unique to iOS 13. On Android 10 the images are cached and appear correctly.

The error I receive in the console isn’t very descriptive, but here it is:
[DEBUG] Returned to javascript: {
callid = “F1D6A10E-7538-49ED-AC32-6814F9775DCA”;
content = {
message = “Unable to save to file”;
subtype = “<null>”;
status = error;

Any tips?

Ah okay, we’ll have to wait then until Apple release the final version of Xcode :slight_smile:

The way I’ve done it in the past is to remove the alpha/beta designators from our platform versions as soon as Apple releases the gold master and we can get it deployed onto the build servers.

Thank you for reporting this, it’s probably a side-effect of directly integrating the httpd module into the platform.

You can track the issue here:

Okay, there was an issue where the iOS 13 version of WKWebView wasn’t recognising the custom content handler we’re using to load the cached images.

I’ve tested the fix against v2.24 of the file module and:

"platform_version": "v2.8.1alpha-5"

That said, I think this might be different to the issue you’re having as your logs are throwing a Unable to save to file error.

If the new release doesn’t resolve your issue can you please send me a small code sample I can use to reproduce the Unable to save to file error on my side?

In particular, the URL you’re trying to cache may be key to reproducing the error.

The fix added in v2.8.1alpha-5 solved the cached image problem for iOS 13. Thank you.

1 Like


Release notes:

Google started shipping the final Android 10 release for some manufacturers (Google Pixel, Essential PH-1, Redmi K20 Pro) last week.

Apple announced their new phones and shipped the 11.0 GM for Xcode last night.

There’s been some weirdness around whether the first version of iOS 13 will be 13.0 or 13.1 so we’re still waiting on Apple for the iOS 13 GM.

That said, going by previous years, whatever they release to the public as iOS 13 will most probably happen next week Monday, 16 September.

All this means that v2.8 of Trigger.IO Forge is now officially in Beta :slight_smile:

Apple usually start accepting app submissions after the release of the Xcode GM so brave souls can try building against v2.8.1beta-1 and submitting their apps.



  • Fixed: Breaking user interface behaviors on different Android versions and devices featuring display cutouts. Behaviors have been standardized as follows:
    • All Android versions: Status Bars are hidden when device is rotated into landscape mode
    • All Android versions: Status Bars are opaque when viewport_fit: auto
    • All Android versions: Status Bars are opaque when the navigation bar is enabled
    • Android < 28: Status Bars are always opaque
    • Android >= 28: Status Bars are transparent for viewport_fit: cover
  • Fixed: Status bar overlaps content on Samsung Galaxy S4 and S5 devices.


  • Add support for new iPhone 11 simulators


  • tabs : 3.1
    • Update screen layout behaviours for Android v2.8.1beta-2
    • Fixed: Memory is not released when closing tab on Android
    • Fixed: Xcode 11 GM release returns incorrect y position for navigation bar
    • Fixed: Xcode 11 GM release corrupts iOS 12.4 display when tab is dismissed



  • Reverted: Force Android support library version for Crosswalk builds


  • Update Xcode to 11.1 GM Seed

This will be the final Forge beta before we officially release v2.8.1 to production. We’re now just waiting for Apple to push Xcode 11.1 to general release.

Apple pushed Xcode 11.1 and macOS Catalina to release this morning which means that v2.8 is out of beta and v2.8.1 is now the latest stable version of the platform:

Pushwoosh push notifications are broken on iOS 13 and 2.8.1.
Pushwoosh push notifications work on iOS 12 and 2.8.1
Pushwoosh push notifications work on iOS 13 and 2.8.1alpha-5
Pushwoosh push notifications are broken on iOS 13 and 2.8.1beta-1

What changed between 2.8.1alpha-5 and 2.8.1beta-1 that could break push notifications on iOS13?

I checked the console and there is an error with registering the device with Pushwoosh.

[PW] [I] -[PWRequestManager] 
|    Pushwoosh request:
| Url:
| Payload:  {"request":{"gateway":"production","jailbroken":0,"notificationTypes":0,"app_version":"2.11.3","application":"43689-65D56","sounds":[],"device_type":1,"userId":"E774EE6E-05D5-4A7D-A9C9-1F96B86814A1","language":"en","hwid":"E774EE6E-05D5-4A7D-A9C9-1F96B86814A1","package":"","timezone":"-21600","os_version":"13.1.3","push_token":"{length=32,bytes=0xac661dc9e0b6dda7b74a630865326ba6...8a9dbc1f310dcee7}","v":"5.15.1","device_model":"iPad7,3"}}
| Status:   "200 no error"
**| Response: {"status_code":210,"status_message":"Invalid token:** {length=32,bytes=0xac661dc9e0b6dda7b74a630865326ba6...8a9dbc1f310dcee7}","response":null}

I’ve double-checked the push cert, app id, and provisioning profile. I don’t know why I’m getting an invalid token response. Also, the same app works on iOS 12 - only fails on iOS 13.

Thank you for the detailed report!

There’s nothing that would have caused this from our side but the only difference between those two versions is that 2.8.1beta-1 was the first version to use the GM (Gold Master) [1] release of Xcode 11. There were no other changes between alpha-5 and beta-1.

So, given also that Apple often make catastrophic changes between their final beta and release versions, it’s likely something changed either in Xcode or the iOS SDK.

That said, we’ve now pushed v2.8.1 to stable release, have you checked to see if the problem occurs there as well?

Edit: Also, are your device(s) on the final release version of iOS?

Either way, this is something that Pushwoosh will need to address from their side, have you spoken to their support?

[1] Named from the days when writable CDROM’s had a gold-coloured surface. The final release would first be burned onto one of these before being couriered to the factory for replication :slight_smile:

Hi Antoine. We tested with 2.8.1 as well against 13.1.3 (latest iOS) and got the same result. This build works on iOS 12.4.x with pushwoosh. We will reach out to them. However in the meantime is there any way you can make 2.8.1alpha-5 available for us to build against? We were planning to release this week until this hurdle, and sometimes Pushwoosh can take several weeks to address library issues.

This does not help in any way with pushwoosh but if you are just doing simple Push you may want to look at switching to a parse setup, its way cheaper then pushwoosh (and stable)

I used pushwoosh a while ago and it was pain, issue like you have reported not to mention a somewhat clunky admin (may be different now)

With parse you have a lot of options from self hosting on things like Heroku to cloud offerings like (its 5.00 a month)

Setup is very easy too, just add parse and bolts modules to project, add the keys and you are set

Unfortunately not, we removed 2.8.1alpha-5 because it used a pre-release version of Xcode and the iOS SDK. Apple will reject your app if you try to submit an app built against that version.