Abstract
Abstract
Mirror is a local Wi-Fi presentation application for iPhone and iPad that sends a user-selected screen to a compatible Cast receiver. Its design uses a bounded local delivery path: screen media remains on the local network, the app does not operate a relay service for presentation content, and the current product does not stream audio. This paper describes the architecture as a local presentation workflow, the difference between local user-content transport and hosted software components, and the practical limits of the release surface.
Introduction
Presenting a phone or tablet screen to a television is often treated as a general cloud-media problem even when the user, device, and receiver are on the same local network. Mirror takes the narrower local case. The user selects a Cast-capable receiver, starts the presentation workflow, and sends the screen across local Wi-Fi. The product does not create an account, operate a relay for screen content, or retain a server copy of the presentation.
The design is intentionally bounded. It supports Cast receivers in the documented scope and does not claim AirPlay, DLNA, Roku, Fire TV, or proprietary television-protocol support. It also does not bypass digital rights management or turn the phone into a background recorder.
System Design
The planned and implemented architecture centers on a broadcast extension, a bounded local segment path, and a Cast receiver session. A ReplayKit screen source produces presentation material that is prepared for local delivery; a local session record coordinates the active presentation; and the application directs the receiver to the local stream path. The design uses an app-group handoff for shared session state and limits media retention to the active presentation window.
Local transport does not eliminate every hosted dependency. The receiver platform and software development kit remain platform components, and a Cast receiver may rely on the platform's standard receiver model. The important privacy distinction is that the user's selected screen content is not routed through a Charles Morgan Software relay service.
Use Cases
Mirror is suited to a meeting, classroom, living-room, workshop, or local demonstration where the user wants to show the entire iPhone or iPad display on a compatible television. It can support presentations, application demonstrations, visual review, and shared viewing of material that is already on the device. The user retains responsibility for what is placed on screen and for confirming that the selected receiver is appropriate for the audience.
The design does not claim universal receiver compatibility or a replacement for platform-native screen-sharing systems. A receiver and the presenting device must be on a reachable local network, and the quality of the experience depends on that network and the receiver's supported media behavior.
Privacy and Operational Boundaries
Mirror is designed for local presentation, not a hosted relay. Charles Morgan Software does not receive or store screen content through a presentation server. The product does not stream audio. The app includes a Cast software development kit whose privacy disclosures are separate from a claim that the developer operates a content relay; users should review platform disclosures for device identifiers, diagnostics, and product interaction data.
The user should avoid displaying passwords, private messages, confidential records, or other material that is inappropriate for the receiver and room. Support reports should include device and television model information rather than private presentation material or account credentials.
Limitations and Implications
Mirror is constrained by iOS broadcast behavior, Wi-Fi quality, receiver compatibility, and the documented video-only scope. A local path can reduce the data exposure created by a cloud relay, but it does not guarantee that every receiving device or network is trustworthy. Users still choose the receiver and control the presentation.
The implication is that local media architecture should be described precisely. Keeping screen content on the local network is a meaningful privacy property, while product claims must still acknowledge platform dependencies, receiver limitations, and the user's responsibility for the content displayed.
References
- Mirror implementation design. Local presentation, segmented media, session handoff, and Cast constraints. Accessed July 2026.
- Mirror privacy policy. Local screen presentation and support boundaries. Accessed July 2026.