← Blog · 30 September 2026 · Lire en français

Listening to an article with the screen locked, and in the car

Audio started from a web page should keep going when the screen turns off, show up on the car's dashboard, and resume after a long pause. What the browser really allows, and where it pushes back.

You start an article playing, slip the phone into your pocket, the screen goes dark, and the sound carries on: that is what you expect from a podcast, and it is what you expect from an article read aloud. The hard part is not producing the sound, it is holding on to it once the page is no longer in the foreground. A mobile browser pauses a page when it drops into the background, cuts the audio after a few seconds unless something tells it this is intended listening, and shows on the lock screen whatever it wants, not what you would want. This piece sets out what WeDispatch does with all of that, and where the browser, for its part, does not budge.

What the lock screen shows, and why it is not the app icon

A phone's lock screen, like a car's "Now playing" screen, only shows still images: a title, a name, a piece of cover art, a progress bar, and a few buttons. The browser does not invent any of it: the page has to hand it over, through the browser's standard media interface (the one that exists precisely for web-page audio players). WeDispatch gives it the title of what is being read, the source, the "WeDispatch Radio" line, and a real piece of cover art drawn on the fly for that audio (its gradient, its word, the brand's wave), 512 pixels square, rather than the app's generic icon. It is a small thing that changes listening in the car: you recognise what is playing at a glance, without unlocking.

The buttons on the lock screen, on the headset and on the steering wheel are each wired to the player one by one: play and pause, skip back and skip forward, previous and next, and dragging straight to a point on the bar when the car offers it. The progress bar itself only moves if the page keeps reporting where playback is (duration, position, speed): without that, the lock screen would show a dead bar. WeDispatch updates it as long as an audio is playing, and clears it the moment the queue ends or the audio is deleted, so no ghost title lingers after the end.

The limit we hit on iPhone, and how it was lifted

Here is where the browser pushes back, and it is the kind of detail you only see in production. On iPhone, after a long pause (the phone put away, the screen off for a good while), the lock screen could show playback as if it were resuming without anything actually advancing: the button flipped to "play", but the sound did not start again. Safari on iOS invalidates the link to an audio file after a stretch of inactivity, and replaying a stale link produces nothing.

The fix, shipped in late September 2026, does not work around the browser, it works with it: on the resume gesture, playback restarts at the same spot on a fresh link rather than the old one; and if it still does not start, it relaunches itself. The lock screen then shows the player's real state, not an assumed one. It is the same principle as resuming an audio where you left off: what matters is not promising that playback will resume, it is that it actually does.

On a public page, and inside an account

Two situations need telling apart, because they do not offer the same thing. The player sitting on an article's public page plays in the background within what the browser grants any ordinary web page: the sound continues when you lock, with the system's basic controls. Gapless play-through, the drawn cover art, resuming after a long pause, a queue of several articles on the car's dashboard: that lives in WeDispatch Radio, the listening space reserved for customer accounts, trials included. It is not a consumer app to download from a store: it is the account's listening space, installable on the home screen, with offline downloads for driving without a signal.

What ties the two together is the reading engine. The quality of what comes out of the car speakers does not depend on the lock screen, it depends on the French text to speech that prepared the text: that is where the difference is decided between an article you listen to all the way through and one you cut off at the first red light.

What to take away

Locked-screen listening is not a checkbox, it is a series of small agreements struck with the browser: give it a title and cover art so it displays them, report the position so the bar comes alive, wire up each steering-wheel button, and fix the one place where iOS cuts playback after a long pause. Any one of these is missing somewhere, and you hear it: an absent title, a frozen bar, a headset button that does nothing, a resume that never starts. The work is letting none of the five slip.

Give your articles a voice with WeDispatch

This blog is itself voiced by WeDispatch. Curious how it sounds on your content?

Book a demo

Read next