Who it is for

Skomi for mobile and desktop apps

Almost every privacy-first analytics product measures websites and stops. Skomi measures apps too, in the same account as the site. An app is a different thing from a page, and half of what you might expect from the website side does not exist here. That half is on this page.

What you get

Eight SDKs for one frozen contract. Android, iOS, Flutter, Kotlin Multiplatform, React Native, Unity, .NET MAUI and Electron all speak the same wire protocol, so a product shipped on four platforms reports one way.

It works offline. Screens are queued on disk and survive quitting, crashing and a fortnight without a network. The sessions that matter most are exactly the ones a naive SDK loses.

It does not double-count. Every event carries an id minted once and resent unchanged, so a retried batch is recognised rather than counted twice. An offline queue without that invents data instead of saving it.

It survives a wrong clock. Each batch records when it was flushed, so a device set to next Tuesday does not report next Tuesday.

Errors with stacks, and whether they were fatal. Enough to see a bad release in the numbers rather than in the reviews.

Your site and your app in one account. One login, one bill, and the same session window on both, so "a session" means one thing across the pair.

What Skomi will not do for you

Only analytics reads an app. There are no heatmaps, no session recordings and no feedback widget for apps. Those three are site products, they need a page in a browser, and there is nothing for them to attach to in a native window. If you came here from the heatmap half of Skomi expecting it to follow you into the app, it does not, and there is no plan on which it does.

No revenue and no purchases. The app protocol carries screens, sessions, versions, platforms, props and errors, and nothing about money. In-app purchases and subscription revenue are not measured, and are not a setting away. Revenue exists on the site side only.

No install attribution and no store analytics. Where an install came from, what the store listing converted at, how many people updated. That is Apple's and Google's data and Skomi never sees it. There are no campaign or referrer fields in the app protocol at all.

Crash reports are not symbolicated. Stack traces are stored exactly as your app sent them, so a release build's stack is as readable as your build made it. There is no place to upload a dSYM or a mapping file, and there will not be one soon.

Screens are named by you. There is no automatic route capture, deliberately. A widget class name is what your code calls a screen, not what you would call it in a report. That is a small amount of work per screen and it is not optional.

Setting it up the way you work

Add the SDK and start it once. There is a guide per platform: Flutter, MAUI and Electron are written up, and tracking an app covers what the rest have in common.

The app ID comes from My Apps, and it is not a secret. It identifies an app rather than authenticating one, the same way a site ID does.

Name screens the way your report should read, not the way your router does. checkout/review beats CheckoutReviewViewController in every conversation you will have about it afterwards.

Send the app version. Most SDKs ask the platform for it; where they cannot, pass it. Without it "did the new release break something" is unanswerable.

Start disabled if you ask for consent, and switch on afterwards. Nothing is recorded while disabled, and not queued for later either, which is the correct behaviour and worth knowing before you test it.

One script, or one SDK. The same reports either way.

Create an account, register a site, and switch on what you need.