Mobile Learning Standards: The Definitive SCORM on iOS and Android Guide for LMS Admins, Developers & Instructional Designers [2026]

SCORM’s JavaScript-based runtime communication model was architected for desktop browsers in 2000 – long before iOS 2.0 shipped in 2008, and three years before Android existed. The practical consequence in 2026 is this: SCORM 1.2 and SCORM 2004 (4th Edition, finalized 2009) will run on mobile, but the conditions under which they silently fail are specific, recurring, and largely undocumented in a single place. This guide consolidates those failure modes, their root causes, and their fixes – covering the iOS WebKit engine restrictions, Android WebView constraints, cross-origin iframe blocking, Safari ITP (Intelligent Tracking Prevention), and the architectural path to cmi5 when SCORM’s limitations become structural rather than solvable.

How SCORM Actually Works on Mobile: The Runtime Communication Model

SCORM is not a content format. It is a communication contract between a browser-hosted SCO (Shareable Content Object) and a JavaScript API object injected into the browser window tree by the LMS.

SCORM 1.2 uses LMSInitialize(), LMSGetValue(), LMSSetValue(), LMSCommit(), and LMSFinish()– all resolved by recursively walking window.parent, window.opener, and window.top until the API object is found.

SCORM 2004 (4th Edition) replaces that with Initialize(“”), GetValue(), SetValue(), Commit(“”), and Terminate(“”)under the API_1484_11 namespace, with the same parent-window traversal logic.

The critical architectural constraint: the SCO and the LMS API object must share the same browsing context or an accessible parent frame. On mobile, this breaks in four specific ways.

The SCORM 1.2 Runtime Data Model (Key CMI Elements for Mobile Tracking)

cmi.core.lesson_status → “passed” | “failed” | “completed” | “incomplete” | “not attempted” | “browsed”

cmi.core.lesson_location → bookmark string (max 255 chars in SCORM 1.2)

cmi.core.score.raw → numeric score

cmi.core.session_time → HH:MM:SS.SS

cmi.suspend_data → free-form string up to 4096 chars (critical for resume on mobile)

The SCORM 2004 Equivalent (cmi namespace, 4th Edition)

cmi.completion_status → “completed” | “incomplete” | “not attempted” | “unknown”

cmi.success_status → “passed” | “failed” | “unknown”

cmi.location → bookmark (max 1000 chars – a key upgrade over 1.2)

cmi.score.scaled → -1.0 to 1.0 (replaces raw-only scoring)

cmi.session_time → ISO 8601 duration (PTxHxMxS)

cmi.suspend_data → 64,000 chars (vs 4,096 in 1.2 – matters enormously for mobile resume)

Why the version matters for mobile: cmi.suspend_data in SCORM 1.2 caps at 4,096 characters. Complex branching courses built with Articulate Storyline or Adobe Captivate routinely exceed this when storing interaction state, causing silent truncation and broken resume behavior on mobile devices that experience frequent interruptions.

The imsmanifest.xml and Mobile Launch

Every SCORM package’s imsmanifest.xml defines the SCO entry point and sequencing rules. A minimal manifest structure:

<?xml version=”1.0″ encoding=”UTF-8″?>

<manifest identifier=”com.example.course1″ version=”1.0″

xmlns=”http://www.imsproject.org/xsd/imscp_rootv1p1p2″

xmlns:adlcp=”http://www.adlnet.org/xsd/adlcp_rootv1p2″>

<metadata>

<schema>ADL SCORM</schema>

<schemaversion>1.2</schemaversion>

</metadata>

<organizations default=”ORG-001″>

<organization identifier=”ORG-001″>

<item identifier=”ITEM-001″ identifierref=”RES-001″>

<title>Module 1</title>

<adlcp:masteryscore>80</adlcp:masteryscore>

</item>

</organization>

</organizations>

<resources>

<resource identifier=”RES-001″ type=”webcontent”

adlcp:scormtype=”sco” href=”index.html”>

<file href=”index.html”/>

</resource>

</resources>

</manifest>

On mobile, the href attribute must point to an HTTPS URL. iOS App Transport Security (ATS), enforced since iOS 9, blocks all HTTP resource loads inside native app WebViews. If your LMS delivers SCORM packages from an HTTP endpoint, content will silently fail to load on iOS in-app WebViews, even if the LMS itself runs on HTTPS.

iOS-Specific SCORM Constraints

