Bah en même temps si tu faisais attention avant de soumettre... c'est pas de leur faute si tu as laissé du contenu de test... Et c'est même heureux qu'ils te le mentionnent, sans quoi tu n'aurais jamais réalisé que tu avais n'importe quoi dans ton app
A noter que Jobs ne voulais pas d'AppStore à l'origine, pensant qu'il étais impossible à ces équipes d'avoir une validation efficace des applications. Heureusement que le reste du staff a su le convaincre !
A noter que Jobs ne voulais pas d'AppStore à l'origine, pensant qu'il étais impossible à ces équipes d'avoir une validation efficace des applications. Heureusement que le reste du staff a su le convaincre !
oui et non. Le Play store s'en sort bien. 90% des contrôles peuvent être automatisés je pense... Le reste, c'est un peu bidon. On le voit bien à travers les différents exemple.
Certains lutins se font pas ch... d'autres font carrément du zèle.
Au final, on a des temps de review d'une semaine là ou le playstore le fait en qques heures.
Et on n'a pas la qualité pour autant. Un collègue avait installé une appli qui lui pompait ttes ses ressources.
Et je pense bien qu'il est aisé par exemple, de mettre un flag sur un serveur : diplayPub.
Si non, alors, n'affiche rien, si oui, affiche la pub.
Quand l'appli d'u bo gosse est en InREview, il met son flag à No. Quand c'est validé, il le met à Yes.
Et puis bon la review c'est un peu toi qui l'a fait aussi. Quand tu veux une application il t'affiche toutes les permissions dont a besoin l'application et a toi de faire le choix de le prendre ou pas. Récemment je fut étonné de voir une appli de golf vouloir avoir accès à mes comptes, mes sms, mes appels téléphonique, accès à mon répertoir, etc... J'ai fais "LOL ! Tu peux aller te t*** avec ton appli".
Et puis bon la review c'est un peu toi qui l'a fait aussi. Quand tu veux une application il t'affiche toutes les permissions dont a besoin l'application et a toi de faire le choix de le prendre ou pas. Récemment je fut étonné de voir une appli de golf vouloir avoir accès à mes comptes, mes sms, mes appels téléphonique, accès à mon répertoir, etc... J'ai fais "LOL ! Tu peux aller te t*** avec ton appli".
Malheureusement vu comment c'est fait sur Android, personne à part toi et 2-3 autres ne lisent ces demandes d'accès de permissions à l'installation. C'est un peu comme les contrats de licence, personne ne les lit et on clique sur Accepter sans lire pour utiliser l'appli au plus vite.
D'autant que des fois, les autorisations demandées sont justifiées du côté développeur, mais les demander au début fait bizarre. Par exemple pourquoi une application de jeux voudrais avoir accès à facebook et à tes contacts et à tes SMS ? Tu vois ça au lancement tu dis WTF.
Par contre s'il faisait comme sous iOS, c'est à dire s'il te demandais l'accès à tes contacts uniquement au moment où tu choisis de faire "partager mon score avec mes amis" ou te demande l'accès SMS uniquement quand tu choisis "recommander l'application à mes amis par SMS", là tu comprendrais le besoin. Et si tu ne choisis jamais aucune de ces options, tu n'auras jamais à donner ces autorisation à l'appli car elle n'a pas besoin de ces accès autrement que pour ça.
Du coup personnellement (mais ce n'est que mon avis) je préfère la façon de faire d'iOS, qui te demande les autorisations qu'au moment où c'est nécessaire et pas en bloc au début. En plus ça incite carrément + l'utilisateur à lire les alertes au moment de faire l'action qu'à lire les autorisations Android à l'install de l'appli.
Encore un bel exemple : Nous sortons une appli qui nécessite la création de compte par activation d'un numéro de tel français. Apple ne pouvant pas le faire, ils nous demande donc un email / password d'un compte déjà existant pour tester l'appli. Et là , un beau rejet comme quoi il est impossible de se connecter, aucun compte avec cet adresse email n'existe!
Après vérification des logs, l'erreur provenait d'un jolie copier/coller de mr le testeur qui a eut pour effet de laisser un espace devant l'adresse email au moment du login.... Corrigé en vitesse côté serveur pour éviter ce genre de blague!!
A mon tour, 2 rejets coup sur coup : pour un truc qui était passé sans problème jusqu'à maintenant. J'offrais une petite in-app en "échange" d'un rating. Je dis en échange, parce que c'est juste le fait de cliquer sur le bouton "Noter", même non suivi d'une note, qui entraà®nait automatiquement la validation de l'in-App.
J'ai récupéré comme ça pas mal de notes, et je n'ai pas essayé d'influencer, l'utilisateur reste libre de mettre une note pourrie....
Cela dit c'est vrai que du coup cela a plutôt eu une influence favorable sur le ranking.
Mais, là , rien à faire, ça ne passe plus. D'après la réponse d'Apple, cette démarche n'est pas autorisée. Il me semble qu'il y a pourtant pas mal d'App qui utilise cette méthode, qui donne des pièces, ou autres...
Qu'en est-il des vôtres ? Quel est votre avis là -dessus ? Est-ce que les règles ont récemment changé ?
Merci d'avance.
Je vous cite quand-même leur dernière réponse :
- Thank you for your questions. Per guideline 11.1, it is against our guidelines to offer In App Purchases through any mechanism other than purchasing through the App Store.
ca, je ne comprends pas trop, parce que je passe par le même processus que pour un achat in-App payant.
- It is not permissible to offer In App Purchases for any activity related to rating or reviewing the app or after asking the user to do so.
Ca, c'est clair, mais je ne sais pas d'où ça sort.
Ne te prends pas la tête: en gros, ça ne leur convient pas, et ils te sortent les articles qui correspondent le plus pour justifier le rejet. Remonte un peu ce fil de discussion, tu verras que les articles sont souvent vaguement en rapport avec la cause du rejet.
En fait je vous rassure la vidéo n'est pas obligatoire, simplement, puisque apparement ils souhaitaient une vidéo pour comprendre le fonctionnement de mon appli (qui entres parenthèse n'a pas changé d'un point de vue interface : c'est juste une mise à jour, mais bon...) j'en ai profité pour faire une App Video Preview... Bizarres quand même ces testeurs Apple ;-)
La semaine dernière j'ai envoyé deux applications, quasiment identique l'une et l'autre (l'une traitant les actualité du club de foot de bordeaux, l'autre du club de foot de lile).
L'application Girondins Infos a été accepté alors que LOSC Infos non.
Sur les deux applications j'ai un lien dans une webview vers le site m.livescore.com. Et apparement sur ce site, dans la localité du testeur, il y a une pub vers un site de jeu en ligne (qui est interdit aux US). Et ils ont refusé l'application LOSC Infos, à cause de cette pub !!!
J'ai tellement perdu de temps avec ces validations, que je commence a saturer. Ce n'est même plus un plaisir de sortir une appli, c'est devenu une angoisse.
Les testeurs sont chinois (en tout cas une partie) car lors d'un rejet, ils m'avaient joints des captures d'écrans qui étaient localisées en chinois (avec des YUAN comme monnaie).
Les testeurs sont chinois (en tout cas une partie) car lors d'un rejet, ils m'avaient joints des captures d'écrans qui étaient localisées en chinois (avec des YUAN comme monnaie).
J'ai tendance à penser, même si ce n'est qu'une hypothèse, qu'Apple fait la même chose qu'UBI Soft : repartir la charge de travail sur plusieurs équipes installées sur différents fuseaux horaires, de manière à fonctionner 24 h sur 24 h.
Réponses
!!! Me dites pas que j'ai laissé le item !
EDIT: Je suis bon pour une re-soumission !
J'en ai marre de me faire soumettre par Apple !
oui et non. Le Play store s'en sort bien. 90% des contrôles peuvent être automatisés je pense... Le reste, c'est un peu bidon. On le voit bien à travers les différents exemple.
Certains lutins se font pas ch... d'autres font carrément du zèle.
Au final, on a des temps de review d'une semaine là ou le playstore le fait en qques heures.
Et on n'a pas la qualité pour autant. Un collègue avait installé une appli qui lui pompait ttes ses ressources.
Et je pense bien qu'il est aisé par exemple, de mettre un flag sur un serveur : diplayPub.
Si non, alors, n'affiche rien, si oui, affiche la pub.
Quand l'appli d'u bo gosse est en InREview, il met son flag à No. Quand c'est validé, il le met à Yes.
Et basta...
Sur le playStore, il n'y a des reviews qu'après avec poster ton appli et qu'elle soit disponible.
Une fois qu'ils ont fait les verification d'identité ( la premiere fois ) ton applis est mise en ligne quasi instantanément.
C'est quand une appli a de mauvaise note qu'il font une review en general et le reste j'ai l'impression que c'est aléatoire.
D'un autre coté, j'ai beau être plus accés android pour le perso, les applications sont de nettement moins bonne qualité.
Je pense que les review sont justifié par ca.
Et puis bon la review c'est un peu toi qui l'a fait aussi. Quand tu veux une application il t'affiche toutes les permissions dont a besoin l'application et a toi de faire le choix de le prendre ou pas. Récemment je fut étonné de voir une appli de golf vouloir avoir accès à mes comptes, mes sms, mes appels téléphonique, accès à mon répertoir, etc... J'ai fais "LOL ! Tu peux aller te t*** avec ton appli".
D'autant que des fois, les autorisations demandées sont justifiées du côté développeur, mais les demander au début fait bizarre. Par exemple pourquoi une application de jeux voudrais avoir accès à facebook et à tes contacts et à tes SMS ? Tu vois ça au lancement tu dis WTF.
Par contre s'il faisait comme sous iOS, c'est à dire s'il te demandais l'accès à tes contacts uniquement au moment où tu choisis de faire "partager mon score avec mes amis" ou te demande l'accès SMS uniquement quand tu choisis "recommander l'application à mes amis par SMS", là tu comprendrais le besoin. Et si tu ne choisis jamais aucune de ces options, tu n'auras jamais à donner ces autorisation à l'appli car elle n'a pas besoin de ces accès autrement que pour ça.
Du coup personnellement (mais ce n'est que mon avis) je préfère la façon de faire d'iOS, qui te demande les autorisations qu'au moment où c'est nécessaire et pas en bloc au début. En plus ça incite carrément + l'utilisateur à lire les alertes au moment de faire l'action qu'à lire les autorisations Android à l'install de l'appli.
Encore un bel exemple : Nous sortons une appli qui nécessite la création de compte par activation d'un numéro de tel français. Apple ne pouvant pas le faire, ils nous demande donc un email / password d'un compte déjà existant pour tester l'appli. Et là , un beau rejet comme quoi il est impossible de se connecter, aucun compte avec cet adresse email n'existe!
Après vérification des logs, l'erreur provenait d'un jolie copier/coller de mr le testeur qui a eut pour effet de laisser un espace devant l'adresse email au moment du login.... Corrigé en vitesse côté serveur pour éviter ce genre de blague!!
Bonsoir à tous,
A mon tour, 2 rejets coup sur coup : pour un truc qui était passé sans problème jusqu'à maintenant. J'offrais une petite in-app en "échange" d'un rating. Je dis en échange, parce que c'est juste le fait de cliquer sur le bouton "Noter", même non suivi d'une note, qui entraà®nait automatiquement la validation de l'in-App.
J'ai récupéré comme ça pas mal de notes, et je n'ai pas essayé d'influencer, l'utilisateur reste libre de mettre une note pourrie....
Cela dit c'est vrai que du coup cela a plutôt eu une influence favorable sur le ranking.
Mais, là , rien à faire, ça ne passe plus. D'après la réponse d'Apple, cette démarche n'est pas autorisée. Il me semble qu'il y a pourtant pas mal d'App qui utilise cette méthode, qui donne des pièces, ou autres...
Qu'en est-il des vôtres ? Quel est votre avis là -dessus ? Est-ce que les règles ont récemment changé ?
Merci d'avance.
Je vous cite quand-même leur dernière réponse :
- Thank you for your questions. Per guideline 11.1, it is against our guidelines to offer In App Purchases through any mechanism other than purchasing through the App Store.
ca, je ne comprends pas trop, parce que je passe par le même processus que pour un achat in-App payant.
- It is not permissible to offer In App Purchases for any activity related to rating or reviewing the app or after asking the user to do so.
Ca, c'est clair, mais je ne sais pas d'où ça sort.
Ne te prends pas la tête: en gros, ça ne leur convient pas, et ils te sortent les articles qui correspondent le plus pour justifier le rejet. Remonte un peu ce fil de discussion, tu verras que les articles sont souvent vaguement en rapport avec la cause du rejet.
Ok, merci. Donc, en fait, ça doit être un coup de chance : ça passe, ça passe pas, selon le testeur....
J'ai vu effectivement que c'était un peu aléatoire, c'est pour ça que j'ai tenté une seconde fois en modifiant juste un peu le texte...
Mais, là , je retenterai plus tard.
J'ai pas bien compris l'intérêt de l'inApp dans ce cas ?
C'est un inApp gratuit qui délivre du contenu ? C'est ça ?
Oui, effectivement, j'aurais du préciser... il y a du contenu.
Premier rejet (type metadata...) mais impossible de corriger pour l'instant (iTunnes Connect indisponible)... pas de bol.
Le pire, c'est que l'appli a été validée par Apple pour les bêtas testeurs externes ;-)
Je vais partager ma galère en vous tenant au courant de la suite des évènements...
et des promo codes pour les IAP ?
ben voilà la raison
Depuis quand la vidéo est obligatoire ???
Etrange, en effet... Elle est toujours affichée comme facultative...
ça dépendait uniquement du type d'application auparavant, non ?
Un moyen de savoir en quoi consiste (grosso-modo) l'application ? Elle permet de contrôler un objet ?
J'ai envoyé plein de mises à jour sans vidéo depuis qu'on peut en mettre une, pas de soucis.
A moins que ce soit une nouvelle app ?
En fait je vous rassure la vidéo n'est pas obligatoire, simplement, puisque apparement ils souhaitaient une vidéo pour comprendre le fonctionnement de mon appli (qui entres parenthèse n'a pas changé d'un point de vue interface : c'est juste une mise à jour, mais bon...) j'en ai profité pour faire une App Video Preview... Bizarres quand même ces testeurs Apple ;-)
La suite au prochaine épisode ...
Ben j'imagine que c'est des mecs peu payer, peut être localisés au mexique, qui testent à la chaine les applis... Donc suivant le lutin...
La semaine dernière j'ai envoyé deux applications, quasiment identique l'une et l'autre (l'une traitant les actualité du club de foot de bordeaux, l'autre du club de foot de lile).
L'application Girondins Infos a été accepté alors que LOSC Infos non.
Sur les deux applications j'ai un lien dans une webview vers le site m.livescore.com. Et apparement sur ce site, dans la localité du testeur, il y a une pub vers un site de jeu en ligne (qui est interdit aux US). Et ils ont refusé l'application LOSC Infos, à cause de cette pub !!!
J'ai tellement perdu de temps avec ces validations, que je commence a saturer. Ce n'est même plus un plaisir de sortir une appli, c'est devenu une angoisse.
Les testeurs sont chinois (en tout cas une partie) car lors d'un rejet, ils m'avaient joints des captures d'écrans qui étaient localisées en chinois (avec des YUAN comme monnaie).
Bon ben ça promet alors si c'est les chinois qui testent mon appli !
J'ai tendance à penser, même si ce n'est qu'une hypothèse, qu'Apple fait la même chose qu'UBI Soft : repartir la charge de travail sur plusieurs équipes installées sur différents fuseaux horaires, de manière à fonctionner 24 h sur 24 h.
Ou c'est cohérent
Mon application est enfin acceptée par Apple après 3 jours en statut 'In review'...
Je n'ai opéré aucune modification de code ! j'ai juste créé un App Video Preview, bizarre non ?
J'adore les rejets sur une mise à jour mineure, juste parce que l'on tombe sur un lutin grognon...
(le tout sur une appli qui date de 2010 et qui a eu 9 ou 10 validations sans problème)
Bon, c'était pour passer mon énervement quelque part, même si on a tous eu droit à ce genre de cas.