v2.3.2beta-1 has now been pushed to production. Please check the changelog for details.
If you were to dig through our platform release notes you’d notice that it’s been nearly 18 months since the last major version number update to the platform.
During this time we’ve released 16 minor platform updates to help you navigate through:
- Two major iOS software and hardware releases.
- Support for writing custom native modules using the Swift programming language.
- Four major Android API releases.
- Beta support for Intel’s Crosswalk web runtime.
- More App Store rule changes than anyone (including Apple) keeps track of.
I’ll be honest, surfing this tsunami of change isn’t always fun but once in a while I’ll come across something that reminds me of the value of what we do:
I don’t want to get into a rant about the kind of thinking responsible for this state of affairs but I would like to place it in perspective:
If, twenty years ago, you compiled a C/C++ application for the Windows WIN32 API using C/C++ there is every chance that your original binary executable will still work on Microsoft’s latest Windows 10 release.
Binary compatibility is unfortunately out of our reach and it’s still too early to tell if Trigger.IO will match Microsoft’s track record but we’re certainly giving it the old college try.
If you shipped a HTML/CSS/JS Trigger.IO app in 2012 chances are very, very good that it will still run on the latest versions of iOS and Android without requiring anything more from your side than a
forge build ios && forge build android.
Your legacy? It matters to us.
Platform Version 2.4
The road to 2.4 has been long and I know a lot of you have been patiently waiting for the Crosswalk support from our beta branch to finally make its way to stable release.
Well, I’m pleased to announce that today we finished the last major piece of work that has been holding this back!
Basically, we had two major blockers:
- The Ant build system had problems dealing with application resources from multiple external libraries which led to all kinds of horrible bugs when using Crosswalk with some native modules.
- There was no simple way to test custom native modules in both the Android and Crosswalk environments.
The resolution wasn’t simple but, ironically, it came in the form of the kind of announcement we’d normally dread:
It’s taken the better part of two months, but we’ve finished migrating our Android build system over to Gradle and it has brought a wealth of cool stuff, including:
- Android Studio support for custom native module development.
- Support for using
.aarpackages directly from your custom native modules.
- Support for including module dependencies directly from Maven and other repositories.
- Support for debugging modules against both Android and Crosswalk.
- Support for building x86 and 64-bit packages for Android.
- No more module resource conflicts!
We’ll continue to support Eclipse for as long as possible, but you may be surprised how easy (and pleasant!) it is to move your module development over to Android Studio.
Migrating the Android build system is a massive change and, no matter how much testing we do on our side, there is still potential for things to break.
We’re now officially in feature-freeze for
v2.4 and will be pushing
v2.3.2beta-1 to production early next week.
Depending on how much feedback we get from y’all at email@example.com we’re hoping to pull the trigger on stable release before the end of the year.