Apple Watch support completely broken in all versions - ITMS-90398: Invalid WatchKit Support

[ivanicin]

Steps to Reproduce

Build any project that contains a watchOS extension and submit it to the App Store (I have provided the sample but it is just a slightly modified default template so that it can pass other upload tests).

Expected Behavior

This should work.

Actual Behavior

You get an email like this:

Dear Developer,

We identified one or more issues with a recent delivery for your app, "labsiitest" 1.0 (1.0). Please correct the following issues, then upload again.

ITMS-90398: Invalid WatchKit Support - The bundle contains an invalid implementation of WatchKit. The app may have been built or signed with non-compliant or pre-release tools. Visit developer.apple.com for more information.

Best regards,

The App Store Team

Environment

Version information

Visual Studio Community 2022 for Mac
Version 17.3.4 (build 4)
Installation UUID: dec5c782-26e3-4e09-9017-2e6a936b7e2e

Runtime
.NET 6.0.5 (64-bit)
Architecture: X64

Roslyn (Language Service)
4.3.0-3.22312.2+52adfb8b2dc71ed4278debcf13960f2116868608

NuGet
Version: 6.2.1.2

.NET SDK (x64)
SDK: /usr/local/share/dotnet/sdk/6.0.400/Sdks
SDK Versions:
	6.0.400
	6.0.302
	6.0.301
	5.0.408
	5.0.407
	5.0.406
	5.0.405
	5.0.404
	5.0.403
	5.0.402
	5.0.401
	5.0.400
	5.0.302
	5.0.301
	5.0.203
	5.0.202
	5.0.201
	5.0.103
	5.0.102
	5.0.101
	5.0.100
	3.1.423
	3.1.422
	3.1.421
	3.1.420
	3.1.419
	3.1.418
	3.1.417
	3.1.416
	3.1.415
	3.1.414
	3.1.413
	3.1.412
	3.1.411
	3.1.410
	3.1.409
	3.1.408
	3.1.407
	3.1.406
	3.1.405
	3.1.404
	3.1.403
	3.1.402
	3.1.401
	3.1.302
	3.1.301
	3.1.300
	3.1.202
	3.1.200
	3.1.102
	3.1.101
	3.1.100
	3.0.101
	3.0.100
	2.1.701
	2.1.700
MSBuild SDKs: /Applications/Visual Studio.app/Contents/MonoBundle/MSBuild/Current/bin/Sdks

.NET Runtime (x64)
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	6.0.8
	6.0.7
	6.0.6
	5.0.17
	5.0.16
	5.0.15
	5.0.14
	5.0.13
	5.0.12
	5.0.11
	5.0.10
	5.0.9
	5.0.8
	5.0.7
	5.0.6
	5.0.5
	5.0.4
	5.0.3
	5.0.2
	5.0.1
	5.0.0
	3.1.29
	3.1.28
	3.1.27
	3.1.26
	3.1.25
	3.1.24
	3.1.23
	3.1.22
	3.1.21
	3.1.20
	3.1.19
	3.1.18
	3.1.17
	3.1.16
	3.1.15
	3.1.14
	3.1.13
	3.1.12
	3.1.11
	3.1.10
	3.1.9
	3.1.8
	3.1.7
	3.1.6
	3.1.5
	3.1.4
	3.1.2
	3.1.1
	3.1.0
	3.0.1
	3.0.0
	2.1.23
	2.1.22
	2.1.21
	2.1.20
	2.1.19
	2.1.18
	2.1.17
	2.1.16
	2.1.15
	2.1.14
	2.1.13
	2.1.12
	2.1.11

Xamarin.Profiler
Version: 1.8.0.19
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

Updater
Version: 11

Apple Developer Tools
Xcode 14.0 (21335)
Build 14A309

Xamarin.Mac
Version: 8.12.0.2 (Visual Studio Community)
Hash: 87f98a75e
Branch: d17-3
Build date: 2022-07-25 20:18:54-0400

Xamarin.iOS
Version: 16.0.0.72 (Visual Studio Community)
Hash: 6756a1146
Branch: release/6.0.4xx-xcode14
Build date: 2022-09-21 08:51:06-0400

Xamarin Designer
Version: 17.3.0.208
Hash: 0de472ea0
Branch: remotes/origin/d17-3
Build date: 2022-09-01 17:18:13 UTC

Xamarin.Android
Version: 13.0.0.0 (Visual Studio Community)
Commit: xamarin-android/d17-3/030cd63
Android SDK: /Users/ivanicin/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		12.0 (API level 31)
		11.0 (API level 30)
		10.0 (API level 29)
		9.0  (API level 28)

SDK Command-line Tools Version: 7.0
SDK Platform Tools Version: 33.0.2
SDK Build Tools Version: 33.0.0

Build Information: 
Mono: dffa5ab
Java.Interop: xamarin/java.interop/d17-3@7716ae53
SQLite: xamarin/sqlite/3.38.5@df4deab
Xamarin.Android Tools: xamarin/xamarin-android-tools/main@14076a6

