chore: bump webrtc to m150 and enable WARP. - #461
cloudwebrtc wants to merge 1 commit into
Conversation
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
Devin Review found 2 potential issues.
2 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)
| # LiveKitWebRTC 150.x is not on CocoaPods trunk yet; it only lives in livekit/podspecs. | ||
| # Remove both sources once the pod is published to trunk. | ||
| source 'https://github.com/livekit/podspecs.git' | ||
| source 'https://cdn.cocoapods.org/' |
There was a problem hiding this comment.
🟡 Private pod source never reaches consumers
External iOS apps do not inherit these source declarations. Their pod installation cannot resolve LiveKitWebRTC 150 outside CocoaPods trunk.
Learn more
CocoaPods resolves spec repositories from the application Podfile, not from Podfiles shipped elsewhere in an npm package. These declarations fix only the repository's CI app and example app. The adapter podspec pins LiveKitWebRTC 150.7871.02, which this change states is unavailable on trunk. A consuming application using the documented installation flow therefore has no source containing that podspec.
Example: An existing app upgrades @livekit/react-native, keeps its standard trunk-only Podfile, and runs pod install. CocoaPods reports that no spec satisfies LiveKitWebRTC (= 150.7871.02) instead of installing the SDK.
Recommended fix: Publish LiveKitWebRTC 150 to trunk before releasing this package, or document and automate adding https://github.com/livekit/podspecs.git in every supported consumer integration, including the Expo plugin.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "@eslint/js": "^9.35.0", | ||
| "@livekit/changesets-changelog-github": "^0.0.4", | ||
| "@livekit/react-native-webrtc": "^144.2.0", | ||
| "@livekit/react-native-webrtc": "https://github.com/livekit/react-native-webrtc.git#bump-libwebrtc-to-m150", |
There was a problem hiding this comment.
🟡 Stale peer range admits incompatible WebRTC
The declared ^144.2.0 can install the old adapter without enableSctpSnap support. Those valid installations silently omit half of WARP.
Learn more
The npm peer dependency defines which adapter versions consumers may install. The new wrapper passes enableSctpSnap, but the existing 144 adapter does not bridge that private RTC configuration field to native code. The Git dependency used for development contains that bridge, so local and CI tests cannot detect the peer mismatch. This also violates the repository rule requiring WebRTC peer ranges to match the SDK's actual requirement.
Example: An app already using @livekit/react-native-webrtc@144.2.0 upgrades this SDK. Its package manager accepts the peer dependency, but each peer connection drops enableSctpSnap before native initialization, leaving SCTP negotiation outside WARP.
Recommended fix: Release the m150 adapter under a distinct npm version, update peerDependencies to require that version, and use the same published version in development, CI, and example manifests.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
No description provided.