# Streamer: a sideloaded iOS and tvOS client for a pluggable source layer > The Streamer app plays movies and TV shows from multiple websites on iOS and tvOS, and the interesting engineering is not the player but the distribution: there is no App Store build, so the application is delivered as an .ipa that a user signs and installs with AltStore, Sideloadly or Scarlet, using a source manifest the project publishes. **StreamerApp/Streamer** — App for Tracking Movies and TV shows on iOS and tvOS - Repository: https://github.com/StreamerApp/Streamer - Stars: 1,134 · Forks: 12 - Language: Unknown - License: not declared - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/streamerapp-streamer ## What the application does Streamer is an app for streaming movies and TV shows on iOS and tvOS, and the feature list is short. It can stream all TV shows and movies from multiple websites, it supports Chromecast to stream to Fire TV devices and Chromecasts, it supports multi-language subtitles on both iOS and tvOS, and it has a favourites feature to quickly reach the shows and movies you care about. Read as a product, that is a player with a source layer attached. The multiple websites are the variable part, and the Chromecast and subtitle support are the parts that make it usable on a television, which is where a person actually wants to watch something. The favourites list is the minimum of state a viewing app needs, and the fact that it is mentioned separately suggests the rest of the app is stateless in that respect. The project is maintained under the StreamerApp organisation, the default branch is `main`, and the recent releases are 1.3.2 from 2026-04-24, 1.3.1 from 2026-04-21 and 1.3.0 from 2025-05-18. The last push was on 2026-04-24, and the project is not archived. Two fields are worth reading carefully in the repository metadata. The licence is not classified by GitHub, so there is no standard licence identifier to rely on, and the primary language is not reported either, which is consistent with a repository whose visible contents are documentation and configuration rather than source. The screenshots in the README show the iOS app and three tvOS screens, and the header image is the app icon. The repository also carries a `CODE_OF_CONDUCT.md` and a `SECURITY.md`, which are the two files a project publishes when it wants to be taken seriously as a project rather than as a personal build. ## Distribution is the actual engineering problem There is no application on the App Store, and the README does not apologise for that. It simply moves the problem, and the whole installation section is about it. For iOS, the application works on iOS 15 or later, and the artefact is a signed package, `Streamer-iOS.ipa`, downloaded from the latest release. The README then lists four ways to install it, and the list is worth reading in full because each one is a different trade. AltStore is the route with the least tooling, and the project also publishes an `altstore.json` source manifest plus a link to an online source viewer, so a user can add the source once and let the tool handle updates. Sideloadly is the route for a computer that can sign for the device directly. Scarlet is another signing tool, with its own `scarlet.json` manifest. And reprovision is the route for a user who already has a provisioning profile and wants to re-sign an existing install. For tvOS the artefact is a different file, `Streamer-tvOS.ipa`, and the README is blunter about the tooling: use an iOS App signer, or Sideloadly. There is no App Store distribution for either platform. So the delivery story of this project is that the binary is published as a file and the user is a signing operator. That has consequences a reviewer should state plainly, because it is the defining characteristic of the project. A signed install on iOS has a lifetime, and when the signature expires the application stops launching until it is signed again. An AltStore source automates that, and the other routes do not. The second consequence is that the update path is the user's problem. There is no store to push a new build to, so a new release is a new file and a new signing operation. ## Addons and resolvers are where the sources come from The repository documents the source layer separately from the app, and two files do most of that work. `streamio_addons.md` covers the addons, and `Universal_Resolvers.md` covers the resolver mechanism. The naming makes the architecture clear: the app is a player, the sources are plugged into it, and the mechanism for extracting a playable URL from a given site is called a resolver. The `altstore.json` and `scarlet.json` files are the distribution manifests for the two signing tools, and the pattern is the same as the one used by the wider Stremio-style addon ecosystem that the name refers to. That separation is the design decision that makes the project extensible. A new source is a new addon rather than a new build of the app, which is why the releases move in small increments and why the addons documentation is a first-class document in the repository rather than a wiki page. The consequence for the user is a two-part system to trust: the binary, which is signed by the user or by a tool on their behalf, and the source configuration, which decides where the streams come from. The first part is the ordinary risk of sideloading, and the second is the ordinary risk of a configurable source layer. The repository also carries `download-error.md`, which is a small sign of how the project is run. A document that only exists to explain a download failure is a document written after the fact, in response to something that actually happened to users, and it is more informative about the state of a project than a feature list is. ## What the README does not tell you The README is a user guide, not a developer guide, and the difference shows in what is missing. There is no build instructions, because the project does not appear to publish its sources in this repository, and the primary language field is empty for the same reason. There is no statement of the technology inside the app, no architecture description, and no test suite. What there is instead is a set of documents, each aimed at a specific failure. `installation.md` and `installation-tvos.md` split the two platforms, because the signing routes genuinely differ. `download-error.md` exists for the case where the download does not work. `altstore.json` and `scarlet.json` are machine-readable manifests for the signing tools, and `Universal_Resolvers.md` and `streamio_addons.md` describe the source layer. That split is a reasonable structure for a project whose users are consumers rather than contributors, and the absence of a contribution guide in the root reflects the same thing. One detail from the metadata is worth repeating, because it decides whether a company can use this at all. The licence is not classified by GitHub, and the root entries do not show a LICENSE file, so the terms are not stated in a form that a compliance process can check. A personal user does not care. An organisation that wants to put the application on a managed fleet of devices has nothing to check against, and that is the first question to ask the maintainer. ## Where the Streamer app is the wrong tool Two limits are obvious and one is a matter of expectations. The first is the distribution model. A sideloaded application on iOS is signed by a certificate with a limited validity, and when the signature expires the app stops opening until it is signed again. The AltStore route automates the cycle, and the manual routes do not, which means a fleet of managed devices needs a signing pipeline that somebody has to own. For a single user that is an annoyance to be reminded of every couple of weeks. For a dozen devices it is a support ticket waiting to happen, and the README does not say how the project intends to handle it beyond pointing at four tools. The second is that the app is a client for content it does not host, so its usefulness depends on sources that it does not control and that change without notice. A resolver that stops working is a support question with no answer in the repository, and the project has no mechanism described for reporting a broken source other than the general issue tracker. The third is the expectation. A client that aggregates many sources and adds subtitles and casting is a convenience, and for a service with its own official application, the official application is better supported, updated by the service, and usually signed by the service. The difference in approach is that this app is a player plus a configurable source layer, which is exactly the right design for somebody who wants one interface across several services, and the wrong design for somebody who wants the best experience from one service. The alternative is a plain sideloaded app per service, or the official apps, and the trade is flexibility against support. The project is at version 1.3.2, published on 2026-04-24, with 1.3.1 three days earlier, and the gap back to 1.3.0 from May 2025 suggests a project that ships when there is something to ship rather than on a schedule. ## Conclusion Streamer fits a user on iOS or tvOS who wants one client for several sources, who is prepared to maintain a sideloaded install, and who wants Chromecast to a television and subtitles in more than one language. It is the wrong tool for anybody who needs an application that updates itself, because a sideloaded build has to be re-signed and reinstalled by hand, and it is the wrong choice for a team that needs a supportable client for a specific service, since the official application of that service will always be the better supported option. Before installing, read `installation.md` and `installation-tvos.md` in the repository, because the two platforms have different signing paths, and check the release you download, since the last published builds are 1.3.1 and 1.3.2 from April 2026. ## FAQ ### What is the Streamer app for iOS and tvOS? It is an app for streaming movies and TV shows from multiple websites on iOS and tvOS, with Chromecast support to stream to Fire TV devices and Chromecasts, multi-language subtitles for both platforms, and a favourites feature for quick access to your shows and movies. ### How do I install the Streamer app on iOS? Download the Streamer-iOS.ipa from the latest release and install it with AltStore, Sideloadly, Scarlet or reprovision. The repository also publishes altstore.json and scarlet.json source manifests so a signing tool can track updates, and the app requires iOS 15 or later. ### How is the Streamer app installed on tvOS? The tvOS build is a separate artefact, Streamer-tvOS.ipa, downloaded from the latest release and signed with an iOS App signer or with Sideloadly, and the README notes that tvOS also requires iOS 15 or later. ### Where do the Streamer app's sources come from? The repository documents them in streamio_addons.md, and the mechanism for turning a site into a playable stream in Universal_Resolvers.md. The source layer is pluggable rather than baked into the binary, which is why the addons are documented separately from the application itself. ## Sources - [Issues](https://github.com/StreamerApp/Streamer/issues) - [README](https://github.com/StreamerApp/Streamer/blob/main/README.md) - [Releases](https://github.com/StreamerApp/Streamer/releases) - [StreamerApp/Streamer on GitHub](https://github.com/StreamerApp/Streamer) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/streamerapp-streamer