Storyline 3 Crashes on iPad Safari and Chrome

Hello, all.

First, I’d like to sincerely thank you for continuing to let us know how important this problem is to you. We cherish our community, and it’s forum threads like this one that really make an impact.

Second, I’d like to tell you a bit more about the root cause of the problem and what we’re doing to fix it:

Some Background

Storyline does two things to produce a speedy learner experience:

1. We quietly preload as much content as possible into memory while the learner is focused on the current slide.
2. We keep visited content in memory after the learner leaves the slide to support the back button.

In doing so, learners can confidently navigate in all directions throughout a course, knowing that whatever slide they need next is preloaded and ready to go.

The Problem

Our customers are great at producing beautiful, media-rich course content, but it’s no secret that Mobile Safari suffers from some memory management challenges. The preload approach serves us well on most devices and browsers, but as many of you have learned, courses with lots of media can crash Mobile Safari. This happens most often on older Apple devices, but even new iPads and iPhones can have trouble keeping lots of multimedia in memory, especially when other tabs or apps are open.

Our Solution

We want to make Storyline smarter about knowing when the browser can handle preloaded content in memory, and we’ve been working hard on logic that:

• Maintains the preload approach on every device and in every browser except Mobile Safari.
• Asks Mobile Safari for information on the age of the device and:
  • Depending on the weight of the slide, preloads some content if the browser can handle it and keeps some content in memory.
  • If the slide is too heavy or the device is too limited, preloads nothing and keeps nothing in memory after exiting the slide. Slides will load more slowly for learners in this scenario, but it should reduce the frequency of crashing.

This is a challenging solution to implement, mostly because of the limited information we get from the browser. This is especially true since iOS is so impacted by other open tabs or apps, about which Mobile Safari tells us nothing.

To make this happen, we’ve been digging deep into the sample projects that many of you have provided and testing them hard against our library of iOS devices in an effort to isolate the limits of Mobile Safari. It’s an inexact science, but we feel confident that we can solve the problem.

I can’t promise a precise release date for the above solution, but it’s super important to us. We have our very best minds working on the problem. We’ll let you know as soon as it’s ready, and thanks again for helping us make this a priority!