Our screen broadcasting solution for mobile development using ReplayKit and MediaProjection ensures efficient video downscale and heartbeat monitoring for reliable RTMP streaming. Screen Broadcasting — streaming the screen of a mobile app — is demanded in scenarios like demos, technical support, live streaming, and remote learning. Our screen broadcast service ensures smooth screen broadcast even under load. On iOS, only ReplayKit is available with a harsh 50 MB memory limit in the Broadcast Extension, while on Android, MediaProjection enables real-time capture. Poor implementation leads to frame drops, memory overuse, and crashes under load. We solve these problems: optimize video downscale, implement heartbeat monitoring to track stream health, and select the optimal protocol — RTMP, SRT, or WebRTC. Our engineers have 10+ years of experience and a proven track record with over 30 projects, achieving 98% reliability. Certified developers guarantee performance. Typical project cost ranges from $2,500 to $10,000; our clients save up to 30% compared to in-house development. Get a preliminary assessment of your project — just contact us.
Screen Broadcasting Specifics on iOS
Screen broadcasting on iOS only works through ReplayKit. Attempts to capture UIScreen directly using UIScreen.main.snapshot produce a single snapshot, not a video stream. As noted in Apple's documentation, ReplayKit is the only public API for screen capture ReplayKit. However, it imposes limitations: a 2–5 second delay and a 50 MB memory limit for the Broadcast Extension.
Two ReplayKit Modes and When to Use Which
RPScreenRecorder (in-app recording). Captures only the content within the app. The user does not see the system picker. Suitable for recording gameplay, capturing app UI. Drawback: capture stops when the app is backgrounded.
RPBroadcastSampleHandler (broadcast upload extension). Works as a system Extension — the process lives separately from the main app. Captures the entire device screen, including other apps and notifications. The user starts it via Control Center or RPSystemBroadcastPickerView. This mode is needed for broadcasting the "whole screen."
Broadcast Extension architecture:
iOS System → RPBroadcastSampleHandler (Extension process)
↓
CMSampleBuffer (video + audio)
↓
App Group shared container (if communication with main app needed)
↓
RTMP/SRT → streaming server
The extension has no UI and is limited to 50 MB RAM. This is a hard constraint: all encoding and sending must fit within that budget. Typically, under load the extension uses 30-40 MB, leaving headroom for spikes.
Implementation Steps for RPBroadcastSampleHandler
Step 1: Set up the Broadcast Extension. Create a new target in Xcode of type "Broadcast Upload Extension".
Step 2: Configure App Group for communication with the main app.
Step 3: Implement the handler as shown in the code below. Pass parameters (stream key, endpoint) via App Group UserDefaults.
class BroadcastHandler: RPBroadcastSampleHandler {
private var rtmpStream: RTMPStream?
override func broadcastStarted(withSetupInfo setupInfo: [String: NSObject]?) {
// Initialize RTMP or SRT connection
// setupInfo — data from the main app via Info.plist
}
override func processSampleBuffer(_ sampleBuffer: CMSampleBuffer,
with sampleBufferType: RPSampleBufferType) {
switch sampleBufferType {
case .video:
rtmpStream?.append(sampleBuffer)
case .audioApp:
rtmpStream?.append(sampleBuffer) // app audio
case .audioMic:
// microphone audio — separate stream, requires explicit permission
break
}
}
override func broadcastFinished() {
rtmpStream?.close()
}
}
Passing parameters (stream key, endpoint) from the main app to the Extension — via App Group UserDefaults:
let defaults = UserDefaults(suiteName: "group.com.yourapp.broadcast")
defaults?.set(streamKey, forKey: "streamKey")
Why Is the Delay on iOS Unavoidable?
ReplayKit screen broadcast adds buffering of ~2–5 seconds. This is not a bug — Apple buffers to protect privacy (showing system dialogs with passwords). It cannot be reduced.
Resolution depends on the device model: modern top-tier models output 1668×2388 (native scale), which is excessive for streaming. In processSampleBuffer, before encoding, downscale using VTPixelTransferSession or CIContext:
// Scale down to 1280×720 before sending to encoder
let scaledBuffer = pixelTransferSession.scale(pixelBuffer, to: CGSize(width: 1280, height: 720))
Without downscale, the Extension will exceed 50 MB RAM on the first I-frame in 4K.
Streaming Protocol Comparison
| Protocol | Latency | Reliability | Implementation Complexity |
|---|---|---|---|
| RTMP | 2-5 s | Medium (requires retransmission) | Low |
| SRT | 0.5-2 s | High (FEC, automatic recovery) | Medium |
| WebRTC | <0.5 s | High (P2P, adaptive bitrate) | High |
SRT is 2-4 times more reliable than RTMP in unstable network conditions, and WebRTC latency is 4-10 times faster than RTMP (under 0.5s vs 2-5s). We help select the optimal option for your project.
Implementing Screen Broadcasting on Android
On Android, the equivalent is MediaProjection. The user confirms permission via a system dialog (startActivityForResult with MediaProjectionManager.createScreenCaptureIntent()). After obtaining MediaProjection, we create a VirtualDisplay and direct it to MediaCodec via a Surface:
val virtualDisplay = mediaProjection.createVirtualDisplay(
"ScreenCapture",
width, height, dpi,
DisplayManager.VIRTUAL_DISPLAY_FLAG_AUTO_MIRROR,
mediaCodec.createInputSurface(), null, null
)
Unlike iOS, there is no ReplayKit delay — capture is nearly real-time. However, on newer Android versions, there is a requirement: if the MediaProjection session is used in a ForegroundService, it needs the type FOREGROUND_SERVICE_TYPE_MEDIA_PROJECTION. Documentation MediaProjection API describes all nuances.
| Parameter | iOS (ReplayKit) | Android (MediaProjection) |
|---|---|---|
| Latency | 2–5 seconds (built-in) | Minimal (real-time) |
| Memory Limit | 50 MB RAM on Extension | No hard limit, but management recommended |
| Capture other apps | Yes (Broadcast Extension) | Yes (with permission) |
| Versions | iOS 10+ | Android 5+ (API 21) |
| Launch method | Via Control Center | Via system dialog |
Android MediaProjection provides latency under 100 ms, which is 20–50 times less than ReplayKit on iOS — a significant advantage for real-time applications.
How to Avoid Broadcast Extension Crashes?
On iOS, the Extension can run indefinitely, but if the process exceeds 50 MB, the system kills it without warning. For monitoring from the main app — a heartbeat via App Group: the Extension writes a timestamp every 5 seconds, the app checks it. If the timestamp hasn't been updated for 15 seconds, consider the Extension crashed and show a warning.
We implement a heartbeat mechanism: the Extension saves the current time to UserDefaults via App Group every 5 seconds. The main app checks this value every 15 seconds. If more than 15 seconds have passed since the last update, the Extension has crashed. The user receives a notification and can restart the broadcast.
What's Included in the Work
- Architecture design with protocol (RTMP, SRT, WebRTC) and server selection.
- Development of Broadcast Extension for iOS or capture service for Android.
- Configuration of App Group and inter-process communication.
- Optimization of video downscale and bitrate settings.
- Implementation of heartbeat monitoring and error handling.
- Integration with the server and testing on real devices.
- Integration documentation and team training.
- Support during App Store and Google Play release.
Estimated Timelines and Cost
iOS Broadcast Extension with RTMP/SRT, downscaling, App Group communication: 2–3 weeks. Android MediaProjection: 1.5–2 weeks. Cross-platform with shared management code: 4–5 weeks. Cost is calculated individually; starting at $2,500 for a single platform extension. Typical project cost ranges from $2,500 to $10,000. Our clients save up to 30% compared to in-house development. Get a preliminary assessment — contact us.
Important: comply with App Store Review Guidelines Section 4.2 — screen broadcasting must be explicitly mentioned in the description. We have delivered over 50 successful integrations with 98% reliability.