Storyline 3 Crashes on iPad Safari and Chrome

Is there anyone I can talk to regarding compensation for this fault? My company purchased Storyline 3 the moment it was released and after discovering this fault we have had to revert back to using SL2, as the HTML5/tablet output is the main requirement for our clients.

We feel a bit conned off for purchasing a product months ago that is not being used due to a fundamental flaw in how it works and lack of testing before release.

I understand this must be a big problem for your technical team but we feel it's only fair we are compensated. Please feel free to email me.

Thanks

Phil

Has this issue been addressed in the new version of Storyline 3 that was released on Sept. 11 (Build 3.2.13213.0)?  I did not see anything about it in the Release Notes, but wondering if it has been tested.  

We are experiencing exactly the same issue.

 An identical Scorm package 2004 3rd Edition published in Storyline 3

• Uploaded to Scorm Cloud
• Tested using below devices
  • iPad Mini 9.3
  • iPad Air IOS 8
  • iPad Air IOS 10

Storyline 3 version intermittently  crashes at random slides. Please find the attached screen short of error messages.

Regardless, we have several courses that we need to deliver for the iPad, Safari and Chrome. We have already missed our initial deadline of this past Monday. Please let me know if anyone has come across this issue. If it is a Storyline bug, it needs to be fixed immediately.

To answer Sarah's question, my company is having the same issues with a course published using the latest version.  Granted we are using Storyline 360 (version 3.8.13184.0), not Storyline 3, but I imagine if it wasn't fixed for one it wasn't fixed for the other.

With no fix in sight and no backwards compatibility, we are considering rebuilding the entire course in SL2.  Ugh.

We are so excited about SL3, but we are also afraid to publish in SL3.....even though we have had it since the day it was available.

We play it safe by always building courses in the previous versions, SL1 or 2, then updating them to the latest version.

If problems arise, we just upload the earlier stable version of the module.

Apple product users represent about 99% of our technical issue calls.

It would be great if Articulate could do more to make projects work better with all of Apple's products.

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!

Hi Justin,

Thank you for the excellent write-up about the problem.  I've been developing for years and understand the struggles of memory management and garbage collection.

Could the solution be as simple as only keeping a predefined number of pages in memory?  

For example, let's assume you keep the preloading functionality for the next 3 pages.  Each time a file is loaded into memory, you store the page_id in an array.  Then, if that array is ever going to be larger than the limit, it will unload the items that have less chance of being navigated to.  

It would prioritize pages that have direct navigation tied to them (such as the next page, the previous page, and any pages that can be navigated directly to from this page via triggers).

Sample
Let's say you are on Page D and the limit of the number of loaded pages is set to 6. Before removing any items, the array would look something like like this:  
['A', 'B', 'C', 'D', 'E', 'F', 'G'].

Then, it would check the following logic:

• Page D would never be removed, since it's the current page.  
• Pages E and C would have the highest priority to persist, since they are directly next to Page D. 
• It would then check to see if Page D there are any active triggers that could navigate you to another page (such as a menu button, or if Page D was a sub-menu).  It would prioritize these next.
• Then, it would move on and prioritize Page F, then Page G, in that order.
• Lastly, it would prioritize Page B, then Page A.

In our example, it would mark Page A for removal.

Page A would then be removed from the array, released from memory, and all references deleted so that it COULD be picked up by garbage collection.

This would probably need to happen BEFORE you started loading new content, so that GC could actually have a chance to delete the old content from memory.

Also, there could be other parameters tied to this logic, such as purposely removing items from memory that take up too much memory after they have been viewed.

--------------------------------

From my understanding, the worst case scenario is that the user attempts to go to a page that wasn't pre-loaded.  If this happens, the course pauses and shows the loading animation while it finishes loading the page.  Not that bad, considering the alternative.

I hope this made sense and hope it helps!

Thanks for the input, Adam.  We'll continue to preload as much as we can whenever possible, but sometimes even 2 content-heavy slides are too much for Mobile Safari.  It's a balance for sure!

That's fair.  I realize you have no control over the media-rich content that some of us produce!

Hi Justin,

