Three things, not three versions
The most common misconception is that SCORM, cmi5, and xAPI are successive versions of one standard, so newer must be better. They are not. They answer different questions. SCORM is a packaging-and-reporting model for content that runs inside an LMS. xAPI is a protocol for sending activity statements to a data store, with no packaging at all. cmi5 sits between them: a package the LMS imports, whose content reports using xAPI. Choosing well means knowing what you need to report and where it has to go, not picking the highest version number.
SCORM: a package the LMS imports
SCORM is a zip file with a manifest. The LMS unzips it, launches the content, and listens for a fixed set of JavaScript calls that report completion, score, and a bookmark. It is the default for one reason: near-universal LMS support. If your content runs inside an LMS and the reporting you need is "did they finish, did they pass, what score", SCORM is the right tool and will be for years. Its limits are equally clear: it reports a handful of values, it has no identity outside one LMS, it needs a live browser session, and it stores no rich activity data. The full picture is in What is SCORM.
xAPI: statements with no package
xAPI (the Experience API, sometimes called Tin Can) is not a package format. It is a way to record things that happened as short statements in the shape actor – verb – object, optionally with a result and context: "Dana passed the final assessment with 0.84", "Dana played the safety video for 4 minutes 12 seconds", "Dana chose branch B in the spreadsheet scenario". Statements are posted to a learning record store (LRS), a database that speaks the xAPI protocol.
Because there is no package, an xAPI activity is not imported into an LMS the way a zip is. It is launched from a link and it can live anywhere content can run — a website, a mobile app, a simulator, a piece of hardware. What you gain is granularity: interactions, durations, paths, attempts, the things SCORM either cannot store or stores where no report will show them. What you take on is that you need an LRS to send to and you need to decide what to do with the data once it is there.
cmi5: a package that carries xAPI
cmi5 is the bridge. It is a package specification — a zip the LMS imports, with its own manifest (cmi5.xml) — but the content inside reports using xAPI statements rather than SCORM calls. The LMS launches the course, hands it the address of an LRS and a secure token, and the course posts its statements there while the LMS still gets the completion and pass/fail it needs for its own records. You get packaged, LMS-native distribution and xAPI-level data at the same time. The cost is that both sides have to support cmi5 properly, which more platforms do every year but not all do well.
What each one reports
| SCORM 1.2 / 2004 | cmi5 | xAPI | |
|---|---|---|---|
| Form | Package (zip) | Package (zip) | No package; launched from a link |
| Imports into an LMS | Yes | Yes | No |
| Reports through | JavaScript API to the LMS | xAPI statements to an LRS | xAPI statements to an LRS |
| Needs an LRS | No | Yes | Yes |
| Data granularity | Completion, score, status, limited interactions | Full statements plus LMS-native completion | Full statements |
| Runs outside an LMS | No | No | Yes |
A decision guide
- Destination is an LMS; you need pass/fail, score, completion. SCORM. Pick 1.2 or 2004 by the rules in this guide.
- Destination is an LMS, but you also want interaction- and path-level data. cmi5, if the platform supports it; otherwise SCORM for the LMS plus xAPI statements to an LRS alongside it.
- Content lives outside an LMS — an app, a portal, a simulator. xAPI to an LRS. There is no package to import.
- You do not yet have an LRS. Start with SCORM. Adding xAPI later is a build change, not a re-authoring.
- You are distributing to organisations whose platforms you do not control. SCORM is the safest import; layer xAPI only where you know the destination can receive it.
You can ship more than one
The same course can produce more than one output. A build can be a SCORM 2004 package for the LMS report and emit xAPI statements to a learning record store at the same time, giving you the completion the LMS needs and the detail the LMS cannot show. The decision is therefore rarely final: choose what the destination requires now, keep the course as the source, and add outputs as your reporting needs grow. That is the model SCORM Central is built around — one source, several outputs, chosen per course.