Whenever Salesforce patches make their way into pre-release orgs our daily test runs kick off and identify the change. These tests run on 15+ org setups and report back any issues that might have been observed. One such observation was reported back during the early days of Summer ‘17 patch rollouts into pre-release. The issue manifested itself initially as the inability to complete the authentication flow on iOS devices built with Salesforce Mobile SDK v4.0.2 and lower.
During the investigations into the issue, we raised a notification on our trust site to keep our partners and customers aware of the risk of the behaviour. We also developed some internal work-arounds. If the issue wasn’t fixed prior to Summer ‘17 making it’s way into our partners’ sandboxes, these would let us unblock them from their development and testing processes.
We also discovered that the bug broke the vanilla experience of browsing standard Visualforce pages on iOS Safari; this could be bad if it got through into production.
When a fix in patch 6.1 came through, our test runs picked this up and we were again able to update our users. We continued to run our daily tests to make sure that this bug, or others, wouldn’t reappear. Thankfully they didn’t and the Summer ‘17 rollout was without incident… but this was not the end.
Surely as cometh the Winter
To our slight confusion, following the introduction of the first Winter ‘18 drops into pre-release, we were flagged by the same failure scenario again. We posted, as we did before, across the array of support channels that exist – G+ Salesforce Mobile SDK Community, Salesforce Dev Forums, etc. This time, however, we had a patch number (for the fix in Summer ‘17), and all sorts of information gathered from the prior investigations. Armed with this, we contacted our AppExchange Partner Account Manager (Gogo Roberts) and the ISV Technical team (in the guise of Michael Holt, who we know well from the London Developer meetup group).
A meeting was arranged with our CTO, our Lead Product Engineer, and Salesforce’s Global Mobile Specialist team. We explained our findings and the impact not only on our customers, but the wider Salesforce user community too. During the call Justin, our CEO, emphasised that changes impacting users of the Salesforce Mobile SDK need to respect that delivering updates to apps used by mobile users is very different from delivering to those running on a SaaS platform. Creating new native builds, testing them, and getting them through the various store processes isn’t a trivial undertaking, and should be appreciated as such. KK Ramamoorthy (Salesforce) acknowledged the gravity of the situation and was very keen to get the issue resolved. He took actions away to contact the relevant product owners and technical teams to find a resolution.
That very evening we heard back from KK, with news that a patch to the issue would be seen in the next rollout. He requested we check our pre-release orgs and verify the fix was in place… Indeed it was, which meant not a single day lost of development or testing for our partners and clients. In fact, we’re only aware of one other company who had raised concerns about the issue.
Let us shoulder the burden
It’s hard enough keeping bugs out of your own code, and not catching them until after launch is costly. The last thing you want, then, is to have to keep an eye out for issues with Salesforce releases or OS updates as well.
That’s exactly why we’ve gone to great lengths to remove these concerns. MobileCaddy’s mobile environment management, QA, and testing processes are always running in the background of every app built with our Application Delivery Framework.
This minimises the risk of app failure, and ensures that enterprise-grade app performance is maintained at all times. Crucially, the MobileCaddy ADF is proactive rather than reactive towards bugs, providing an extra layer of confidence in the stability of our partners’ and customers’ Salesforce mobile apps. This also saves them time and money by reducing the need for troubleshooting and post-deployment maintenance.
Of course, there will always be some manual work required, so when it comes to staying on top of the Salesforce release cycle our team is always there. This article is just one of many examples of how we work directly with Salesforce to maintain reliability for all apps in the ever-changing ecosystem.