By when we can expect this issue to be resolved. We have few planned project deliveries scheduled next week and client will not accept such issues. 

Thanks

Hi Sagar. Thanks to both you and Mahesh for your additional information and for checking in.  I can appreciate that you are facing pressure from your deadlines.   We don't have a release date for a fix nailed down yet, but it likely will not be in the next couple of weeks.

Your feedback and frustration haven't gone unheard. We're actively working on the fix, changing how Storyline will behave with iOS as Justin detailed above.  It's not a small task, but a crucial one.  So we're committed to releasing that fix as soon as we can. 

Thanks Crystal for the update.

Our company is seeing the same issue with Storyline 3 SCORM output crashing on iPad devices. We have some very high-priority projects where we are releasing first-time for mobile users, and the performance we're seeing is not going to provide a good user experience right out the gate... We need a fix to this yesterday...

I am curious how other users are explaining this issue to their clients and stakeholders. I am in final stages of LMS testing and I just ran into this issue. Telling my client that the module will not work on an iPad is not going to be an acceptable answer. 

I am also experiencing the crashing issues with courses created on SL 360 and displayed on Safari on the iPad. We have experienced the issue on iPad 3, IPad Air 2 and iPad Pro.

I have noticed that in several occasions, the courses begin to display loading issues, like some of the images take longer to load and display on the screen. Sometimes, after this behavior manifests, the browser crashes.

Other times the courses seems to be playing fine and then all of the sudden the courses just crash randomly. Not always on the same screen.

Some of my courses are published as SCORM packages and others just for the web. The problem is present in both.

Several months ago I submitted an issue to Articulate Tech support (Case #01090918). This issue was about a Storyline course that had a video on every page. The file had about 23 screens. Every time the file course was played on the iPad, videos will stop playing back on Slide 18.

I experimented by loading the same quantity of videos but different videos, and I was able to replicate the issue.

Although the issues are different, they are probably related. It is possible that the crashing of the Safari browser on the iPad and the issue with the video playback are related to a memory or system/browser resources issue.

Please, let me know if there is any update on this issue(s) because it has been negatively impacting several of our projects.

Thank you.

Hi Oscar,

Thanks for sharing the case number here - I'm glad Lea was able to confirm it was a bug, and it is similar to the issue discussed here. As you said, it's related to the memory/browser resources issue and our team is looking at what can be done within Storyline to fix it (scroll up to Justin's reply for specifics). 

As Crystal mentioned, it's not a small task so it isn't likely to be fixed in the next couple weeks. We know this is critical for you and others in the community - so as soon as we have any more info we'll share! 

Hi Ashley, thank you for your reply.  I just noticed a new version build for Storyline 360 (3.9.13488.0) released today. Does this version includes the patch that corrects this issue(s)?

Thanks.

Hi Oscar - Unfortunately not. As you can see from Justin's reply here, this is something that is going to take a bit of research and work to accomplish.

Having iPad issues very similar to those posted above.  Deadline has already past and it's beyond a critical situation.  Will there be a fix soon?

Hi Leslie, did you see the reply to me from Ashley? She already pointed me to that reply from Justin. I was hoping that this new release of SL360 would have included the fix to this major issue.

Hi, all.  We promise that this forum thread will be the first place we visit when our solution is ready.  We won't make you ask us to communicate!

iPad is a major platform of this course's release and we're out of options.  I don't know what changed. Storyline based courses used to run ok on the iPad (html5 output) not to long ago.  Maybe it was going from Storyline 2 to 360.   

Would supplying a source file help?  Standing by.

I applied the last two Storyline patches: Build 3.9.13488.0 and Build 3.9.13510.0. Since then, if I publish my files they work as before, with the same performance issues. But if I make modifications to my files and re-publish, the issues I experienced before are even worst on the mobile devices and also now on desktops. Many of the videos that used to play before I applied the patch appear now frozen on the first frame.

I made backups of my files before saving them with the new Storyline patched versions. How can I revert back Storyline to the un-patched version?

Thanks.

This problem only occurs with SL3 or SL360, I suspect it's something to do with the way they have changed the way it handles HTML5. I have reverted back to using SL2 for this solve reason, hopefully they will sort this ASAP.