Product & Technology

Three structures dominate this market, and the label "white label" gets applied to all of them, unhelpfully. A shared app (the most common model) means your readers use the vendor's app — your books appear inside it, sometimes with your branding on the shelf, but the app listing, the install base and often the customer relationship belong to the vendor. An SDK means the vendor licenses you reading-engine components and your developers build and operate your own app around them — maximum control, but you become a software team. A true white-label app — Publish360's model — means a complete branded app built and operated for you, but published under your own Apple and Google developer accounts, so the asset is structurally yours without your team writing code. The question that cuts through every vendor's marketing: whose developer account is the app published under, and who keeps the readers if we separate? Ask it of everyone, including us.

Because it converts the app from a service you rent into an asset you own. The Apple and Google developer accounts determine, contractually and technically, who owns the store listing, the app's ratings and reviews, its install base, and its push-notification relationship with every reader who installed it. If the app lives on a vendor's account, then no matter what your contract says, leaving the vendor means leaving the asset: your readers' installed app belongs to someone else's account, and you start again. On your own account, a change of platform provider is an update your readers receive, not an app they lose. It costs you $99/year (Apple) and a one-off $25 (Google) — we set both up in your name during onboarding — and it is, in our view, the single most important structural question to ask any app vendor in this market. Most don't volunteer the answer.

Four content types in one library: ebooks (EPUB 3, reflowable and fixed-layout), audiobooks (streamed and downloadable for offline listening), video, and courses (structured multi-part content). One library, one reader identity, one set of engagement data across all four — which matters because cross-format bundles (ebook + audio + bonus video at one price) are among the strongest direct-channel offers, and are precisely what single-format retail channels can't assemble.

Readium LCP — the open, passphrase-free DRM standard developed by EDRLab, of which Eden Interactive is a member. Why LCP: it protects content with real encryption (unlike watermarking, which only identifies leaks after the fact) while treating readers like customers rather than suspects — no Adobe ID, no third-party account, no device-authorisation ritual that fails at 9pm on launch night. Why not Adobe DRM: it's a closed system with per-transaction costs, a reader experience that publishers' own support inboxes testify against, and a dependency on one company's licensing decisions. Why not watermarking alone: for some lists it's a reasonable choice, but most trade publishers and agents want encryption on frontlist. LCP is also what a publisher should want strategically: because it's an open standard, your protected files aren't hostage to any single vendor — including us.

Yes — books and audiobooks download for fully offline reading and listening, and a reader's library syncs across their devices (phone, tablet, web) under one account. Reading position, bookmarks and annotations follow the reader across devices. The design brief is simple: the reading experience must never punish the reader for having bought direct — anything Kindle makes easy, your app must make at least as easy, or the channel leaks trust.

Honestly: not on Kindle e-readers — Amazon's devices are a closed system that only Amazon's store can sell into, which is, of course, the business model this platform exists to counterweight. Your app runs on iOS and Android phones and tablets, and in the browser (see 4.13), which between them cover the overwhelming majority of digital reading. Some open e-ink devices (PocketBook, Boox and others) support Readium LCP, and LCP-protected files can be readable there. For readers who are devoted Kindle-hardware users, the practical pattern is: serve them audiobook, web and phone reading through your channel while continuing to sell them Kindle editions through Amazon — a direct channel doesn't require abandoning any reader where they are; it stops every reader being somewhere you can't see.

Adjustable type size and fonts (including dyslexia-friendly options), spacing and theme controls, reflowable text, screen-reader support, and text-to-speech — built on the EPUB 3/Readium stack that carries accessibility metadata through from your production files. If your EPUBs are born accessible, the app preserves that work; if your backlist isn't, the reading system's own affordances cover much of the gap. See 3.6 for the compliance position.

We prepare and manage the submissions on your developer accounts, and store review is our problem to absorb, not yours to learn: we know the current review guidelines, the reader-app category's specific rules (including what a reader app may and may not link to), and the documentation each store expects. Rejections in this category are almost always resolvable formalities — a metadata clarification, a screenshot revision, a purchase-flow adjustment — handled in days as part of onboarding, and the launch timeline we give you includes review contingency. Post-launch, every update goes through review the same way, invisibly to you. What you'd feel as existential risk alone — "Apple said no" — is, for a platform that ships app updates continuously, routine weather.

The platform absorbs it — that's a core part of what the fee buys. Store policies shift constantly (IAP requirements, external-link rules, privacy-label demands, SDK deadlines), and the regulatory environment is currently moving in publishers' favour — courts and regulators in the US and EU have been forcing the stores open to external checkout links. When rules change, we update the platform and every publisher's app inherits the fix; when rules loosen, you inherit the opportunity (e.g., link-out checkout reducing IAP exposure — see 1.5). Because your checkout mix is diversified by design (web, in-app, offline, vouchers), no single store's policy change can hold your revenue hostage — which is precisely the resilience argument for owning a multi-channel checkout rather than living inside one store's rules.

We do — it's a maintained platform, not a bespoke build. OS-version updates, security patches, crash fixes, store-policy compliance and feature releases ship to your app continuously, under your developer account, with no work from your team; you never inherit a codebase, a backlog or a maintenance invoice. This is the structural difference from agency-built apps, which are famously cheap to quote and ruinous to keep alive: the $104k–$325k build-it-yourself estimate on our pricing page is the entry price of that road — the 15–20% annual maintenance is the toll.

You get named support for your publishing team during UK business hours, with reader-facing customer care handled separately so your readers are looked after without consuming your staff's time. Uptime targets, response-time commitments by severity and support channels are all stated plainly in the service agreement — ask for the current figures at the demo and we'll put them on the record.

The roadmap is ours to run and yours to influence: features ship platform-wide, so every publisher inherits every improvement without integration projects (that's the economics that keep the fee flat). Publisher requests are weighted by how many houses need them. Genuine custom development — features exclusive to one publisher — is Enterprise-tier conversation territory: possible where it doesn't fork the platform, honestly declined where it would, because a forked platform quietly becomes the bespoke build we've been warning you about (see 4.10).

Both. The branded apps (iOS, Android) carry the full experience — offline reading, push notifications, the home-screen presence that makes the channel durable — and a browser-based reader covers desktop reading, readers who resist installing anything, and the instant gratification moment after first purchase. The strategic weight sits with the apps: a home-screen icon is a marketing channel; a browser tab is a session.

Either, deliberately. A house with one consumer-facing brand ships one app; a group with genuinely distinct audiences (say, a literary imprint and a children's list) can run separate branded apps on the same platform, each under your developer account, each with its own store listing and design. The decision rule we'd offer: separate apps only where audiences genuinely don't overlap — every additional app divides your install-base gravity, and one well-populated app usually beats two sparse ones. Imprint-level branding inside a single app (curated shelves, imprint pages) covers most group structures without the split.