Rejet de l'application par Apple : iCloud en cause.
Planext
Membre
Bonjour,
Je me permets de vous écrire car j'ai soumis il y a quelques jours une application à Apple.
J'ai eu un retour de leur part m'indiquant :
Le détail du rejet indique :
J'ai donc cherché d'où provenait ces 3.3MB. Ils correspondent à la taille de mon fichier sqlite utilisé pour Core Data. Lors du premier lancement de l'applicaiton, je remplis cette base de données grâce à des fichiers JSON qui sont traités.
Dans le détail du rejet, Apple m'indique un lien pour résoudre ce problème : https://developer.ap...719/_index.html
Je suis donc la procédure et ajoute alors le flag "do not back up" sur la base sqlite. Je vérifie alors sur mon device que les 3.3Mb ne sont pas enregistrés pour iCloud, et les 3.3Mb n'apparaissent pas. Je soumets à nouveau à Apple pensant que la correction est effective. Quelques jours plus tard, je reçois à nouveau un rejet de leur part, exactement pour la même raison, avec exactement le même message ci-dessus.
Je ne comprends pas quel est le problème.
Avez-vous rencontré ce genre de retour d'Apple? Comment corriger cette erreur?
D'avance merci pour vos réponses
Je me permets de vous écrire car j'ai soumis il y a quelques jours une application à Apple.
J'ai eu un retour de leur part m'indiquant :
- 2.23 Apps must follow the iOS Data Storage Guidelines or they will be rejected
Le détail du rejet indique :
We found that your app does not follow the iOS Data Storage Guidelines, which is required per the App Store Review Guidelines.
In particular, we found that on launch and/or content download, your app stores 3.32MB. To check how much data your app is storing:
- Install and launch your app
- Go to Settings > iCloud > Storage & Backup > Manage Storage
- If necessary, tap "Show all apps"
- Check your app's storage
The iOS Data Storage Guidelines indicate that only content that the user creates using your app, e.g., documents, new files, edits, etc., may be stored in the /Documents directory - and backed up by iCloud.
Temporary files used by your app should only be stored in the /tmp directory; please remember to delete the files stored in this location when the user exits the app.
J'ai donc cherché d'où provenait ces 3.3MB. Ils correspondent à la taille de mon fichier sqlite utilisé pour Core Data. Lors du premier lancement de l'applicaiton, je remplis cette base de données grâce à des fichiers JSON qui sont traités.
Dans le détail du rejet, Apple m'indique un lien pour résoudre ce problème : https://developer.ap...719/_index.html
Je suis donc la procédure et ajoute alors le flag "do not back up" sur la base sqlite. Je vérifie alors sur mon device que les 3.3Mb ne sont pas enregistrés pour iCloud, et les 3.3Mb n'apparaissent pas. Je soumets à nouveau à Apple pensant que la correction est effective. Quelques jours plus tard, je reçois à nouveau un rejet de leur part, exactement pour la même raison, avec exactement le même message ci-dessus.
Je ne comprends pas quel est le problème.
Avez-vous rencontré ce genre de retour d'Apple? Comment corriger cette erreur?
D'avance merci pour vos réponses
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'ai créé un dossier <Application_Home>/Library/Private Document [font=arial,helvetica,sans-serif]comme conseillé par la note.[/font]
Puis j'ai mis l'attribut "do not backup" sur le dossier "Private Document", j'ai soumis et c'est passé (2 fois).
Attention, la note précise qu'en-dessous de 5.0.1, tu dois te démerder pour que ça sauvegarde pas. Donc mettre tes fichiers dans un dossier qui n'est pas sauvegardé. Ce que je n'ai pas fait, bien que mon app cible 5.0 et +.
Si tu préfères, si ce sont des documents à lui, comme des docs, des pdf, des images, etc.
Déplace ta base de donnée dans le dossier Application Support (tu peux t'aider de ça http://cocoawithlove.com/2010/05/finding-or-creating-application-support.html )
Ce que je ne comprends pas, c'est pourquoi nativement la BDD est située dans /Documents lors de la création d'un projet Core Data, si derrière l'appli est rejettée.
J'utilise Xcode 4.3.2.
Qu'un fichier CoreData grossisse au fur et a mesure des actions de l'utilisateur, je pense que ça ne pose pas de problème à Apple. Mais qu'un fichier CoreData de 3Mo apparaisse du simple fait du lancement de l'application, ce n'est pas normal pour eux.
On ne doit sauvegarder que les données générées par l'utilisateur.
Si cette base est ensuite modifiée par l'utilisateur, alors tu as le droit de la sauvegarder.
Les données qu'on peut recréer ne doivent pas être sauvegardées.
Dans les données qu'on peut recréer, il faut distinguer les données qu'on peut recharger facilement (par ex: le cache) qui va dans Library/cache et qui n'est pas sauvegardé et qui peut-être détruit si on a besoin de place.
Et les données qui doivent être disponible offline et qu'on souhaite conserver sans avoir besoin de les sauvegarder (par exemple des tuiles de cartes offline). C'est pour ces données qu'on doit utiliser le nouvel attribut.
J'ai donc déplacé le fichier sqlite dans le répertoire <Application_Home>/Library/Application Support et ai placé le flag "do not back up" sur le répertoire Application Support.
En revanche, lorsque je retourne dans les paramètres iCloud, j'aperçois 70ko, ce qui correspond à la taille du fichier plist de l'application (présent dans <Application_Home>/Library/Preferences). Ce fichier contient une paire clef/valeur que j'utilise dans mon application (NSUserDefaults) pour déterminer s'il s'agit ou non du premier lancement et ainsi savoir s'il faut télécharger du contenu à partir d'un serveur. Apple risque-t-il de rejeter l'application à cause de ça?
Merci
Ok ! Merci pour ta réponse.
Je renvoie mon archive et vous informe du résultat !
Une évolution dans la gestion des fichiers et documents prévues pour iOS 6 ?
Je n'ai pas eu de problème avec Apple pour l'instant sur ce point, je pense que c'est parce que cette utilisation est facultative (backup/sync).
Je caricature, mais en gros Apple s'en foutait tant que les sauvegardes via iTunes ne prenaient de la place que sur ton disque dur.
Maintenant qu'on peut sauvegarder sur les disques dur de Cupertino, alors ça devient important de réduire la taille des sauvegardes.
De toutes façons, depuis la sortie de l'iPad la gestion du répertorie Documents a été mal géré.
Avant l'iPad, on mettait les documents de l'app dans Documents. Logique.
Ensuite, avec l'iPad, l'utilisateur a pu voir le contenu de ce dossier via iTunes (par une procédure un peu pourrie qu'aucun noob ne comprend).
Du coup, il a fallu déplacer les documents privé que l'utilisateur ne devait pas voir.
Devant l'absence de solution proposé par Apple, certains ont mis leur data dans "Library" d'autres dans des dossiers cachés dont le nom commence par un point. Ouf! Sauf que sous Windows, ça marche pas car iTunes montre les dossiers qui commencent par un point vu que ça n'a aucune signification pour l'OS.
Tardivement Apple a sorti une note pour indiquer qu'il faut mettre les dossiers <Application_Home>/Library (developer.apple.com/iphone/library/qa/qa2010/qa1699.html), c'est vachement logique de mettre ses documents dans "Library" et pas dans "Documents".
Ensuite il y a eu iOS5 et iCloud, Apple a ajouté une fonction de cleaning qui vide les caches. Et là tous les développeurs qui avait mis leur données dans Library/cache pour ne pas gonfler le disque dur de l'utilisateur, se sont cassés les dents. Grâce sans doute à des développeurs influents comme Marco, Apple a rapidement fait un patch en 5.0.1. (http://www.marco.org...caches-cleaning).
Et je ne parle pas du dossier "inbox".
Bref. La gestion des Documents dans iOS, c'est le bordel.
Dans iOS 6, ce serait bien d'avoir une remise à plat.
Et que le dossier "User Documents" soit visible dans le Finder sans passer par iTunes.