Автор уже держит собственный Umami для сайтов и захотел то же самое для iOS-приложений — без тяжёлого SDK, запроса IDFA и сторонних сборщиков данных. Он выпустил open-source Swift-пакет umami-swift, который подключает приложение к тому же дашборду Umami, что и сайты. Теперь в списке сайтов рядом с настоящими сайтами появляются иконки приложений, а экраны приложения отображаются как страницы — видно, какие части люди реально используют.
Пакет не тянет зависимостей. API минимален: Umami.configure(websiteId:host:baseURL:) запускает трекинг, Umami.track("event") отправляет именованное событие с опциональным словарём данных, а Umami.screen("settings") — pageview для экрана. Важно: при конфигурации сразу ставится в очередь pageview запуска и событие app_started, так что первый запуск попадает в дашборд без лишнего кода. Все запросы буферизируются на диск и отправляются батчами — приложение не ждёт ответа от аналитики.
Внутри umami-swift обращается к тем же эндпоинтам Umami (/api/send и /api/batch), к которым ходит браузерный трекер. Никаких API-ключей не нужно — Umami идентифицирует сайт по website-id в теле запроса. Пакет сам генерирует UUID для каждого пользователя — он хранится только в памяти и меняется каждый день. Так достигается анонимность, как на вебе с cookieless-хэшем от IP и User-Agent. Никаких встроенных идентификаторов вроде IDFA, данные не пересекаются между приложениями и днями. Каждый запуск считается новым посетителем.
Для корректной работы Overview пакет отправляет pageview для / на каждый запуск и возвращение из фона — это даёт счётчики просмотров, визитов и посетителей. Экраны приложения отправляются как pageview с соответствующим путём (например, /settings), и они появляются в списке страниц Umami.
Блокировщики рекламы в iOS (например, Safari content blockers) не видят трафик нативных приложений. Системные блокировщики вроде NextDNS или AdGuard видят только домен, но не путь — а самописный Umami на необычном домене (например, hjerpbakk-analytics.fly.dev) не внесён ни в один блок-лист. Поэтому umami-swift обращается напрямую к серверу, минуя Cloudflare Worker, который используется для веб-сайтов.
Для отображения иконок приложений в дашборде автор заменил стандартный сервис favicon на свой Cloudflare Worker. Когда Umami запрашивает /icons/<domain>, Worker проверяет, не приложение ли это, и возвращает встроенную в него PNG-иконку 48×48 (рендерится в дашборде как 16pt). Остальные домены перенаправляются на DuckDuckGo. Иконка добавляется одной командой — скриптом резизит 1024‑пиксельную иконку и запаковывает её в Worker.