How SCORM works technically
A SCORM package is a ZIP file containing the course content (HTML, CSS, JavaScript, media) and a manifest file (imsmanifest.xml) that tells the LMS how to navigate and launch the content.
When an LMS launches a SCORM package, it opens the content in an iFrame or popup window and makes a JavaScript API object available (API for SCORM 1.2, API_1484_11 for SCORM 2004). The content uses this API to report progress, score, and completion status back to the LMS.
SCORM 1.2 vs SCORM 2004
SCORM 1.2 is simpler and more universally supported. It tracks:
- lesson_status (passed/failed/completed/incomplete)
- score (raw, min, max)
- session_time
- suspend_data (bookmark)
SCORM 2004 adds more granular completion tracking, better sequencing rules, and interaction-level data. However, its sequencing specification is complex and inconsistently implemented across LMS platforms. Use SCORM 1.2 unless you have a specific requirement that only SCORM 2004 can meet.
How xAPI works
xAPI sends activity statements to a Learning Record Store (LRS) via a REST API. Statements follow a subject-verb-object format. The LRS can be part of your LMS or a separate service (SCORM Cloud, Learning Locker, Watershed).
For basic completion tracking, xAPI and SCORM 1.2 deliver similar results. xAPI's advantage is in mobile learning, offline sync, and cross-platform learning records — scenarios where the browser-only, online-only nature of SCORM is a limitation.
Common integration issues
- Popup blockers preventing SCORM launch windows from opening
- SCORM packages hardcoded to specific domain origins failing CORS checks
- Suspend_data field exceeding the 4096-character limit in SCORM 1.2
- Missing API initialisation causing all tracking data to be lost
- Completion status not firing because the content's completion trigger is not reached