1. Safari ITP and Cross-Origin iFrame Cookie Blocking

Safari’s Intelligent Tracking Prevention (ITP), introduced in Safari 11 and significantly hardened with each subsequent version, blocks third-party cookies in cross-origin iframes. SCORM LMS implementations that serve content from a CDN or static file host on a separate domain (e.g., LMS on learn.company.com, SCORM assets on cdn.assets.com) will have the LMS API object inaccessible to the SCO because the browser treats the iframe as third-party.

Root cause: The SCORM API discovery traversal calls window.parent.API across an origin boundary. ITP’s cross-site tracking prevention partitions storage and, in some configurations, blocks script access across frame origins.

Fix options:

• Serve SCORM content from the same registrable domain as the LMS (or a subdomain). E.g., content.company.com and learn.company.com both satisfy same-site requirements.
• Use document.domain normalization (deprecated and removed in Chrome 115; not a long-term solution).
• Migrate to cmi5, which uses a URL-parameter-passed xAPI endpoint rather than DOM traversal – completely immune to this issue.

2. WKWebView localStorage Volatility

iOS native LMS apps using WKWebView (required since WKWebView replaced UIWebView, which Apple deprecated in iOS 12 and removed support for in 2020) have a documented issue: localStorage written in WKWebView is not guaranteed to persist across app suspension cycles when the OS reclaims memory.

