2015-07-03 32 views
6

Ho un codice singolo che deve essere compatibile con Xcode 7 beta e Xcode 6.4. Questo perché i test beta e le build di App Store dovrebbero essere costruiti con la versione stabile del compilatore e dell'SDK, ma ho anche iOS 9 beta su un telefono che uso per i test.Esiste un #ifdef per distinguere tra Xcode 6.4 e Xcode 7 beta in Swift?

Questo non è stato un problema con Objective-C, ma ora che sto aggiungendo un po 'di Swift, trovo difficile mantenere la compatibilità con entrambe le versioni di Xcode.

Cosa posso fare?

So che Swift ha una direttiva #ifdef, ma ci sono #ifdefs che possono distinguere tra Swift 1.2 e 2.0? Non riesco a trovare un elenco di quelli validi per Swift eccetto DEBUG, os e arch.

Ecco un esempio di ciò che intendo:

#ifdef __IPHONE_9_0 
    some Swift code that works in Swift 2.0 but won't compile in Swift 1.2 
#else 
    some Swift code that works in Swift 1.2 but won't compile in Swift 2.0 
#endif 

O un esempio più concreto:

public final class MessageParser : NSObject { 

    #ifdef __IPHONE_9_0 
    static let sharedHashtagRegex = try! NSRegularExpression(pattern:"(^|\\W)(#|\\uFF03)(\\w*\\p{L}\\w*)", options:[]); 
    #else 
    static let sharedHashtagRegex = NSRegularExpression(pattern:"(^|\\W)(#|\\uFF03)(\\w*\\p{L}\\w*)", options:nil, error:nil)! 
    #endif 

    // ... 
} 
+1

"Ho un codice singolo che deve essere compatibile con Xcode 7 beta e Xcode 6.4" Non lo sarà. Dimenticalo. Queste sono due versioni completamente diverse di Swift (e dell'API Cocoa); non è possibile scrivere codice Swift che funzioni per entrambi. – matt

risposta

2

no, come Swift impone tutto "definire" percorso deve compilare. scusate ma i vecchi bei tempi di #ifdef sono spariti

1

Il problema non è così raro. Lo vediamo ogni volta quando siamo nel bel mezzo di un pesante refactoring del codice. Cosa sai fare? Utilizza un sistema di controllo delle versioni, ad es. idiota.

Con git:

Swift 1.2 (Xcode 6.4) - mantenere il vecchio codice a vostra master filiale

Swift 2.0 (Xcode 7.0) - mettere il codice migrato ad un nuovo ramo, ad esempio, features/swift20.

Ora, per un po 'dovrai mantenere due rami ma non dovrebbe essere difficile. È possibile aggiungere le modifiche a master e quindi unirle a features/swift20, risolvendo tutte le collisioni/migrazioni durante l'unione.

Quando esce Xcode 9 GM, è sufficiente unire features/swift20 in master perché non occorrerà più Swift 1.2.

Problemi correlati