There is currently an issue (confirmed by Microsoft) with Xamarin-based apps built for iOS 14.2 – they crash when deployed via MDM (but do not crash if installed manually from store) and only on the newer devices (iPhone XR etc). In this post I will show a solution that we came up with together with one of my customers, who is using Workspace ONE Intelligence. We cannot fix the app, but we can improve the user experience, and save a couple hundred help desk tickets about a known issue that may take a while to fix.
In case of my customer, we have come up with the following scenario:
- Identify the devices really affected by the bug and create a report for analysis
- iOS 14.2 or newer
- Model: anything using arm64e (A12) CPU or newer: iPhone XR, XS, 11, 12 etc (no bug on older devices – leave them in peace)
- App Name includes the affected apps (I will not list them and use another app in the screenshot, not their fault really)
- App installed as managed (if the app is installed manually – its OK).
- Automatically apply a workaround to the affected devices only
- Inform the user of an issue
- Remove the affected app
- Create a “resolved” help desk ticket about the workaround, so that there is some audit trail available for the ITSM tools. I will not include this in my screenshot, since my sandbox does not have help desk integration (if someone knows how to keep a developer instance of ServiceNow alive, w/o having to log into it every now and then – pleas let me know!)
- Prevent MDM takeover of the app when installed by the user
- Basically, uncheck the “Make app MDM managed if user installed” box in app assignment.
Step 1: Identify the devices really affected by the bug and create a report for analysis
The challenge here is identifying the devices – modern MDMs can do wonders when it comes to choosing devices, but when it’s about choosing a specific combination of device and app parameters – things get trickier.
Fortunately, Workspace ONE Intelligence does just that, and for free! Here’s a filter that I used in my sandbox for demo purposes. Below there are explanations
- Row 1: this is a good practice to ensure that any unenrolled / pre-registered devices do not get included into your report
- Row 2: OS Version is a string, so doing just “greater than” is not that easy. Until 14.3 comes out this should suffice. If you want to be precise, you could use Major/Minor versions instead
- Row 3: You can choose as many models as you want, and when using “includes” you will simply select from the dropdown list of the models known to your WS1 UEM. In my case I had to add some of these as custom values, as my most modern test iPhone is iPhone8 😦
- Row 4: This is to exclude apps installed manually from the App store – those are OK for our case
- Row 5: This is kind of obvious
- Row 6: You can use identifier, [friendly] name, or the UEM app ID – whichever you like. The apps here are just sample ones that I had deployed to my test device – they are fine 🙂
Now, let’s make the report only contain data that is relevant. We don’t need many default fields, and some criteria are fixed by out filters, so we can reduce the number of columns and order them the way we like
Now we have ourselves a nice report! We can view it, schedule it, share it via a link to external users (L1 help desk) or even better – automate it!
Step 2: Automatically apply a workaround to the affected devices only
Note that the report above has a nice “Automate” button – this saves a lot of typing and clicking!
One we click that button, our filter will be automatically copied into a Workflow and we can focus on the automation part
First off, we will add the app removal. Depending on the app type you may need to choose a correct action. In my case the apps are deployed using VPP, so I chose Purchased.
Then you have an option to look up app ID via a list or via a UEM app ID. I am an old school person and use the old ID method (which also works with tags and other elements). The ID can be found in the UEM console, when you mouse over the app (profile, tag etc) in the respective list.
Now let’s send user an email. Note that you can use lookup variables liberally.
The next logical step would be to create a help desk log entry, but, as I said before, I don’t have the integration in my sandbox.
This is how the completed Workflow looks like (note that I had to tweak some values to test it on my iPhone8 with iOS 14.0).
As a final touch, you may want to change the workflow type from Automatic to Manual to run it once for existing devices (automatic workflows only trigger for new events, not for existing historical data).
Another thing to do would be to build a dashboard to track the progress of your deployment, but we will cover it some other time 🙂
In this post we had looked at how Workspace ONE Intelligence can be used to solve tricky problems.
- Identify very precise groups of devices based on multiple criteria
- Build multi-step workflows to reduce manual admin work and help desk load
If you found in interesting be sure to check the Workspace ONE Intelligence section on VMware TechZone, and check out the next-gen orchestration engine called FreeStyle (tech preview): short demo and long demo.
As always, let me know your thoughts in the comments!