API privées non contrôlées par la validation Xcode
Mala
Membre, Modérateur
Je viens d'avoir la désagréable surprise de voir la soumission d'une appli rejetée sur la Mac App Store pour usage d'API privée.
Cela me semble une aberration en soit mais la fonction de pré-validation mise à disposition dans Xcode ne semble faire absolument aucun contrôle d'usage d'API privée.
Dans mon cas, il s'agissait de quelques lignes de code provenant du composant open source SMDoubleSlider...
The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The following non-public APIs are included in your application:
: OBJC_IVAR_$_NSCell._cFlags
: OBJC_IVAR_$_NSSliderCell._scFlags : OBJC_IVAR_$_NSSliderCell._value
Rien de méchant en soit mais c'est très frustrant. Cela signifie qu'on ne peut faire aucune confiance à Xcode alors que c'est la première chose qu'on aimerait pouvoir valider dès qu'on inclue des composants Open Source dont on ne va pas forcément relire tout le code.
Si vous avez une solution de contrôle annexe qui soit fiable, je suis preneur pour éviter de perdre du temps à l'avenir.
Réponses
Je ne sais pas si il existe une solution,
le souci c'est que Apple fait la vérification sur 2 passes
La première au niveau de XCode,
la deuxième quand tu envoies le binaire via Itunes Connect.
Tu peux utiliser par exemple le framework QTKit qui est déprécier , la validation passera la première étape
mais l'app sera refusée (invalid binary) a la seconde.
Dans ton cas c'est immédiat lors de la soumission? Moi il m'indiquait que tout était ok et j'ai reçu un mail aujourd'hui m'invitant à consulter le "Resolution Center". C'est surprenant, sur la toile beaucoup de gens semblent indiquer que ce pré contrôle est réalisé.
J'ai vu quelques liens envoyant vers l'appli App Scanner mais elle n'est plus maintenue et semble être pour iOS seulement.
Oui c'est immédiat (enfin dans mon cas), tu reçois un mail dans les 5 minutes indiquant que l'app n'est pas valable.
Pour info, dans le même genre un point ou Apple est super chiant c'est sur les Entitlements Keys
Il faut mettre uniquement celle que tu utilises vraiment, et bien leur expliquer leur utilisation dans ton programme!
Un composant open-source qui inclue des API privées sans le dire dans le readme, c'est pas cool.
Après sur Mac, c'est vrai que c'est moins dans les habitudes des développeurs d'éviter les API privées.
C'est pas le rôle de Xcode faciliter la vie des utilisateurs de librairie open-source peu scrupuleuse.
Après, puisque l'outil existe quelque part, pourquoi ne pas l'inclure dans Xcode ?
A choisir, j'aimerais mieux qu'Xcode vérifie les API qui sont incompatibles avec mon "Deploy OS".
Je me permettrait pas de les blâmer. La dernière mise à jour de SMDoubleSlider date de 2010 et sur Mac l'accès aux API privés a longtemps été un mal nécessaire. Là par exemple, il s'agit d'un dérivé de NSSlider permettant un réglage min et max (parfait pour ajuster les seuils min et max de l'histogramme d'une image dans mon cas). Apple ne propose aucune équivalence dans IB et la surcharge d'un NSSlider est pas des plus simples. Là je me suis même pas posé la question, j'ai vite retaillé un fake à partir d'une NSCustomView pour pouvoir re-soumettre au plus vite.
@Mala balance une autre version vite
, peux être qu'elle sera validée avant la fin de la semaine, puisque Apple ne va pas faire de la review pendant la semaine de Noel.
Merci samir.
C'est ce que j'ai fait immédiatement le temps de remettre à plat le composant. J'espère qu'il n'y aura pas d'autre mauvaise surprise. Je croise les doigts.