Popping Sound

After the call is connected from the lock screen, is there any supported way for iOS to bring my app to the foreground automatically when the user later unlocks the device - without requiring the user to manually open the app or tap a notification? No, aside from the obvious option of making it a video call*. *As one small clarification here, I think that, in the context of CallKit, the term video call should be understood as the very broad concept of the call involves visual content the user might want to see, not just one or more users talking into their camera. Content like virtual whiteboards, shared documents, or broadcast video can all be considered valid video calls. Most critically, this is primarily about what the user can see, NOT what their sending- a video call is still a video call, even if the user’s camera isn't or even can't be turned on. If this is not supported, is there any recommended pattern (e.g., specific CallKit/PushKit APIs or entitlements) beyond using a time-sensitive local notifica

Hello @Chavd, This sounds like a regression, please file a bug report for this issue if you have not done so already using Feedback Assistant. Having said that, I've been unable to reproduce the behavior you described, so I'd be curious to see a focused sample with steps to reproduce. --Greg

Hi Ziqiao, Thank you for the response on this. All your first paragraph points sound good. Unfortunately I too don't have an affected device so short of importing one, I'm not sure on the exact behaviour. As for the measurements, yes any further details you can provide would be good including if the background measurements are still taken in the same way on these models and if data can be automatically synced back to iPhone and therefore the HealthKit database when the iPhone is available. Thank you

Sadly, I can’t read Chinese, so I’m answering based on a machine translation. It sounds like your goal is to create a Mac product to distribute directly, using Developer ID signing. If so, there are three basic steps: Created a Developer ID signed version of your product. Submit that for notarisation. On successful notarisation, staple the resulting ticket to your product [1]. We have documentation that covers all of this. A good place to start is: Creating distribution-signed code for macOS Packaging Mac software for distribution Once you’ve done these steps, I recommend that you test your product using the process described in Testing a Notarised Product. If you continue to have Gatekeeper problems, I have lots of advice on how to investigate that in Resolving Trusted Execution Problems. Finally, see the following forums posts for links to even more info: Notarisation Resources Code Signing Resources Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @

hi Kevin, let me clarify, my question is about audio-only VoIP calls. Scenario: • The app is not running (App state is not started). • An incoming call arrives via CallKit. • The user slides to answer on the lock screen. Question: After the call is connected from the lock screen, is there any supported way for iOS to bring my app to the foreground automatically when the user later unlocks the device - without requiring the user to manually open the app or tap a notification? If this is not supported, is there any recommended pattern (e.g., specific CallKit/PushKit APIs or entitlements) beyond using a time-sensitive local notification with a deep link? For audio VoIP calls, instead of answer on lock screen and stay there? Can we choose the unlock → open app?

I have built a simple dialer UX with a numberpad, contact lookup, etc. Then when the user presses the Call button, does it have to pop up the system prompt Call number? No. A default dialer app can use the StartCellularConversationAction to initiate a call. Does it have to swap over to the system ui for the actual call? To be honest, I don't remember whether or not StartCellularConversationAction immediately presents the call UI (like Phone.app does) or just leaves the app in the foreground (like CallKit and LiveCommunicationKit do). However, that should be straightforward to test. However... So there's no way to show information about the call during the call? Or am I using the frameworks incorrectly? I believe the system will still handle the out of app interface. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hi, No, it's not responding verbatim, sorry if unclear. It's responding with a single sentence saying some variation of I cannot fulfill this request because... like you see in the above post. It will give a reason but it sounds like you're saying that's likely hallucinated so perhaps just nonsense. But it's just a refusal, not the original article text returned back to me. I seem to see this most consistently on political stories but also strangely on tech stories (it will sometimes refuse to summarize any Apple related rumors which I'm sure is not intentional but pretty odd). I will post my FBs.

I'm able to play custom audio and loop it. I have mine set for multiple minutes of looping. The playback is the most stable when a scheduled alarm plays in the main app's view. It's currently flaky at best, when the custom audio plays via live activity widget extension views, and routinely falls back to the single tone audio that plays once that others have reported on Reddit [https://www.reddit.com/r/iOSProgramming/comments/1lgam98/setting_custom_sound_in_alarmkit_doesnt_seem_to/] Something I realized today though. The main app playback works both in simulator and on a physical device. The widget extension playback WILL work in simulator, but almost always falls back to the default single tone audio when testing on a real device.

Is this happening when the boat is floating around very slowly? Also, does the placement of the phone change things, as in handheld vs. mounted, and perhaps changing the mounting position? What would be important here is the .activityType your app is using. If you have selected a different type, you may want to try CLActivityType.other and see if that changes your results. The wrong locations jumping to the shore sounds like the system is trying to correct to a possible location at the shore. In any case, if the issue only happens when slowly floating, or the phone's position changes the results, we would still like to see the diagnostic logs through a bug report (I explained how to obtain the logs above).