Implementing AirPlay streaming from a mobile app

AirPlay streaming on iOS: where the broadcast breaks

AirPlay streaming doesn't break at the "pressed the button" stage, but in three specific places: device discovery, stream retention, and audio-to-video synchronization.

Let's break down each failure, because they are treated differently, and there is no universal "AirPlay fix."

The first class — the receiver isn't found.

iPhone screen mirroring goes over the local network, and if the router hands out different subnets to clients or keeps access point isolation enabled, the phone physically won't see the Apple TV, even though both are "on the network." The second common case is corporate Wi-Fi with portal-based authentication: the device connects, but multicast traffic between clients is blocked, and the list of receivers stays empty.

The second class — the stream starts and drops. Video output to Apple TV is sensitive to jitter and packet loss: when the channel degrades, the buffer empties, and instead of a smooth picture the user gets stutters or a complete disconnect after 10-20 seconds.

What matters here is whether the app can survive a network change — switching from Wi-Fi to mobile internet kills the session if a restart with playback position preservation isn't built in.

The third class — audio desync. Picture and sound travel different paths: video is buffered on the receiver, audio on the source, and with different buffer depths the sound drifts ahead or behind by 200-500 ms.

On speech this is almost unnoticeable; on music and dynamic scenes it's jarring. A separate cause is audio output to external speakers connected to the TV rather than to the phone: latency is added at every link in the chain.

The fourth class — mid-stream failure due to resources: the phone goes to the background, the system suspends the session, and the broadcast cuts out without a clear error for the user. We break down how this is addressed at the app and network level.

What a correct streaming integration delivers

Predictable connection time

Connecting to a speaker or TV set-top box takes 1-2 seconds: the device appears in the system list as soon as the player opens, rather than after a manual network search.

We handle discovery through the native system layer, so receiver selection works the same on iPhone and iPad and does not depend on which subnet the user happens to be on.

If the receiver is busy or has dropped off the network, the player falls back to local playback without a frozen screen or repeated taps.

No audio-video desync

The main cause of complaints about casting is a mismatch between audio and video when switching tracks or changing quality.

We synchronize the buffers on the sender side and correctly handle pause, seeking, and incoming calls: after returning from the background, the stream continues from the same position.

The user does not hear an "echo" or see the audio lag behind — and this is exactly the class of defects that takes the longest to diagnose in support.

Fewer support requests

Typical scenarios — "can't see the TV," "sound is coming from the phone," "it cuts out halfway through" — are resolved at the code level, not with an instruction sheet.

We log the connection state and the reasons for disconnection, so an incident is investigated based on the facts rather than the user's description. The share of requests related to casting drops severalfold, and the load on the first line drops along with it.

Lossless sound quality

The stream is delivered at the track's original quality, without intermediate transcoding on the phone: the receiver gets the same bitrate as local playback.

This is noticeable on wireless headphones and external systems, where the user hears the difference between "fine" and "as intended."

Output methods: built-in protocol and alternatives

The choice of output mechanism determines what exactly the viewer sees on the receiver: a separate video stream with its own interface or a full copy of the device screen.

The system protocol delivers content directly from the app, so playback control stays with the user, and quality does not depend on what is happening on the screen.

Screen mirroring hands everything over to the receiver — including notifications, device rotation, and system panels, which in content presentation scenarios is almost always unnecessary.

In practice, two modes are most often combined: the system protocol as the primary path for media content and mirroring as a fallback when the interface itself needs to be shown.

Streaming limitations are factored into the architecture in advance — handling connection drops, restoring playback position, behavior when the screen is locked. This way the app does not "break" on receivers of different generations and in an unstable network.

How we integrate AirPlay iOS streaming into an app

Integrating AirPlay into an existing app starts with an audit: we look at how the player is structured, where track metadata is stored, and whether there is a dedicated playback control layer.

