Mise à jour de iDesserts pour iPhone rejetée ce jour:
We found the following non-public API/s in your app:
gridView:willDisplayCell:forIndexPath:
If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions.
J'ai du mal à comprendre en quoi ça leur pose problème, c'est la classe d'Ali qui fait des grilles... je ne vois pas en quoi c'est une API privée.
C'est d'autant plus débile, que la grande soeur "iDesserts pour iPad" a été validée 5 minutes après, avec les mêmes API !!!
Yep j'ai déjà eu un ticket sur mon github de qqun qui m'a signalé le même rejet pour une de ses applis utilisant ma classe... faudrait que je change le nom des méthodes !
Putain je pensais que c'était NRGridView qui était en cause mais non, j'ai mal lu /biggrin.png' class='bbc_emoticon' alt=':D' />
La seule différence c'est le "forIndexPath:" qui est changé en "atIndexPath:" de mon côté. ça m'étonne vraiment qu'Apple ait choisi "forIndexPath:" alors que la plupart des méthodes delegate/dataSource de UITableView utilisent toujours le terme "atIndexPath"
Encore plus étonnant, c'est qu'Apple ait choisi "gridView" plutôt que "collectionView" (comme OS X)
M'enfin à ta place je ferai du forcing, c'est pas normal d'être rejeté pour ça. C'est clairement un problème du côté de leur validation. P-e que tu peux pointer vers le github de OHGridView et leur expliquer tout ça?
Yep j'ai déjà eu un ticket sur mon github de qqun qui m'a signalé le même rejet pour une de ses applis utilisant ma classe... faudrait que je change le nom des méthodes !
C'est dingue quand-même, les validateurs sont des guignols.
iPhone: ta classe est incluse mais je ne l'utilise pas => passe pas
iPad: ta classe est include et je l'utilise => passe
Putain je pensais que c'était NRGridView qui était en cause mais non, j'ai mal lu /biggrin.png' class='bbc_emoticon' alt=':D' />
La seule différence c'est le "forIndexPath:" qui est changé en "atIndexPath:" de mon côté. ça m'étonne vraiment qu'Apple ait choisi "forIndexPath:" alors que la plupart des méthodes delegate/dataSource de UITableView utilisent toujours le terme "atIndexPath"
Tout à fait, c'est ce que j'ai remarqué aussi, juste la préposition qui change.
M'enfin à ta place je ferai du forcing, c'est pas normal d'être rejeté pour ça. C'est clairement un problème du côté de leur validation. P-e que tu peux pointer vers le github de OHGridView et leur expliquer tout ça?
J'ai demandé plus d'explications mais j'ai déjà envoyé la MAJ sans la classe, donc je ne sais pas si ils répondront.
De toute façon, Vinocella est aussi en validation et je l'utilise ! On va voir si ils la jettent !
" This bundle is invalid. The key CFBundleShortVersionString in the Info.plist file must be a period separated list of at most three non-negative integers.â€
Tout ça parce qu'on a mis "v1.2" au lieu de "1.2" dans la "Short Version String" ! (pour la clé CFBundleVersion on a bien mis "1.2" bien sûr par contre)
Tout ça parce qu'on a mis "v1.2" au lieu de "1.2" dans la "Short Version String" ! (pour la clé CFBundleVersion on a bien mis "1.2" bien sûr par contre)
T'es sur qu'il n'y a pas une différence entre iOS et OS X ? Plus le fait que ce qu'ont faisait avant avec ShortVersionString n'est peut être plus adapté à ce qu'en fait Apple sur le MAS.
CFBundleShortVersionString (String - iOS, Mac OS X) specifies the release version number of the bundle, which identifies a released iteration of the application. The release version number is a string comprised of three period-separated integers. The first integer represents major revisions to the application, such as revisions that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases.
The value for this key differs from the value for “CFBundleVersion,†which identifies an iteration (released or unreleased) of the application. This key can be localized by including it in your InfoPlist.strings files.
Bah oui mais bon dans ce cas je trouve ça un peu con d'avoir 2 clés, une pour les release versions l'autre pour les build versions...
Ah ça personnellement j'aime bien, un numéro de build et un numéro de version, ça permet un suivit correct des version de dev et des beta que l'on fournis sans avoir à gérer une branche de version pour ça (surtout si on génère les numéro de build avec le numéro révision git / svn).
Bah oui mais bon dans ce cas je trouve ça un peu con d'avoir 2 clés, une pour les release versions l'autre pour les build versions...
Je suis entièrement d'accord. Je me suis posé la question il n'y a pas longtemps. Du coup, je même le même numéro dans les 2 champs maintenant pour être "tranquille".
Je me suis fait jeté mercredi dernier pour une autre application parce que je n'avais pas fourni de login/password demo. Sauf que 99% de l'application fonctionne sans connexion réseau... c'est un peu, beaucoup, de l'excès de zèle.
Je me suis fait jeté mercredi dernier pour une autre application parce que je n'avais pas fourni de login/password demo. Sauf que 99% de l'application fonctionne sans connexion réseau... c'est un peu, beaucoup, de l'excès de zèle.
mon appli vient d'être aussi rejettée car je n'ai pas fourni un commpte demo. t'as modifié l'appli pour rajouter un compte demo ?
L'application est rejetée parce qu'Apple considère que cela ressemble trop à l'écran d'accueil d'iOS. En particulier, ce sont les icônes aux coins arrondis qui semblent leur poser problème:
Réponses
J'ai du mal à comprendre en quoi ça leur pose problème, c'est la classe d'Ali qui fait des grilles... je ne vois pas en quoi c'est une API privée.
C'est d'autant plus débile, que la grande soeur "iDesserts pour iPad" a été validée 5 minutes après, avec les mêmes API !!!
La seule différence c'est le "forIndexPath:" qui est changé en "atIndexPath:" de mon côté. ça m'étonne vraiment qu'Apple ait choisi "forIndexPath:" alors que la plupart des méthodes delegate/dataSource de UITableView utilisent toujours le terme "atIndexPath"
Encore plus étonnant, c'est qu'Apple ait choisi "gridView" plutôt que "collectionView" (comme OS X)
M'enfin à ta place je ferai du forcing, c'est pas normal d'être rejeté pour ça. C'est clairement un problème du côté de leur validation. P-e que tu peux pointer vers le github de OHGridView et leur expliquer tout ça?
C'est dingue quand-même, les validateurs sont des guignols.
iPhone: ta classe est incluse mais je ne l'utilise pas => passe pas
iPad: ta classe est include et je l'utilise => passe
Leur méthodologie doit être toute pourrie.
Non, elle est déjà obsolète depuis NRGridView !
Tout à fait, c'est ce que j'ai remarqué aussi, juste la préposition qui change.
J'ai demandé plus d'explications mais j'ai déjà envoyé la MAJ sans la classe, donc je ne sais pas si ils répondront.
De toute façon, Vinocella est aussi en validation et je l'utilise ! On va voir si ils la jettent !
Si ils font un truc aussi performant que NSCollectionView je me pends
Tout ça parce qu'on a mis "v1.2" au lieu de "1.2" dans la "Short Version String" ! (pour la clé CFBundleVersion on a bien mis "1.2" bien sûr par contre)
Je suis sur le c*l car autant pour CFBundleVersion j'ai toujours mis que des chiffres séparés par des points car pour moi c'est ce qui est utilisé pour comparer les versions et savoir s'il y a une mise à jour etc, mais pour CFBundleShortVersionString j'étais persuadé que c'était libre, genre comme sur les applis OSX pour mettre le texte à afficher dans la fenêtre d'infos, genre "v1.2 ©2012, Tous droits réservés" un truc comme ça. En plus, la clé CFBundleShortVersionString est indiquée comme "localisable", mais si on est obligé de mettre que 3 chiffres séparés par des points, quel intérêt de la traduire ?!
T'es sur qu'il n'y a pas une différence entre iOS et OS X ? Plus le fait que ce qu'ont faisait avant avec ShortVersionString n'est peut être plus adapté à ce qu'en fait Apple sur le MAS.
https://developer.ap...11349-TPXREF113
Ah ça personnellement j'aime bien, un numéro de build et un numéro de version, ça permet un suivit correct des version de dev et des beta que l'on fournis sans avoir à gérer une branche de version pour ça (surtout si on génère les numéro de build avec le numéro révision git / svn).
Je suis entièrement d'accord. Je me suis posé la question il n'y a pas longtemps. Du coup, je même le même numéro dans les 2 champs maintenant pour être "tranquille".
mon appli vient d'être aussi rejettée car je n'ai pas fourni un commpte demo. t'as modifié l'appli pour rajouter un compte demo ?
Non, sans rire, c'est dingue quand même...
Certains doivent avoir la trouille de se faire taper dessus si ils laissent passer quelque chose.