Appcenter-sdk-dotnet: Apple rejection for non-public API usage (ITMS-90338) related to MSAnalytics

[warpedgeoid]

When submitting our app for review using Xamarin.iOS 14 and any version of Microsoft.AppCenter.Analytics from 3.2.2 to 3.4.2, the app is quickly rejected with the following message:

ITMS-90338: Non-public API usage - The app contains or inherits from non-public classes in <app_name>: MSAnalytics . 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 http://developer.apple.com/support/technical/

Removing Microsoft.AppCenter.Analytics results in the app being accepted.

This is with Xcode 12 and built on VS for Mac 8.7.8b4.

[MatkovIvan]

Hi @warpedgeoid,

Thanks for getting in touch! That's weird, we didn't receive this kind of reports before and didn't change anything in this part recently. However, there was a report about false-positive detection on Apple side appeals helped in that case.

Anyway, could you please share

the private Apple APIs listed above

? For now, it's not clear what API triggers it (our SDK doesn't use any private ones).

[warpedgeoid]

That's just it, they didn't really provide any hint of which API is being flagged. The text above is all that pertains to this issue in the rejection email. What's odd, this is not our first upload of this app for testing, but it's the first time we've seen an issue.

[rpendleton]

As can be read in Apple's documentation, two letter class prefixes are reserved by Apple and should not be used in third-party apps or libraries:

In order to keep class names unique, the convention is to use prefixes on all classes. You’ll have noticed that Cocoa and Cocoa Touch class names typically start either with NS or UI. Two-letter prefixes like these are reserved by Apple for use in framework classes. As you learn more about Cocoa and Cocoa Touch, you’ll encounter a variety of other prefixes that relate to specific frameworks:
...
Your own classes should use three letter prefixes. These might relate to a combination of your company name and your app name, or even a specific component within your app. As an example, if your company were called Whispering Oak, and you were developing a game called Zebra Surprise, you might choose WZS or WOZ as your class prefix.

Unfortunately, it seems that some of the classes defined by the App Center SDK have names that are now being used by Apple in some of their private frameworks. If you link with certain frameworks, you can see warnings about this when launching your app.

For example, when launching an app that uses the Xamarin SDK (which I believe links with most frameworks) on iOS 14, the following is logged to the console.

objc[2330]: Class MSService is implemented in both /System/Library/PrivateFrameworks/MailServices.framework/MailServices (0x1f4ac7608) and /private/var/containers/Bundle/Application/E03418CE-A6DF-4DAE-96C9-C0BAC18D2DE8/************.app/************ (0x10f0c7080). One of the two will be used. Which one is undefined.
objc[2330]: Class MSAnalytics is implemented in both ?? (0x1f540b368) and /private/var/containers/Bundle/Application/E03418CE-A6DF-4DAE-96C9-C0BAC18D2DE8/************.app/************ (0x10f0cc738). One of the two will be used. Which one is undefined.

I'm not sure why MSAnalytics shows an image of ??, but it seems reasonable to assume it's part of the MailServices private framework since that's where MSService is. Either way, all of the classes with a prefix of MS should be renamed to something that isn't reserved by Apple.

For what it's worth, this issue affects more than just app submission. My company is seeing crashes whenever we track events using the App Center SDK due to the following exception being raised:

Objective-C exception thrown. Name: NSInvalidArgumentException Reason: +[MSAnalytics trackEvent:withProperties:]: unrecognized selector sent to class 0x1fa831430

This is happening because Apple's implementation of the MSAnalytics class, understandably, doesn't include the +[MSAnalytics trackEvent:withProperties:]: method. It seems like this defect is being tracked by #1445.

[warpedgeoid]

Good explanation, @rpendleton.

[MatkovIvan]

Hi there. We've just released 3.4.3 with a hotfix for this issue.
In this patch, only MSAnalytics is renamed to MSACAnalytics to avoid conflict with Apple's private framework. It should solve the problem and unblock you. Changing the prefix for all classes requires more time and introduces breaking changes for Objective-C/Swift so it will be a bump of major version for iOS SDK.

Please check it out and let us know if you have any issues with the new version.
Thanks.

[MatkovIvan]

Closing this for now, but feel free to comment or reopen if the problem is still here or you have any questions.

[rpendleton]

In this patch, only MSAnalytics is renamed to MSACAnalytics to avoid conflict with Apple's private framework

@MatkovIvan What about the MSService conflict with MailServices that I mentioned in my comment? That's also part of a private framework...

objc[2330]: Class MSService is implemented in both /System/Library/PrivateFrameworks/MailServices.framework/MailServices (0x1f4ac7608) and /private/var/containers/Bundle/Application/E03418CE-A6DF-4DAE-96C9-C0BAC18D2DE8/************.app/************ (0x10f0c7080). One of the two will be used. Which one is undefined.
objc[2330]: Class MSAnalytics is implemented in both ?? (0x1f540b368) and /private/var/containers/Bundle/Application/E03418CE-A6DF-4DAE-96C9-C0BAC18D2DE8/************.app/************ (0x10f0cc738). One of the two will be used. Which one is undefined.

[MatkovIvan]

@rpendleton I found the same message about MSService in 1y old StackOverflow issue, this one was there for a while and didn't cause any issues aside of this warning.
As I mentioned about we're working on changing the prefix everywhere, but it will take some time. Today's patch should fix this issue.