Ho appena visto il video # 216 del WWDC, "Creazione dell'interfaccia utente adattiva con UIKit".

Verso le 45:10 Tony Ricciardi parla delle modifiche a IB in Xcode 6 per supportare le nuove modifiche.

Dice "Puoi distribuire questi documenti all'indietro nelle versioni precedenti di iOS".

(dove "Questi documenti" presumibilmente indicano XIB e storyboard con impostazioni specifiche per classi di dimensioni diverse.)

Non lo sto inventando. Vai a guardare il video del WWDC.

Come è possibile? Le raccolte di tratti e le classi di dimensioni sono definite solo in iOS 8. In che modo il comportamento di runtime che dipende dai costrutti dell'interfaccia utente che sono nuovi a iOS 8 funziona nelle versioni precedenti di iOS?

Se è possibile, sarebbe meraviglioso. Potresti creare app che funzioneranno su iOS 6, 7 e 8 e trarre vantaggio dalle nuove capacità di layout dell'interfaccia utente flessibile che Apple ha aggiunto a Xcode 6. Ho creato io stesso la logica dell'interfaccia utente adattiva nel codice, ed è abbastanza di lavoro.

Le modifiche apportate all'interfaccia utente con le classi di dimensioni in Interface Builder vengono visualizzate correttamente sui dispositivi iOS 7 e sull'anteprima in Xcode. Ad esempio, ho modificato alcuni vincoli di Layout automatico e le dimensioni dei caratteri per Altezza normale Larghezza normale e tali vincoli modificati sono visibili nel Simulatore iPad con iOS 7.0.

Tutte le ottimizzazioni delle classi di dimensioni sono rese disponibili per iOS 7, ad eccezione delle classi di dimensioni che hanno un'altezza compatta. Ciò è stato confermato da Apple e ora è indicato direttamente nella documentazione :

Per le app che supportano versioni di iOS precedenti a iOS 8, la maggior parte delle classi di dimensioni sono retrocompatibili.

Le classi di dimensioni sono retrocompatibili quando:
- L'app viene creata utilizzando Xcode versione 6 o successive
- La destinazione di distribuzione dell'app è precedente a iOS 8
- Le classi di dimensioni sono specificate in uno storyboard o in xib
- Il valore del componente altezza non è compatto

Poiché iOS 7 non rispetta un paio di classi di dimensioni, se le usi ti imbatterai in problemi. Ad esempio: quando hai Compact w Any h definito e quindi Compact w Compact h definito, su iOS 7 rispetterà Compact w Any h ma su iOS 8 rende l'aspetto Compact w Compact h.

Quindi, se desideri utilizzare quelle due classi di dimensioni e mantenere la compatibilità con iOS 7, farei tutte le ottimizzazioni che desideri per l'iPhone in orizzontale in Any w Any h o Compact w Any h, quindi esegui le tue altre ottimizzazioni per classi di dimensioni diverse se necessario e in questo modo non sarà necessario utilizzare alcuna classe di dimensioni con altezza compatta ed evitare di incorrere in problemi.

Quando si distribuisce l'app su iOS 7, Xcode compila lo storyboard in due modi diversi:

• Per iPhone, lo storyboard viene compilato come "Compact-Regular" (larghezza compatta, altezza normale) e questo viene impacchettato come pennino "~ iphone".

• Per iPad, lo storyboard viene compilato come "Regular-Regular" e viene impacchettato come pennino "~ ipad".

Quindi, se stai cercando di distribuire su iOS 7 e iOS 8, dovresti concentrare il tuo design sulle classi di dimensioni Compact-Any e Regular-Any. Ciò fornirà la migliore esperienza in termini di abbinamento dell'interfaccia utente tra le destinazioni di distribuzione. Naturalmente, sei invitato a modificare il layout per altre classi di dimensioni, ma a meno che tali modifiche non vengano applicate alle classi di dimensioni Compact-Regular o Regular-Regular, non vedresti quelle modifiche su iOS 7.

Nota: questa risposta era rilevante per una versione beta di Xcode 6 e non è più applicabile alla versione di spedizione. Vedi le risposte di Joey e Dave DeLong in questa pagina per informazioni corrette.

(risposta originale mantenuta di seguito):

Sebbene Storyboards/XIBsconfigurato per l'utilizzo delle classi di dimensioni iOS 7, il sistema operativo attualmente non li rispetta size classese sembra utilizzare la classe di dimensioni predefinita "Qualsiasi / Qualsiasi".

