Xamarin-macios: [watchOS,Xcode10]Appstore upload fails with an error "Binary uploaded is invalid"

[GouriKumari]

Steps to Reproduce

1. Install XI, Xamarin.iOS
   Version: 12.0.0.10 (Visual Studio Enterprise)
2. Install Xcode10 GM
3. Build and Archive https://github.com/xamarin/SubmissionSamples/tree/master/WatchOS
4. Upload .ipa to AppStore

Expected Behavior

.ipa should upload successfully

Actual Behavior

Fails to upload with an error, "binary uploaded is invalid"

Environment

https://gist.github.com/GouriKumari/ae499cc374c46bf05e47b47474af962a

Build Logs

Log: https://gist.github.com/GouriKumari/fe878d0876c22f84974de05d2f226021
Link to .ipa: https://www.dropbox.com/s/khzz35q4u6ew5bh/MainApp.ipa?dl=0

Example Project (If Possible)

https://github.com/xamarin/SubmissionSamples/tree/master/WatchOS

Additional Data:

This was working with Xcode10-beta6, https://devdiv.visualstudio.com/DevDiv/_releaseProgress?releaseId=155634&_a=release-environment-extension&environmentId=559110&extensionId=ms.vss-test-web.test-result-in-release-environment-editor-tab.
Tested with: Xamarin.iOS 11.99.3.605:
Xcode10-beta6

[spouliot]

https://forums.developer.apple.com/thread/108405
https://forums.developer.apple.com/thread/108426

@GouriKumari seems many people hit the same issue - but the last comment said it was now working. Can you try again ?

[GouriKumari]

I checked it now and the bot also executed the tests and got the same error.

Screenshot:

https://screencast.com/t/c3whTWg4mV

[rolfbjarne]

I can reproduce this when submitting the WatchKitCatalog sample built with our xcode10 branch and using Xcode 10 GM.

I can't reproduce it:

1. When building and submitting an Xcode project with Xcode 10 GM.
2. When building and submitting the WatchKitCatalog sample built with our xcode10 branch and using Xcode 9.4.
3. When building and submitting the WatchKitCatalog sample built with our xcode10 branch, using Xcode 10 GM, and replacing the watch extension executable with the one from the Xcode project in point 1.

So it seems Apple is requiring arm64_32 in watch extensions when the app is built with Xcode 10.

[rolfbjarne]

The App Store is using the DTPlatformVersion key in the watch app extension's Info.plist to determine whether to check for an arm64_32 slice or not. If DTPlatformVersion == '5.0', an arm64_32 slice is required, otherwise it's not.

Workaround: edit the corresponding Info.plist so that it claims it was built with Xcode 9.4

This can be automated in the project file, here's an example for the WatchKitCatalog sample:

diff --git a/watchOS/WatchKitCatalog/WatchKit3Extension/WatchKit3Extension.csproj b/watchOS/WatchKitCatalog/WatchKit3Extension/WatchKit3Extension.csproj
index d93d4ea6..d5fe3488 100644
--- a/watchOS/WatchKitCatalog/WatchKit3Extension/WatchKit3Extension.csproj
+++ b/watchOS/WatchKitCatalog/WatchKit3Extension/WatchKit3Extension.csproj
@@ -177,4 +177,12 @@
     <ImageAsset Include="Resources\Images.xcassets\Whale.imageset\Contents.json" />
     <ImageAsset Include="Resources\Images.xcassets\Whale.imageset\Whale%402x.png" />
   </ItemGroup>
