How to listen to articles with your phone locked

You find a reader that speaks articles aloud, start one, put your phone in your pocket, and thirty seconds later it goes quiet. This is the single most common reason people abandon browser-based listening tools, and it is not a bug in the tool so much as a consequence of how phones treat web pages.

Why the audio stops

Phones are aggressive about suspending background work, because background work is what drains batteries. When you lock the screen, iOS and Android freeze most of what a web page is doing — timers stop, scripts stop, network requests stop.

There is one significant exception: a media element that is actually playing audio. The operating system understands playback, keeps it running, and hands it a slot on your lock screen. That exception is the whole game, and whether a reader survives a locked phone comes down to whether it qualifies for it.

Speech synthesis does not qualify

Most read-aloud tools use the browser's built-in speech engine. It is free, instant and needs no server — genuinely the right choice for reading a paragraph back to you at your desk.

But to a phone, speech synthesis is not audio playback. There is no media file, no track, nothing to show on a lock screen. So when the screen goes off, it is treated as ordinary background work and suspended. On iOS this is particularly unforgiving: Safari will often cut speech the moment you leave the tab, never mind lock the device.

No amount of clever coding gets around this. The only reliable fix is to stop using speech synthesis and produce real audio.

What actually works

A reader that keeps playing has to do three things:

1. Generate an audio file rather than speaking live. The text goes to a server, comes back as audio, and plays through a normal media element — indistinguishable to your phone from a podcast.
2. Stream it rather than waiting for the whole thing. A forty-minute article is a large file. Delivered as one download you stare at a spinner; delivered in segments it starts in seconds and keeps buffering as you listen. This is the same approach streaming video uses.
3. Register with the operating system's media controls. This is what puts the title on your lock screen and makes the buttons on your headphones and in your car work.

Do all three and there is no difference between listening to an article and listening to music. Skip the first and nothing else matters.

How to test a reader in thirty seconds

Before you commit to any tool, on your phone:

1. Start playing something.
2. Lock the screen. Does the audio continue?
3. Look at the lock screen. Is there a player with the article's title, or nothing?
4. Wait two minutes with it locked. Still going, or silently stopped?
5. Switch to another app. Does it survive that too?

Step four catches the tools that survive locking for a few seconds and then get suspended anyway. Step three is the quickest tell of all: if the operating system shows a real player, the tool is producing real audio, and it will almost certainly pass the rest.

Does it need to be a native app?

No, and this is worth saying because it is a common assumption. A web app can use the same media pipeline and the same lock-screen integration as an app from the App Store. What it needs is to be built around real audio rather than live speech.

Adding a web app to your home screen helps for a different reason — it opens in its own window without browser chrome, which makes it feel like an app — but it is not what keeps the audio alive. That is the media element.

What we do

ListenMore generates audio on a server and streams it in segments, which is specifically so playback survives a locked iPhone. It registers with your operating system's media controls, so the article shows up on your lock screen and in your car with play, pause and skip.

It installs to your home screen without an app store, and there is a Chrome extension for sending the page you are reading to your library from a laptop. The free tier is enough to run the thirty-second test above on something you actually wanted to read.