“Popping Sound”

[quote='821109021, JTechHyd, /thread/821109, /profile/JTechHyd'] Are there known issues with aggressive optimization (-O) affecting … ? [/quote] Yes. If you’re using a C-based language it’s very easy to rely on undefined behavior, and the exact behaviour you get can change based on the optimisation level, the compiler version, the OS version, and so on. This is true in safer languages as well, but it’s less common. For example, Swift is generally safer than C but there are still sources of undefined behaviour, including unsafe pointers [1] and concurrency [2]. Is sounds like you’re building this third-party library from source. Is that right? If so, you can dig into the library to see if you can isolate the cause of the problem. This is no different from tackling a hard-to-debug problems in your own code. You can use both build-time tools (like the Clang static analyser) and runtime tools (like the standard memory debugging tools). It’s also possible for problems like this to be caused by bugs in the

Thank you @Tomato and @DTS Engineer ! The purpose of my app is to provide a notification mechanism when there are drastic air quality changes. To accomplish this, I have an async function that makes a GET request to an air quality sensor (using UrlSession), decode the payload, and then do comparisons with previous readings. If the readings have changed drastically, an UNMutableNotificationContent() is scheduled. Currently, my async function is called from within a repeating scheduled timer so that I can poll my sensor every minute: Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in timerVal -= 1 if timerVal == 0 { timerVal = startVal getAQI() } } This all works just fine (including when the app is in the background) ONLY when I run the app from Build and Run in Xcode on my dev iPhone as the destination. I've left the app running this way for hours in the background and with the phone locked and it works great! However, when I try to run the app purely from the app shortcut on my iPhone, it work

Also, on the specific question here: Could you please explain about this inconsistency w.r.t. Volume level. There are actually at least two different factors at work here: I don't know the full details of the entire system, but the system does maintain separate volume states for at least CallKit and other audio, so that phone calls start at a consistent volume regardless of other activity. Different audio session configurations have different maximum volumes and, in particular, Playback is louder than PlayAndRecord. In addition, the CallKit AudioSession has a noticeably higher max than a standard PlayAndRecord. Either/both of those factors mean that it's normal for the playback volume to change when the audio category changes. This doesn't matter for most apps, as they simply pick the category that best fits their overall requirements and don't change it. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I have built a very similar macOS dictation tool — global hotkey, continuous mic capture, on-device transcription, then AX API text injection. My first notarization also took several hours, which is normal for this entitlement combination. Tips for future submissions: (1) Hardened Runtime with specific exceptions only — avoid blanket disable-library-validation. (2) Use Developer ID Application signing to prevent TCC permission resets. (3) After first successful notarization, subsequent submissions go through in minutes. The audio + clipboard + AX combo triggers deeper first-time analysis but is not a rejection risk. Glad yours went through.

Given that you'd move the Core Data store to a group container, I'd assume that the store will be shared across different processes, such as your main app and its extension (a widget, for example). In that case, I'd like to start with pointing you the following threads: Core Data Light Migration Crash When Widget is Installed (Error 134100). CoreData error=134100 Failed to open the store. These threads made it clear that: After a user installed your new version app, depending on what extension you have, the app and extension can open and migrate the store simultaneously, and so you will need to implement a mechanism to make sure that the store is only migrated once. Consider having your main app in charge of the the synchronization, as discussed in Avoid synchronizing a store with multiple persistent containers. Thank you, this is very helpful. At the moment, my app does not have any widgets or extensions, but adding them is one of the reasons I want to move the store into an app group container. From what yo

Hi, Sorry to hear you are having problems getting previews working. The issue you are hitting here sounds like one we are actively looking at. If you want us to check for certain then the best next step will be to file a feedback with diagnostics so we can take a look. We will need the diagnostics Xcode Previews generates in order to make sure we understand the error the previews system is encountering. Install the logging profile using instructions available here: https://developer.apple.com/bug-reporting/profiles-and-logs/?name=swift On your mac running Xcode. Install the logging profile using the following instructions on your mac running Xcode: https://developer.apple.com/bug-reporting/profiles-and-logs/?name=swift Then when you reproduce the problem in Xcode: Either (a) an error banner will appear, click the Diagnostics button in that banner; or (b) if you're not seeing an error but you still want to provide diagnostics you can get the same diagnostics window by going under the Editor menu in th

Like the documentation explains to control the audio for that control use AVRoutePickerView Thanks Albert 
  Worldwide Developer Relations.

Thank you for a quick reply. We are using non-deprecated MPVolumeView (https://developer.apple.com/documentation/mediaplayer/mpvolumeview) to control system audio output volume. // volumeView is `MPVolumeView` volumeView.showsRouteButton = false volumeView.backgroundColor = .clear addSubview(volumeView) volumeView.snp.makeConstraints { make in make.top.greaterThanOrEqualTo(self) make.bottom.lessThanOrEqualTo(self) make.centerY.equalToSuperview() make.leading.equalTo(volumeMuteImageView.snp.trailing).offset(6). make.trailing.equalTo(volumeHighImageView.snp.leading).offset(-15) make.height.equalTo(44) } What should we do? Thank you!

I have hit this exact crash pattern in my own ScreenCaptureKit audio capture pipeline. The EXC_BAD_ACCESS in swift_getErrorValue happens because the error object passed to didStopWithError is being deallocated before the delegate method can access it — it is a race condition in the XPC boundary between replayd and your process. The root cause in my case was that the SCStream object was being deallocated (or stopCapture was called) while a pending error was being delivered across the XPC connection. The error object lives in replayd's address space and gets bridged to your process, but if the stream tears down mid-delivery, you get a dangling pointer. Keep a strong reference to the SCStream instance beyond the point where you call stopCapture. Do not nil it out immediately. In your stream delegate, wrap the didStopWithError handler in a DispatchQueue.main.async to ensure the error is fully materialized before you access it: func stream(_ stream: SCStream, didStopWithError error: Error) { let errorDesc