Apple News+ & Hearst Magazines

A design system I started on in 2014, still rendering in 2025. Web components on the brand sites first, then the Apple News templates in 2016, mapped onto the same tokens rather than built beside them. Every screenshot on this page links to the live article, most of them twice: once in Apple News and once as the web page on the brand’s own site. You are welcome to go and check rather than take my word for it. The Apple News Top 100 stories are free to read, no subscription, and the web versions are just web pages.

Working against a moving format

We were missing a way to publish directly from our CMS to Apple News. I started this work in 2016, a year after Apple News’ public launch, right as the first beta version of News Publisher came out, meaning I was working with a JSON format that was constantly changing, and learning it from documentation that was itself being written as Apple iterated. There was no established pattern to follow because the format was too new for one to exist yet. The only out-of-the-box publishing path required waiting for finalized InDesign files from our print magazines, which meant Apple News content was always a print reprint: behind on timing, not optimized for the platform, and dependent on the print production cycle.

We needed a way to publish digital-native content directly from the CMS, styled and customized per brand, at the full velocity of our editorial operation. Apple’s own guide to using a CMS with News Publisher describes the mechanism any CMS integration has to use: a REST API and News Publisher backend, authenticated per channel with a channel ID, key ID, and secret. My work built the CMS-side templates and token mapping against that interface.

The process

The project started with a content inventory. I catalogued every content type Hearst editorial teams produced (article, gallery, video, recipe, product roundup) and mapped them to the Apple News Format component palette. That mapping immediately surfaced a tension: Apple News Format is opinionated about layout. Our magazine brands weren’t. Cosmopolitan’s visual identity is not interchangeable with Popular Mechanics.

I wireframed the token-to-JSON mapping as a design document first: which component types needed which token references, which Apple News properties had no equivalent in our system (and what decisions to make there), and where editorial judgment would still be required. The wireframes weren’t for visual design; they were for information architecture. How does an article’s content structure become an Apple News article layout?

From there I moved into implementation: writing Apple News JSON templates, styling rules, and the CMS integration that populated them. I owned both the design and the front-end code. No handoff, no translation layer between design intent and shipped output.

QA happened on device across every brand layout: iPhone, iPad, macOS. Apple News Format rendering has browser-like quirks: things that look right in the News Publisher tool don’t always render correctly on actual hardware. I caught and resolved those discrepancies before launch.

Underneath the editorial workflow, Apple News itself runs on RSS/Atom feeds and the proprietary Apple News Format JSON, with content fetched by Apple’s own AppleBot crawler; articles render as native text rather than web views so tools like VoiceOver can read them natively.

Learning a format as it’s written

I keep coming back to this project when I think about what it takes to work in a genuinely new medium. In 2016, there was no Stack Overflow answer for Apple News Format, no established best practice at platform scale, no prior implementation to study. The documentation itself was incomplete because Apple was still writing it while I was building against it. The only way through was reading what existed, testing what wasn’t documented, and adjusting as the format changed under me.

That’s the same skill I’m using now, a decade later, learning to design for AI systems from the inside rather than from a settled body of best practice that doesn’t exist yet either. Different medium, same posture: build with a spec that’s still being written, and expect to redo work when it changes. The native-text rendering described further up is the detail I keep returning to: accessibility was a property of that medium rather than a pass applied afterward, and it set the standard I hold myself to now. Apple built that in from version 1.0 of the format: accessibilityCaption is a documented property on image, figure, gallery and video components, and the Apple News Format reference, archived in 2016, says it “is used by VoiceOver for iOS only”.

Why token systems travel across channels

The approach here, mapping one semantic token layer to multiple output formats, isn’t specific to Hearst or Apple News. It’s a documented pattern for any multi-channel publishing problem, written up by Martin Fowler and by Contentful: tokens turn design decisions into structured, platform-agnostic data, so consistency across web, native apps, and third-party feeds becomes a build-layer concern instead of a design-and-redo-it-per-channel one.

The vocabulary arrived after the work did. I started building this way at Hearst in 2014, off a Salesforce talk, before the phrase “design token” was something anyone around me said. I am not claiming anyone invented anything, and I am deliberately not putting a coinage or a date on the term: the attributions that circulate for it do not hold up when you check them. The point is narrower and it survives whoever named it. The approach on this page is not a retrofit. It is what the work was already doing before there was a word for it.

Design tokens before we knew or cared. We didn’t have the term. It’s popularly dated to Salesforce around 2014, though Jina Anne, the person usually credited, doesn’t claim to have coined it. Either way it arrived after we already started.

