J'ai reçu le formulaire de courrier suivant Apple, en considérant mon application:
Merci d'avoir soumis votre mise à jour à νομοθεσία à l'App Store. Lors de notre examen de votre demande, nous avons constaté que cela utilise des API privées, qui en violent l'accord de licence de programme de développeurs iPhone 3.3.1; "3.3.1 Les applications ne peuvent utiliser que des API documentées de la manière prescrite par Apple et ne doivent pas utiliser ou appeler des API privées." Bien que votre demande n'a pas été rejetée, il serait approprié de résoudre ce problème dans votre prochaine mise à jour.
Les API non publiques suivantes sont incluses dans votre application:
u_isspace
ubrk_close
ubrk_current
ubrk_first
ubrk_next
ubrk_open
Si vous avez des méthodes définies dans votre code source avec les mêmes noms que les API mentionnées ci-dessus, nous vous suggérons de modifier vos noms de méthodes afin qu'ils ne soient plus en collision avec les API privées d'Apple pour éviter que votre demande soit signalée avec des soumissions futures.
Veuillez résoudre ce problème dans votre prochaine mise à jour de νμοθεσία.
Sincèrement,
Équipe d'examen de l'application iPhone
Les fonctions mentionnées dans ce courrier sont utilisées dans la bibliothèque ICU (composants internationaux pour Unicode).
Bien que mon application ne soit pas rejetée à ce stade, je ne me sens pas très sécurisé pour l'avenir de mon application, car il repose fortement sur le protocole Unicode et sur ces composants en particulier.
Une autre chose est que je n'appelle pas ces fonctions directement, mais elles sont appelées par une construction "SQLite" personnalisée (avec des extensions FTS3 activées).
Est-ce que je manque quelque chose ici?
Toute suggestion?
3 Réponses :
Je recommanderais de ne pas vous évacuer publiquement sur la question (qui vous ferait mal à long terme), mais répondant poliment à l'adresse e-mail d'examen de la demande que vous avez été donnée, expliquant que vous utilisez une construction de SQLite personnalisée qui fait référence à l'ICU. cadre. Étant donné qu'il s'agit d'un cadre de tiers standard, je dirais que ce ne sont pas les API privées d'Apple que vous utilisez. Il se peut qu'ils soient simplement trop zézables dans l'inclusion de symboles dans leur logiciel de numérisation.
Si vous ne pouvez pas les convaincre autrement, vous risquez de contempler passer de SQLite avec FTS3 à quelque chose comme Aaron Hillegass ' Bnrpersistence , qui vient d'ajouter une recherche rapide en texte intégral rapide.
Merci pour votre réponse Brad. Je vais jeter un oeil à la bnrpersistence.
S'ils ont des problèmes liés à la liaison avec le système ICU, pourquoi ne pas simplement importer le code source ICU dans votre projet?
Cela devrait être mon dernier recours. Dans ce cas, je dois faire le nom de changer pour éviter le problème.
hmmm ... il est possible que Apple utilise également des composants ICU. La meilleure réponse serait d'expliquer poliment ce qui se passe et, espérons que les choses devraient trier correctement.
S'y habituer. L'AppStore est un lieu de nombreuses règles appliquées au hasard.
Si vous liez statiquement les fichiers .lib de l'ICU sera-t-il acceptable? Ou devez-vous réellement importer le code source ICU dans le projet? Quel était le mot final à ce sujet?
Voudrais entendre quel était le résultat de cela? Comment était-ce résolu?
FWIW, Apple décrit désormais la possibilité d'utiliser le système ICU dans la documentation: développeur.apple.com/library/ios/documentation/stringstextfon TS / ...