+  <Target Name="BeforeCodeSign">
+    <Exec Command="/usr/libexec/PlistBuddy -c 'Set :DTPlatformBuild 15T212' $(_AppBundlePath)Info.plist" />
+    <Exec Command="/usr/libexec/PlistBuddy -c 'Set :DTPlatformVersion 4.3'  $(_AppBundlePath)Info.plist" />
+    <Exec Command="/usr/libexec/PlistBuddy -c 'Set :DTSDKBuild 15T212'      $(_AppBundlePath)Info.plist" />
+    <Exec Command="/usr/libexec/PlistBuddy -c 'Set :DTSDKName watchos4.3'   $(_AppBundlePath)Info.plist" />
+    <Exec Command="/usr/libexec/PlistBuddy -c 'Set :DTXcode 0940'           $(_AppBundlePath)Info.plist" />
+    <Exec Command="/usr/libexec/PlistBuddy -c 'Set :DTXcodeBuild 9F1027a'   $(_AppBundlePath)Info.plist" />
+  </Target>
 </Project>

This workaround is only required for the watch app extension, neither the iOS app nor the watch app have to be modified.

[spouliot]

Nice investigation :)
We'll add it to the release notes as a workaround

[t9mike]

I am running into this issue. The BeforeCodeSign project fix had no effect. I did a clean and re-build. One try I used Sign and Distribute. I inspected IPA and found standard entries for the properties listed. I then tried via Build->Archive (what I usually use) and also so no effect of the plist fix. For both looking in equivalent of Products/Applications/SundialPhoneApp.app/Watch/SundialWatchApp.app/PlugIns/SundialWatchAppExtension.appex/Info.plist.

    DTCompiler = "com.apple.compilers.llvm.clang.1_0";
    DTPlatformBuild = "16R363";
    DTPlatformName = "watchos";
    DTPlatformVersion = "5.0";
    DTSDKBuild = "16R363";
    DTSDKName = "watchos5.0";
    DTXcode = "1000";
    DTXcodeBuild = "10A254a";

I am not an Apple native developer. I don't know how to edit the plist in my source area manually. I tried cobbling together a script.

/usr/libexec/PlistBuddy -c 'Add :DTPlatformBuild 15T212' Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTPlatformVersion 4.3' Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTSDKBuild 15T212'     Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTSDKName watchos4.3' Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTXcode 0940'        Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTXcodeBuild 9F1027a' Info.plist

I get:

Unrecognized Type: 15T212
Unrecognized Type: 4.3
Unrecognized Type: 15T212
Unrecognized Type: watchos4.3
Unrecognized Type: 0940
Unrecognized Type: 9F1027aInfo.plist

Can I get help getting this working? I am trying to submit my app for review so it will run on Series 4 watches + updates for new phones. I received a call from Apple on September 10 stating that I would need to re-submit my watch app, and this must be the issue.

@GouriKumari, have you been able to submit your app/binary to store?

[t9mike]

Note before I found this issue I had opened up issue via VS for Mac: https://developercommunity.visualstudio.com/content/problem/338715/apple-watch-bitcode-may-be-broken.html.

[rolfbjarne]

@t9mike Can you try executing the following from a terminal window and see if it changes the Info.plist as expected?

/usr/libexec/PlistBuddy -c 'Set :DTPlatformBuild 15T212' Info.plist
/usr/libexec/PlistBuddy -c 'Set :DTPlatformVersion 4.3'  Info.plist
/usr/libexec/PlistBuddy -c 'Set :DTSDKBuild 15T212'      Info.plist
/usr/libexec/PlistBuddy -c 'Set :DTSDKName watchos4.3'   Info.plist
/usr/libexec/PlistBuddy -c 'Set :DTXcode 0940'           Info.plist
/usr/libexec/PlistBuddy -c 'Set :DTXcodeBuild 9F1027a'   Info.plist

[t9mike]

@rolfbjarne it does not because these keys do not exist in the source code version of the plist. I get:

Set: Entry, ":DTXcodeBuild", Does Not Exist

And similar.

That is why I tried add mode. But I was awfully lazy+tired and did not do this correctly. I just tried:

