Non ça ne posera pas de problème, car Xcode 7 tourne sous 10.10 (je l'ai testé chez moi ça fonctionne très bien).
La mention "SDK: iOS9 beta, OS X v10.11 beta" ça indique juste les SDK fournis avec Xcode.
Le SDK fournit les APIs (les headers et frameworks) pour développer. Utiliser le SDK iOS9 te permettra d'utiliser toutes les APIs de iOS9... et iOS précédents, donc pas de soucis pour développer pour iOS8 avec. Je développement bien des applications ciblant iOS7 avec le SDK actuel (SDK 8.3).
Quand on crée un projet, on indique d'un côté quel "Base SDK" utiliser (il n'y a en pratique *aucune* raison pour ne pas utiliser le "Latest SDK", pour indiquer à quelles APIs on a accès (qui peut le + peut le moins donc le dernier est le mieux) et de l'autre quel "Deployment Target" utiliser pour le projet (c'est la version d'iOS minimum sur laquelle ton application va pouvoir tourner, par exemple ces derniers temps on a tendance à cibler uniquement iOS7 et supérieur, voire que iOS8 et supérieur, pour pas avoir à gérer le support d'anciennes APIs de iOS6 par exemple)
En pratique si justement il y a une raison pour faire gaffe et éviter de déphaser le Base SDK et le Deployment Target car encore faut-il pouvoir appréhender le "Conditionally use these APIs" lors du développement.
Hors, à moins qu'Xcode ait évolué dans ce sens mais je ne l'ai pas vu, on fait comment pour connaitre les évolutions d'API (sans se farcir toute la doc méthode par méthode) lorsqu'on compile? Berfis en avait été pour ses frais pour cette raison dans une ancienne discussion. On compile à l'aveugle en Base SDK 10.6 (pour reprendre le schéma d'illustration) et on se casse les dents lors des tests en lançant l'appli sous 10.4 avec des "unrecognized selector sent to instance" parce qu'on a utilisé des évolutions d'APIs qui n'existaient pas encore sous 10.4.
Pour que cela fonctionne, il faudrait qu'Xcode dispose des différents SDK et fasse un contrôle de rétro-compatiblité à la compilation afin d'avertir d'éventuelles incohérences. Un peu comme les warning deprecated mais à l'envers.
Bref, je reste d'expérience convaincu que c'est hyper dangereux de bosser comme ça.
Hors, à moins qu'Xcode ait évolué dans ce sens mais je ne l'ai pas vu, on fait comment pour connaitre les évolutions d'API (sans se farcir toute la doc méthode par méthode) lorsqu'on compile? [...] Pour que cela fonctionne, il faudrait qu'Xcode dispose des différents SDK et fasse un contrôle de rétro-compatiblité à la compilation afin d'avertir d'éventuelles incohérences. Un peu comme les warning deprecated mais à l'envers.
C'est vrai que ça manque en ObjC, mais par contre sache que c'est (enfin) ce qui est fait en Swift.
Si tu codes en Swift et que dans ton code Swift tu utilises une API qui n'est pas forcément disponible selon ton Deployment Target (genre tu utilises une API de iOS8 alors que ton Depl Target est iOS7), sans protéger l'appel d'une vérification d'availability au préalable, alors le compilateur va non seulement refuser de compiler cette ligne, mais en plus te proposer comme fix d'encadrer cet appel à cette API d'un "if #available(iOS 8) { ... }" pour protéger l'appel et donc éviter que ça ne crash au runtime. C'est donc maintenant détecté à la compilation (et ça change tout).
Encore un des nombreux avantages à passer à Swift (dont les fonctionnalités supplémentaires qu'il offre par apport à ObjC sont de plus en plus nombreuses, d'ailleurs maintenant je souffre de plus en plus à faire de l'ObjC quand je bosse sur certains projets ou je peux pas encore faire du Swift car les clients ou collègues ne sont pas encore au niveau :-/)
C'est cool que ce soit intégré en Swift même si en l'occurrence Obj-C n'y est pour rien pour le coup. Il y aurait tout ce qu'il faut pour le faire.
Encore un des nombreux avantages à passer à Swift (dont les fonctionnalités supplémentaires qu'il offre par apport à ObjC sont de plus en plus nombreuses, d'ailleurs maintenant je souffre de plus en plus à faire de l'ObjC quand je bosse sur certains projets ou je peux pas encore faire du Swift car les clients ou collègues ne sont pas encore au niveau :-/)
Sans parler que casser la compatibilité descendante sur un produit existant avec une belle mise à jour 10.10 only c'est suicidaire commercialement.
C'est cool que ce soit intégré en Swift même si en l'occurrence Obj-C n'y est pour rien pour le coup. Il y aurait tout ce qu'il faut pour le faire.
C'est loin d'être sûr, car Objective-C est un langage dynamique par nature, ce qui fait que toutes les résolutions d'appel de méthodes sont en fait des envois de message (objc_msgSend) résolus au runtime, que tu as aussi des @selector (performSelector, pattern Target/Action, etc), du swizzling possible (certaines librairies implémentent une rétro-compatibilité de nouvelles APIs iOS pour que ça utilise l'implémentation native si elle est dispo, et leur implémentation sinon, en faisant du swizzling, te permettant d'appeler la même méthode de façon transparente...). Autant de choses que le compilateur ObjC aurait beaucoup de mal à détecter
Alors qu'en Swift ce n'est pas la même donne, vu l'aspect bien plus statique du langage, il y a à mon avis moins de barrières à implémenter ce genre de protection dans le compilateur qu'avec un langage pur-dynamique.
Sans parler que casser la compatibilité descendante sur un produit existant avec une belle mise à jour 10.10 only c'est suicidaire commercialement.
Heu pourquoi 10.10 only ? Les applications écrites en (ou contenant du) Swift sont rétrocompatibles iOS7 et OSX 10.9 Mavericks.
Réponses
En pratique si justement il y a une raison pour faire gaffe et éviter de déphaser le Base SDK et le Deployment Target car encore faut-il pouvoir appréhender le "Conditionally use these APIs" lors du développement.
Hors, à moins qu'Xcode ait évolué dans ce sens mais je ne l'ai pas vu, on fait comment pour connaitre les évolutions d'API (sans se farcir toute la doc méthode par méthode) lorsqu'on compile? Berfis en avait été pour ses frais pour cette raison dans une ancienne discussion. On compile à l'aveugle en Base SDK 10.6 (pour reprendre le schéma d'illustration) et on se casse les dents lors des tests en lançant l'appli sous 10.4 avec des "unrecognized selector sent to instance" parce qu'on a utilisé des évolutions d'APIs qui n'existaient pas encore sous 10.4.
Pour que cela fonctionne, il faudrait qu'Xcode dispose des différents SDK et fasse un contrôle de rétro-compatiblité à la compilation afin d'avertir d'éventuelles incohérences. Un peu comme les warning deprecated mais à l'envers.
Bref, je reste d'expérience convaincu que c'est hyper dangereux de bosser comme ça.
Si tu codes en Swift et que dans ton code Swift tu utilises une API qui n'est pas forcément disponible selon ton Deployment Target (genre tu utilises une API de iOS8 alors que ton Depl Target est iOS7), sans protéger l'appel d'une vérification d'availability au préalable, alors le compilateur va non seulement refuser de compiler cette ligne, mais en plus te proposer comme fix d'encadrer cet appel à cette API d'un "if #available(iOS 8) { ... }" pour protéger l'appel et donc éviter que ça ne crash au runtime. C'est donc maintenant détecté à la compilation (et ça change tout).
Encore un des nombreux avantages à passer à Swift (dont les fonctionnalités supplémentaires qu'il offre par apport à ObjC sont de plus en plus nombreuses, d'ailleurs maintenant je souffre de plus en plus à faire de l'ObjC quand je bosse sur certains projets ou je peux pas encore faire du Swift car les clients ou collègues ne sont pas encore au niveau :-/)
C'est cool que ce soit intégré en Swift même si en l'occurrence Obj-C n'y est pour rien pour le coup. Il y aurait tout ce qu'il faut pour le faire.
Sans parler que casser la compatibilité descendante sur un produit existant avec une belle mise à jour 10.10 only c'est suicidaire commercialement.
Alors qu'en Swift ce n'est pas la même donne, vu l'aspect bien plus statique du langage, il y a à mon avis moins de barrières à implémenter ce genre de protection dans le compilateur qu'avec un langage pur-dynamique.
Heu pourquoi 10.10 only ? Les applications écrites en (ou contenant du) Swift sont rétrocompatibles iOS7 et OSX 10.9 Mavericks.
La dernière version de llvm semble intégrer la vérification de la présence des API en fonction du la version de l'OS ciblé : http://llvm.org/viewvc/llvm-project?view=revision&revision=232750