“Account Locked”

[quote='878946022, DTS Engineer, /thread/817976?answerId=878946022#878946022'] The ACTUAL enforcement mechanism is a second check in callservicesd that happens a few seconds (~7s) after the push is delivered to your app. [/quote] If I display CallKit immediately after receiving the callback, and then the function returns, but the call ends within 7 seconds, will the second check be considered a misuse? [quote='878946022, DTS Engineer, /thread/817976?answerId=878946022#878946022'] First off, my major question would be why are you doing this? [/quote] We did this for two reasons: 1.Using VoIP + CallKit ensures call arrival rates while allowing users to easily answer calls from the lock screen. 2. Keeping the custom in-app call UI in the foreground and disabling CallKit gives users the ability to switch network nodes, improving call quality when the network is poor. But now I understand, we can keep both CallKit and the custom in-app call UI. The custom in-app call UI provides network node switching cap

Didn't see that anyone replied to your post, but I'm experiencing the same issue. Can sign in to sandbox account on my device just fine but when I try on the simulator it does the same thing you described. Never lets me log in. There's nothing wrong with my sandbox account on my device.

First off, as a side note, I'd strongly recommend reviewing this post to read about the newly introduced push delegate method, as it's a significant improvement over the previous API. However, I would like clarification about non-happy scenarios and when it is acceptable to use VoIP pushes to update or stop a CallKit ringing state. At a purely technical level, our only requirement is that your app must call reportNewIncomingCall for every VoIP push it receives. That also highlights the main downside of this approach, since inevitably means that your app will be forced to report extra calls which it would otherwise not have had to do. Any guidance on the recommended architecture for these cases would be greatly appreciated. My general view here is that this thinking: The server must inform User A that the call was rejected. ...is somewhat misguided, as it fails to account for the larger context all of this is happening in. More specifically, the basic call handling sequence looks like this: App Receiv

Unfortunately, on watchOS, the system doesn't seem to treat a video call any differently from an audio call and won't dismiss the system UI once it's answered. Basically... yes, that's what it does. watchOS VoIP support has a very narrow focus, which basically locks the screen into the CallUI in exactly the way you're describing. If you'd like this support to be expanded, please file a bug and post the bug number back here. We would like for our platform to be able to display visual content on the watch's screen during the call – in other words, we would like to be able to treat this as a video call. I believe the only way to do this at the moment is to stream the incoming video like any other video feed while using a PlayAndRecord audio session to capture audio from the user. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

By saying token is invalidated I assume you are talking about receiving a 410 Error for your push request. This is not an issue new to iOS 26.4. It seems like it just happens that you may have encountered it just yet, or have not noticed it before. The 410 status was never meant to be a signal for developers to determine that the app has been removed. It is only a signal to the push provider server that they should stop using that token. Although this could mean that the app may have been removed, it could also mean the token has changed while the app is still installed. The app token may change due to certain system events. Deleting and reinstalling the app, restoring the device from a backup, resetting the device (and then installing the app), certain major iOS updates, transferring all apps and data to a new device are all events that will cause the token to change. Because of this, it is recommended that apps register for remote notifications at every launch. If the token has changed, the app would need t