/usr/libexec/PlistBuddy -c 'Add :DTPlatformBuild string "15T212"' Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTPlatformVersion string "4.3"' Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTSDKBuild string "15T212"' Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTSDKName string "watchos4.3"' Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTXcode string "0940"' Info.plist
/usr/libexec/PlistBuddy -c 'Add :DTXcodeBuild string "9F1027a"' Info.plist

This worked. The new archive passed the validation step. I've uploaded it to App store. Been processing for 22 minutes and counting. I'll report back.

The PlistBuddy Import mode w/ small file _might_ be the best way to provide bullet proof steps for fix.

[t9mike]

App finished processing and I was able to install via TestFlight. Yeah!

[rolfbjarne]

@t9mike OK, so something went wrong with the BeforeCodeSign target I create above in your project. If your solution works fine for you, there's no need to try to make mine work in your project, yours is just as good (it's just a workaround anyway).

[t9mike]

Off topic @rolfbjarne, but are you aware of any Today Widget issues w/ latest Xcode / Xamarin? My today widget inexplicably will not run anymore. Fine on iOS12 simulator. Old app store version OK on my iOS12 devices. But new builds from Xamarin fail on devices: debug builds uploaded via USB or TestFlight.

[t9mike]

My Today Widget issue was two fold:

1) With latest Xamarin/Xcode my SVGKit binding now required --optimize=-remove-dynamic-registrar option. I had added to my phone project but not the today extension project

2) After fixing this -- and deleting app and restarting phone to get around the "Can't request remote view controller that is blacklisted" issue -- I hit what seems to be a genuine Xamarin bug. I was running in Debug mode and had "Enable profiling" checked. I saw this in the log output:

dyld: Library not loaded: @rpath/libmono-profiler-log.dylib
  Referenced from: /private/var/containers/Bundle/Application/F52BC588-976C-43EE-8024-E701F29AC758/SundialPhoneApp.app/PlugIns/SundialTodayExtension.appex/SundialTodayExtension
  Reason: image not found
dyld: Library not loaded: @rpath/libmono-profiler-log.dylib
  Referenced from: /private/var/containers/Bundle/Application/F52BC588-976C-43EE-8024-E701F29AC758/SundialPhoneApp.app/PlugIns/SundialTodayExtension.appex/SundialTodayExtension
  Reason: image not found

Unchecking "Enable profiling" fixed the issue.

[rolfbjarne]

@t9mike

1. With latest Xamarin/Xcode my SVGKit binding now required --optimize=-remove-dynamic-registrar option. I had added to my phone project but not the today extension project

Why do you need to use this flag? Is this as a workaround to an issue already reported here?

1. After fixing this -- and deleting app and restarting phone to get around the "Can't request remote view controller that is blacklisted" issue -- I hit what seems to be a genuine Xamarin bug. I was running in Debug mode and had "Enable profiling" checked.

This is a bug in Xamarin.iOS. I can reproduce, and I've filed #4846 for it (it only occurs if profiling is enabled for the extension, but not for the container app).

[ramyzbeidy]

i can validate that @rolfbjarne workaround worked for me.

[t9mike]

1. With latest Xamarin/Xcode my SVGKit binding now required --optimize=-remove-dynamic-registrar option. I had added to my phone project but not the today extension project

Why do you need to use this flag? Is this as a workaround to an issue already reported here?

With latest Xamarin I started seeing ObjCRuntime.RuntimeException: Can't register the class XXX when the dynamic registrar has been linked away

Googling found this:

https://help.frozenmountain.com/docs/icelink3/faq/ios-and-macos-questions/i-am-getting-an-error-in-xamarin-re-dynamic-registrar-how-do-i-fix-this

Problem solved so I moved on.

Thanks for investigating/creating ticket for extension issue.

[rolfbjarne]

1. With latest Xamarin/Xcode my SVGKit binding now required --optimize=-remove-dynamic-registrar option. I had added to my phone project but not the today extension project

Why do you need to use this flag? Is this as a workaround to an issue already reported here?

