With the upcoming release of IOS 9 – with a guess date of the 16th September2015 – we’ve been working hard to make sure your Salesforce.com mobile applications powered by MobileCaddy will be fully supportive of the new OS version. We shall be completely transparent and let you know that this hasn’t been plain sailing.
Since testing the earlier betas things have been getting better, but there’s still a couple of breaking changes that mean your apps need to be updated to work as best they can;
Changes requiring an app store submission
NS Exception Domains
The default version of SSL that the OS plays nicely with has been upped. This mean that applications built with the Salesforce Mobile SDK (including the Cordova Plugin) require some extra configuration to allow the app to communicate with the salesforce.com and force.com domains.
A PR we raised has been included in the 3.3.2 version of the Salesforce Mobile SDK Cordova plugin to support the automatic inclusion of this configuration.
Logins are not Persistent
Along with the above issues with oAuth’ing into Salesforce in the first instance it was also seen that once the app was closed (not just resumed from the background) that the user was required to log in again. A bug was raised to the Mobile SDK team and this fix is now in the 3.3.1 version of the IOS repo and in the 3.3.2 version of the Cordova plugin.
Both these breaking changes result in the need for a new IOS app version. If you’re a MobileCaddy customer then these applications have already been built and submitted for you. If you are building your own device apps then you should also specify config to disable BITCODE in xcode. This is needed as the Salesforce Mobile SDK does not yet support BITCODE. This StackOverflow answer guides you through the process.
Changes requiring a new Application Bundle
Along with the need to have a new device application (IPA) available on the iTunes store (or your enterprise counterpart) there are other changes to be aware of if you are using Angular/Ionic for your core application code.
Delay the Bootstrapping of Angular
For some reason (we are still investigating) it seems that some of the digest cycles run into mass loops (this has been put down to a bug in the UIWebView in the latest version of IOS 9 Beta that is available). One result of this appears to be that apps that rely on the manual bootstrapping of Angular can end up hanging. One solution we have found that seems to work is to, albeit a bit dirty, delay the calling of the bootstrapping.
Original Line…
|
1 2 3 |
angular.bootstrap(document, ['starter']); |
Replace with…
|
1 2 3 4 5 6 7 |
setTimeout(function(){ angular.bootstrap(document, ['starter']); }, 500 ); |
Once your code has had these change applied it is recommended that you deploy to the platform and test on IOS 9 and pre IOS 9 devices. Our experience shows that there is no need to target IOS 9 in this particular case. Using the MobileCaddy Deploy to Salesforce functionality and our Dynamic Versioning it should be possible to target your test users (if you have some) and also dynamically up version your users prior to the IOS 9 release.
Wrap Up
As with prior IOS releases it’s a case of “keep your wits about you” and be prepared as best you can.
And we shall keep you posted on any further findings… though at present it looks like MobileCaddy and even non-MobileCaddy Salesforce mobile application developers should have the fixes they need to have their enterprise apps running.