The news app, from feed to front page.
A news app is judged in the two seconds after it opens: is the front page fresh, and is it mine? Everything that makes those two seconds work is invisible. Feeds arrive in slightly different dialects, the same story turns up twice, every source has to be credited, and two app stores have their own definition of what a news app is allowed to be. This page walks the whole path, from the RSS specification to the lock screen, and it sits with the other app examples on this site, each written the same way: what the job actually requires, before any tool.
It covers the three shapes a news app takes, the article record underneath all of them, where fetching should happen, how a front page gets ranked, what breaking alerts owe the reader, and the App Store and Google Play rules that decide whether it ships.
See where a news app gets its storiesThe short version
A fetcher, a ranked list, and a rulebook.
Every news app, whether it belongs to one publisher, ranks many, or is an RSS reader app where the reader picks the feeds, does the same four things. It fetches stories on a schedule the publisher can live with. It normalises them into one article record and drops the duplicates. It ranks that record into a front page, by recency, by section, by source balance, or by an editor. And it decides which stories are worth interrupting someone for. The stores then check two things above all: that the app is more than a list of links, and that every source gave permission and gets the credit.
Feeds
RSS, Atom, an API, or your own CMS
Fetcher
One poll per feed, on the publisher's schedule
Article record
One shape per story, duplicates dropped, source kept
Front page
Ranked by recency, balance, section, or an editor
Alerts
Opt-in by topic, capped, deep-linked to the story
Sources
Where a news app gets its stories.
Three routes, and most apps end up mixing them. Which ones you use decides your licensing position, your image quality, and whether you can send an alert before anyone else does.
Feeds you subscribe to
RSS and Atom feeds published by newspapers, broadcasters, councils, clubs and blogs. Built for syndication, free to fetch, and the reason an RSS reader app can exist without a contract with anyone. You get whatever the publisher puts in the feed: usually a headline and a summary, sometimes full text, rarely a clean image.
APIs from publishers or wires
Structured JSON with proper fields, images and categories, usually behind an API key and a licence with limits on what you may show and for how long. The key belongs on a server; a key compiled into the app can be pulled out of it.
Your own CMS
Stories written by your newsroom, your club, or your company. The only route where you own the full text outright, and the one that turns a reader app into a publisher app with its own editorial front page.
What the RSS 2.0 specification promises, and what it does not
Most feeds a news app will ever meet are RSS 2.0, and the specification is shorter and looser than people expect. Atom feeds cover the same ground with stricter rules (every entry must carry exactly one id, one title and one updated timestamp), so code that copes with RSS copes with Atom.
| Element | What the spec says | What your app should do |
|---|---|---|
| Channel title, link, description | The only three required channel elements. | Enough for a source card. Let the reader rename a source; feed titles are often the site name plus a slogan. |
| Item title and description | Every item element is optional; an item only needs one of title or description. | Never assume both exist. Fall back to the first line of the description as a headline. |
| guid | A string that uniquely identifies the item, with no rules for its syntax. An aggregator may use it to decide whether an item is new. isPermaLink defaults to true. | Dedupe on guid first, then on the link. Treat it as an opaque string unless isPermaLink says it is a URL. |
| pubDate | When the item was published, in RFC 822 date format. Items dated in the future may be held back. | Store it apart from your fetch time, and parse the RFC 822 format; it is not ISO 8601. |
| enclosure | An attached media file with a url, a length in bytes, and a MIME type. | Podcasts and video. Ignore it in a text reader, index it in an audio one. |
| ttl, skipHours, skipDays | How many minutes a channel may be cached, and the hours (in GMT) and days when aggregators may skip reading it. | Honour them. They are the publisher telling you how often to knock. |
| source | The channel an item came from, included to propagate credit for news items. | Keep it. Google Play requires a source per article anyway. |
Element behaviour from the RSS 2.0 specification maintained by the RSS Advisory Board. The spec also defines a cloud element for publish-subscribe notification of updates; unless your sources support it, polling is what you will actually do.
The article record
One record for every story, whatever the feed looked like.
Feeds disagree about everything: date formats, whether there is an author, whether the picture is an enclosure, a media tag, or an image buried inside the description. The fix is to normalise at the door. Every story becomes one record with the same fields, and the front page never sees a raw feed again.
- A stable story ID: the feed's guid when there is one, otherwise a hash of the canonical link
- Source name and feed URL, kept on every story (Google Play requires the original publisher or author to be shown per article)
- Title, link, and summary, remembering that RSS only promises one of title or description
- Author, when the feed carries one, and blank rather than guessed when it does not
- Published time, stored separately from the time your fetcher saw it
- Updated time, so a corrected story replaces itself instead of appearing twice
- Lead image and its type, whether it came as an enclosure, a media tag, or an image inside the summary
- Section or category tags, mapped from the feed's labels to your own taxonomy
- Reader state: read, saved, dismissed, each with a timestamp
Three rules that keep the record honest
Dedupe in a fixed order
guid first, then the canonical link with tracking parameters stripped, then the same title from the same source within a day. A corrected story updates its record; it never creates a second one.
Keep published and fetched apart
A feed you poll at 06:00 does not mean the story happened at 06:00. Rank on fetch time and a slow feed looks like breaking news every morning.
Store what you are allowed to store
The headline, summary and link a feed provides are there to be shown with credit. The full text behind them is not, unless the publisher has said so in writing.
Device or server
Fetch on the phone, or fetch once on a server?
It is the first architecture decision news app development forces, and the one most often made by accident. A reader app for your own feeds can fetch on the device. Almost anything with more than one user, or with alerts, wants a fetcher on a server that pulls each feed once, normalises it, and hands the app clean JSON it can render without parsing anything.
| Question | Fetching on the device | Fetching on a server |
|---|---|---|
| Who hits the publisher's feed | Every phone, on every refresh | One fetcher, on a schedule that honours the feed's ttl |
| Breaking alerts | Not without a server; the phone would have to be awake and polling | Yes |
| API keys and licensed feeds | Unsafe: a key shipped inside the app can be extracted | Safe: keys never leave the server |
| Read and saved state across devices | Stays on the phone unless you add accounts and sync | Shared, once the server holds the record |
| Works in a browser preview | Rarely: feeds seldom send CORS headers, so the browser blocks the request | Yes |
| Runs while the app is closed | Only in the short background windows the OS allows | Yes |
| What it costs to run | Nothing beyond the app itself | A small always-on job and a database |
| Right for | A personal RSS reader app, a prototype | A town, a club, a trade, anyone with readers you do not know |
The server side does not have to be large. A scheduled job that walks the feed list, sends conditional requests so unchanged feeds return almost nothing, writes new records, and marks anything tagged breaking is the whole fetcher. The app then reads one endpoint, which is also what makes it testable in a browser before it ever reaches a phone.
The front page
How a front page gets ranked.
Newest first is where every reader app starts, and it is where the flooding problem shows up: one wire feed posting all morning pushes the weekly local paper off the page entirely. The usual fixes are a balanced rotation across sources, a pin for anything tagged breaking that is still fresh, and section tabs so sport never competes with the council. Try them below.
Try it
Mix a front page from five sources
Sample stories for an imagined town, invented for this demo. The ranking rules are the real part: toggle sources, switch the order, and pin breaking news.
- 1
Regional transit board publishes autumn timetable
County wire6 min ago
- 2
Flood warning issued for the river valley
Weather service9 min agoBreaking
- 3
County approves budget for road resurfacing
County wire14 min ago
- 4
Farmers' market moves indoors for the season
County wire22 min ago
- 5
Library extends weekend opening hours
County wire31 min ago
- 6
Water main repair closes Mill Street until Friday
Town Hall bulletin40 min ago
- 7
Bridge inspection scheduled for next week
County wire45 min ago
- 8
Recycling collection moves to Thursdays
County wire58 min ago
County wire holds 6 of 8 slots. One prolific feed is flooding the page; try Balanced.
Breaking news alerts
Alerts that earn the lock screen.
The Reuters Institute's Digital News Report 2026, published in June 2026 from surveys across 48 markets, found that news organisations' own websites and apps were used by 51% of respondents, behind social media and video networks at 54%, the first time those platforms have led globally, and that use of news websites and apps is down 12 percentage points since 2020. Its authors are blunt about the wrong response: more content, or more notifications on people's lock screens, is unlikely to be the answer. An alert has to be worth more than the tap it costs, which means rules, and the rules live on the server, not in someone's good intentions.
- Opt-in by topic, not one master switch: breaking, my town, my team, the council.
- A hard cap per day and quiet hours the reader sets, enforced where the alert is sent.
- One alert per story: an update replaces the earlier notification instead of stacking a fourth one.
- Every alert deep-links to a story that is already cached, so it opens on a bad connection.
Deciding which stories qualify is an editorial rule you can write on one page. Delivering them reliably on iOS and Android, with tokens, topics and the platform services in between, is a separate subject, covered in the guide to push notifications in mobile apps, which is worth reading before the alert rules are final.
What the stores require
What the App Store and Google Play ask of a news app.
Both stores have rules that land on news apps, and they are different rules. Apple's are about whether the app is enough of an app and whether you have the rights. Google Play's are a specific policy for anything that declares itself, or presents itself, as news.
| Requirement | Apple App Store | Google Play |
|---|---|---|
| More than a list of links | Guideline 4.2.2: other than catalogs, apps should not primarily be marketing, ads, web clippings, content aggregators, or a collection of links. | Not phrased that way, but the News & Magazines policy requires regularly updated content, not static pages. |
| Permission for third-party content | Guideline 5.2.2: you must be specifically permitted under the service's terms of use, and authorisation must be provided on request. | Publishing sources of third-party content must be clearly shown, which the policy calls out for aggregator apps. |
| Source credited per article | Not a stated rule in 4.2 or 5.2. | Required: the original publisher or author of each article. |
| Declare the app as news | No declaration; you pick a category at submission. | Required: declare it as News or Magazine in the Play Console and complete the self-declaration. Listing in the category and calling yourself news in the title, icon, developer name or description counts too. |
| Contact information | Not a news-specific rule. | Required: clear, easy access to up-to-date contact information for the app. |
| Subscriptions | Not a news-specific rule. | An in-app content preview before purchase when a membership or subscription is required. |
| Business model | Not a news-specific rule. | Affiliate marketing or ad revenue must not be the app's primary purpose. |
Apple rules from the App Review Guidelines, sections 4.2 and 5.2. Google rules from the Google Play News & Magazines policy. Both read on 20 September 2026.
The line Apple draws is the one to design around. Guideline 4.2.2 says apps should not primarily be "content aggregators, or a collection of links", and a news app that only lists headlines which open in a browser is exactly that. Saved stories, offline reading, alerts by topic, search, and a front page with its own rules are what move it across the line. If the app is built in Newly, the publishing split matters here too: the iOS build goes up through App Store Connect and you submit it for review yourself, while the current version does not produce Android release builds, so the Play Console declaration above is a separate job on a separate toolchain.
Choosing one
What is the best app for news?
The top news app for a given reader comes down to one question: who picks the sources? The four routes differ mostly on that, and on who controls the front page once the sources are in.
| Route | Who picks the sources | Who ranks the front page | Where it lives | When it fits |
|---|---|---|---|---|
| Platform aggregatorApple News, Google News | The platform, tuned by what you follow | The platform's editors and algorithms | The platform's own app and rules | Reading, not building. Nothing to run. |
| RSS reader appFeedly, Inoreader, NetNewsWire | You, feed by feed | Newest first, with your filters and folders | The reader app, on your account | When you already know which feeds you want |
| A publisher's own appAny newspaper or broadcaster app | That publisher only | Its editors | Its app, its subscription | Following one outlet closely |
| Custom news appA town, a league, a trade body | Whoever runs it, from feeds, an API, or a CMS | Your rules: balance, sections, breaking | Your app, your readers | News that nobody else covers the way you need |
Two neighbours are often mistaken for a news app. If the product is live video with a chat beside it, a match, a council meeting, a launch, that is a live streaming app with a schedule, not a feed. And if the stories are written by the reader rather than pulled from publishers, a daily entry with a photo and a date, that is a journal app, which shares the timeline screen and almost none of the plumbing.
Building one
How to build a news app, in order.
The order matters because the early decisions are cheap to change on paper and expensive once screens exist. Sources and the record come first; the front page, which everyone wants to start with, comes fourth.
- 1
Choose the sources and confirm you may use them
Feeds you can fetch, an API with a licence, or your own CMS. Where a publisher's terms are unclear, get permission in writing; Apple can ask to see it.
- 2
Write the article record
The fields above, with the dedupe order and the published-versus-fetched split decided before any screen exists.
- 3
Decide where fetching happens
On the device for a personal reader. A server fetcher for anything with alerts, API keys, or readers you do not know.
- 4
Set the front page rules
Newest, balanced, or sectioned; what counts as breaking; how long a story stays on the page before it drops.
- 5
Build the reader screens
Front page, a story view that opens the publisher's page with credit, a saved list, search, and a place to manage sources.
- 6
Add alerts by topic
Opt-in per topic, a daily cap, quiet hours, and one alert per story however many times it is updated.
- 7
Cache for offline
The last front page and its stories stay readable in a tunnel; images load when they can and never block the text.
- 8
Prepare the listings
On Google Play the News declaration, contact information, and visible sources. On the App Store, enough real features to clear guideline 4.2.
When to build your own
Subscribe to one, or build a news app of your own
For most readers the answer is a reader app or an aggregator, and the honest advice is to use one. The reason to build instead is fit: a town, a league, a trade, or a company with sources no aggregator carries, alerts no publisher will send, and a front page no RSS reader app will rank your way. That gap, a process no off-the-shelf tool quite fits, is what Newly is for: describe the sources, the record, the ranking and the alert rules you actually want, and it builds a real native app around them, from $25 a month with no free plan.
Whatever builds it, write the feed list, the record, and the alert rules down first. They are the part a reader never sees and the part that decides whether the front page is still fresh in a year.
Sources
Where the specifics came from.
Four things on this page come from a primary source rather than general practice. All four were read on 20 September 2026.
FAQ
News apps, answered.
A news app is any app whose main job is to show current stories from one or more sources. It comes in three shapes: a publisher's own app that shows only its newsroom's work, an aggregator such as Apple News or Google News that ranks stories from many publishers, and a reader app where the person picks the feeds themselves. All three share the same plumbing: a fetcher that pulls stories, an article record that removes duplicates, a ranked front page, and alerts for the few stories that cannot wait.
Start with the feeds, not the front page.
The front page is the easy part. The fetcher, the record, the alert rules and the store checklist are what make a news app hold up, and they are all on this page. See what other people have built in Newly, then describe yours.