search

openbakery / gradle-xcodePlugin

gradle plugin for building Xcode Projects for iOS, watchOS, macOS or tvOS
Apache License 2.0
457 stars 127 forks source link

Can't successfully upload to TestFlight after upgrading to XCode 10.1 #407

Closed wizofaus closed 2 years ago

wizofaus commented 5 years ago

Currently I'm using open-bakery to build and sign the ipa for uploading to TestFlight, which I do separately using altool. It had been working fine with Xcode 9.2 but then we started getting warnings about needing to build with Xcode 10.1 before March, so I made the necessary changes to support that. Now it still uploads fine but then after an unbelievably long wait I get an email from Apple saying

Invalid Swift Support - The files libswiftCoreGraphics.dylib, libswiftCoreMedia.dylib, libswiftDarwin.dylib, libswiftCoreAudio.dylib, libswiftos.dylib, libswiftQuartzCore.dylib, libswiftCoreData.dylib, libswiftContacts.dylib, libswiftFoundation.dylib, libswiftMetal.dylib, libswiftCoreFoundation.dylib, libswiftAVFoundation.dylib, libswiftCoreImage.dylib, libswiftObjectiveC.dylib, libswiftsimd.dylib, libswiftUIKit.dylib, libswiftDispatch.dylib, libswiftCore.dylib don’t match /Payload/PaymentApp.app/Frameworks/libswiftCoreGraphics.dylib, ...

And the app is removed from TestFlight.

I've tried playing around with the "bitcode" and "useXcodebuildArchive" options but to no avail.

When I archive and upload to TestFlight from within Xcode itself it works fine.

I have confirmed in the ipa created by open-bakery that, as suggested, the dylib files in the "SwiftSupport" folder are a (slightly) different size to the ones in the "Payload/xxx.app/Frameworks" folder.

BUT the same is true for the ipa created by XCode (that uploaded successfully) - the difference is that the dylib files under Payload/xxxx.app/Frameworks are actually considerably smaller (about half the size). This is despite the fact I unselected the option to strip symbols etc.

I'm a bit stuck at this point, has anybody done any work ensuring that XCode 10.1 packages can be successfully uploaded to TestFlight?

wizofaus commented 5 years ago

PS.. where is the documentation about how to control the behaviour of the archiving/packaging, specifically wrt app thinning, stripping symbols, building symbol maps etc.?

renep commented 5 years ago

Already fixed this issue with #401 The fix was in the develop version. I have leased this now a few seconds ago in version 0.15.4

wizofaus commented 5 years ago

Great, that fixed that error, unfortunately now I'm getting the error described at https://developer.apple.com/library/archive/qa/qa1964/_index.html, despite the fact I definitely don't have code coverage or llvm instrumentation turned on anywhere.

wizofaus commented 5 years ago

Turned out code coverage is turned on for the scheme for the "Test" command, and apparently this is enough to cause xcodebuild to always have code coverage on when building, unless you specifically run xcodebuild with the "archive" command. Unfortunately we need code coverage for our ci to pass, so I'm having to experiment with how to have it on during debug/testing builds and off for release/package builds.

phatblat commented 5 years ago

@wizofaus Use a separate scheme for release