“Apple Maps Guides”

In short: create a virtual device with the HID descriptor of a FIDO device, receive data from browsers, etc., through the system with the HIDVirtualDeviceDelegate class, repackage these and communicate over BLE, receive an answer, repackage back to USB HID packets, and send back to the system with dispatchInputReport. Please add these details to your bug, as a big part of what matters here are the details of exactly what kind of device you're trying to present to the system. This might be something Apple does not approve of, and that would be acceptable, but the rejection we got didn't seem to fit that sort of issue. So, what triggers the rejection here is that the Accessibility authorization you're getting is extremely powerful. In particular, it also controls access to CGEventTap and the AXAccessibility API. Between those two APIs, your app has the ability to modify all interface event activity, as well as access to the Accessibility API that exposes the interface to assistive apps like screen read

I'm not in the App Store team, I'm just looking at the documentation myself: https://developer.apple.com/app-store/product-page/ If you have question about that process I recommend that you sign up for a session with App Review during the weekly Meet with Apple event. Sign in with your Developer ID and select Request a one-on-one App Review consultation. A member of the App Review team will help you with your questions regarding the review process and the App Review Guidelines. https://developer.apple.com/events/view/upcoming-events Albert
  Worldwide Developer Relations.

It was my understanding that we weren't allowed to mention any Apple Copyrighted services in our app descriptions (I got reminded of that a few years ago).

Thanks for the post. Why are you not allowed to mention any product name on your description? I reviewed this https://developer.apple.com/app-store/product-page/ Apple’s Trademark Guidelines: https://www.apple.com/legal/intellectual-property/guidelinesfor3rdparties.html Can you explain a little bit more about that limitation? Albert  WWDR

Context for what we're trying to do: Apple has not implemented FIDO2 support over BLE, so we decided to try and make our own, following the framework we did for Linux. In short: create a virtual device with the HID descriptor of a FIDO device, receive data from browsers, etc., through the system with the HIDVirtualDeviceDelegate class, repackage these and communicate over BLE, receive an answer, repackage back to USB HID packets, and send back to the system with dispatchInputReport. Since this communication goes back and forth, we need to be able to both receive and post events. I assume this is how the PassKeez project I mentioned in the initial post could use it as well. This might be something Apple does not approve of, and that would be acceptable, but the rejection we got didn't seem to fit that sort of issue.

Thank you for your post, I was very interested on your post as you are using a regular APNs alert notification for a VoIP calls I’m sure it does introduces delays and requires the user to tap a notification before the app can even begin setting up the call or you sending those notifications with the voice? Since watchOS 9, I believe that CallKit and PushKit support directly for Apple Watch. You can now build an experience that perfectly mimics native FaceTime or Phone calls, where the watch rings immediately with a full-screen incoming call UI. I believe your post talked about callkit. I’m more interested in how are you using that framework. https://developer.apple.com/documentation/callkit/voip-calling-with-callkit There is a WWDC 2016 talking about that platform https://developer.apple.com/videos/play/wwdc2016/230/ There are many watchOS experts here, so if you get into any troubles using that framework, they'll be able to help you better. Albert
  Worldwide Developer Relations.

Here's the video I initially shared with them. It's recorded via Apple Watch > iPhone screen sharing. And they believe this is a simulator, lol https://youtu.be/izXpnEZCCp4

My Mac Mini crashed and restarted, and the SDKs are all broken again. I am going to have to spend another hour with SIP etc to get this working. Can Apple acknowledge this is a real issue they are working on resolving please? It's an intolerable situation.

antho2305, I discussed your case with the notary team and the conclusion is that: While there were some transient issues caused by oddities at our end… This all falls into the category of the notary service ‘learning’ how to recognise your submissions. Your submissions should be flowing normally now, but if you continue to have problems please reply here with the details and I can take another look. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com