App Review - Rejet "Obfuscated code"
FKDEV
Membre
2.3.1 - Hidden or undocumented features
We noticed that your app contains hidden features. Specifically, this app contains a hidden downloading feature.
EDIT: En fait c'était une erreur... C'était une private API. Mais à priori, je n'en utilise pas...
Quelqu'un a déjà s'est déjà vu rejeter pour une private API ? Ils ne donnent pas le nom de l'API d'habitude ?
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'ai eu ce problème avec Uncia.
En fait j'utilisait une ivar que j'avais nommeÌ _quelquechose. C'était justement une ivar privée mais ça marchait quand meÌ‚me (j'ai plus les détails deÌsoleÌ).
Ils ont cru que j'utilisais une API priveÌe pour cette raison et m'ont donc demandeÌ de changer tout ça .
PS: Je vais voir si j'arrive à retrouver les mails.
Et ils t'avaient donné le nom de l'ivar ?
Quand je leur demande quelle est l'API, ils me renvoient vers le support "code level" (qui est le support payant pour lequel on a une question gratuite par an).
Non je retrouve pas les infos c'est un genre d'issue sur le site mais comme il est fermeÌ j'y ai plus accès. Si quelqu'un sait ouÌ€ trouver ça je serai heureux de te donner les infos
C'est surprenant. Je m'étais fait rejeté une fois pour cette raison à cause de l'intégration d'un slider open source à double curseurs (min/max) mais à l'époque ils m'avaient indiqué le code incriminé. Autant chercher une aiguille dans une botte de foin sinon. ???
Je te conseille de lister tous les frameworks tierces ajoutés à ton projet et de les googler avec le terme "private api". Tu es sans doute pas le premier.
Je n'ai rien trouvé. Et je n'utilise pratiquement que des librairies bien connues.
Le truc c'est que j'utilisais une private api dans un binaire précédent donc je me demande s'ils ne se sont pas trompés de binaire.
Je vais soumettre une nouvelle version, on verra bien...
Fais un bon clean avant. Limite vide DerivedData. Il m'est deÌjaÌ€ arriveÌ de me retrouver avec des parties de code pas recompileÌes. Si tu as utiliseÌ une API privée il se peut que des bouts subsistent.
J'ai deÌjaÌ€ eu, avec Swift, des bouts de code qui disparaissent à la compilation. Un clean ne changeait rien, un reboot d'Xcode non plus mais un wipe de DerivedData si.
Cela dit d'habitude, je fais juste un clean. Je vais intégrer le vidage des derived data.
Xcode n'a jamais été au clair avec le clean...
En fait ce dont on m'accuse c'est d'utiliser des techniques d'obfuscation et du code caché.
J'ai soumis une nouvelle version avec suelques modifications mineures. A suivre...
Rebelote:
App review renvoie vers "iTunes connect contact us" qui, à priori devrait me renvoyer vers le support développeur.
Ils pourraient au moins indiquer si cela vient d'un framework ou du binaire principal.
On va suivre la procédure jusqu'au bout cette fois...
Tiens-nous au courant !
Cette fois "iTunes Connect - contact us" me renvoie vers "app review" :
"-Savez-vous qu'il est possible de répondre directement à "App Review" à partir du Resolution Center, d'ailleurs nous avons copié votre réponse dans le Resolution center, au revoir."
J'ai contacté le support de code qui m'a conseillé d'aller voir appstore contact pour demander un "reject clarification" en précisant que je souhaitais faire une "technical investigation".
Puis quelques jours plus tard, j'ai finalement reçu le nom des classes et méthhodes qui posaient problèmes.
Par exemple :
Donc là , avec la commande strings, je me suis vite rendu compte que cela venait de la librairie binaire fournie par le sdk deezer qui est linkée en static.
Du coup j'ai répondu que c'était dans le framework Deezer avec un lien sur le site developer Deezer, et mon app a été validée.
Un long combat .. Tu dois être soulagé d'arriver au terme. Champagne ce soir ?
Soulagé, et agréablement surpris qu'ils ne me demandent pas d'enlever carrément le framework Deezer.
Souvent j'évite d'utiliser les SDK des fournisseurs si une API http est disponible, mais pour certaines étapes comme le login via OAuth, c'est pratique.
Champagne, non, car à chaque fois que j'ai un rejet injuste, injustifié, ou mal géré, cela abime ma motivation. Sur cette app, j'ai été bien servi.
Je crois que si/quand Swift permettra de programmer sur Android, je tenterai l'aventure pour avoir plus de liberté.
Cela refroidit également les fantasmes d'en vivre. Etre dépendant d'un processus aussi capricieux et opaque pour ses revenus principaux, cela doit quand même être assez stressant.
En plus, qui me dit que dans 6 mois, ils ne vont pas retomber dessus...
Là , par exemple, je soumets une modification vraiment mineure. Bah, tout d'un coup, ils décident de rejeter le nom que j'utilise depuis deux versions : "mixlib - Import your Spotify playlists into Apple Music".
Ce nom m'a permis d'augmenter fortement les téléchargements. Donc si j'étais à une échelle d'en vivre, cela veut dire que du jour au lendemain, tes revenus sont peut-être divisés par deux parce qu'un stagiaire de l'app review a mal interprété les règles de l'app store.
En fait, dès qu'il y a quelque chose d'un peu limite, tu as une chance sur deux que ce soit refusé en fonction de la personne qui fait la review. Donc, à chaque fois que tu soumets, c'est un gros stress, sur quoi ils vont tomber cette fois ?
C'est le supplice de Damoclès.
C'est pas normal. Si un nom a été accepté, ils ne devraient pas pouvoir revenir dessus à moins d'une nouvelle règle.
C'est sacrément risqué d'utiliser "Apple Music" dans le nom d'une application. Je suis même surpris qu'il a fallu attendre 2 versions avant que la guillotine ne tombe.
c'est l'épée de Damoclès, pas le supplice
Mais je suis d'accord avec toi. Pour vivre les maj côté iOS et Android, c'est clairement le jour et la nuit.
Sous Android, tu prends ton APK, si tu veux la beta tester, tu upload dans beta et tu ajoutes les mails des beta testeurs. Bim, dans la 1/2h, les gens peuvent beta tester.
Pareil pour la mise online. Ultra simple.
Pareil pour les achats intégrés.
Sous iOS, je peux comprendre les process de validation mais c'est lourd, très lourd.
Pour livrer l'appli, il faut en passer par XCode. Admettons... Mais pour livrer des inApp, il faut passer par application loader...
Il m'est arrivé un rejet de mon appli pour quelquechose de non justifié.
Pire, il m'est arrivé une validation d'un achat InApp alors que le package envoyé était ko et faisait planté l'appli !
Pour rectifié le tir, il a fallut attendre 3j de revalidation....
Je parle meme pas des beta tests ou il faut passer par TestFlight qui n'est compatible que iOS8+
Au final, cette histoire de validation "humaine" est sans doute obsolète. Les mecs ont un temps imparti pour tester qui est de ttes façons trop faible.
Le problème c'est qu'à cause de l'apathie d'Apple dans la gestion de l'app store, c'est devenu une pratique tacitement accepté de compléter le nom d'une app avec une description. D'autant que cette zone est 10 fois plus efficace que la liste des mots clés cachés.
Donc, on peut considérer que ce qui suit le tiret dans le nom est une description.
Dans une société qui prend ses responsabilités et gère son produit, on aura interdit cette pratique et ajouter un champ 'sous-titre'.
Oui, Apple prend des décisions bizarres sur ces stores.
Au final (pour l'instant)
pas bien : mixlib - Import your Spotify playlist into Apple Music
bien : mixlib - Import/export for Spotify & for Apple Music
En français, j'ai même mis trois noms de service :
mixlib - Import/export pour Spotify, pour Deezer & pour Apple Music
En fait, j'imagine que pour des raisons légales, ils sont hyper prudents avec les noms des autres sociétés, ce qui peut se comprendre.
Du coup, la conclusion c'est qu'il est possible de mettre un nom de société tierce à condition de respecter le schéma suivant :
MonApp pour Spotify.
MyApp for Spotify.
* touche du bois *
Ainsi, pour tes versions futures, je t'invite, pour éviter de stresser, d'indiquer dans ce champ un truc du genre "Une précédente version avait été rejeté à cause de code obfusqué. Il a été noté que ce code émane en fait du SDK Deezer et non de mon propre code, ce qui a permis en conséquence de passer la validation", enfin je sais pas mais un truc comme ça. Ou plus simplement "You might notice there is some obfuscated code in the binary, but all that obfuscated code is coming from the third-party Deezer SDK and not our own code."
Car d'après ce que disent les ingés Apple aux ateliers WWDC, autant ils ne consultent pas toujours TOUT l'historique des validations des versions précédentes pour relire l'historique entier de ce qui a été rejeté ou pas à chaque fois (ça serait un boulot fou), autant ce champ commentaire par contre ils le lisent et le prennent en considération.
https://library.launchkit.io/a-simple-tip-to-reduce-app-store-rejections-4517ca505e44
Comme ils le disent dans l'article, depuis qu'ils ont expliqué dans cette "Info Box" les points qui régulièrement semblaient porter à confusion à chaque review, ces explications ont permis de ne plus avoir de rejet dans les versions suivantes.