Resolved Apparently, one must purchase the subscription first - then the Offer Code works as intended. I don't recall seeing that in the docs anywhere. Sorry to waste time.

Apparently I was premature as the app got rejected once again for the very same reason. The circumstances are the same. I sent a support request with case #: 102365830295 I have no way to change the app review environment. The subscription is unavailable ONLY in the app review environment. Is there ANYTHING I can do to resolve this?

Disregard.

Hey - thanks for your reply. Yes, I followed that guide and the code seems to work. That guide does not answer the question of how to go about testing the functionality. Specifically: How do I create a mock/test "purchased product" that I can use to test "if the product as been purchased". You see, I don't have a "purchased product" on my watch that I can validate as being purchased. XCode loads the app onto the watch for debugging. So the AppTransaction reports a originalPurchaseDate of 1970-01-01. As in, never purchased. In order to validate that a product has been purchased, I need to test originalPurchaseDate against Data.now in a test environment. How do I accomplish that?

The description for NWPathMonitor: An observer that you use to monitor and react to network changes. That's all I'm asking for. Why is it that not a single Apple engineer will answer the following question: "Why is NWPathMonitor unavailable on watchOS?" I've reviewed many, many, many posts/comments/threads on this topic dating back years. The Apple response falls into the general category of "won't do what you expect" or similar condescending retorts. I've yet to find a reasonable technical response as to why. TN3135 addresses the general idea of "Low Level Networking". So it seems the approach is the ban EVERYTHING in the API regardless of whether it actually involves "Low Level Networking" or not. Can someone please provide a reasonable and non-condesending explanation of why exposing: An observer that you use to monitor and react to network changes. would be catastrophic for the watchOS platform?

Sure, but I’m not sure that I need consultation. I believe I know how to solve my use case in the “restricted” way. What I was hoping is that this would get up channeled to a decision maker who could effect this change.

Forgive me, but I was unaware of having a lab appointment today. What am I missing?

@Frameworks Engineer et. al. The fix was to increase the WatchOS and IOS versions to their latest versions in Xcode. For anyone else seeing this issue - specifically, and nondescript rejection message on App Store Connect that states: We were unable to install the app on Apple Watch. The UIRequiredDeviceCapabilities key i> n the Info.plist is set in such a way that the app will not install on Apple Watch . It is very possible this doesn't have anything to do with UIRequiredDeviceCapabilities.

FYI - "Autonomous Watch App" is from the Apple documentation.

@Frameworks Engineer - I just confirmed that the Info.plist in my app is exactly the same as the template watch only Info.plist of an archived template app. The only differences are the obvious app name and app version numbers.

@Frameworks Engineer - Awesome...thanks for sticking in there with me. In Xcode - Target/Info - "App is only available as a standalone watchOS app" is set to YES, and there is no IOS companion. Expanding the app archive's package and then the application package contents, the info.plist does not contain a WKWatchOnly key at all. Is that where that key should reside? If so, shouldn't Xcode automatically insert the key based upon the info settings in the image? I am 99.9% certain the only difference between this project and the default WatchOS only app template is the inclusion of a complication extension in my app.