This is the part the paired links above are for. Every one of them is a single story opened twice, once on the brand’s own site and once in Apple News, and the two look like the same magazine because they come out of the same design system rather than out of two teams agreeing to match. I wrote every part of that: the brand styling on the web and the Apple News templates it maps into. The pairs are the argument, and they are checkable, which is why they are links rather than a claim.

Design system tokens to the rescue

Apple News is based on proprietary JSON written in Apple News Format. One layout defines the presentation for iPhone, iPad, and macOS. As the format matured over the years that followed, I mapped new features and styling to our templates and design system.

The visual treatment already developed for the web platform, and later for Custom Feeds once that system existed, (typography scale, color palette, image aspect ratios) could be reused and applied programmatically based on each magazine’s design tokens. The integration’s presentation layer was built to consume whatever the token system currently defined, so it picked up Custom Feeds-era refinements automatically rather than needing a separate update.

That token layer is not something this project invented, and it is not something Custom Feeds invented either. Both inherit it from the mediaOS platform, where platform tokens cascade to brand tokens and, for brands with multiple locale editions, to locale tokens on top of that. The Custom Feeds block system is the other thing built on that cascade. Custom Feeds used it to make one block definition produce dozens of different-looking homepages. This project used it to make the same content render as a magazine inside somebody else’s app. Same cascade, different output target.

Since we were reusing design tokens and patterns, onboarding new brands was a token configuration exercise, not a rebuild. After the initial integration work, bringing a new magazine onto Apple News was mostly hands-off. Hearst’s own account of MediaOS describes it as having formed “budding partnerships with Google, Apple and Facebook”, of which this integration was the Apple side.

The part I never saw

The plumbing between MediaOS and Apple was not mine, and I am not going to describe it as though I watched it work. Publishing was manual at first, and it ran through a contact at Apple News rather than through a pipe we controlled. Later the product owner owned it, and when it broke, fixing it was out of my hands. My side was the CMS templates and the token mapping, and adding features to those as the format grew.

The only part of it I can point at is Apple’s half, because Apple publishes it: any CMS integration authenticates per channel and publishes through the News Publisher API, on the channel ID, key ID and secret model Apple’s own documentation describes. What MediaOS did on its side of that boundary, and who fixed it when it failed, is somebody else’s story to tell.

What this rests on

No public source names me or confirms design ownership of this integration. Apple’s own newsroom material confirms Hearst was among the platform’s first publishers in 2015; nothing external documents a 2016 start, Apple News Format specifics, or who built Hearst’s integration. The revenue framing and the onboarding-time figure below are my own account of internal terms, not externally published. The one fully independent, checkable fact here is the “8 of 100” placement in Apple’s own “Ten Years of Apple News” feature, linked below. I’m noting the gap directly rather than letting the page read as more externally verified than it is.

Scope of ownership

Designed the system and built the front-end end-to-end: HTML/CSS, Apple News Format JSON templates, design-system/JSON architecture, wireframes, and on-device visual QA. The same person owned design intent and shipped code, so there was no handoff gap between what was intended and what shipped.

$10M to $20M, and how I got there

Apple is very consistent about privacy, and I was never privy to audience numbers. Even when I asked, it was never really clear. That’s part of why I’m not going to pretend I can break down global reach or line-item profits from data I can’t see. I’m not a finance person. I’m a designer, so I’m staying in my lane and talking about what I can actually verify. What I can actually verify is that I’m disclosing an estimate based on published data. I don’t have access to Hearst’s internal numbers, so I’m not presenting this as a reported figure. That said, the public data gets us to a reasonable estimate: Apple News likely became a low eight-figure annual revenue line for Hearst at the portfolio level. My rough method is simple: about half of Apple News+ subscription revenue is distributed to partner publications, and that publisher share has been estimated at roughly $136 million a year. The Daily Beast was reported to be on track to make $3–4 million a year from Apple News alone, which gives me a concrete public benchmark for what a publisher can earn on the platform.

So the number is $10M to $20M a year, which is the figure in the band at the top of this page. Here is the step that gets there, stated plainly because it is the weakest one: The Daily Beast is a single title earning $3–4 million, and Hearst ran dozens of brands through this integration. Scaling one publisher’s reported figure up to a portfolio is my own judgment, not published arithmetic, and nobody has published the Hearst number. That is the whole reason it is labelled an estimate, linked to this section, and not stated anywhere on the page as a reported result.

What backs the metrics at the top

The revenue line is not a Hearst-specific published figure. Executives at Hearst and peer publishers described Apple News+ to Semafor in 2024 as “a substantial stream of direct revenue”, which is Semafor’s summary of what executives at five publishers, Hearst among them, told the outlet collectively.

The “minutes, not months” onboarding held up over time. Hearst UK’s own press release confirms Digital Spy launched a digital magazine custom-built for Apple News+ in July 2020, well after the original integration shipped.