As documented in Apple Developer Forums (thread #742037), localStorage in WKWebView can be lost during retrieval after the initial set when the OS evicts the process. SCORM packages that rely on localStorage for intermediate state buffering before LMSCommit() – a pattern common in some authoring tool outputs – will lose that buffer silently.

Fix: Confirm with your authoring tool vendor that LMSCommit() / Commit(“”) is called at every navigation event, not only on LMSFinish(). In Articulate Storyline, this is configured under Publish > LMS > Reporting and Tracking > Every slide rather than only on exit.

3. window.open() in WKWebView

SCORM packages that launch assessment windows or resource pop-ups via window.open() – a pattern common in legacy courses – will silently fail in both iOS WKWebView and Android WebView. Neither WebView implementation forwards window.open() calls to external browser windows; the call returns null.

Fix: Repackage the SCORM content to use inline navigation (window.location.href or in-frame navigation) rather than popup windows. Configure your LMS to launch the SCORM player in current window mode rather than new window/popup mode wherever possible.

4. HTTPS/ATS Enforcement

All resource URLs within a SCORM package must use HTTPS on iOS. Mixed-content (HTTP resources in an HTTPS frame) and HTTP-only content served inside WKWebView will be blocked by ATS without throwing a JavaScript error that’s visible in SCORM logs. The failure mode is a blank white screen or a partially loaded course with no error in the LMS.

Android-Specific SCORM Constraints

Android’s SCORM behavior depends heavily on where the content is accessed:

• Chrome for Android: Nearest to desktop Chrome behavior. Most reliable for SCORM delivery. Supports all modern JavaScript APIs used by SCORM runtimes.
• Android System WebView (LMS native apps): More restrictive. The window.open() issue applies identically to iOS. JavaScript console errors are not surfaced to the user. File API access patterns differ from desktop Chrome.
• Samsung Internet Browser: Uses a separate rendering engine configuration; has historically had quirks with postMessage cross-frame communication used by some LMS implementations to proxy SCORM API calls.

Android-specific gap not covered in most guides: Android WebView apps must explicitly call webView.getSettings().setJavaScriptEnabled(true) and webView.getSettings().setDomStorageEnabled(true) in the native application code. If the LMS vendor’s Android app doesn’t enable DOM storage, localStorage calls inside the SCORM package fail silently – causing cmi.suspend_data to never persist and breaking all resume functionality.

SCORM Mobile Compatibility Matrix: LMS, OS, and Browser

Version note: SCORM 2004 4th Edition (the final ADL release, published 2009) is the recommended version for mobile deployments because of the larger cmi.suspend_data limit (64,000 vs. 4,096 chars), ISO 8601 session time formatting, and cmi.score.scaled. However, SCORM 1.2 remains more universally supported across LMS platforms and is less prone to sequencing engine inconsistencies.

Implementation Steps for Mobile SCORM Deployment

Step 1: Validate Content Delivery Architecture

Before touching authoring tool settings, confirm your content delivery architecture satisfies same-origin requirements:

✅ Correct: LMS at learn.company.com | SCORM content at learn.company.com/scorm/

⚠️ Risky: LMS at learn.company.com | SCORM content at cdn.thirdparty.com/content/

❌ Broken: LMS at https://learn.company.com | SCORM content at http://content.company.com/

If using a CDN for SCORM asset delivery, ensure the CDN domain is a subdomain of your primary domain and that your LMS is configured to serve the SCORM API on the same origin as content.

Step 2: Authoring Tool Export Configuration

For Articulate Storyline 360 (SCORM 2004 4th Edition):

1. Publish > LMS > Select SCORM 2004 4th Edition
2. Under Reporting: Set tracking to Slides viewed with threshold, OR Quiz result – not both simultaneously unless your LMS handles compound completion criteria
3. Player > Uncheck Launch player in new window – this is the single most common cause of popup-blocked failures on mobile
4. Verify output does not contain .swf references

For Adobe Captivate (2019 and later):

• Publish Settings > SCORM > Select version
• Set Manifest Identifier to a unique reverse-domain string
• Under Quiz > Reporting, set LMSCommit frequency to per-interaction, not just on exit

Step 3: Test on SCORM Cloud Before LMS Deployment

SCORM Cloud (Rustici Software) is the reference SCORM implementation. Upload your package and test on actual mobile devices – not browser developer tools mobile emulation, which does not replicate WKWebView or Android WebView constraints.

If content fails on SCORM Cloud mobile but works on desktop, the issue is in the content package or device configuration. If content passes SCORM Cloud mobile but fails in your LMS mobile app, the issue is in your LMS configuration or native app WebView settings.

Step 4: LMS-Side Mobile Configuration

For Moodle (4.x):

Site Administration > Plugins > Activity Modules > SCORM package

→ Set “Display package” to “Current window” (not “New window”)

→ Enable “Auto-commit” in SCORM defaults

→ Confirm SCORM secure frames setting matches your content hosting

For SuccessFactors Learning (mobile): Per SAP documentation (Mobile Learning Guide, April 2023): Set Launch Method to Document Type for content served to mobile. Browser launch type does not function correctly in SAP SF Mobile and should not be used for mobile-targeted content.

Step 5: Offline Strategy Decision

SCORM has no native offline specification. The options are:

Common Mobile SCORM Errors and Fixes

Error 1: Completion Not Recorded on iOS Safari (Most Common)

Symptom: Learner completes course, LMS shows “In Progress” or no data. Reproducible specifically in Safari; Chrome on the same device works.

Root cause: Safari ITP blocking cross-origin iframe communication between SCO (on CDN domain) and LMS (on separate domain). LMSSetValue() calls may execute in the SCO’s JS context but never reach the LMS API object, which is inaccessible across the origin boundary.

Fix:

1. Host SCORM content on the same registrable domain as the LMS
2. If using a cross-domain setup, implement postMessage-based API proxy where the LMS iframe listens for SCORM API calls and forwards them – requires LMS customization or a middleware layer
3. Test with Safari’s ITP temporarily disabled (Safari > Preferences > Privacy > Prevent cross-site tracking: OFF) to confirm diagnosis

Official reference: ADL SCORM RTE Specification, Section 3.2.1 (API Discovery Algorithm); WebKit ITP documentation at webkit.org/tracking-prevention/

Error 2: Course Launches to Blank White Screen on iOS

Symptom: SCORM course opens an in-app browser or WKWebView, displays blank white screen. No error in LMS logs.

Root cause (90% probability): HTTP content in an HTTPS context (ATS violation) or a window.open() call returning null in WKWebView, causing the launch to silently fail.

Root cause (10% probability): User agent sniffing in the SCORM package JS that incorrectly identifies the WKWebView as an unsupported browser and aborts initialization.

Fix:

1. Verify all resource URLs in imsmanifest.xml and content files use HTTPS
2. Search published output for window.open() and replace with in-frame navigation
3. Disable any UA-sniffing compatibility checks or update them to include WebKit/605 (WKWebView UA string)

Error 3: Resume (Bookmark) Not Working After Mobile Interruption

Symptom: Learner is mid-course on mobile, switches apps or receives a phone call, returns to LMS, and course restarts from the beginning.

Root cause: cmi.suspend_data either not being written (authoring tool only commits on LMSFinish(), which never fires if the browser navigates away), or being written but truncated (SCORM 1.2 4,096-char limit exceeded).

Fix:

1. In authoring tool, enable slide-level or interaction-level LMSCommit() calls
2. Switch to SCORM 2004 4th Edition for the 64,000-char cmi.suspend_data limit
3. Confirm cmi.core.exit (SCORM 1.2) or cmi.exit (SCORM 2004) is set to “suspend” on page unload, not “normal” or empty

Diagnostic: Check SCORM Cloud’s detailed log viewer – if LMSFinish() never appears in the session log, the course is not committing before the browser context is destroyed.

Error 4: window.open() Popup Blocked on Android WebView / iOS WKWebView

Symptom: SCORM course attempts to open a quiz or resource in a new window; nothing happens. No error message.

Root cause: WebView implementations on both platforms do not pass window.open() calls to the system browser. The call returns null. Moodle’s documentation explicitly notes: “This is not a limitation of the app, it is a limitation of the complete iOS/Android WebView implementation.”

Fix:

1. Repackage SCORM content to use in-page navigation
2. In Articulate Storyline: Player settings > Uncheck “Launch player in new window”; Ensure no slides use “Open URL/file” with _blank target
3. In Moodle: Set “Display package” to “Current window”

Error 5: LMSFinish() Returns false on Back Navigation (iOS)

Symptom: Learner taps the device back button or browser back while in a SCORM course. LMS receives no completion or suspend data. iOS-specific.

Root cause: iOS Safari and WKWebView handle window.onbeforeunload and window.onunload inconsistently. When the back gesture triggers a page navigation, the SCORM package’s unload handler (which calls LMSFinish()) may not execute before the browser kills the page context.

Fix:

1. Implement visibilitychange event handling in your SCORM wrapper as a fallback to window.onunload: call LMSCommit() on document.visibilityState === ‘hidden’
2. If using Rustici SCORM Engine as your LMS backend, enable the “Offline Player Extension” which handles this at the engine level
3. Add an explicit “Exit Course” button that fires LMSFinish() before allowing navigation – communicate to learners not to use browser back on mobile

Error 6: Android setDomStorageEnabled Crash / Silent Failure in Native LMS App

Symptom: SCORM works in Android Chrome but fails in the LMS’s native Android app. Suspend data never persists. No user-facing error.

Root cause: The LMS native app’s WebView is not configured with webView.getSettings().setDomStorageEnabled(true), causing all localStorage operations inside the SCORM package to fail silently. This affects SCORM packages from Articulate Storyline, Lectora, and other tools that buffer tracking data in localStorage before LMSCommit().

Fix: Report to your LMS vendor. This requires a change in the native Android application code. It is not configurable from the LMS admin UI. Reference: Android WebView API documentation, WebSettings.setDomStorageEnabled().

SCORM vs. cmi5: The Architectural Decision for Mobile-First Deployments

If you are designing a new mobile-first deployment in 2026 and SCORM’s constraints are recurring operational problems rather than edge cases, the ADL’s cmi5 specification (finalized 2016, current version maintained at github.com/AICC/CMI-5_Spec_Current) is the architecturally correct solution.

The fundamental difference: SCORM uses DOM traversal to find a JavaScript API object – a browser-specific mechanism. cmi5 uses HTTP (xAPI/REST) to communicate with a Learning Record Store (LRS). An HTTP request from a mobile app does not require a shared browser context, does not depend on iframe parent access, and is not affected by ITP or WebView popup restrictions.

A cmi5 xAPI statement for completion looks like this:

{

“actor”: { “mbox”: “mailto:jdoe@company.com”, “objectType”: “Agent” },

“verb”: {

“id”: “https://adlnet.gov/expapi/verbs/completed”,

“display”: { “en-US”: “completed” }

},

“object”: {

“id”: “https://courses.company.com/module1”,

“objectType”: “Activity”

},

“result”: {

“completion”: true,

“success”: true,

“score”: { “scaled”: 0.92 },

“duration”: “PT14M22S”

},

“context”: {

“contextActivities”: {

“grouping”: [{ “id”: “https://w3id.org/xapi/cmi5/context/categories/cmi5” }]

},

“extensions”: {

“https://w3id.org/xapi/cmi5/context/extensions/sessionid”: “abc-123-session-guid”

}

}

}

This statement can be sent from a native iOS Swift app, an Android Kotlin app, a React Native component, or a browser – without any LMS-injected JavaScript API object in scope.