Sono d'accordo che la particolare diapositiva a cui ti riferisci sembra promettere tale compatibilità, ma al momento non sembra essere il caso (Xcode 6 beta 2).

Per testare, ho creato un progetto (iOS 8 SDK, deployment target of 7.1)con un solo pulsante centrato vertically and horizontallynella classe di dimensioni Qualsiasi / Qualsiasi, ma allineato all'angolo in alto a sinistra nella classe di dimensioni Compatto / Compatto (ad es. IPhone in orizzontale). L'Assistente anteprima di Xcode mostra che il pulsante cambia posizione iOS 8, ma non iOS 7. Ho confermato questo comportamento anche su un iOS 7dispositivo.

Mentre alcune delle risposte e dei commenti discutevano della natura della retrocompatibilità, ho pensato di condividere un estratto direttamente dalla documentazione Apple :

~~~~~

Distribuire un'app con classi di dimensioni su versioni precedenti di iOS

Per le app che supportano versioni di iOS precedenti a iOS 8, la maggior parte delle classi di dimensioni sono retrocompatibili.

Le classi di dimensione sono retrocompatibili quando:

• L'app viene creata utilizzando Xcode versione 6 o successive
• Il target di distribuzione dell'app è precedente a iOS 8
• Le classi di dimensioni sono specificate in uno storyboard o in xib
• Il valore del componente altezza non è compatto

~~~~~

Quest'ultimo punto è mirato a questa discussione, in cui Apple conferma che fintanto che non viene utilizzata "altezza compatta" , dovrebbe mantenere la retrocompatibilità.

Spero che questo aiuti qualcuno!

Mentre affrontavo un problema simile, ho trovato un'altra risposta che non ho ancora visto qui. Sembra che le classi di dimensioni nei XIBfile non funzionino affatto. Se creo un prototipo di cella nel storyboardfile, funziona in iOS7 come spiegato in altre risposte, tuttavia quando la stessa cella di prototipo viene spostata in XIBfile separati, le classi di dimensioni vengono ignorate in iOS7.

Ecco il link al progetto di esempio che dimostra questo comportamento: https://dl.dropboxusercontent.com/u/6402890/testSizeClasses.zip

Nella cella del prototipo ho quattro vincoli da ciascun bordo della vista grigia. Ognuno dei è configurato allo stesso modo: Qualsiasi / Qualsiasi - 10, Regolare / Regolare - 20

Funziona bene nel simulatore iOS8 sia per XIB che per Storyboard e in iOS7 solo le celle definite in Storyboard ottengono vincoli aggiornati su iPad:

Se si risparmia tempo a nessuno, credo che il modo in cui Xcode 6 offra una compatibilità quasi all'indietro per le classi di dimensioni è tramite gli storyboard storici ~ipade con ~iphonesuffisso e nient'altro. Ciò ha senso poiché le classi di dimensioni sono un modo più astratto di come abbiamo precedentemente definito uno storyboard per iPad e uno storyboard per iPhone.

Perciò:

• Se il tuo obiettivo è utilizzare le classi di dimensioni per supportare layout specifici della famiglia di dispositivi (iPad vs. iPhone), allora sei fortunato: le classi di dimensioni sono un'interfaccia migliore del metodo precedentemente supportato.

• Se il tuo obiettivo è utilizzare classi di dimensioni per supportare layout modificati per modelli diversi all'interno della stessa famiglia di dispositivi, ad es. iPhone 5/6/6 + inc. paesaggio, allora sei sfortunato . L'uso di questi richiederebbe un target di distribuzione iOS 8 minimo.

@lducool: in Interface Builder, nella finestra di ispezione Identity, modifica "Builds For" in iOS7.1 e versioni successive.

Sfortunatamente le risposte di Dave e Joey non funzionano per me. Non posso commentare in questa discussione, quindi ti prego di perdonarmi se questo è il posto sbagliato.

Ho formulato una domanda specifica per questo: Esempio di interfaccia utente adattiva per paesaggi verticali per iPhone che è retrocompatibile con iOS 7

Da quello che ho imparato finora, credo ora che, come nel mio esempio, non è possibile avere 2 vincoli separati e diversi per un elemento dell'interfaccia utente in modalità verticale e orizzontale con iPhone iOS7 basato su classi di dimensioni. Sarei felice se mi sbaglio, però.