Normal, il n'y a pas le SDK iOS6 dans le bundle de Xcode5. Tout comme il n'y a pas les SDK précédents (iOS4, etc.) dans Xcode4. Il n'y a que le dernier SDK de fourni.
Je vous conseille si vous en avez besoin de renommer Xcode.app en Xcode4.app avant de faire votre mise à jour via l'AppStore par exemple, pour garder Xcode4 sous la main si besoin.
C'est exactement ce que j'ai fait de façon à avoir les deux versions.
Mis à part que çà génère un petit bug sur le simulateur, çà permet de vérifier si un problème trouvé sous iOS7 est également présent sur la version compilée avec Xcode 4.
Et là , on peut voir que certains bugs sont essentiellement présents sur iOS7. Un binaire généré avec Xcode 4 et qui fonctionne correctement sur iOS6, bug sur iOS7 !!!
Record battu. Envoi aujourd'hui d'un correctif de notre application sur iOS 7 pour bug. Envoyer à 18h en Review à 23h. Les p'tits lutins sont au taqués en ce moment.
Record battu. Envoi aujourd'hui d'un correctif de notre application sur iOS 7 pour bug. Envoyer à 18h en Review à 23h. Les p'tits lutins sont au taqués en ce moment.
Bon, j'ai à mon tour du faire une demande Expedited review hier à 20h, j'ai reçu un email automatique à minuit me signalant que ma demande serait étudiée sous 1 à 2 jours !
Je ne sais pas comment vous avez fait pour passer si rapidement...
C'est simple je les ai caressé dans le sens du poil.
Il faut savoir leur parler.
Tu leur dis que si ils valident pas rapidement, Apple va perdre des ventes et ses 30% de commission. Du coup, les actionnaires ne seront pas content que la CA fasse 0.0000001% de moins.
Normal, il n'y a pas le SDK iOS6 dans le bundle de Xcode5. Tout comme il n'y a pas les SDK précédents (iOS4, etc.) dans Xcode4. Il n'y a que le dernier SDK de fourni.
Je vous conseille si vous en avez besoin de renommer Xcode.app en Xcode4.app avant de faire votre mise à jour via l'AppStore par exemple, pour garder Xcode4 sous la main si besoin.
je viens de relire la discussion, moi je rajoute a la main le SDK 6 dans Xcode 5 comme ça je peux changer le base sdk et le mettre en 6, de coup je ne sais pas si c'est vraiment nécessaire de garder Xcode 4.
( J'ai pas fait de soumission avec Xcode 5 et base sdk 6, juste des tests pour l'instant).
C'est risqué comme solution. Xcode5 vient avec le SDK7, mais aussi avec les Dev Tools, tels que clang/LLVM en particulier. le LLVM packagé avec Xcode4 par exemple sera incapable de builder une application utilisant le SDK7 (du moins c'est pas garanti) car le nouveau LLVM apporte son lot de nouveautés (support des modules et header maps et de directives telles que @import, etc) qui n'étaient pas supportées par le LLVM de Xcode4. De la même manière, il n'est pas garanti (même s'il y a moins de risques) que le LLVM de Xcode5 interprète de la même manière le SDK6 que le LLVM de Xcode4. Normalement il n'y a pas de régressions, mais bon qui sait, Appe a peut-être laissé des #if dans ses headers qui font que...
Bref, en pratique c'est possible que ça marche d'injecter le SDK6 dans Xcode5, j'avais proposé l'idée aussi, et dans l'ensemble ça devrait fonctionner. Mais disons que ce n'est pas non plus garanti par Apple donc si y'a qqch qui va de travers ou qui a un comportement différent, faudra pas s'étonner.
PS : Je ne vois pas trop l'intérêt de compiler avec le SDK5 ? Il est toujours conseillé de compiler avec le dernier SDK, la seule petite entorse est que pour le SDK7 le comportement change drastiquement concernant les barres et le contenu qui passe en dessous. Mais il n'y a pas de telle différence entre SDK5 et SDK6 donc ça me semble bien moins justifié
Je veux changer le modèle économique d'une app: passage de payant à gratuit + IAP. Le problème est que la mise à jour va léser tous ceux qui ont déjà acheté l'app. Est-ce qu'ils pourraient télécharger l'ancien binaire pour récupérer le contenu devenu payant ?
Je déterre ce sujet pour une question d'actualité :
- J'ai une application en version 1.0 qui est compatible iOS6 et supérieur
- Aujourd'hui, vu les nouveautés d'iOS8 et le temps que ça prendrait pour certaines fonctionnalités spécifiques de les faire rétrocompatibles, je songe à sortir une mise à jour v2.0 en iOS8+ minimum
Jusque là , on est bien d'accord que ceux qui seront encore sur iOS7 continueront à pouvoir télécharger la v1.0 et ceux sous iOS8 téléchargeront la v2.0.
Mais si ensuite demain mon client me dit "sur la version iOS7 y'a un bug majeur qu'il faut corriger", est-ce que je peux republier une version v1.1 pour corriger le bug de la v1.0, cette v1.1 ayant donc de nouveau un Deployment Target iOS6+ ?
Bon, déjà je sais que iTunesConnect va me refuser que j'appelle cette version "1.1" car quand on publie une nouvelle version il impose qu'on augmente le numéro de version par rapport à la précédente. Donc je serais obligé de la nommer v3 ou un truc comme ça.
Mais n'empêche, ma question principale c'est est ce que je peux
Publier une application v1.0.0 en iOS6 minimum hier
Aujourd'hui démarrer une nouvelle branche pour commencer une application v2.0.0 en iOS8 minimum, avec des nouvelles fonctionnalités et corrections de bugs propres à iOS8, et la publier
Et demain faire une v3 iOS6+, qui ne fait que reprendre ma branche v1 et corriger une anomalie dessus, et la publier (alors que j'ai déjà publié une app iOS8+ entre temps
Et bien sûr on peut imaginer recommencer le cycle, publier une v4 version corrective de la v2-iOS8, et une v5 version corrective de la v3-iOS6
Ceci pendant le temps de transition entre (1) le moment où la VABF / Période de garantie de l'application iOS6 soit terminer mais qu'on doit continuer à faire du support dessus et (2) le moment où on va faire une version qui profite de iOS8, adapte l'ergonomie pour s'étirer proprement sur iPhone 6 / 6 Plus, etc
Si qqun a l'info je suis fortement preneur de retours !!!
Mon dieu. ALI POSE UNE QUESTION TECHNIQUE !! La terre s'est-elle mise à tourner à l'envers ? A-t-il eu une inversion du champ magnétique terrestre ? Est-ce le début de l'apocalypse ? Le calendrier maya et Nostradamus ont-ils prédis cet événement ?
A mon avis, tu devras faire des cycles v3/v4 v5/v6 etc.
Mais que se passera-t-il le jour où Apple obligera à supporter l'iPhone 6, tu ne pourras plus publier de v1/v3/v5.
Pour l'iPhone 5, c'était une obligation au 1er mai 2013, donc 8 mois après sa sortie :
Starting May 1, new apps and app updates submitted to the App Store must be built for iOS devices with Retina display and iPhone apps must also support the 4-inch display on iPhone 5. Learn about preparing your apps by reviewing the iOS Human Interface Guidelines.
A mon avis, tu devras faire des cycles v3/v4 v5/v6 etc.
Mais que se passera-t-il le jour où Apple obligera à supporter l'iPhone 6, tu ne pourras plus publier de v1/v3/v5.
Pour l'iPhone 5, c'était une obligation au 1er mai 2013, donc 8 mois après sa sortie :
Starting May 1, new apps and app updates submitted to the App Store must be built for iOS devices with Retina display and iPhone apps must also support the 4-inch display on iPhone 5. Learn about preparing your apps by reviewing the iOS Human Interface Guidelines.
Alors évidemment, ce cycle que je veux mettre en place, c'est uniquement pendant la phase de transition.
Genre le temps que soient pondus les nouveaux designs "flexibles" des applications par les designers et graphistes, par exemple. Une sorte de phase intermédiaire le temps de terminer totalement la migration. Et le temps que la phase de garantie de l'application se termine et que toutes les anomalies que notre client nous demande de corriger sur l'application vendue pour iOS7 soient closes.
Quand le contrat sur l'application iOS7 est fini et qu'on a basculé full-time sur le contrat "évolution pour iOS8" on oubliera les anciennes versions pour ne se concentrer que sur les nouvelles.
Ma question n'est pas tant "jusqu'à quand je pourrais encore publier pour iOS7" un peu comme quand Apple a obligé les apps à supporter l'iPhone 5 le 1er mai.
Ma question est plutôt "est-ce qu'on peut alterner une publication d'une version de l'app en Deployment Target iOS6 et la publication d'une version avec un Deployment Target iOS8, puis une autre publication d'une version avec un Deployment Target iOS6 à nouveau, etc, de sorte de maintenir pendant la phase de transition une app pour ceux qui restent sous iOS7 et une app optimisée pour ceux qui sont sous iOS8 ?
Mon dieu. ALI POSE UNE QUESTION TECHNIQUE !! La terre s'est-elle mise à tourner à l'envers ? A-t-il eu une inversion du champ magnétique terrestre ? Est-ce le début de l'apocalypse ? Le calendrier maya et Nostradamus ont-ils prédis cet événement ?
Tu m'as devancée !
J'ai pensé la même chose en lisant le post d'Ali !
A mon avis c'est impossible, en tout cas je ne vois pas comment faire. Si tu publie une version iOS 6+ elle remplacera (je pense) la version iOS7+/iOS8 pour tout les utilisateurs. Puisque ça sera la dernière mise à jour sur le store et qu'elle sera compatible, il n'y a aucune raison pour que le store propose aux utilisateurs sous iOS8 la version précédante (bien qu'elle soit plus optimisé)
Je pense que tu devra republier la version iOS8 après chaque version de ton iOS6+ pour que ça soit celle là qui soit proposé au utilisateurs sous iOS8.
Ce n'est que m'on avis, il existe peut être une autre façon de faire mais je vois pas comment.
A mon avis c'est impossible, en tout cas je ne vois pas comment faire. Si tu publie une version iOS 6+ elle remplacera (je pense) la version iOS7+/iOS8 pour tout les utilisateurs. Puisque ça sera la dernière mise à jour sur le store et qu'elle sera compatible, il n'y a aucune raison pour que le store propose aux utilisateurs sous iOS8 la version précédante (bien qu'elle soit plus optimisé)
Je pense que tu devra republier la version iOS8 après chaque version de ton iOS6+ pour que ça soit celle là qui soit proposé au utilisateurs sous iOS8.
Ce n'est que m'on avis, il existe peut être une autre façon de faire mais je vois pas comment.
En effet, bonne remarque.
Bon alors changeons les hypothèses, imaginons qu'à chaque fois que je publie une version corrective de la iOS6+ je publie aussi dans la foulée la version iOS8+. Ca sera un peu saoulant à faire c'est clair. Mais imaginons que je le fasse quand même, vous pensez que :
- ça reste possible de publier une version iOS6+ après avoir publié une version iOS8+ ?
- Apple va pas gueuler à la validation quand on va publier notre version corrective de la iOS6+ qui du coup va "rétrograder" en terme de fonctionnalités qui avaient été poussées par la version iOS8+ d'avant ? (la v3 retomberait sur le fonctionnel de la v1 alors que la v2 avait introduit des nouveautés)
J'ai un peu peur de la réponse, malheureusement...
Bon alors changeons les hypothèses, imaginons qu'à chaque fois que je publie une version corrective de la iOS6+ je publie aussi dans la foulée la version iOS8+. Ca sera un peu saoulant à faire c'est clair. Mais imaginons que je le fasse quand même, vous pensez que :
C'est ce que j'avais compris de ta logique v3/v4 v5/v6...
Bon alors changeons les hypothèses, imaginons qu'à chaque fois que je publie une version corrective de la iOS6+ je publie aussi dans la foulée la version iOS8+. Ca sera un peu saoulant à faire c'est clair. Mais imaginons que je le fasse quand même, vous pensez que :
- ça reste possible de publier une version iOS6+ après avoir publié une version iOS8+ ?
- Apple va pas gueuler à la validation quand on va publier notre version corrective de la iOS6+ qui du coup va "rétrograder" en terme de fonctionnalités qui avaient été poussées par la version iOS8+ d'avant ? (la v3 retomberait sur le fonctionnel de la v1 alors que la v2 avait introduit des nouveautés)
J'ai un peu peur de la réponse, malheureusement...
Déjà , les lutins vont rien comprendre et ensuite, avec les délais de validation entre les 2, c'est juste pas gérable.
Réponses
C'est exactement ce que j'ai fait de façon à avoir les deux versions.
Mis à part que çà génère un petit bug sur le simulateur, çà permet de vérifier si un problème trouvé sous iOS7 est également présent sur la version compilée avec Xcode 4.
Et là , on peut voir que certains bugs sont essentiellement présents sur iOS7. Un binaire généré avec Xcode 4 et qui fonctionne correctement sur iOS6, bug sur iOS7 !!!
C'est validé. En tout ça aura mis 8 heures.
Ca marche bien l'emergency !
Record battu. Envoi aujourd'hui d'un correctif de notre application sur iOS 7 pour bug. Envoyer à 18h en Review à 23h. Les p'tits lutins sont au taqués en ce moment.
En emergency aussi ?
Tout à fait.
Je ne sais pas comment vous avez fait pour passer si rapidement...
(C'est ma premiere expedited en 4 ans)
C'est simple, ils ont peur des loup-garous.
C'est simple je les ai caressé dans le sens du poil.
Il faut savoir leur parler.
Tu leur dis que si ils valident pas rapidement, Apple va perdre des ventes et ses 30% de commission. Du coup, les actionnaires ne seront pas content que la CA fasse 0.0000001% de moins.
Vous êtes en forme
, bizarre la pleine lune n'est que dans deux jours !
Bonjour,
je viens de relire la discussion, moi je rajoute a la main le SDK 6 dans Xcode 5 comme ça je peux changer le base sdk et le mettre en 6, de coup je ne sais pas si c'est vraiment nécessaire de garder Xcode 4.
( J'ai pas fait de soumission avec Xcode 5 et base sdk 6, juste des tests pour l'instant).
le LLVM packagé avec Xcode4 par exemple sera incapable de builder une application utilisant le SDK7 (du moins c'est pas garanti) car le nouveau LLVM apporte son lot de nouveautés (support des modules et header maps et de directives telles que @import, etc) qui n'étaient pas supportées par le LLVM de Xcode4.
De la même manière, il n'est pas garanti (même s'il y a moins de risques) que le LLVM de Xcode5 interprète de la même manière le SDK6 que le LLVM de Xcode4. Normalement il n'y a pas de régressions, mais bon qui sait, Appe a peut-être laissé des #if dans ses headers qui font que...
Bref, en pratique c'est possible que ça marche d'injecter le SDK6 dans Xcode5, j'avais proposé l'idée aussi, et dans l'ensemble ça devrait fonctionner. Mais disons que ce n'est pas non plus garanti par Apple donc si y'a qqch qui va de travers ou qui a un comportement différent, faudra pas s'étonner.
PS : Je ne vois pas trop l'intérêt de compiler avec le SDK5 ? Il est toujours conseillé de compiler avec le dernier SDK, la seule petite entorse est que pour le SDK7 le comportement change drastiquement concernant les barres et le contenu qui passe en dessous. Mais il n'y a pas de telle différence entre SDK5 et SDK6 donc ça me semble bien moins justifié
oups erreur de ma part. je parlais bien du 6.
Ouf !
Perso le "Processing for Appstore" fut presque plus long que la review ^^
Petite question:
Je veux changer le modèle économique d'une app: passage de payant à gratuit + IAP. Le problème est que la mise à jour va léser tous ceux qui ont déjà acheté l'app. Est-ce qu'ils pourraient télécharger l'ancien binaire pour récupérer le contenu devenu payant ?
Hello les gens,
Je déterre ce sujet pour une question d'actualité :
- J'ai une application en version 1.0 qui est compatible iOS6 et supérieur
- Aujourd'hui, vu les nouveautés d'iOS8 et le temps que ça prendrait pour certaines fonctionnalités spécifiques de les faire rétrocompatibles, je songe à sortir une mise à jour v2.0 en iOS8+ minimum
Jusque là , on est bien d'accord que ceux qui seront encore sur iOS7 continueront à pouvoir télécharger la v1.0 et ceux sous iOS8 téléchargeront la v2.0.
Mais si ensuite demain mon client me dit "sur la version iOS7 y'a un bug majeur qu'il faut corriger", est-ce que je peux republier une version v1.1 pour corriger le bug de la v1.0, cette v1.1 ayant donc de nouveau un Deployment Target iOS6+ ?
Bon, déjà je sais que iTunesConnect va me refuser que j'appelle cette version "1.1" car quand on publie une nouvelle version il impose qu'on augmente le numéro de version par rapport à la précédente. Donc je serais obligé de la nommer v3 ou un truc comme ça.
Mais n'empêche, ma question principale c'est est ce que je peux
Ceci pendant le temps de transition entre (1) le moment où la VABF / Période de garantie de l'application iOS6 soit terminer mais qu'on doit continuer à faire du support dessus et (2) le moment où on va faire une version qui profite de iOS8, adapte l'ergonomie pour s'étirer proprement sur iPhone 6 / 6 Plus, etc
Si qqun a l'info je suis fortement preneur de retours !!!
A mon avis, tu devras faire des cycles v3/v4 v5/v6 etc.
Mais que se passera-t-il le jour où Apple obligera à supporter l'iPhone 6, tu ne pourras plus publier de v1/v3/v5.
Pour l'iPhone 5, c'était une obligation au 1er mai 2013, donc 8 mois après sa sortie :
Starting May 1, new apps and app updates submitted to the App Store must be built for iOS devices with Retina display and iPhone apps must also support the 4-inch display on iPhone 5. Learn about preparing your apps by reviewing the iOS Human Interface Guidelines.
Alors évidemment, ce cycle que je veux mettre en place, c'est uniquement pendant la phase de transition.
Genre le temps que soient pondus les nouveaux designs "flexibles" des applications par les designers et graphistes, par exemple. Une sorte de phase intermédiaire le temps de terminer totalement la migration. Et le temps que la phase de garantie de l'application se termine et que toutes les anomalies que notre client nous demande de corriger sur l'application vendue pour iOS7 soient closes.
Quand le contrat sur l'application iOS7 est fini et qu'on a basculé full-time sur le contrat "évolution pour iOS8" on oubliera les anciennes versions pour ne se concentrer que sur les nouvelles.
Ma question n'est pas tant "jusqu'à quand je pourrais encore publier pour iOS7" un peu comme quand Apple a obligé les apps à supporter l'iPhone 5 le 1er mai.
Ma question est plutôt "est-ce qu'on peut alterner une publication d'une version de l'app en Deployment Target iOS6 et la publication d'une version avec un Deployment Target iOS8, puis une autre publication d'une version avec un Deployment Target iOS6 à nouveau, etc, de sorte de maintenir pendant la phase de transition une app pour ceux qui restent sous iOS7 et une app optimisée pour ceux qui sont sous iOS8 ?
Tu m'as devancée !
J'ai pensé la même chose en lisant le post d'Ali !
A mon avis c'est impossible, en tout cas je ne vois pas comment faire. Si tu publie une version iOS 6+ elle remplacera (je pense) la version iOS7+/iOS8 pour tout les utilisateurs. Puisque ça sera la dernière mise à jour sur le store et qu'elle sera compatible, il n'y a aucune raison pour que le store propose aux utilisateurs sous iOS8 la version précédante (bien qu'elle soit plus optimisé)
Je pense que tu devra republier la version iOS8 après chaque version de ton iOS6+ pour que ça soit celle là qui soit proposé au utilisateurs sous iOS8.
Ce n'est que m'on avis, il existe peut être une autre façon de faire mais je vois pas comment.
En effet, bonne remarque.
Bon alors changeons les hypothèses, imaginons qu'à chaque fois que je publie une version corrective de la iOS6+ je publie aussi dans la foulée la version iOS8+. Ca sera un peu saoulant à faire c'est clair. Mais imaginons que je le fasse quand même, vous pensez que :
- ça reste possible de publier une version iOS6+ après avoir publié une version iOS8+ ?
- Apple va pas gueuler à la validation quand on va publier notre version corrective de la iOS6+ qui du coup va "rétrograder" en terme de fonctionnalités qui avaient été poussées par la version iOS8+ d'avant ? (la v3 retomberait sur le fonctionnel de la v1 alors que la v2 avait introduit des nouveautés)
J'ai un peu peur de la réponse, malheureusement...
C'est ce que j'avais compris de ta logique v3/v4 v5/v6...
Déjà , les lutins vont rien comprendre et ensuite, avec les délais de validation entre les 2, c'est juste pas gérable.
Ouais c'est clairement ce que je me dis, au final faut pas compter dessus donc.