Platforms
The 15 platforms the Intempt CLI generates typed wrappers for, and how coverage scanning detects your events on each.
Platforms
The platform field in intempt.yaml decides
which wrapper intempt generate writes. Fifteen values are supported.
Supported values
| Value | Target |
|---|---|
browser-ts | Browser, TypeScript |
browser-js | Browser, JavaScript |
node | Node.js |
reactnative | React Native |
android | Android, Kotlin |
ios | Apple platforms, Swift |
php | PHP |
python | Python |
ruby | Ruby |
java | Java |
go | Go |
csharp | C# |
cpp | C++ |
dart | Dart |
rust | Rust |
Coverage scanning works on all 15
intempt status finds event calls by matching the code the generator actually
emits, so detection follows each language's own naming convention rather than
assuming one:
| Convention | Platforms |
|---|---|
| Event name as written | python, ruby, rust |
| Capitalised | go |
Capitalised, Async suffix | csharp |
| camelCase | everything else |
On top of that it matches the two universal call shapes, .method( and
->method(, which covers instance calls in every generated language including
Swift and the pointer form in C++. Kotlin's wrapper is a singleton, so calls on
the type are matched too.
It also recognises direct SDK calls, for code that skips the generated wrapper entirely.
Why that holds
The test that guards this generates each platform's wrapper, reads the method name
back out of the generated source, and asserts the patterns match a call to it. A
generator that renames a method fails that test rather than quietly making
intempt status blind to your events.
All 15 platforms are covered by it.
Using it in CI
intempt status --ciExits non-zero when the tracking plan contains events your code never fires. Safe to gate a build on for any platform.