With latest Xamarin I started seeing ObjCRuntime.RuntimeException: Can't register the class XXX when the dynamic registrar has been linked away

Googling found this:

https://help.frozenmountain.com/docs/icelink3/faq/ios-and-macos-questions/i-am-getting-an-error-in-xamarin-re-dynamic-registrar-how-do-i-fix-this

Problem solved so I moved on.

I'm interesting in looking into this and trying to find a solution that doesn't involve keeping the dynamic registrar, so would it be possible to get access to your project so that I could have a look?

[t9mike]

I'm interesting in looking into this and trying to find a solution that doesn't involve keeping the dynamic registrar, so would it be possible to get access to your project so that I could have a look?

I will create a sample for you @rolfbjarne.

Q: what is ETA for real fix for watchOS issue? I won't be able to submit new Series 4 complications to the App Store until resolved as work around is to target watchOS 4.3. That really goes for any new watchOS 5 API.

[t9mike]

Can I do anything to test against a Series 4 watch? I reverted my Info.plist back to standard so I could develop my new Series 4 complications on simulator (required watchOS 5 APIs). When run on Series 4, I get from watch Debug session:

IncorrectArchitecture: Failed to find matching arch for 32-bit Mach-O input file /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.oxMEnz/extracted/SundialWatchApp.app/PlugIns/SundialWatchAppExtension.appex/SundialWatchAppExtension
error MT1006: Could not install the application '/Users/XXX/Git/Main2/Projects/SundialWatchApp/App/PhoneApp/bin/iPhone/Debug/device-builds/iphone11.6-12.0/SundialPhoneApp.app' on the device 'Mike's Phone': AMDeviceSecureInstallApplicationBundle returned: 0xe8000087 (kAMDIncorrectArchitectureError).

[rolfbjarne]

Can I do anything to test against a Series 4 watch?

We just ran into this ourselves and filed #4864. This came as a surprise to us as well, so we don't know when there will be a fix/workaround available.

[rolfbjarne]

Q: what is ETA for real fix for watchOS issue? I won't be able to submit new Series 4 complications to the App Store until resolved as work around is to target watchOS 4.3. That really goes for any new watchOS 5 API.

No ETA yet, we haven't had much time to look at it.

However, the workaround is to _fake_ using the watchOS 4.3 SDK (you use the watchOS 5.0 SDK and then change the Info.plist to make it look like you used the 4.3 SDK), so it _might_ still be possible to use the watchOS 5 APIs (it depends on whether the App Store has consistency checks or not when you upload your app).

[t9mike]

However, the workaround is to _fake_ using the watchOS 4.3 SDK (you use the watchOS 5.0 SDK and then change the Info.plist to make it look like you used the 4.3 SDK), so it _might_ still be possible to use the watchOS 5 APIs (it depends on whether the App Store has consistency checks or not when you upload your app).

I was having compilation issues w/ VS.NET not seeing the 5.0 interfaces and enum values when I was using the edited plist. So I had switched back to standard plist. Tonight I reverted back and I could both compile and submit my app to app store. Not sure what was going on earlier.

I installed via TestFlight and see my Series 4 only complication (using CLKComplicationTemplateGraphicCircularImage and CLKFullColorImageProvider).

A very laborious way to test on real device, however, due to https://github.com/xamarin/xamarin-macios/issues/4864.

[rolfbjarne]

Closing since this was fixed in the d15-9 and xcode10.1 branches.

[mykyta-bondarenko]

@rolfbjarne could we merge it into the master too?

[Dids]

Is the fix available for VS4Mac (stable) yet? The workaround is no longer working, and I'm seeing the same error on iTunes Connect when submitting my binary: Your binary doesn’t support Apple Watch. The screenshots for Apple Watch won’t be shown on the App Store.

[rolfbjarne]

@Dids this has been available for a while. If you're having issues with iTunes Connect, it most likely has a different cause, so please file a new issue about it.