Trouble with Single App Mode

Could you send the settings you're using, so the MDM deployed settings and in case you're starting exams with different settings those as well (please remove passwords or replace with something you can tell me like "quit"). You could also try to send the log files from an affected device, just after the issue happend. The "Send Logs to SEB Developers" button in at the bottom of the license text in the About SEB window. This can either be invoked from the web browser view (when there's no exam running, no single app mode active) or when there are no client settings by tapping the SEB icon in the Initial Configuration Assistant (you can reset SEB settings temporarily if necessary, in the SEB menu in Settings.app).

I would also need a step-by-step description how exams are started in your case.

This error is displayed when the device is already running in a single app mode (manually activated Guided Access, the classic Single App Mode invoked by MDM, the Apple Classroom app or similar or if the default AAC Assessment Mode is being started and this is interrupted by another attempt to invoke AAC). Don't know if Intune itself tries to invoke a single app mode (is SEB being started directly by tapping its icon ?).

Btw. if possible please try it with the beta of the next iOS version, where I integrated some improvements (although I'm not sure if they help for the MDM issues). I will send you the TestFlight link.

The Intune settings are attached. We run SEB with default settings.
The users log in to Inspera, provide a test code, and starts SEB by a button on the Inspera website.

I will be back with logfiles. (My test has expired...)

Single App Mode are disabled in Intune.

Logs from failing iPad

Looking at the logs I don't see why it would be related to MDM, but it also looks like I have to improve logging to get more information out.

But I have a suspicion what happend on that devices: When users log into Inspera in another browser, let's say Safari and start SEB from there, iOS displays the "Back to Safari" link in the iOS Status Bar on the top left ("< Safari"). There's a bug in iOS 14, when tapping that link, iOS switches back to that previous app even when in the AAC single app mode. Students are then locked in that other app and I think only a restart of the device helps (at least on my iOS devices). Maybe on managed devices a restart isn't necessary, and students come back to SEB by tapping the start exam on the Inspera page in Safari again. It looks like that happend. Apple has to fix that bug, but there's a workaround, Inspera has to add these settings:

mobileStatusBarAppearance = 0
mobileStatusBarAppearancesExtended = 0

Then the Status Bar and this back link is not displayed.

Maybe I have been unclear:
When a student starts a test in SEB, the dialogue-box SEB_1 appears.
When clicking "OK", the error message appears immediatley.
If they perform a hard reset, it works fine for the rest of the day. Then the problems starts again. The next day or so...

Did you try it out yourself or is this what students told you?

I could imagine that a student won't tell you if they found out that they can go back to Safari, research stuff there and then they either managed to switch back to SEB (which I was told should be possible with this bug described above, I never was able to get back) or they restarted their device and then told you that there was a bug (leaving out that they were able to use Safari during the exam...).

The log is not clear, but it's clear that SEB was for some reason backgrounded (which should not be possible while it is in Single App Mode and then terminated, most likely by the user (swiping it up in the iOS app switcher). After that, the single app mode cannot be activated and this error dialog box 1 is displayed.

The log doesn't prove that anybody was cheating or trying to cheat, but it suggests that some user action caused the issue. When dialog 2 is displayed, students have to confirm it with "YES". If they try to press the home button on their iPad instead or tap "NO" and force quit SEB and start all over again maybe iOS comes into this state where the single app assessment mode cannot be invoked anymore. To be clear: I can just start and end it in code, the rest is done by iOS and I don't have any influence and don't get any internal error messages back. So as long as I cannot reproduce this issue, I probably can't solve it.

I think the only thing to help understand the issue would be if you try to reproduce it yourself, while filming the screen of the iPad (from the beginning until the isse occurs). You would need to use another device as SEB stops the screen capture over a Lightning-USB cable. If successful, again send that log file. Only then I might be able to reproduce or analyze step-by-step what happened and what went wrong.

For sure Inspera HAS to add those two settings for the workaround of the iOS 14 bug, as that issue would allow students to cheat or it could cause other problems.

I will release an update with the same workaround in code, but for specific reasons I can't do it immediately.

Yes, I can see it myself.

Here it comes, as a film...

Ok, I can see SEB crashes after activating the AAC single app mode. When the AAC mode is on an the app crashes, it's usually/sometimes (I have to check that, maybe there is a difference between MDM managed devices and non-managed ones) restarted by iOS, but then it cannot restart the single app mode (which is normal after a crash while in AAC). I need to find out the reason for the crash.

Did you select to share diagnostics data with Apple and developers on those iPads? Then I get the iOS crash logs automatically (but I have to guess which of those it could be, as they are anonymous). But better would be if you could send me the crash log of that device directly. This is either possible with Xcode in the Devices window (but if you're not a developer you probably didn't do that before). Or you can go to the Settings app / Privacy / Analytics & Improvements, scoll to SEB.xxxxxxxxx.ips in the list and send me those files please.

The video really helped to understand what happens, thanks for that!

Me and a colleague has enabled "Share With App Developers" on faulty iPad's.
Hope You get some logs.
We can't find any SEB.xxxxxxx.ips-logs in "Analytics Data"

I think I found a possible reason for the crash right after activating the Single App Mode, there were also some crash logs which could confirm that (but only from a few devices, I still don't understand why it happens only on some devices).

I updated the SEB iOS beta version, please test if the crash still happens with that version. I also improved logging, so I might be able to analyze the problem better if I get logs from that version. You can use the public TestFlight link to get access to the beta version:
https://testflight.apple.com/join/egxLmc4j

Hello!
I'm sorry to say this, but we get the same error with the beta,
Crash-log attached.

It looks like the crash actually happens when loading the web page, not in the place I suspected it to. The log entry before SEB being backgrounded and terminated is
2021/03/03 12:35:33:567 -[SEBBrowserController customHTTPProtocol:didReceiveAuthenticationChallenge:]: didReceiveAuthenticationChallenge

Maybe you have some special network settings on the devices deployed by MDM, I see .WebContentFilter in your Intune settings. Maybe that interferes with the custom HTTP protocol used in SEB. Or you have some other special network settings not visible in those Intune settings you posted, like a custom root or other custom SSL/TLS certificate deployed on your devices, a proxy server or VPN.

I really would need the crash log, otherwise I can only try to improve logging to figure out where exactly SEB crashes. Are you 100% sure you don't have any SEB.(anything following after "SEB.") files in Settings app / Privacy / Analytics & Improvements / Analytics Data / ? Maybe on that Analytics & Improvements page, "Share iPhone & Watch Analytics" and "Share With App Developers" has to even be selected to save the crash log files locally. In TestFlight it takes some time (maybe a day or two) for crash logs to show up.

We have "Share With App Developers" activated, but no SEB.xxxxx in "Analytics Data"

Do You think it can help to allow the url/domain in Web Content Filter?

It would still be good to get an iOS crash log (not the SEB log file you sent), but after some short research, it seems like crashes in apps using the UIWebView embedded web browser when WebContentFilter is enabled are a known issue.
https://stackoverflow.com/questions/44057041/ios-uiwebview-crashes-randomly-on-webcoreframetreetop

I guess it might help if you make sure that all URLs (or its domains) accessed by SEB are allowed in the Web Content Filter (which I never used, I have to see how it works exactly). It might be hard to not miss specific URLs (for example a single sign on system may access a federation authentication server with a diffent domain than your exam system). Inspera Assessment I think runs on Amazon cloud servers, so you would need to add that domain(s) as well. You could use the URL filter feature in SEB to avoid SEB accessing other domains than you also allow in Web Content Filter.

I'm working on integrating WKWebView into SEB for iOS and macOS, with this modern embedded browser engine the error doesn't seem to happen according to the posting above. Should be available in April I hope.

I'm sorry, but we don't seem to get any crasch-logs.

Maybe they are only created on devices enabled for development. Did you try to add allow rules to the Web Content Filter?

Yes I added https://gavle.inspera.com/ as allowed domain.
Not sure if it worked. Need to test for a few days...

Still the same error...

Inspera uses Amazon cloud servers, those probably also would need to be included in the Web Content Filter allowed list.

But I think this would get too complicated, I'm working on integrating WKWebView, when that is finalized next month, that UIWebView issue should be fixed generally. WKWebView should help making SEB more stable, as crashes in the web engine (which runs separate processes) don't crash the app itself.