Living Content: What It Means When Each Feed Item Actually Runs | Rifff

The short answer

"Living content" in Rifff means each item in the vertical feed is a program that runs on your phone, not a file that plays on it. A still image and a video clip are both finished artifacts — you watch them and move on. A living item is mounted as a live view that responds to you, and it is riffable: remixed, continued, or rewritten into your own version. There is no broadcaster and no live stream; "alive" describes what the item is, not who is transmitting it. If you are weighing whether this is categorically different from a video feed, that difference is the whole point — and the sections below say exactly what runs, what fails, and what it costs.

Why "living content" needs explaining at all

Two different things hide behind the word. First, "live" in social apps almost always means live streaming: a person broadcasting right now, a viewer count, a delay you cannot scrub back. Rifff means neither. Second, "interactive" gets used loosely for videos with a tap-to-pause overlay or a poll pinned on top — a wrapper around a fixed clip.

The real problem behind the query is more practical than semantic. People arrive at the phrase expecting to be told what the app looks like and get marketing instead. What they actually need to know is: when I scroll to the next item, what happens — and if it does not work, will the app pretend it did? Both have concrete answers, and both are things a competitor page will skip.

What actually runs when you scroll

Every item in the feed carries publication coordinates: a content id, a revision id and an artifact id. That triple resolves into an execution route the client is willing to trust, and the route says how to fetch the item's package — its source plus the assets it references — instead of pointing at a media file. The package goes to the Sigma engine, which renders it into a scene sized to the screen, and that scene is mounted as a real view inside the full-screen cell.

Three consequences fall out of that, and they are the mechanics behind the marketing sentence:

• The scene is sized to your screen, not to a fixed canvas. Rendering happens at the cell's size, so an item lays out differently on a small phone and a large one.
• It is rendered in your identity. The renderer is handed the current signed-in user's id, so the same published item is not guaranteed to render identically for two different people.
• Turning live is prefetched, not waited for. Rifff warms the packages of the next two items and the one behind you into a disk cache, so most items are already on the phone when the swipe lands. Pulling the list is a separate mechanism and starts two items from the end.

Alive means it fails in the open

This is the part that separates a live feed from a video feed in practice, and it is the honest cost of the model.

Rifff never shows a still image as a stand-in for a live item. While a package is loading, the cell shows an animated waveform over a gradient. If the package fails to fetch or fails to render, the cell says so and offers a tap to retry — it does not fall back to the preview image. The reason is mechanical rather than stylistic: the preview still has the same shape and colour as the live scene, so showing it would produce an item that looks playable and does nothing when you touch it.

That creates a state video feeds essentially never have: an item that is in the feed and cannot be played. And the client refuses the quiet version of that failure too — a published item carrying only some of its coordinates, a revision id without an artifact id for instance, is rejected outright rather than downgraded into a legacy load. Rifff draws that line on purpose.

There is also a second kind of item, which the app treats honestly rather than pretending: content that is only a preview, with no package behind it. Those render as a static image, and for them the static image is the final state, not a placeholder. So "every item is alive" describes the feed's design and its default, not a claim that nothing in it can be still.

What it costs to run instead of play

Set the two feeds side by side and count what one swipe costs.

A video item is one fetch and a decoder handing frames to a surface. A living item is a package fetch, an engine handoff, a rendered view graph mounted into the cell, and a teardown when the cell is recycled. That is more work per swipe, and it is why three mechanisms exist that would be pointless in a clip feed:

• Prefetching the render, not just the list — two items ahead, one behind — so the engine work overlaps your scroll rather than trailing it.
• Cancelling in-flight work on reuse. Each slot carries a generation counter; when a cell is reused, its in-flight tasks are cancelled and the counter is bumped, so a slow render from the previous item can never paint over the one you are actually looking at.
• Treating live as a terminal state. Once the scene is mounted, nothing writes back into that cell.

The cost runs the other way too, and you should price it: the first item after a cold launch has no warm cache, so the waveform is genuinely visible; and a weak connection surfaces that waveform more often than a video feed would, because a package is a larger and more failure-prone fetch than a stream a CDN can already serve.

What "alive" is not

Each of these is a reasonable guess, and each is wrong:

• It is not a livestream. No broadcaster, no viewer count, no live badge. Nothing is happening at the source while you look at it.
• It is not interactive video. The interaction is not a control layer painted over a clip, because there is no clip.
• It does not use your camera. Rifff records your microphone only and never opens the camera. The camera permission is declared solely to get past Apple's static review scan, which reads the capture framework by symbol and cannot see that the session is audio-only. In practice: you cannot film living content and post it.
• You do have to sign in. Apple sign-in and email code both work, and the feed sits behind the login. There is no anonymous browsing mode.

What Rifff does differently

Rifff's bet is that the unit of a social feed should be something you can act on rather than something you have seen: riffing is the primary verb on an item, not an extra button sitting beside save. How riffing actually works covers that loop, and the live rendering is what makes it feel like a medium instead of a format.

The honest limits:

• iPhone, iOS 17 and later.
• It is early. The app is on a weekly release cadence and still moving feature by feature.
• Living items are heavier than clips, asking more of the network and the battery than a video feed does. On a poor connection you will see the loading state more than you would like.
• The value depends on the catalogue. A feed of living items is only worth scrolling if people are publishing them. Rifff ships a conventional feed around that format; the live layer is a medium available to creators, not a guarantee about what any given creator makes with it.

Whether it is worth your evening

The decision is narrow. If you have wanted a feed whose content responds to you rather than the other way round, and you are willing to accept that some items will show a loading waveform or a retry prompt, Rifff is worth an evening. If what you want is a video feed that always plays, or a way to film and post video from your phone, this is the wrong app — the second one especially, since the camera is never opened.

Judge it on one scroll rather than on the description. If the first two items turn live under your thumb with no button press, the concept landed; if you find yourself tapping a still that was never going to move, then you wanted a video feed, and no amount of "living content" marketing changes that.