It often turns out that the logic is spread across screens and the player state is not extracted into a separate service — in that case we first clean this up, otherwise streaming to an external screen will be out of sync with the interface.

Next, we design the integration scheme: we determine what exactly goes to the receiving device (audio, video, artwork, playback position), how the app learns about connection and disconnection, and how it behaves when the screen is locked and during an incoming call.

We lock down the scheme before work begins — it shows which modules are affected and which remain untouched.

1. App audit. We analyze the current player code, dependencies, supported formats, and system versions. The output is a map of bottlenecks and a list of changes.
2. Scheme design. We describe the data flow between the app and the receiving device, control points, scenarios for connection loss and returning audio to the phone.
3. Streaming setup. We connect the system media output layer, register the app as a source, and configure metadata and control from the lock screen.
4. Interface work. We add device selection, an active streaming indicator, and correct behavior for pause and seek buttons on both ends.
5. Streaming testing. We run scenarios on real devices and speakers: connection, switching between receivers, network loss, long playback, background mode.
6. Edge case debugging. We check audio and video desync, indicator freezing, and reconnection after a disconnection.
7. Handover. We deliver the source code, integration scheme, verification instructions, and a list of known platform limitations.

After handover, the client's team can develop streaming independently — extension points are documented and behavior for each scenario is locked down. If needed, we support the release and update it for new system versions.

Artifacts and documentation for the customer's team

After the project is handed over, your team retains a working environment that can be developed and maintained without us.

We hand over not a "folder with files," but a set of documents that enable an engineer familiar with iOS development to reproduce the build, deploy the receiver, and troubleshoot an incident.

• Integration documentation — where broadcasting is enabled in the app, how receiver discovery is configured, and what rights and permissions are required on the user's side.
• Flow diagrams — the path of media data from source to screen: buffering, quality switching, behavior during a network drop and when returning to the app.
• Access policies — which devices and networks can receive the stream, how rights are granted and revoked, and what happens when the device owner changes.
• Update procedures — the process for releasing changes to the broadcasting module, and compatibility checks with the current iOS branch and with previous versions of the app.
• Diagnostics instructions — typical failures (receiver not found, connection drops, audio-video desync) and the sequence of steps for each.
• Environment configurations — build parameters for the test and production environments, so that testing does not leak into production.
• Acceptance checklist — a set of scenarios by which your team independently confirms that broadcasting works on the target devices.

The documentation is written to be read by an engineer, not by the author: without references to our internal context, with extension points and places where edits are safe indicated.

If the system's behavior changes during maintenance, the procedures are updated along with the code — otherwise, six months later, no one will remember why that particular decision was made.

Case: Eliminating Desynchronization in a Video Conferencing Application

The client is a video conferencing service that broadcasts to external screens via AirPlay. Everything worked on test benches, but in real calls with 20-40 participants, the audio ran ahead of the video: the discrepancy reached 400-600 ms and grew as the meeting progressed.

Users wrote to support saying "the speaker talks before their mouth opens," and moderators restarted the broadcast manually — on average 2-3 times per meeting.

What Was Actually Happening

The application sent video and audio as separate streams, and the receiver built its own playback queue independently. When the network degraded, video was buffered while audio continued — the buffers diverged and no longer synchronized.

We moved the broadcast to a unified timeline: timestamps are set at the source, the receiver aligns both streams to a common reference signal, and when the buffer overflows, it resets only the video rather than the entire stream — without interrupting the audio.

Metrics Before and After

We also separately addressed reconnection: if the receiver lost the network for 5-10 seconds, the session recovered on its own, without dropping out of the conference.

Support stopped being the "first line" for audio — the share of broadcast-related requests dropped severalfold, and moderators returned to their own tasks instead of manual restarts.

How is AirPlay different from screen mirroring?

AirPlay is based on streaming: the app sends the receiver a media stream and metadata, and the TV or speaker decodes it on its own. In this mode, the phone remains a remote control — it manages the queue, position, and volume, but does not push a ready-made picture to the screen.

