Native mobile publishing platform on a headless CMS with server-resolved deep links
Native Android and iOS apps built directly on a publisher's existing headless CMS, so editorial composes the home screen, sections and video series without engineering involvement, with server-resolved deep linking, native adaptive video and destination-aware push notifications.
The publisher had an established website, a large social following and a growing investment in original video series, but web traffic converts poorly into habit and offers no way to bring a reader back, and video was competing for attention against dedicated platforms while served through an article-centric web page. Any mobile product that asked editors to publish twice, or asked engineering to deploy every time the lead story changed, was going to be abandoned within months — and a large back catalogue of existing web URLs, linked from search and social, needed to keep working without the client understanding the CMS's internal routing.
Mapped the product's structure onto curated collections in the publisher's own content system rather than defining it in code: each feed section, tab and video series is backed by its own dedicated CMS endpoint, so what leads the home screen or which series gets promoted is an editorial decision reflected on the next refresh, not an engineering ticket waiting on a release. Article bodies render as the publisher's own HTML inside a native app shell — navigation, imagery, the pager and the video player are all native, with viewport and typography injected into an embedded web view for the body — so rich formatting and third-party embeds survive without maintaining two bespoke HTML renderers that would never quite match the website.
Deep links are resolved server-side rather than parsed on the client: the app hands the whole inbound URL or a node identifier to a resolution endpoint and renders whatever content comes back natively, falling back to an in-app browser when nothing resolves. The client never needs to understand the CMS's routing rules, which means those rules can change years from now without breaking apps already installed. Share links work the same way: the app asks the backend for a canonical shareable path rather than assembling one on the device, so link format and campaign tagging can change server-side with no release.
The home screen assembles from several independent, independently-fetched collections so a slow or failing section degrades only itself, and video plays through each platform's native player — adaptive-streaming-capable on Android — with full-screen handling. Push notifications carry a navigation instruction through to the launch path, so a tap opens the exact article or video announced rather than a generic home screen, and all content is browsable without an account, with sign-in gating only personalisation.
The newsroom publishes once, and content created in the existing content system appears in both mobile apps with no parallel workflow or duplicated effort — editorial controls what leads, what's featured and which series are promoted as a CMS edit rather than an engineering ticket. The existing web catalogue became app content, with links from search, social and messaging opening natively instead of bouncing readers to a browser, and push notifications that land readers directly on the announced content gave the publisher a re-engagement channel a website can't provide. Video got a native home through full-screen native players with a swipe-through reading flow, and both platforms received the same product — equivalent content, deep-linking and notification behaviour from a single content source.
Something holding you back?
New build, rebuild, or adding AI to what you already have — I'll take a look and give you an honest perspective.