Introduction

If you are building a realtime avatar kiosk in Swift, the hard part is usually not drawing a face. It is choosing the transport and runtime model that keeps audio, video, and conversational state aligned under real network conditions. For a kiosk, you typically need low latency, predictable reconnect behavior, a clean way to stream mic input and receive synthesized speech/video, and a deployment model that does not turn every browser or device into a security liability.

This post compares WebRTC, WebSocket, and LiveKit for that use case, with a focus on what actually matters for an interactive avatar running in Swift on a kiosk device. By the end, you should be able to decide which transport fits your architecture, what trade-offs you are accepting, and where an avatar-specific layer helps avoid unnecessary plumbing.

WebRTC is the right mental model for realtime media, not just “video in a browser”

People often treat WebRTC as “the browser video API,” but for avatar kiosks it is better thought of as a media session protocol: it is designed for low-latency audio/video, network adaptation, NAT traversal, and bidirectional streams. If your kiosk needs to capture microphone input and display a lip-synced face with minimal delay, WebRTC is the most natural transport.

Why it matters:

• Audio and video are first-class. You are not bolting media onto a generic message channel.

• Latency control is built in. SRTP, jitter buffers, congestion control, and adaptive bitrate exist specifically for this workload.

• Reconnection semantics are media-aware. A transient network issue does not necessarily mean your whole app state is gone.

For a Swift kiosk, the usual pattern is: capture audio from the device, send it to a media session, receive avatar video frames or tracks back, and render them in a native view. That gives you a path to real-time conversation where speech and face animation stay synchronized.

The downside is complexity. WebRTC is a stack, not a single socket. You need signaling, ICE candidate exchange, session coordination, media track handling, and usually a server-side component or provider to manage the session. If your team wants to own the full media plumbing, WebRTC is powerful. If you only want a talking avatar working this quarter, it is easy to lose time in the details.

WebSocket is simpler, but it is the wrong default for media

WebSocket is excellent for control plane traffic: session state, prompts, partial transcripts, events, and UI updates. It is not a media transport optimized for realtime audio/video. You can stream binary audio over WebSocket, and many teams do this early on, but once the system becomes interactive, the trade-offs show up quickly.

The main limitation is that WebSocket gives you a reliable ordered byte stream, which is not the same as low-latency media delivery. If packets are delayed, they queue. If the network is jittery, you feel it. If your avatar depends on timely audio chunks to drive lip sync and speech timing, buffering behavior becomes user-visible.

Use WebSocket when:

• You are sending control messages, not live media.

• You can tolerate buffering and occasional stalls.

• You want the simplest possible client/server model.

Do not use WebSocket as your primary transport if the kiosk experience depends on continuous audio/video playback with tight synchronization. It can work for prototypes, but it is usually a migration path, not an end state.

LiveKit gives you the media layer, plus a practical realtime application model

LiveKit sits in the middle in a useful way: it gives you a WebRTC-based realtime media system and an application model for rooms, participants, tracks, and agents. For kiosk-style avatars, that is often the sweet spot. You get WebRTC where it belongs, but you do not have to implement all the session plumbing yourself.

Conceptually, this is the cleanest split:

• WebRTC handles transport of audio/video.

• LiveKit handles rooms, signaling, participant lifecycle, and agent coordination.

• Your voice agent handles ASR, reasoning, TTS, and conversation policy.

• The avatar layer turns the agent’s speech into synchronized video.

That separation matters because the avatar is not the conversation engine. It is a rendering surface tied to the agent’s speech timeline. If the user interrupts, the transport must stop cleanly, the agent must update state, and the avatar must reflect the interruption without drift. LiveKit is a better fit than raw WebSocket for that because the session model matches the media problem.

Swift kiosk architecture: what should live where

For a native Swift kiosk, a reasonable architecture looks like this:

1. The kiosk app authenticates to your backend.

2. Your backend creates or joins a realtime session.

3. The kiosk joins the media session and publishes microphone audio.

4. The avatar/video track is subscribed to and rendered locally.

5. Conversation events and metadata move over the control plane, not the media plane.

Two practical rules keep this sane:

First, keep secrets out of the client. If your Swift app runs on controlled hardware, you may still prefer short-lived session tokens instead of long-lived API keys in the device. If the kiosk is not trusted, never expose privileged credentials there.

Second, separate media from orchestration. Let a control service decide which avatar, instructions, and voice profile apply to a session. Do not overload the media connection with business logic.

That separation also makes debugging possible. When a kiosk looks “laggy,” you want to know whether the issue is microphone capture, transport jitter, TTS latency, avatar rendering, or session orchestration. If everything rides the same generic WebSocket, you lose that visibility quickly.

Where Protoface fits: an avatar layer on top of the realtime session

This is the part that usually saves the most time. Protoface is built to add a synchronized talking face to realtime voice systems without forcing you to build the avatar pipeline from scratch. For teams already using LiveKit agents, the relevant integration is the LiveKit plugin: it drops a Protoface avatar into the agent so the voice interaction gains a lip-synced video face while the underlying media session stays intact.

In practice, that means you can keep your existing LiveKit-based voice flow and add the avatar as a media participant instead of inventing a separate video stack. The exact setup varies by agent framework, but the shape is straightforward: create or choose the avatar, attach it to the session, and let the agent drive speech while the avatar renders the synchronized output. The plugin and examples are the best place to start if you want to see the agent-side wiring in context: example quickstart and the integration docs at docs.protoface.com.

If your kiosk is not using LiveKit, the REST API and Python SDK cover avatar and session management directly. A minimal API flow looks like this:

curl https://api.protoface.com/sessions \
}'

curl https://api.protoface.com/sessions \
}'

curl https://api.protoface.com/sessions \
}'

The exact request fields are documented, but the important point is architectural: keep avatar/session creation on the server, keep credentials out of the browser, and let the kiosk consume a scoped realtime session rather than permanent credentials.

When WebSocket still makes sense

WebSocket is not useless here. It is useful for:

• sending user events, button presses, and session metadata;

• streaming partial transcripts or agent state;

• simple admin panels or dashboards;

• fallback control channels when media is handled elsewhere.

If you are building a kiosk that only needs to trigger an avatar animation, play back pre-generated audio, or show status updates, WebSocket may be enough. But once the experience becomes conversational and interactive, you generally want WebRTC for the media path and WebSocket only for control.

Practical decision guide

Choose based on the problem you are actually solving:

• Use WebRTC if you need low-latency bidirectional audio/video and are willing to manage the media stack.

• Use LiveKit if you want WebRTC-based realtime sessions with a cleaner application model for voice agents and avatars.

• Use WebSocket for control, metadata, and simpler non-media interactions.

For a Swift avatar kiosk, the common mistake is to start with WebSocket because it looks simpler, then bolt on enough media logic that you have effectively reimplemented parts of WebRTC badly. A better approach is to use the transport that matches the media problem, then keep the rest of the system boring.

Conclusion

For realtime avatar kiosks, WebRTC is the right transport class, WebSocket is the right control channel, and LiveKit is often the pragmatic layer that keeps the system manageable. If you are building in Swift, optimize for clean media handling, session-scoped credentials, and a separation between orchestration and rendering.

If you want to add a synced avatar to an existing voice agent, start with the LiveKit integration and the docs at docs.protoface.com. If you need a server-side session flow or programmatic avatar management, use the REST API or Python SDK and keep the kiosk client focused on joining and rendering. That will save you from most of the transport and security mistakes teams make on their first pass.