That is why the resolution and quality of the stream adapt to the receiver's capabilities, buffering smooths out network drops, and the phone itself can turn off its screen or switch to another app without interrupting playback.

Screen mirroring works differently. The device continuously encodes everything happening on the display and sends the receiver ready-made frames.

There is no separate media stream here — there is a video stream from the screen, so the TV gets exactly what the user sees: the interface, notifications, portrait orientation.

Latency is higher, the battery drains more noticeably, and quality is limited by how quickly the phone can encode frames.

The difference between the protocols shows up in what exactly the receiver knows. During streaming, it receives a track and decodes it natively, so the picture stays sharp on a large screen.

During screen duplication, the receiver works like a monitor: it knows nothing about the content and simply displays what it was sent.

For an app, these are two different tasks. If you need to output video or audio, streaming provides playback control, seeking, and correct background operation.

If you need to show an interface, a game, or slides, screen duplication is unavoidable, but keep in mind latency and battery consumption. The choice of mode also determines how the app behaves when the phone is locked and how stably the connection holds with a weak signal.

Common technical concerns

Streaming via AirPlay is not "ticking a checkbox in the settings" but working with a system protocol that has its own rules for codecs, buffering, and access rights.

Below are the things most often clarified before starting: receiver compatibility, real-world latency, channel security, and behavior across different system versions.

What is the latency between the phone and the screen?

During direct streaming, latency typically stays within fractions of a second — enough for video, presentations, and music.

For games and interactive scenarios, we configure buffering separately: we shrink the preload window but make sure the picture doesn't "tear" on a weak network. If latency is critical, we build in an alternative delivery channel and switch to it automatically.

How secure is the stream?

The connection between the device and the receiver is encrypted, and access to the receiver is confirmed by a one-time code on the screen.

The app doesn't store keys in plain text and doesn't pass content through third-party servers — the stream goes directly over the local network. For corporate scenarios, we add a restriction based on an allowlist of devices.

What about support for different iOS versions?

We set a minimum supported system version and test the build on the current branch and the two previous major ones. Where the system streaming interface differs, the app adapts its behavior on its own — the user doesn't notice a difference.

We also test rollback separately: if a system update breaks streaming, we have a plan to ship a fix without stopping the service.

Let's discuss your streaming task

Describe your current situation: what video or audio you're delivering, to which receivers — Apple TV, HomePod, third-party TVs with AirPlay support — and what you've already tried.

That's enough to understand the class of the task: enhancing an existing player, embedding streaming from scratch, or troubleshooting an already working protocol. Then we come back with an estimate and a work plan, with no obligation on your side.

How the task review works

• Gathering inputs. We clarify the content sources (HLS, local files, protected streams), target devices, and the minimum OS version that needs to be supported. Separately, we record what's already implemented in the app.
• Reviewing the current state. We look at the player, audio session handling, interruption and background mode handling. At this step it becomes clear exactly where the connection drops or the audio drifts out of sync with the video.
• Checking constraints. We assess which formats and content protections the receivers accept and which require transcoding on the app side. This determines the scope of work more than anything else.
• Estimate and plan. We break the task into stages with a clear result at each: basic connection, session stability, lock screen controls, failure handling.
• Agreeing on acceptance criteria. We define what we consider a finished result: the list of devices, reconnection scenarios, behavior during a phone call or network switch.
• Starting work. After the plan is agreed, we begin with a prototype on a single device — this reveals real constraints earlier than a full build would.

What you get from the task review

• An estimate of timelines and team composition for your task.
• A stage-by-stage work plan with a result for each.
• A list of risks: incompatible formats, receiver limitations, app store requirements.
• Recommendations on streaming architecture based on your current code.
• An engineer's answers to technical questions during the discussion.

To make the conversation concrete, attach a link to the app or describe the player and content sources — that way the estimate will be more accurate the first time. Describe the task, and we'll come back with a work plan and timelines.