Smart TV apps live and die by their playback experience. On mobile, users can drag a timeline slider to scrub through content precisely. On TV platforms like Apple TV, however, interaction happens through a remote with limited input signals no touch screen, no mouse, just a few buttons and a touchpad.
Imagine trying to skip ahead 15 minutes in a 2-hour movie using fixed 10-second jumps. That’s 90 button presses just to get where you want to go. This is the problem intent-based playback controls set out to solve not just making seeking faster, but making it smarter.
The seek bar on Apple TV works reliably in most playback scenarios, but there are specific cases where intent-based controls become particularly valuable. In certain contexts such as when keyframes are active during scrubbing or during live content playback, seek bar focus is intentionally restricted and taps are added as the primary input instead. This means the user is interacting with the player through gestures and button presses rather than navigating a scrubber, and the app needs to interpret those inputs as meaningful seek actions rather than ignoring them or falling back to fixed increments.
Even in cases where seek bar focus is fully available, requiring users to first navigate focus down to the scrubber just to skip ahead adds unnecessary friction to the viewing experience. Intent based controls eliminate this by allowing seek actions to be triggered directly from wherever focus currently sits no extra navigation required.
What Does “Intent-Driven” Mean?
A standard player treats every remote press identically. Press left once or press it twenty times, each press means the same thing: subtract 10 seconds.
An intent-driven player asks a different question: what is the user trying to do?
A tap says “move a little.” A hold says “I meant more than just a tap, move further.” A long press, where the finger stays down, says “keep moving, I’ll lift when I get there.” A direction reversal says “I overshot, correct me.”
Each of these is a distinct intent expressed through the same physical button. Instead of fixed actions, we derive behaviour from press duration and frequency turning a simple remote into a precise navigation tool.
From Remote Signals to User Intent
The Apple TV remote only provides a few signals: Directional press (left / right), Press duration, Gesture velocity, Focus updates.
The architecture recognises three distinct levels of intent from a single directional press, each with a different behaviour and a different threshold.
A tap under 0.6 seconds triggers seek acceleration. The first press jumps a small amount. Continuing the same direction builds momentum through a quadratic ease-in curve, reaching larger and larger jumps with each additional press.
A held press in the same direction still under the long press threshold continues acceleration. The step size grows from a base of 10 seconds up to 120 seconds for long-form content, reaching full acceleration after roughly 5 presses. The same logic could be used for main screen rails scroll acceleration as well.
A long press held for 0.6 seconds without releasing activates speed mode. The engine switches from position-based seeking to rate-based playback. The right arrow ramps forward playback through 1.5x, 2x, and 3x. The left arrow does the same in reverse. Releasing restores normal 1x playback instantly.
Architecture Overview
Our architecture has a core component that calculates acceleration using press timing, a component to handle long-press speed mode, another component that handles seek preview, acceleration logic, commit timing, it also contains the seek state machine.
The player supports two complementary navigation styles.
Timeline Scrubbing (Focus Based) where users focus on the seek bar and then navigate along the timeline similar to mobile scrubbing. Intent-Driven Remote Seeking provides quick navigation without focusing the timeline.
Seek Intent Engine
The SeekIntentEngine interprets directional presses and converts them into seek actions.
It converts step size into a target time in seconds. It maintains a formal state machine: idle, pressing, accelerating, committing, cancelled.
enum SeekState: Equatable {
case idle
case pressing(direction: PressDirection, stepSeconds: Int)
case accelerating(direction: PressDirection, stepSeconds: Int)
case committing(direction: PressDirection, targetTime: Double)
case cancelled
}Content-Aware Acceleration
Playback startup performance is also equally important. A key metric we track is Time to First Frame (TTFF) The player can dynamically adjust acceleration based on metadata like videoDuration, isLive, contentType.
This makes the experience feel tailored rather than generic such as : smaller jumps for trailers, limited seek window for live streams, balanced acceleration for movies.
How AVPlayer Rate Works
The speed ramp comes down to one property: player.rate. AVPlayer uses this single float to control everything playback speed, direction, and pause state. Setting it to 2.0 doubles forward speed. Setting it to -1.5 plays in reverse at 1.5x. Setting it to 0.0 pauses.
Not all content supports all rates. HLS streams declare supported playback rates in their manifest. Most VOD streams support up to 2x natively; beyond that, AVPlayer may silently fall back to a lower supported rate without any error or callback. Before advertising a speed tier in the UI, check currentItem?.canPlayFastForward and currentItem?.canPlayFastReverse to confirm the content supports it. A speed badge showing 3x while AVPlayer quietly plays at 2x is a credibility problem.
The separation between seek and speed is clean. They share no state. When speed mode activates it cancels any pending seek commit so there is no double-movement. When speed mode ends the seek engine is ready to receive input again from the next press.
Accelerated Carousel Navigation – Reusing the Intent Model for UI Navigation
Consider the home screen has 20 content rails, each with 10 items. Default tvOS focus moves one item per press. For a user looking for something specific in a long rail this is the same problem as seeking they need to move faster than single-press navigation allows.
The Scroll intent engine solves it with the same Acceleration Engine core. The only difference is the output: instead of seconds, the step becomes an item count. First press moves one item. Held press builds to three items at a time.
Each RailCell owns its own ScrollIntentEngine instance. Acceleration state is independent per rail, switching rails resets the step counter automatically. There is no shared state to manage.
Looking Ahead: Apple Ecosystem Integration
The intent engine architecture is well positioned to extend into the broader Apple ecosystem in ways most OTT apps have not yet explored.
Siri integration is the most natural next step. Because intent is already modeled explicitly, seek forward, seek backward, jump to position, change speed those intents can be exposed as App Intents and made available to Siri voice commands. The intent layer already exists. It just needs to be surfaced to the system.
Handoff from iPhone is equally compelling. Because SeekIntentEngine tracks current time and content profile continuously, that state can be encoded into an NSUserActivity and picked up on Apple TV. The experience becomes: put down the phone, pick up the remote, continue. No menus, no progress bars, no resume prompt required.
Both extensions follow naturally from modelling navigation as structured intent rather than raw button events. When the system understands what the user is doing, other Apple platforms can participate in that understanding.
This pattern is not exclusive to Apple TV. The same concept translates well to mobile platforms too. On iOS and Android, users often interact with video players through taps and swipes rather than navigating to the seek bar directly. Implementing intent-based controls on mobile means a double-tap seeks forward or backward, a swipe adjusts position, and the user never has to precisely target a small scrubber handle on a touch screen. The intent is the same across platforms only the input method changes.
Wrapping Up
Playback controls are one of the most important interactions in any TV streaming experience. Yet many players still treat every remote press the same, forcing users to navigate long content through repetitive fixed jumps.
With a small intent engine, a simple state machine, and careful use of AVPlayer capabilities, developers can transform basic playback controls into a far more responsive interaction system.
As OTT experiences continue to evolve across Apple TV, mobile devices, and voice interfaces, setting navigation around user intent rather than raw events opens the door to more human centric experiences across the entire Apple ecosystem.
