Supporto Swift non valido: i file non corrispondono

Ho appena riscritto un'app in Swift 2. Sto cercando di caricare l'app su iTunesConnect (tramite Xcode 7 GM) per test interni.

Ho lottato con un errore "Supporto rapido non valido" per un po '( che ha altre domande correlate ) ... ma ora è cambiato in qualcosa di leggermente diverso.

L'errore di Apple ora dice:

Supporto Swift non valido

I file libswiftCoreLocation.dylib, libswiftCoreMedia.dylib, libswiftCoreData.dylib, libswiftAVFoundation.dylib non corrispondono

/Payload/App.app/Frameworks/libswiftCoreLocation.dylib, /Payload/App.app/Frameworks/libswiftCoreMedia.dylib, /Payload/App.app/Frameworks/libswiftCoreData.dylib, /Payload/App.app/Frameworks. dylib

Assicurati che i file siano corretti (?), Ricostruisci la tua app e inviala di nuovo.

Non applicare la post-elaborazione a

/Payload/App.app/Frameworks/libswiftCoreLocation.dylib, /Payload/App.app/Frameworks/libswiftCoreMedia.dylib, /Payload/App.app/Frameworks/libswiftCoreData.dylib, /Payload/App.app/Frameworks. dylib.

Non sono riuscito a trovare errori simili cercando "Non applicare la post-elaborazione", "Assicurati che i file siano corretti, ricostruisci l'app e inviala di nuovo" e così via.

Qualcuno sa come posso "assicurarmi che i file siano corretti" o avere altri consigli? Grazie.

Stesso problema qui. Penso che questo sia molto probabilmente un bug degli Strumenti per sviluppatori, relativo al Bitcode.

Ho appena trovato la soluzione per questo.

