jwplayer / jwplayer-react-native

MIT License
32 stars 9 forks source link

[BUG] iOS build failure with JWPlayerKit 4.20.0 #89

Open chriszs opened 1 month ago

chriszs commented 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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

holladortun commented 3 weeks ago

Hello, can anyone please help on what should be done? We have productions apps that we can push an update for since ios does not build because of the below errors image

chriszs commented 3 weeks ago

@holladortun I just pinned the JWPlayerKit native pod until a fix lands. See above for how to do it in an Expo prebuild project.

holladortun commented 3 weeks ago

@holladortun I just pinned the JWPlayerKit native pod until a fix lands. See above for how to do it in an Expo prebuild project.

Thank you soo much.

Doing this worked and the app now builds with expo eas