Microsoft Build of OpenJDK
Java SDK: /Library/Java/JavaVirtualMachines/microsoft-11.jdk
11.0.12
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Eclipse Temurin JDK
Java SDK: /Library/Java/JavaVirtualMachines/temurin-8.jdk
1.8.0.302
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Android SDK Manager
Version: 17.3.0.23
Hash: 965bf40
Branch: remotes/origin/d17-3
Build date: 2022-09-01 17:18:18 UTC

Android Device Manager
Version: 0.0.0.1169
Hash: fafb1d5
Branch: fafb1d5
Build date: 2022-09-01 17:18:18 UTC

Build Information
Release ID: 1703040004
Git revision: 5ec72d3a5e7c84e88be448c0ff9e58839e0913e9
Build date: 2022-09-01 17:16:20+00
Build branch: release-17.3
Build lane: release-17.3

Operating System
Mac OS X 12.6.0
Darwin 21.6.0 Darwin Kernel Version 21.6.0
    Mon Aug 22 20:17:10 PDT 2022
    root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64

Build Logs

Log.txt

Example Project (If Possible)

WatchTest.zip

[ivanicin]

Just to note that creating a new project in Xcode and submitting the .ipa file from it works.

I am not sure how much it is relevant, but I have noted that in Xcode now you have only the App project, there is no more an extension project.

[ivanicin]

This was added as suggested here: #15954 (comment)

[ivanicin]

One thing that I have tried but didn't help - targeting watchOS 9.0 and submitting only 64-bit binary.

[ivanicin]

My best guess is that this issue explains also why this is happening: #16142 (comment)

It points out that WatchkitStub is not used anymore in Xcode while Xamarin seems to use it (which likely causes this issue) and expects it (which caused that issue).

[ivanicin]

I have further tried to build this with XCode 13 and Xamarin.iOS 15.12.0.2 and the issue still appears. So this isn't Xcode 14 issue at all!!!!

[ivanicin]

@dalexsoto I would appreciate if you could be more precise on what this means:

Looks like we will need to have a deeper look at this.

At the moment WatchKit support is completely broken including with Xcode 13 and Xamarin iOS 15.12.0.2 as you can't submit any app to the store. It seems that you can't even submit the watch extension built in Xcode according to another issue.

