“Popping Sound”

Firstly, I am using AVAudioEngine for recording implementation. We are not currently using CallKit. The audio recorded by AVAudioEngine still has noise in the above scenario (when PushToTalk is turned on and the app is switched to the background, the app is in a state of long-term survival in the background, and then AVAudioEngine recording is started by clicking the Bluetooth device button), but I found that the audio recorded after clicking the intercom button on the PushToTalk interface has no noise. The audio recorded by clicking the Bluetooth device button is noise. The method called by Bluetooth devices is (requestBeginTransmitting), which enables AVAudioEngine recording in the (channelManager: PTChannelManager, didActivate audioSession: AVAudioSession) method. Is there any additional setting for the intercom button on the PushToTalk interface?

fileVerA not existing on device B explains why currentVersionOfItem returns fileVerB. But as you've pointed out and the documentation mentions , presentedItemDidGain(_:) is supposed to be called after a new version was added, which does seem to conflict with your observation. I’d hence suggest that you file a feedback report – If you do so, please share your report ID here. In presentedItemDidGain I check if the URL passed in is in a conflict state by using 'newVersionURL.isConflict', and it returns true, and then I run the merge. Is this the right way to check for a pending conflict? Yes, the above flow sounds right, assuming presentedItemDidGain is called at the documented timing. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Hello, iPadOS 26 brings significant changes to UI interaction and this sounds like a regression from iPadOS 18.x. Please install the latest non-beta version of iPadOS 26 and verify whether this is still occurring. If so please send us a bug report. Note: it's important to verify with a non-beta version as there may be subtle timing delays in beta.

One bit of follow-up on the bug fix side of this: FB19429215 (CallKit does not activate audio session with higher probability after upgrading to iOS 18.4.1) Having looked into the issue in more depth, there are technical issues that are likely to delay a fix coming from our side. The CallKit team is still committed to resolving this, but you should not expect the issue to be resolved in the short term. I'll also say that, based on my own analysis, I do NOT think this is in fact a new issue. That is, going back to the original report on this thread: We've noticed that this issue occurs more frequently after upgrading to iOS 18.4.1 The focus here was on the increased rate; however, it's very likely that this was simply a shift in the rate an existing bug occurred, NOT a new/different issue. Because of that, my recommendation is that all CallKit apps send a setConfiguration immediately before they report a new call. It's the best way I can see to prevent the problem from occurring and is already fully s

In the above scenario, the sound recorded with AVAudioRecorder is all noise. Like most of our higher-level audio APIs, AVAudioRecorder will work with the PushToTalk (or CallKit) framework. The issue here is that the PushToTalk framework is tightly integrated into our audio infrastructure and, as part of that integration, the activation of your audio session MUST be triggered by the PushToTalk system, NOT your app. Unfortunately, AVAudioRecorder does its own activation, which will then break the PTT system. You'll need to use a lower-level audio API, typically AVAudioEngine. For an example of how the audio side of this, please see the Speakerbox CallKit sample. It may seem odd that I'm recommending a CallKit sample, but the thing to understand is that CallKit and the PushToTalk framework share exactly the same underlying implementation. Both frameworks are managed callservicesd and, internally, they actually share a common implementation, particularly when

In the above scenario, the sound recorded with AVAudioRecorder is all noise.

Looked at a previous embeddedcapabilities and the current one being generated and we see CarPlay Navigation App enabled. Since our app was no longer being considered as an audio app, we could not attach the CPNowPlayingScreenTemplate force a rebuild now that capabilities have been updated to the ones we had

Thank you for your answer. So, having talked to App Review about this, the basic answer I have currently is that we don't currently support 3rd-party App Extensions on the iOS App Store. The framework itself is built to work across all of our platforms and is public (which is why new functionality is added that's available on iOS), however, the App Store policy has not changed. If you haven't already, I'd appreciate you filing a bug on this and then posting the bug number back here. It sounds like you're trying to create extensions that are specifically for your apps’ usage, and that's a distinct use case that we need to more actively consider. Clarifying a few details, I think the difference here is basically a quirk caused by slightly different handling paths: The only difference I could see is that sometimes it would fail when uploading (I would get the error message inside Xcode) and other times it would fail after uploading: I would get a kind e-mail from AppStore Connect, stating: For many year

Hi @ArcSurgeryLab I'm not sure why updating would cause a shift in entities. It sounds like you are trying to display a grid of entities, when someone taps an entity, in the grid, you want to position content relative to the tapped entity (not the tap location). Is that correct? If so here's a snippet that does that. Try comparing it to your code to it as a means of debugging. What does stand out is your use of a world AnchorEntity. Keep in mind, querying the position of a world AnchorEntity or its children will return a position that does not account for the position you passed to the world AnchorEntity's constructor (in this case [1, 1.3, -0.8]). For example, in the snippet below, modelAnchor.position(relativeTo: nil) will return [0, 0, 0] and not [0, 1.3, -0.8]. struct ImmersiveView: View { let modelAnchor = AnchorEntity(world: [0, 1.3, -0.8]) var body: some View { RealityView { content in let gridCell1 = createGridCell() let gridCell2 = createGridCell() gridCell2.position.x = 0.5 modelAnchor.addC

We are experiencing the exact same issue. It popped up this week. Is there any workaround available while waiting for a fix?

@RickMaddy I think that might be a little out of scope for this thread. But in any case, I was able to update my macOS 26.1b2 VM to 26.1b3 via my logged-in Apple Account, so I don't think it's universally broken. Although my host is still on Sequoia 15.7.1. The closest thing I've experienced to what you're describing is an issue that I've seen for a while where logging in with an Apple Account hasn't been working for me if I have physical security keys enabled on my account for 2FA (FB19614234). Unfortunately if you're in this situation I don't know of any workaround other than removing all the security keys (and even if you re-enable them after logging in with the VM, eventually the VM will start complaining with pop-ups asking you to login again, although beta updates will still work despite this). This isn't new to 26.1, though. If this isn't the issue you're experiencing you might find better luck creating a new thread since I don't think many people with similar issues are going to find this rep

Kevin and ssmith_c for your assistance. I fortunately managed to file in the bug: FB20677188 Thank you! Looking over the bug, there was one point I wanted to comment on: For the Matter Media Device Basic Video Player Type Apple Home does support the commissioning (adding the device to the list of accessories displayed in Home App), but no controls are displayed. Not even the mandatory required controls: ... This type of Matter Device, which is part of the standard, should at least expose the mandatory controls and commands. The idea that Apple (and general ecosystem vendors more broadly) should try and support the full range of the Matter specification is, IMHO, one of those ideas which sounds reasonable on the surface but is, in fact, a very bad idea. First off, quoting myself: The Matter specification itself is sufficiently broad and complex that, in practice, I'm not sure it will ever really be possible to create a high-quality controller app* that actually supports EVERY possible accessory config