Why is this API not available on iOS? We can use ethernet interfaces with iOS.
DrMickeyLauer
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
From
Neu-Isenburg, Germany
Post
Replies
Boosts
Views
Activity
The answer in this case is plist keys. Here's the deal: While the old location APIs with CLLocationManager had runtime assertions for checking the required NSLocation{xyz}UsageDescription keys – thus crashing, if they were not present – the new APIs just silently ignore missing usage descriptions.
Please consider the case closed – other than considering better diagnostics for this case as a feature request.
9 years later and it's still a problem.
The problem was a corrupted empty project created by Xcode. It did NOT include the necessary iOS stub target (which seems to be important for deployment, even for a watch-only watchOS app).
With another Xcode version this worked.
Even 9 years after this doesn't seem to be available.
Same problem… ridiculous state of the tools.
Any updates here? I can't seem to make "App Store Connect" as distribution mechanism available, so I can't upload the standalone app.
Did you manage in the last 4 years? Still seems broken here. Can only select "custom" deployment.
This no longer seems to work. When I create a new standalone app, I only get a Watch App target and when trying to archive this, I only get options for exporting the archive to file.
The bundlid ends with .watchkitapp, the app records are online at AppStoreConnect, there is even a screenshot in the watchOS portion of the app record. Stiil:
What am I missing?
But what's the secret sauce in uploading? I only get the option to export the IPA to a file.
It's a complete joke nowadays. I stopped 4 years developing for AppleWatch because of the miserable tools situation. Guess what… it's even worse these days.
I'd like to know this as well. It doesn't seem to documented properly.
Ok, this is looking good now. If my tests are not wrong (it's a bit hard to match the exact requirements), the relevant delegate call urlSessionDidReceiveChallenge is now being called in a background session!
As expected, it's still broken in Xcode 18 beta 1.