Unfortunately I am aware that your current level of quality allows to keep issues like this open (e.g. take a very deep look) for years (see: #10911 ), so I would like some sort of feedback if this is coming in a few weeks or it is better idea to say goodbye to watchOS on Xamarin and see what are my options....?

[ivanicin]

After some more check, I can confirm that I was previously able to successfully build for the App Store using those identical tools. Which means either Apple changed something server side in the last two weeks or Visual Studio itself broke the process (if that is possible).

[ivanicin]

The last test that I had in mind was checking whether Xcode 13 works as expected with a new project, and it works properly. I am just trying to narrow down the cause if someone at some points decides to take a look at this...

[mjo151]

I am experiencing the same issue. After building my app With VS 17.3.6 and Xcode 14 and uploading to AppStore Connect, the binary was rejected and I received an email from Apple with this error:

ITMS-90398: Invalid WatchKit Support - The bundle contains an invalid implementation of WatchKit. The app may have been built or signed with non-compliant or pre-release tools. Visit developer.apple.com for more information.

[juliososa04]

I have same issue XCode 14.0.1 Xamario IOs 16.0.0.75. ITMS-90398: Invalid WatchKit Support - The bundle contains an invalid implementation of WatchKit. The app may have been built or signed with non-compliant or pre-release tools. Visit developer.apple.com for more information. after traying to upload to TestFlight , in visual studio 2022 mac and from windows as well any updated on this?

[fireup]

We are having the same issue. We are NOT using Xamarin.

[ivanicin]

Searching some more this is the official answer from Apple on why this is happening and what should be done:

https://developer.apple.com/forums/thread/714224

Please note that if you're manually copying the "WK" stub from the SDK via a custom .ipa assembly process, you'll need to manually remove the arm64e slice from that binary using the lipo tool. Otherwise, using the standard Xcode Archive action will do this for you automatically.

@dalexsoto is this the reason why this fails on Xamarin?

[ivanicin]

@chamons I apologise for tagging you without your direct relation to this issue, but I feel that something is wrong here and you were always helpful in such situations.

At the moment this is the bug that completely blocks range of developers from releasing the app for at least 3 weeks, there is no workaround and there is the official Apple's answer on why this is happening which could likely lead to fairly quick fix and still there is no activity here. My personal guess is that it is just lack of awareness of the situation due to many ongoing activities now and fairly small number of people that cover it, but that is just my guess.

Any help or at least some message would be highly appreciated.

[ivanicin]

As I have reported this I am closing - it is not fixed but I don't expect it to be fixed.

One thing is clear - Apple will require you to use SwiftUI to build watchOS apps (you can't create any other new projects in Xcode 14), so in couple of years Xamarin won't be able to support watchOS and if you want to support it you will have to rewrite the app. And I guess it is better to start to do it now.

And it is even said that watchOS won't be available in .NET 6, so that's another reason why you will have to rewrite. Yes it would be better if they supported it properly and you wouldn't have to rush, but I guess you can read the message and something that is in dating called 'ghosting' - Microsoft is not brave enough to tell us the truth that they want us to get away from this as quickly as possible.

[hgyang107]

We have the same issue. We now have to remove the WatchOS support in order to submit our app. @dalexsoto

[jahmai-ca]

@ivanicin Can you please reopen this issue? I realise you no longer care about it but it affects other MS/Xamarin customers and this issue is being referenced by Microsoft support: https://learn.microsoft.com/en-us/answers/questions/1049349/tms-90398-invalid-watchkit-support-the-bundle-cont.html

[ivanicin]

@ivanicin Can you please reopen this issue? I realise you no longer care about it but it affects other MS/Xamarin customers and this issue is being referenced by Microsoft support: https://learn.microsoft.com/en-us/answers/questions/1049349/tms-90398-invalid-watchkit-support-the-bundle-cont.html

@jahmai-ca my resolution to close the issue came from the fact that everything points out that it won't be fixed. The issues that won't be fixed should be closed, that is actually a useful information for developers to give up on it and search for alternatives.

At least one Microsoft representative was subscribed to this issue and I think that the wording was very clear. He hasn't reopened the issue.

As said it is very unfortunate that Microsoft's employees don't have the right to say that this won't be fixed as such a decision is not announced, but in reality it is already in effect. On the other hand I think that they won't reopen this unless they have someone to assign to this task, that would be dishonest considering whole the conversation. And they don't. So keeping this close is helpful for everyone, it is better to know the truth than to live in some fairytale that this might get fixed one day.

If you wish you can tag Alex Soto (I have tagged him multiple times and he answers on other issues but not on this), David Ortineaux and Rolf Bjarne to be sure that they are informed, after that I don't see any point in doing anything but to give up.

[fireup]

Not sure if this would help but I've got a solution, as described in another thread.

I finally got this fixed and build was accepted by TestFlight. Turned out it's the VALID_ARCHS settings. If I remember correctly it was carried over from Xcode 11 to 12, that the VALID_ARCHS in Build Settings ended up under User_Defined. All I needed to do was to change this setting to $(ARCHS_STANDARD) in both WatchApp and Watch Extension.
Before the change I couldn't even build it onto Watch Simulator, showing the error in Xcode console: WatchKit 1 apps aren't supported on this version of watchOS. Quitting "(null)". This was fixed as well.

[hgyang107]

Cannot find such setting $(ARCHS_STANDARD) in Visual Studio for Mac.

[jahmai-ca]

Not sure if this would help but I've got a solution, as described in another thread.

I finally got this fixed and build was accepted by TestFlight. Turned out it's the VALID_ARCHS settings. If I remember correctly it was carried over from Xcode 11 to 12, that the VALID_ARCHS in Build Settings ended up under User_Defined. All I needed to do was to change this setting to $(ARCHS_STANDARD) in both WatchApp and Watch Extension. Before the change I couldn't even build it onto Watch Simulator, showing the error in Xcode console: WatchKit 1 apps aren't supported on this version of watchOS. Quitting "(null)". This was fixed as well.

That's great but how do we do this workaround for Xamarin applications?

[jahmai-ca]

@ivanicin Can you please reopen this issue? I realise you no longer care about it but it affects other MS/Xamarin customers and this issue is being referenced by Microsoft support: https://learn.microsoft.com/en-us/answers/questions/1049349/tms-90398-invalid-watchkit-support-the-bundle-cont.html

@jahmai-ca my resolution to close the issue came from the fact that everything points out that it won't be fixed. The issues that won't be fixed should be closed, that is actually a useful information for developers to give up on it and search for alternatives.

At least one Microsoft representative was subscribed to this issue and I think that the wording was very clear. He hasn't reopened the issue.

As said it is very unfortunate that Microsoft's employees don't have the right to say that this won't be fixed as such a decision is not announced, but in reality it is already in effect. On the other hand I think that they won't reopen this unless they have someone to assign to this task, that would be dishonest considering whole the conversation. And they don't. So keeping this close is helpful for everyone, it is better to know the truth than to live in some fairytale that this might get fixed one day.

If you wish you can tag Alex Soto (I have tagged him multiple times and he answers on other issues but not on this), David Ortineaux and Rolf Bjarne to be sure that they are informed, after that I don't see any point in doing anything but to give up.

IMO it's up to Microsoft to close issues they don't want to fix. But anyway I'm not going to try to convince you, so I just created a clone of this issue #16499 - hope you don't mind.

[ivanicin]

That's great but how do we do this workaround for Xamarin applications?

Even if you could it is not useful as he had the problem because he wanted to use app format that was available only in watchOS 1.0, that is not our problem.

[ivanicin]

IMO it's up to Microsoft to close issues they don't want to fix. But anyway I'm not going to try to convince you, so I just created a clone of this issue #16499 - hope you don't mind.

Not a problem :). I hope you'll be of better luck than what I was...