Popping Sound

Hello, You may want to try uninstalling the beta and then reinstalling as a workaround. Otherwise, it sounds like you might have an issue with available storage so you can also try deleting unnecessary apps and data before attempting to update to beta 3 again.

[quote='793484021, TekMun, /thread/793484, /profile/TekMun'] I followed this instruction to manually re-sign my ipa [/quote] To be clear, DTS doesn’t support folks re-signing iOS apps. If you need to re-sign an app, the best path forward is to distribute an Xcode archive (.xcarchive) and then re-sign that using Xcode. However, I don’t think that’s the issue here. Rather, it sounds like you’re trying to run distribution-signed code. That won’t work. See Don’t Run App Store Distribution-Signed Code. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Are you specifically trying to use the new arm64e enhanced security that we enabled with iOS 26 beta? For more on that, see Enabling enhanced security for your app. The reason I ask is that arm64e on iOS was previously limited to folks creating a third-party browser engine using BrowserKit. But it sounds like you’re not in that business at all. If I’m right, then my advice is to disable arm64e until App Store Connect is set up to receive iOS 26 beta submissions. In the past that’s happened at the Release Candidate stage, although I can’t make concrete statements as to what’ll happen this year. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for that. I see the documentation now on Sequoia in the man pages. It doesn't seem like I can specify the timeout for a package postinstall script, only if I specify a script for a specific bundle. Would you agree? Does a dictionary in a component plist need to refer to an app bundle? I don't really have a bundle to install for the package choice. To answer your question, there are very large libraries of audio content available for our program, and the install scripts help them with various options for installing/using this content - it can definitely take longer than 10 minutes.

Hi Kevin, what I’m trying to do is use Picture-in-Picture to display relevant call information to the user—such as the current call status and connection quality—when the app goes into the background. My read of that is that it seems like something that would be much better handled through Live Activities and/or some other mechanism like the notification system. Notably: Live Activities work in broader contexts, like on the lock screen. Live Activities can be initiated from the background, while starting PiP requires your app to be in the foreground. Using PiP for this is going to disrupt whatever other PiP activity the user was doing. Basically, I think using PiP for something like this is going to require significantly more work than LiveActivities and will only work in a much narrower context. The purpose is to keep the user informed during an ongoing call. Just to clarify something, you are planning to use CallKit, LiveCommunicationKit, or the PushToTalk framework, correct? My concern here is that you're

[quote='843657022, DTS Engineer, /thread/788023?answerId=843657022#843657022'] It seems incorrect to indicate the presence of captions when they aren't there in an audio or video asset. [/quote] Perhaps, although I DO have captions for every single video in my app, (which is zero). The reverse mislead, that some of my content is inaccessible, seems like a worse error to me. I have no such inaccessible content. Clearly, what's needed here is something more than a 2-state response. We need to be able to say Not applicable - no videos to caption.

What is logPath? It sounds like you may have sandboxed the app. It probably no longer has access to whatever logPath is. Since this is your own app, the easiest solution would be to disable the sandbox. If you want to be clever, you could give yourself a temporary exception entitlement for that path.

Hi @DTS Engineer I would like to follow up this issue. From our metics, looks like after upgrading to iOS 18.4.1,** the incoming call no audio issue is increased**. we did not observe outbound call increased. Here is the incoming call process in our app incoming call from push notification, app call reportNewIncomingCall after report incoming call success, our app will configure audio session our app will post the configureAudioSession to another thread reportNewIncomingCall callback configureAudioSession in another thread (app will wait for the user press answer button, may take several seconds) user answer the call and AnswerCallAction will callback app will finish the signaling answering logic action.fulfill() callkit shall setActive Audio session didactivate audio session shall be triggerd, but it's not. our app detect no audio for 5 seconds try to setActive(YES) for workaround, sometimes it will success, sometimes it won't if the setActive(YES) failed, it will

So, there are actually a few different things at work here. First of the errors here: /usr/local/mnt: No such file or directory ...means exactly what it sounds like. You specified the mount target (the point the new file system would attach on your file system) as /usr/local/mnt/ and that directory either does not exist or you don't have permission to it. That's what I'd expect, as that's not a standard macOS directory, so it won't exist unless you create it. The solution is to create the directory, change the permissions, or pick a new directory. I'm not familiar with how Time Machine on a NAS works I believe we still create disk images, which are then mounted and treated as local backup target volumes. That means there are actually two permission systems at work here: The permission of the smb volume the NAS device shares. The permission of the TimeMachine disk image. That difference is important, because it leads to the difference in behavior between this case: This was on a USB drive mounted with

Thank you for your response, Kevin. From what I can see, the document appears to focus only on video calls, while my use case involves audio-only communication. Could you kindly confirm whether it’s acceptable to display a Picture-in-Picture view for an audio-only call, even if the document primarily focuses on video calls? What are you actually trying to do? While the documentation primarily describes camera to camera streaming and the idea of two people looking at each other through their camera's, nothing in the API actually requires that. As far as the API concerned, it has no idea what content it's actually showing and will happily display whatever you tell it to. Similarly, many VoIP apps allow their users to send content other than the image of the person currently talking (screen captures, shared documents, white boards, etc.). I'm not aware of us ever having had any issue with that sort of thing, particularly when the user has direct control of what's happening and the value to the