Apple Review Rejection for private API use

Hello,

We’re using BitmovinPlayer version 3.36.0 in our app. In our latest release we received binary rejection and cannot proceed.

ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/BitmovinPlayer.framework/BitmovinPlayer: _CMTimebaseCreateWithMasterClock. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at Requesting Technical Support - Support - Apple Developer

Any help on that you can help?

PS.: we cannot use the latest SDK version as its minimum deployment target is 14 while ours is 12.

Thanks.

1 Like

Good day @macdigital ,

Our Findings

Maybe worth watching that thread AND/OR reaching out to Apple support referencing that thread.

1 Like

We’re having the same issue. We updated the player version to 3.41.0 but that didn’t seem to help. Hopefully Apple sorts this out quickly

The issue seems to have been resolved by Apple. Apple Store Connect Engineer have confirmed this in Apple forums
ITMS-90338: Non-public API usage _CMTimebaseCreateWithMasterClock - ITMS-90338: Non-public API usage _… | Apple Developer Forums

3 Likes

Hi @lucky.goyal,

On our side, we still face the same issue even after its resolution by Apple:

The app references non-public symbols in Payload/Otto.app/Frameworks/BitmovinPlayer.framework/BitmovinPlayer: _CMTimebaseCreateWithMasterClock (ID: 6a96df8c-5afb-4834-9d0a-4b84926c7ab5)

This message displays on Xcode at the end of the IPA uploading process. Our app still uses the Bitmovin Player iOS SDK version 3.36.0.

Is it mandatory to upgrade to another version to solve this problem? If it is, what is the minimum version?
Best regards,

EDIT: IPA upload works on version: 3.26.0 but does not on version 3.41.2, 3.39.0 and 3.36.0.

Hi @lucky.goyal Today My app is rejected from Apple saying the same rejection message.

ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/BitmovinPlayerCore.framework/BitmovinPlayerCore: _CMTimebaseCreateWithMasterClock. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed.

Use 3.30.0 was working well for now.

@admin.vodfactory @abichal.jha The problem you’re experiencing is related to Apple’s App platform and is unrelated to the Bitmovin SDK, as we do not use any private APIs. This is similar to the problem that occurred two weeks ago. Based on recent discussions, it appears that Apple has already resolved the issue. Could you please retry the upload process?

@Kishore @mit-bitmovin The seems to be the issue in Bitmovin latest version. I try with multiple version starting from 3.36 to 3.41 all get rejected. So I switch back to old version 3.28 and it was accepted by Apple yesterday. Please do investigate with these versions so that we can use latest Bitmovin’s framework. So that we can’t encounter such issues in future.

@abichal.jha Would you mind trying again with the latest version today, considering that Apple resolved their issue yesterday evening?

Hi @Kishore,

Thanks for the information, it works now indeed.

However as @abichal.jha mentioned, this problem does not impact previous versions of Bitmovin iOS SDK. We could arguably conclude something in recent SDK triggers this issue. It might worth to check and identify the root cause to avoid if it happens again.

@admin.vodfactory Thank you for verifying and providing feedback. Starting with version 30, we use CMTimebaseCreateWithSourceClock, which is a public API. However, it appears that Apple’s validation tools mistakenly interpret it as CMTimebaseCreateWithMasterClock, leading to the issue. Therefore, we have concluded that this problem is not related to our implementation but rather an issue with Apple’s tools.

1 Like

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.