Case study
AniMoon: the site and its app
The short answer to “show us what this looks like on a real site”. AniMoon is connected to AnimeVault and already runs on iPhone: the same catalogue, the same player, its own brand. Not a single line of Swift on the site's side.
Site
animoon.space
An anime catalogue with a player, collectible cards and an economy of its own. Running since 2026, with an audience in Russia and Ukraine.
App
AniMoon for iPhone
Built by the AnimeVault engine from the site's manifest. Closed beta: builds go out through TestFlight, with Android and TV to follow.
What came out of it
What a viewer sees
Captured on the site's live data, not mocked up for a slide.
Home
Season hero, resume watching, collections. The site sets the order of the blocks — we don't rearrange it.
Catalogue
Search and filters by status, type and genre. Six thousand titles scroll in a native grid, not a web view.
Cards
The collectible half of the site moved across in full: rarities, frames, authors. The economy stayed on AniMoon's side.
What it took
A manifest instead of an app
The site described its screens in one JSON: which blocks, where the data comes from, what happens on tap. The app renders that natively.
Its own endpoints
Data comes straight from animoon.space. We proxy nothing and store nothing — accounts, money and content stay with the site.
Its own brand
The icon, colours, fonts and name are the site's. In the stores this is the AniMoon app, not an AnimeVault storefront.
The honest part
AniMoon is our first source and the engine grew on it: some of the work happened alongside the site itself. The second partner connects off the documentation alone, with no involvement from us in their code — that is exactly what we want the next case study to prove.
Want the same for your own site?
Read the manifest documentation, or send a request right away: we'll look at your catalogue and tell you what it takes.