Adding your article audio inside a mobile app

Plenty of publishers have a website and, on top of it, a mobile app. The site already has its audio version, and the question comes up fast: how do you get the same listening experience inside the app, without rebuilding an audio layer from scratch? The honest answer is that there is no single button, but two clearly identified paths, and the choice between them is not about technical difficulty. It is about what your readers expect from listening on a phone.

There is no dedicated mobile SDK, on purpose

Let us start with what we do not offer. WeDispatch does not ship a native iOS or Android library to drop into your project. That would be one more surface to maintain, ageing with every OS release, for a questionable gain: everything an app needs is already provided by an embedded web player or a plain audio file. So instead of a fragile SDK, we have two stable, documented building blocks. It is the same stance as on the web: describe precisely what each block does, do not sell a black box.

Path 1: the WebView, to reuse the player as is

A mobile app can display a web page inside a WebView, the component that embeds a browser within the screen. If your articles already render in a WebView inside the app (very common for editorial content), the audio player appears there exactly as on the site, with no extra work. The embed code you use on the web works identically.

This is the fastest path, and often the right one to start with. Its limit is precise and worth knowing: a WebView is bound by the rules of the embedded browser. Depending on the platform and its configuration, playback can stop when the user leaves the article or locks the phone, and lock screen controls (play, pause, skip) are not guaranteed. For a quick listen, on an open article, that is harmless. For a long listen, during a commute, it is the point that makes the difference.

Path 2: the API, to play the file natively

The second path separates generation from playback. Your app requests an article's audio through the API and CMS integration, retrieves the address of the generated file, then hands it to the system's native audio player (AVPlayer on iOS, the media player on Android). From there, the audio is no longer a web page: it is a media item the operating system knows and manages like any podcast.

That changes everything about the experience: playback continues when the user goes back to the article list or locks the screen, controls appear on the lock screen and in the control centre, and the file can be cached for offline listening. It is more work on the app side, since you have to wire up the native player and manage the play queue, but it is the only path that offers real background listening.

The deciding question: the background

It all comes down to a single decision. If your readers listen to an article while keeping it on screen, for a few minutes, the WebView is enough and you are in production today. If your readers listen while doing something else, phone in pocket, screen off, you have to go through the API and the native player, no exception. No WebView setting makes background listening as reliable as a real system media player, because it is not the same software layer.

That is also what separates a simple read from a genuinely mobile use, the one we describe in our piece on offline listening: as soon as you leave the "page open, screen on" frame, it is the file that matters, not the page.

React Native, Flutter and hybrid apps

Both paths hold whatever your development framework. A React Native or Flutter app can display a WebView (path 1) or call the API and pass the file to a native audio playback module in its ecosystem (path 2). The logic does not change: it is always the trade off between quick in page listening and long background listening that drives the choice, not the app's technology.

One point of care common to both worlds: mount the player, in a WebView as in native code, only after the access check if your content is subscriber only. The same principle applies on the web, and it avoids exposing the audio of a paid article to a logged out user.

Where to start

The wisest move is to validate the use before investing. Turn on the audio version of your articles, let it live in a WebView inside the app for two or three weeks, and watch who listens and for how long. If listening is short and in page, you are done. If listening times climb and feedback mentions listening on the move, you will know the investment in a native player is justified, with figures to back it. It is the same step by step approach as for a static or generated site: start simple, measure, then automate what deserves it.

For the details of the audio player and its behaviour, or to wire the API into your publishing pipeline, the documentation gives the level of precision a technical team needs.

Test before you write a single line

You do not need your app to know how the audio will sound: run the test on your articles from the web, listen to the result, then choose the mobile path with full knowledge of what you are getting.

Read next

• An audio player in the page or in an iframe: what that choice decides
• Image captions and photo credits: what French text to speech does with them
• Footnotes and note markers: what French text to speech does with them