Howdy, I have a ***** feeling that the answer to my question is "Y'all cain't do that!", but I figure I'll ask, anyway. THE SAD STORY (GET YOUR HANKY): We have an app that implements Sign [up|in] with Apple. It does it pretty well, with no password visible to the user, and a pretty smooth UX. The issue is what happens when users bork their install. We don't think it will happen often, but want to be able to give the user the best way out, if possible. With the regular (non-SiiA) method, they bonk on a "Forgot Password" button, and the app sends them a new password. We can't do that, with SiiA. The password is stored in the app (in the keychain, so it's very persistent, and shared across devices), and it would a Very Bad Security Hole, to allow users to simply send a new password to the server (the other method generates a rando in the server), which is what would happen, with our method of handling the password. It would also be equally bad, if the server could simply send a new password to the user, directly to their device (the other method sends an email, based on the sign-in information on the server). So the user needs to delete their keychain data completely, which we can easily do, but that does not deal with their SiiA stuff, stored on Apple's server. This is what Apple tells us to do, to delete that. WHICH BEGS THE QUESTION: My question is: Is there a URL scheme that I can use to directly open that panel? If so, it would allow us to create a screen that helps the user to do all the deletions (on the device, our server, and the Apple server).

I have seen a lot of discussion on this, but nothing that seems helpful. If the user has not given calendar permissions, or has declined permissions, in the initial access request, they need to go to the above page, to reset the permission. However, I don't think that we are allowed to programmatically ask for this page. Am I wrong?

I have developed this shared package - https://github.com/RiftValleySoftware/RVS_Spinner. It works fine. In the package test harnesses (3 iOS apps), it works great, and also, the IB storyboard renders the control (It's an IBDesignable). However, when I include it as a package in another app (I can't share the source), I get these really weird render failure messages:Error: 'UIPickerView' is unavailable in tvOS And so on. There's a bunch of "not available in tvOS" errors. Well...DUH. It's an iOS package and utility, and leverages a lot of things like haptics. The package explicitly states that it is iOS(12), and I can't see any indication of why my storyboard is insisting on trying to render as tvOS. What am I missing?

That may seem like an odd question, but hear me out... I have a couple of apps that I've written: A Watch app, and an iOS app. They are both basically "faces" of the same thing. The Watch app has just been submitted as a standalone app, for offer in the new Watch App Store. The iOS app has already been in the iOS App Store. It would be nice to have the Watch app embedded in the iOS app, so that people getting the iOS app would also get the Watch app. They don't have any interactions with each other. It would just be a "2fer" deal. What I would like, is if people that had the Watch app, were to download the iOS app, the embedded app would not interfere with the one they got from the App Store, or would replace it. It seems that I can't set this up in Xcode. It has to be one or the other. This can be done by giving them different App IDs, but that means that the user could get two copies of the same app on the Watch, with one not aging well. Is there a way to get a Watch app to be both embedded AND standalone?

META: I also asked this over on StackOverflow - https://stackoverflow.com/questions/62963627/inconsistency-between-mac-and-ios-with-core-bluetooth, but hardly anyone has even looked at the question. I have discovered that Core Bluetooth Peripheral Discovery seems to return different results for Mac, and iOS. iOS seems to give me a lot more info, in the discovery callback, while the Mac seems extremely sparse. I'm wondering if anyone could shed light on why, exactly, this is. The test project I created - https://github.com/ChrisMarshallNY/TestCBIssue is about as simple as you can get. I have a pretty much default "Hello World" SwiftUI project, with targets for MacOS and iOS, using a shared ContentView that also instantiates a VERY simple CBCentralManagerDelegate object, and prints discovery info to the console. I will simply paste the contents of the README, below. It should explain the issue. The two console dumps were made from my Mac and my iPhone, about six inches apart, and about thirty seconds apart. BTW: You need to run the iOS target on a device. The simulator won't work. STRANGE CORE BLUETOOTH ISSUE This project contains about the simplest comparison I can make for testing this. This is the GitHub repo for this project - https://github.com/ChrisMarshallNY/TestCBIssue THE ISSUE When a MacOS app gets the centralManager(_ central: CBCentralManager, didDiscover: CBPeripheral, advertisementData: [String : Any], rssi: NSNumber) - https://developer.apple.com/documentation/corebluetooth/cbcentralmanagerdelegate/1518937-centralmanager callback, it delivers different data on the Mac, than on iOS. The code is EXACTLY the same between them. I use a simple shared SwiftUI view to instantiate a dirt-simple CentralManager, and display discovered devices. On iOS, I get the names of the devices. On the Mac, I fail to get most of the names. iOS console log:Discovered "Soulcatcher" Discovered "Croaker" Discovered "One-Eye" Discovered "[TV]Living Room TV" Discovered "Soulcatcher" Discovered "NO NAME!" Discovered "Desk" Discovered "NO NAME!" Discovered "Lady" Discovered "Eve Light Switch 60" Discovered "NO NAME!" Discovered "Tom-Tom" Discovered "The Limper" Discovered "TV" Discovered "NO NAME!" Discovered "NO NAME!" Mac console log:Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "Eve" Discovered "Eve Light Switch 60CC" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "Eve" Discovered "Eve Light Switch 60CC" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!" Discovered "NO NAME!"