Popping Sound

Based on the explanation you have provided it sounds like the current track is still working as it has in the past with tracks in the user's library but it has not been updated to work with tracks from other sources. Because of that, this could be interpreted as either a bug or an enhancement request. To work around this change, I suggest enclosing any usage of the current track property inside of a try block so that in cases where using this property fails you can provide appropriate alternative functionality. Whether or not this is a bug or an enhancement request, I recommend filing a feedback report (ad Quinn has suggested above) and testing your software in system software updates (including beta updates) whenever a new one is made available. And, whenever you test in a new update, please update your feedback report.

Hello, This sounds like a regression in beta iOS 26. What version of the betas (iOS and Xcode) are you using and has this behavior changed between any other beta versions recently? To fully understand the request flow and configuration it would be helpful to have a sample project. Please provide one if you're able. Something in the documentation of note: GameKit calls the [authenticateHandler] handler, possibly several times, for the following cases ... so we'll need to check each case. All that said, please also file a bug report as this is still in beta.

When I called the PTP function below to send a command and add data, the response timed out for more than 5 seconds. After waiting for a period of time, I obtained the response. However, the response callback function obtained responsivData.length as zero and ptpResponseData.length as zero too. What were the full contents of ptpCommand (6 bytes) and ptpData (if applicable)? More generally, what command were you trying to send and what did you expect to happen? I haven't looked at the PTP spec in any great detail, but what your describing sound like what happens if you sent the device a command it didn't handle well. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

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).