Nieprawidłowa obsługa Swift - pliki nie są zgodne

Właśnie ponownie napisałem aplikację w Swift 2. Próbuję przesłać aplikację do iTunesConnect (przez Xcode 7 GM) do testów wewnętrznych.

Przez jakiś czas zmagałem się z błędem „Invalid Swift Support” ( który ma inne, powiązane pytania ) ... ale teraz zmieniło się na coś nieco innego.

Błąd od Apple mówi teraz:

Nieprawidłowa pomoc techniczna Swift

Pliki libswiftCoreLocation.dylib, libswiftCoreMedia.dylib, libswiftCoreData.dylib, libswiftAVFoundation.dylib nie pasują

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

Upewnij się, że pliki są poprawne (?), Odbuduj aplikację i prześlij ją ponownie.

Nie stosuj przetwarzania końcowego do

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

Nie udało mi się znaleźć podobnych błędów, wyszukując „Nie stosuj przetwarzania końcowego”, „Upewnij się, że pliki są poprawne, odbuduj aplikację i prześlij ją ponownie” itp.

Czy ktoś wie, jak mogę „Upewnić się, że pliki są poprawne” - lub - ma jakieś inne zalecenia? Dziękuję Ci.

Mam ten sam problem. Myślę, że jest to najprawdopodobniej błąd narzędzi deweloperskich związany z Bitcode.

Właśnie znalazłem obejście tego problemu.

1. Zarchiwizuj swoją aplikację z nowym numerem kompilacji :(
2. Znajdź archiwum (plik .xcarchive) w Finderze z Organizatora „Pokaż w Finderze”
3. Otwórz pakiet i znajdź katalogi takie jak Products/Applications/YourApp.ipa/Frameworks/iSwiftSupport/iphoneos/
4. Skopiuj wszystkie libswiftXxx.dylibpliki z SwiftSupport/iphoneos/do Products/Applications/YourApp.ipa/Frameworks/i nadpisz
5. Teraz prześlij do App Store z Organizatora

Dzięki temu procesowi udało mi się przesłać moją kompilację. Teraz czekam na recenzję.

UWAGA:

Używam CocoaPods, a ENABLE_BITCODEopcja była NIE.

Edycja: wydano CocoaPods 0.39.0 , które rozwiązuje ten problem!

Jak wspomniał @orkenstein , istnieje prostsze rozwiązanie polegające na zakomentowaniu części kodu w Pod-frameworks.sh. Podaję tutaj nieco więcej szczegółów.

W katalogu projektu Xcode otwórz Pods/Target Support Files/Pods/Pods-frameworks.sh

Skomentuj następujące wiersze:

# 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

Zapisz Pods-frameworks.shi powinieneś być gotowy!

Poprawka dotycząca tego problemu została scalona i jest dostępna w najnowszej wersji CocoaPods 0.39.0.beta.5

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

Aby uzyskać najnowszą wersję uruchom CocoaPods gem install cocoapods --pre

Ewentualnie postępuj zgodnie z instrukcjami dotyczącymi uruchamiania niewydanych funkcji: http://guides.cocoapods.org/using/unreleased-features

Gdy będziesz mieć najnowszą wersję CocoaPods, uruchom pod installponownie.

Używałem Fastlane Gym 1.9.0 do budowania mojej aplikacji i Apple ciągle ją odrzucało, ponieważ pliki nie pasowały, podczas gdy jeśli przesłałem przez XCode 8, zostało to zaakceptowane. Sprawdziłem swift libs w folderze swift support w ipa iw folderze Frameworks, stwierdziłem, że biblioteki w folderze swift support były dla swift 2.3, podczas gdy w folderze Frameworks było to szybkie 3. Więc w moim pliku gym dodałem toolchain opcja:

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

* Zauważ, że musiałem zmienić use_legacy_build_api na false, aby użyć opcji toolchain

Aby skorzystać z opcji toolchain, należy ustawić use_legacy_build_api: false https://github.com/fastlane/fastlane/issues/6003#issuecomment-244792185

Jest trochę mniej złożone rozwiązanie, które można znaleźć na GitHub :

Rozejrzałem się po Pods-frameworks.sh i znalazłem sekcję z komentarzem:

Osadzone połączone biblioteki
uruchomieniowe Swift Komentowanie bloku kodu, który kopiuje te biblioteki (i podpisuje je w kodzie) wydaje się rozwiązać moje problemy z przesyłaniem. Nie zagłębiłem się jeszcze głębiej, aby sprawdzić, czy to tylko ich kopiowanie powoduje problemy, czy też jest to podpisywanie kodu. Wychodzę trochę z mojej głębi.

1. Zaktualizuj swoje cocoapody do najnowszej wersji, wpisz sudo gem install cocoapodsterminal.
2. Uruchom pod updatew katalogu twojego projektu.
3. Pamiętaj, aby ustawić Enable Bitcode na NO forDebug opcji dla wszystkich .
4. Naprawiony

Problem został rozwiązany, ponieważ następujący kod w 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

został zmieniony na:

# 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

Moje rozwiązanie na to:

Używam Reveal through Cocoapods i Reveal musi wyłączyć Bitcode. Więc dołączyłem Reveal (powinien działać dla każdego innego Framwork) tylko do debugowania:

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

Ponieważ moje ujawnienie jest teraz skonfigurowane tylko do debugowania, wyłączyłem Bitcode tylko do debugowania.

Z tymi ustawieniami wszystko działa dobrze, bez żadnych hacków ...

Widziałem ten błąd podczas integracji bibliotek, które nie obsługują kodu bitowego (na przykład aktualna stabilna wersja New Relic). Rozwiązaniem jest albo usunięcie bibliotek, wyłączenie kodu bitowego (i potencjalnie niemożność przesłania do sklepu) lub oczekiwanie na zaktualizowane pliki bitcode, które obsługują bitcode od dostawcy biblioteki.

Błąd polegał na tym, że utworzyłem profil Adhoc zamiast profilu App Store w celu przesłania spa do sklepu z aplikacjami.