jwplayer / jwplayer-react-native

MIT License
28 stars 8 forks source link

[BUG] iOS build failure with JWPlayerKit 4.20.0 #89

Open chriszs opened 2 weeks ago

chriszs commented 2 weeks ago

Describe the bug When building an app with the latest version of this package on EAS I got the following build failure:

❌  (../../node_modules/@jwplayer/jwplayer-react-native/ios/RNJWPlayer/RNJWPlayerViewController.swift:266:19)

  264 |     // MARK: - JWPlayer State Delegate
  265 | 
> 266 |     override func jwplayerContentIsBuffering(_ player:JWPlayer) {
      |                   ^ method does not override any method from its superclass
  267 |         super.jwplayerContentIsBuffering(player)
  268 |         parentView?.onBuffer?([:])
  269 |     }

❌  (../../node_modules/@jwplayer/jwplayer-react-native/ios/RNJWPlayer/RNJWPlayerViewController.swift:267:15)

  265 | 
  266 |     override func jwplayerContentIsBuffering(_ player:JWPlayer) {
> 267 |         super.jwplayerContentIsBuffering(player)
      |               ^ value of type 'JWPlayerViewController' has no member 'jwplayerContentIsBuffering'
  268 |         parentView?.onBuffer?([:])
  269 |     }
  270 | 

I couldn't reproduce this locally until I upgraded the JWPlayerKit pod to the latest version, which is 4.20.0. Locally I only get the method does not override any method from its superclass error, not the has no member error, but the build does fail with that pod version regardless.

Steps to reproduce the behavior:

  1. cd ios/
  2. pod update JWPlayerKit
  3. cd ..
  4. npm run ios

Expected behavior No build failure.

chriszs commented 2 weeks ago

Working around this by pegging the version in my Podfile using the following build configuration in my Expo app.config.js:

          extraPods: [
            {
              name: 'JWPlayerKit',
              version: '4.19.2',
            },
          ],
Jmilham21 commented 2 weeks ago

Hey @chriszs, so the native iOS version 4.20.0 went out in a non-viable state. We don't advise upgrading to it in your apps, and we are actively working on creating a patch and pushing out the update in a working state. We cannot roll back the pod release, however, so your workaround and our suggestion would be to skip 4.20.0 and only upgrade to a verified version.

With the 4.20.+ release that follows, this repository may need to be changed, but we will make the changes required to support that version when we roll it out. Upgrading the version before the wrapper is upgraded may cause problems and it seems we aren't protecting you with our current configuration.

@AmitaiB would you agree we should be more explicit in our podspec, like the following? s.dependency 'JWPlayerKit', '4.19.2'

chriszs commented 2 weeks ago

My Podfile.lock would have prevented this, but that gets removed by Expo Prebuild and recreated in CI. I believe this right now would bite anyone who installs this fresh.

AmitaiB commented 2 weeks ago

Hello @chriszs, everything @Jmilham21 said is accurate, and this use case should certainly specify a specific version rather than a wildcard (those who know what they are doing can always change this).

That said, this is not caused by the instabilities introduced by 4.20.0, most of which are ad-event related, specifically for DAI implementations. Rather, the