Possible Issue on the AppStore

[fdhsdrdark]

Hey,

Thank you very much for creating this package, supporting migration from traditional Xamarin to .Net 6/7.

I run into an issue though on my updated .Net iOS app and I'm not really sure if this package is related in any way.

When I uploaded my app on the App Store I got an email about the app being rejected, with the following
"The app references non-public symbols in MyAppName: _ubrk_openRules, _ucal_add, _ucal_close, _ucal_get, _ucal_getAttribute, _ucal_getKeywordValuesForLocale, _ucal_getNow, _ucal_getTimeZoneDisplayName, _ucal_getTimeZoneIDForWindowsID, _ucal_getWindowsTimeZoneID....".

Searching about the error got down to the symbols above being related to libicucore, a native library providing
 Unicode and localization support (I was not able to figure that out by myself - got it from a response on an issue I raised for another possible offended package).

I am trying to find the offended package on my project by checking the ones updated/added for the migration. ImageCache.Nuke is one of the few added ones.

Is there any change the error is coming from the updated ImageCaching.Nuke package?

Thank you very much for any response.

[roubachof]

mmh I don't think it's coming from here cause I think @Cheesebaron successfully published on the app store with the nuke package bindings, or am I mistaken ?

[Cheesebaron]

Yep, works fine. I've released multiple times with the ImageCaching.Nuke package.

ucal and ubrk seems like a different namespace and related to a different package.

Something is maybe referencing this ICU library: https://github.com/zhm/icu-ios/tree/master https://icu.unicode.org/home that is where the code seems to be coming from.

[fdhsdrdark]

Thank you very much @roubachof and @Cheesebaron for getting back on this. It would be really nice of you if you could share some more info on how to go about this, for me and for anyone landing here with the same problem.

Checked the bin directory and I see files named icudt_CJK.dat icudt_EFIGS.dat icudt_no_CJK.dat Icudt.dat libicudata.a libicu18n.a libicuuc.a Matching the package @Cheesebaron describes. So I started removing nuget packages one by one from my project. These files above however keep coming up on every new build. Even by removing packages that were not updated for the .Net6 migration. So I created a brand new project from the .Net iOS template, didn’t add any packages at all and these files did came up upon build.

So if these files cause the appStore rejection but should be present since they are created by default - maybe there is an issue with the built in building process?

If on the other hand these files are not related with the rejection and it’s likely that a nuget package reference is causing the error - could I try consecutive deploys on the App Store until I spot the offended package?

Thank you very much!

[Cheesebaron]

Nothing prevents you to upload to TestFlight multiple times, so you should be able to do that.

You could go though each of the NuGet packages your iOS project references and run them through https://nuget.info and inspect what stuff the packages contain. Perhaps you can narrow down which package is using this private API.

Also if you don't have the Linking/Trimming enabled, it would be ideal if you enabled that, perhaps the code is only used for debug and can be trimmed away.

[fdhsdrdark]

@Cheesebaron Thank you very much - working on it.