1. Archivia la tua app con il nuovo numero di build :(
2. Trova l'archivio (file .xcarchive) nel Finder da Organizer "Mostra nel Finder"
3. Apri il pacchetto e trova directory come Products/Applications/YourApp.ipa/Frameworks/eSwiftSupport/iphoneos/
4. Copia tutti i libswiftXxx.dylibfile da SwiftSupport/iphoneos/in Products/Applications/YourApp.ipa/Frameworks/e sovrascrivi
5. Ora carica su App Store da Organizer

Con questo processo, riesco a caricare la mia build. Ora sto aspettando la revisione.

NOTA:

Sto usando CocoaPods e l' ENABLE_BITCODEopzione era NO.

Modifica: CocoaPods 0.39.0 è stato rilasciato che risolve questo problema!

Come menzionato da @orkenstein , esiste una soluzione più semplice commentando un po 'di codice in Pod-frameworks.sh. Includo un po 'più di dettagli qui.

Nella directory del progetto Xcode, apri Pods/Target Support Files/Pods/Pods-frameworks.sh

Commenta le seguenti righe:

# Embed linked Swift runtime libraries
local basename
basename="$(basename "$1" | sed -E s/\\..+// && exit ${PIPESTATUS[0]})"
local swift_runtime_libs
swift_runtime_libs=$(xcrun otool -LX "${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}/${basename}.framework/${basename}" | grep --color=never @rpath/libswift | sed -E s/@rpath\\/\(.+dylib\).*/\\1/g | uniq -u  && exit ${PIPESTATUS[0]})
for lib in $swift_runtime_libs; do
  echo "rsync -auv \"${SWIFT_STDLIB_PATH}/${lib}\" \"${destination}\""
  rsync -auv "${SWIFT_STDLIB_PATH}/${lib}" "${destination}"
  code_sign_if_enabled "${destination}/${lib}"
done

=>

# Embed linked Swift runtime libraries
# local basename
# basename="$(basename "$1" | sed -E s/\\..+// && exit ${PIPESTATUS[0]})"
# local swift_runtime_libs
# swift_runtime_libs=$(xcrun otool -LX "${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}/${basename}.framework/${basename}" | grep --color=never @rpath/libswift | sed -E s/@rpath\\/\(.+dylib\).*/\\1/g | uniq -u  && exit ${PIPESTATUS[0]})
# for lib in $swift_runtime_libs; do
#   echo "rsync -auv \"${SWIFT_STDLIB_PATH}/${lib}\" \"${destination}\""
#   rsync -auv "${SWIFT_STDLIB_PATH}/${lib}" "${destination}"
#   code_sign_if_enabled "${destination}/${lib}"
# done

Risparmia Pods-frameworks.she dovresti essere pronto per partire!

La correzione per questo problema è stata fusa ed è disponibile nell'ultima versione di CocoaPods 0.39.0.beta.5

https://github.com/CocoaPods/CocoaPods/pull/4268

Per ottenere l'ultima versione di CocoaPods, esegui gem install cocoapods --pre

In alternativa, segui le istruzioni per eseguire funzionalità non rilasciate: http://guides.cocoapods.org/using/unreleased-features

Una volta che hai l'ultima versione di CocoaPods, esegui di pod installnuovo.

Stavo usando fastlane gym 1.9.0 per creare la mia app e continuava a essere rifiutata da Apple perché i file non corrispondevano, mentre se caricavo tramite XCode 8 veniva accettata. Ho controllato le librerie swift nella cartella swift support di ipa e nella cartella Frameworks, ho scoperto che le librerie nella cartella swift support erano per swift 2.3 mentre nella cartella Frameworks era swift 3. Quindi nel mio file gym ho aggiunto la toolchain opzione:

gym(
  scheme: "CoCadre", 
  configuration: "Production Release",
  clean: true,
  use_legacy_build_api: false,
  toolchain: "com.apple.dt.toolchain.Swift_2_3"
)

* Nota che ho dovuto cambiare use_legacy_build_api in false per utilizzare l'opzione toolchain

Per utilizzare l'opzione toolchain, è necessario impostare use_legacy_build_api: false https://github.com/fastlane/fastlane/issues/6003#issuecomment-244792185

C'è una soluzione un po 'meno complessa, trovata su GitHub :

Ho dato un'occhiata in Pods-frameworks.sh e ho trovato una sezione commentata come:

Incorpora le librerie di runtime Swift collegate
Commentando il blocco di codice che copia queste librerie (e il codice le firma) sembra aver risolto i miei problemi di sottomissione. Non mi sono ancora approfondito per vedere se è solo la loro copia a causare i problemi o se è la firma del codice. Sto andando un po 'fuori dalla mia profondità lì.

1. Aggiorna i tuoi cocoapods all'ultima versione, digita il sudo gem install cocoapodsterminale.
2. Esegui pod updatenella directory del tuo progetto.
3. Ricorda di impostare Abilita Bitcode su NO per l' Debugopzione per tutti i tuoi pod.
4. Fisso

Il problema è stato risolto perché il codice seguente in Pods-frameworks.sh:

# Embed linked Swift runtime libraries
local basename
basename="$(basename "$1" | sed -E s/\\..+// && exit ${PIPESTATUS[0]})"
local swift_runtime_libs
swift_runtime_libs=$(xcrun otool -LX "${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}/${basename}.framework/${basename}" | grep --color=never @rpath/libswift | sed -E s/@rpath\\/\(.+dylib\).*/\\1/g | uniq -u  && exit ${PIPESTATUS[0]})
for lib in $swift_runtime_libs; do
  echo "rsync -auv \"${SWIFT_STDLIB_PATH}/${lib}\" \"${destination}\""
  rsync -auv "${SWIFT_STDLIB_PATH}/${lib}" "${destination}"
  code_sign_if_enabled "${destination}/${lib}"
done

è stato modificato in:

# Embed linked Swift runtime libraries. No longer necessary as of Xcode 7.
if [ "${XCODE_VERSION_MAJOR}" -lt 7 ]; then
    local swift_runtime_libs
    swift_runtime_libs=$(xcrun otool -LX "$binary" | grep --color=never @rpath/libswift | sed -E s/@rpath\\/\(.+dylib\).*/\\1/g | uniq -u  && exit ${PIPESTATUS[0]})
  for lib in $swift_runtime_libs; do
    echo "rsync -auv \"${SWIFT_STDLIB_PATH}/${lib}\" \"${destination}\""
    rsync -auv "${SWIFT_STDLIB_PATH}/${lib}" "${destination}"
    code_sign_if_enabled "${destination}/${lib}"
  done
fi

La mia soluzione per questo:

Sto usando Reveal tramite Cocoapods e Reveal deve disabilitare Bitcode. Quindi ho incluso Reveal (dovrebbe funzionare per qualsiasi altro Framwork) solo per Debug:

pod 'Reveal-iOS-SDK', :configurations => ['Debug']

Poiché il mio Reveal è ora configurato solo per Debug, ho disabilitato Bitcode solo per Debug.

Con queste impostazioni tutto funziona bene, senza alcun hack ...

Ho visto questo errore verificarsi durante l'integrazione di librerie che non supportano bitcode (come l'attuale versione stabile di New Relic). La soluzione è rimuovere le librerie, disabilitare il bitcode (e potenzialmente non essere in grado di inviarlo allo store) o attendere i binari aggiornati che supportano il bitcode dal distributore della libreria.

L'errore per me è stato che ho creato con il profilo Adhoc invece del profilo App Store per caricare la spa nell'app store.