App store rejection due to private API _locale_charset

[ChrisLowe-Takor]

We are using libspatialite compiled with this make file for our GIS application on XCode 8.3.3. It's been months in the making and when we submitted to the app store we received an automated rejection email stating:

Non-public API usage:

The app references non-public symbols in {app name}: _locale_charset

Poking around a little I think the problem is something inside of libspatialite is referencing a method which matches the name of a method that is part of apples private api.

Doing a binary string match inside the project I find:

grep -Rnis '_locale_charset' *
Binary file spatialite2.3.1/libs/libspatialite.a matches
Binary file spatialite2.3.1/libs/mod_spatialite.a matches

This is a false positive on Apple's part because although the method names match they aren't related. I've replied to appreview@apple.com to see if they can rectify it from their end but there hasn't been any response for several weeks.

I've also submitted a TSI with the Apple developer program and their response was to remove the offending library. This will essentially kill the app and throw away months worth of work.

So I guess my question is:

• Has anyone successfully uploaded an app with the libspatialite library to the app store
• Is there any way of removing or renaming the offending method _locale_charset
• Are there any build flags or patches I need to apply to build a viable library for iOS

I'm desperate and at the end of my rope on this one. Any help will be hugely appreciated.

[muellermartin]

This sounds bad, but after a quick search I found this bug report in the GNOME repository with a very similar issue, and probably this helps you: https://bugzilla.gnome.org/show_bug.cgi?id=723805

[dtomicAZ]

Hi, I released app on App Store 2 months ago, and had no problems.

I am using Spatialite version 4.x.x

[frizull]

We had the same problem and went trough the exact same steps you described. Our bug report was left open to rot.

On Tue, Jul 25, 2017 at 3:17 PM, Martin Müller notifications@github.com wrote:

This sounds bad, but after a quick search I found this bug report in the GNOME repository with a very similar isse, and probably this helps you: https://bugzilla.gnome.org/show_bug.cgi?id=723805

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gstf/libspatialite-ios/issues/18#issuecomment-317734241, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJr9OjtHO-2PHzzNxo1EGF79C9uqMszks5sResFgaJpZM4OiA6U .

--

I.

[ChrisLowe-Takor]

@muellermartin Thanks I've seen that. I tried adding those compiler flags:

-Dlocale_charset=intl_locale_charset

to the make file but it wouldn't compile. The error was something along the lines of gaia could not find symbol intl_locale_charset.

@dtomicAZ Thanks. Do you think you could do me a huge favour and run that grep command against the archive? I'm trying to figure out if this is something Apple are only recently checking for or if it's something specific to my project.

It'll only take a second. Open the organiser. Right click the archive -> show in finder. CD to that directory then run:

grep -Rnis '_locale_charset' *

[dtomicAZ]

Hi, no problem,

Here you go:

grep -Rnis '_locale_charset' *

Binary file VoziStedi 26-07-2017, 10.21.xcarchive/Products/Applications/VoziStedi.app/lib/libspatialite.a matches Binary file VoziStedi 26-07-2017, 10.21.xcarchive/Products/Applications/VoziStedi.app/lib/mod_spatialite.a matches

[ChrisLowe-Takor]

@dtomicAZ Thanks mate. I owe you a beer.

I see something different on my end. That _locale_charset symbol also gets copied into the project binary while yours doesn't. It gives me something to work from.

[gstf]

@ChrisLowe-Takor Any progress?

[ChrisLowe-Takor]

@gstf Yes I managed to compile a version of the library without the _locale_charset symbol and it passed the itunes verification.

The steps are a little odd and I wouldn't recommend it to anyone unless they have run into this problem so I won't submit a PR or a patch.

I first changed the make file script to use the latest 4.4.0.RC2 version of spatialite and did a full build. Then I opened up the source file at spatialite/src/giaaux/gg_utf8.c and deleted all the lines of code that contain locale_charset.

I then deleted the $(CURDIR)/spatialite: section of the makefile so it doesn't download the source files again and re-ran make.

Surprisingly it compiled without complaint and the new shared libraries don't contain this symbol. All my unit tests pass and nothing seems to be broken from the change, not even shapefile import/export which I suspect is what was using the charset methods.

I'm happy to close this issue.

[adolby]

This is still an active issue when Bitcode is required for your project. If spatialite-ios is built with Bitcode flags set, you will get this rejection from the app store.

[ChrisLowe-Takor]

I was getting the rejection both with and without Bitcode. My issue was with this method name that Apple's automated processing had mistakenly flagged as one of their private API calls.

I can't comment on wether or not this is still an issue. It happened to me six months ago and I am still using the spatialite library I built by removing references to that method from source.

[ChrisChares]

I'm seeing this rejection for _local_charset. Going to give your steps a try @ChrisLowe-Takor.

FWIW I have Bitcode disabled at the project level atm, although the libspatialite-ios make commands compiled the static libs with bitcode enabled.

[raid5]

I can confirm this is still an issue. I went to upload a build for beta testing and got rejected by Apple.

@ChrisChares Did you have any luck following those steps?

[ChrisChares]

@raid5 Yes a subsequent submission after following @ChrisLowe-Takor's steps was accepted to the store.

[raid5]

@ChrisChares Awesome, good to hear!

I was just able to successfully submit my app without bitcode and Apple did not complain. So I guess that could be another solution for some.