“Popping Sound”

Have you filed a bug on this and, if so, what is the bug number? Not yet, but I do have another thread where I describe the same problem in regards to .DS_Store: https://developer.apple.com/forums/thread/819041 I will post the bug number (most likely there) when I carve out a little time for it. Currently if copyfile fails and errno is not set my code falls back to a kind of 'Unknown Error' which I hate but if the user is counting on my app to perform the copy it's kind of a gamble if the operation doesn't succeed to just hope not critical data was lost. A big part of this is that xattrs aren't actually safe“— the system doesn't have a documented system for defining how they should be handled, and app/copy engine/file format support for them is inconsistent, so storing critical data in them can end up being a good way to lose critical data. Importantly, that kind of data loss isn't really a bug in the same way other kinds of data loss would be. The general point of xattrs is to allow the attachment of arbitra

Thanks for confirming. This is unexpected because from the documentation it sounds like only the provided UTIs are allowed by the document picker; there's no mention of the Info.plist types. Is there no way of allowing the user to select only the provided UTIs? On macOS, regardless what document types the Info.plist contains, using the following code only allows to select folders: let openPanel = NSOpenPanel() openPanel.allowedContentTypes = [.folder] openPanel.runModal()

Problem: When the screen is locked, an incoming call does not initiate the launch of the Flutter application required for audio and video communication through Jitsi Meet. In the unlocked state, the application functions correctly. This is a problem with your app that you'll need to address, not an issue with our API or the system’s broader behavior. The core point is actually here: The current implementation does not have a mechanism for activating the Flutter engine when receiving a call via CallKit while the screen is locked. Although CallKit UI displays the call acceptance interface and the audio session is configured, the Flutter application remains in a suspended state, making it impossible to connect to the media server. Audio session activated using didActivateAudioSession method. The CallKit UI isn't an independent system component outside of your app’s control, but is actually an interface element your app is controlling and managing. Case in point, the ONLY reason the inc

I had the same problem even with Audio, AirPlay and Picture in Picture background mode enabled and with all the AVAudioSession.setActive(true) and AVAudioSession.setCategory(...) calls. We run some tests and it seems Apple made things more restrictive since iOS 18 (it was working on iOS 17.6). The only fix I found is to use the good old MPVolumeView as a substitute, but there's a catch - it's mandatory to add it to UI otherwise it will always return volume of 0. In SwiftUI it was as simple as creating a UI component: import MediaPlayer import SwiftUI struct VolumeSlider: UIViewRepresentable { private let volumeView: MPVolumeView = MPVolumeView() func makeUIView(context: Context) -> MPVolumeView { return volumeView } func updateUIView(_ view: MPVolumeView, context: Context) {} func getVolume() -> Float { if let slider = volumeView.subviews.first(where: { $0 is UISlider }) as? UISlider { return slider.value } return AVAudioSession.sharedInstance().outputVolume } } And then in your SwiftUI view yo

It sounds like your static library isn't built as an XCFramework that then contains your static library. In essence, your library needs to be built twice, once for iOS devices and a second time for iOS simulators, with both copies and the header files then packed inside of the XCFramework so Xcode then handles all of the details from there. The documentation covers all of the details you need. — Ed Ford,  DTS Engineer

Yeah, the obvious way doesn't work so well if you're using auto-renewing subscriptions - forcing the user to run the outer app every three days when the grace period expires to see if the user is still subscribed is a non-starter - this needs to be transparent and just work™ once the user has bought the subscription - my target customers are mastering engineers and similar - I wouldn't put up with that from a plugin for long, so I cannot expect my customer to. I have one local beta tester I'm going to try a TestFlight version with subscription support enabled and lots of logging and see if the extension is able to see products defined for the outer app. The fact that all of this is essentially untestable by the developer (getting a StoreKit config through to the extension process seems to be a no-go, not to mention my experience with local StoreKit configs working on a much simpler iOS app spotty enough not to trust) is fairly maddening. The combinatorics in the state machine you need for definitely-not-subsc

Update — Workaround found After further investigation I have found a workaround that resolves the inconsistent track switching behaviour described above. Observation I noticed that changing the order of EXT-X-MEDIA audio entries in the manifest produced different results. Specifically, when the DEFAULT=YES track is listed first, switching behaviour is unreliable. When the DEFAULT=YES track is placed last, switching back to the default language works correctly. Workaround Reorder the EXT-X-MEDIA audio entries so that the DEFAULT=YES rendition appears last in the manifest: #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=de,NAME=Deutsch,AUTOSELECT=YES,DEFAULT=NO,CHANNELS=2,URI=audio_DEU.m3u8 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=fr,NAME=Francais,AUTOSELECT=YES,DEFAULT=NO,CHANNELS=2,URI=audio_FRA.m3u8 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=en,NAME=English,AUTOSELECT=YES,DEFAULT=YES,CHANNELS=2,URI=audio_ENG.m3u8 In our case the

Everything you've described sounds like you're on the right track. Great, thanks! Interesting. Are you primarily editing the contents of the zip file (so you end up modifying the data inside, but don't really change it's overall size or structure)? Cloning is a huge help if you can clone the contents and then modify but if your modifications end up changing the fundamental contents, then I wouldn't expect the difference to be nearly as large. At large scale, this eventually devolves to bytes moved. Yes, I believe editing a large zip file using LibZip can indeed still be slow on APFS. However, the nice thing is that if a user edits a text file in a (zip) project in our app, only the first save to those edits would have the potential to be slow. After that, until they switched to editing another text file in the project, saving subsequent edits even into a huge zip file would be fast on APFS. (A project created in our app can contain text but also research files such as PDFs, media and images.) This is

It sounds like you’re making great progress. [quote='879776022, jblum2000, /thread/817268?answerId=879776022#879776022, /profile/jblum2000'] The surprise here is simply that the app worked [/quote] Such is the nature of the Mac. On iOS the trusted execution system would simply block your code from running in this case. That’s much easier to debug. The Mac, with its legacy stretching back 40+ years, has to be more flexible. That has its pros and cons, and you’ve just hit one of the cons )-: [quote='879776022, jblum2000, /thread/817268?answerId=879776022#879776022, /profile/jblum2000'] once I hear back from the employee running this on Sequoia … [/quote] *cross fingers* Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com