Search results for

Popping Sound

19,599 results found

Post

Replies

Boosts

Views

Activity

Reply to PushToTalk session sometimes returns silence data after activation
I have a working walkie-talkie app based on the PushToTalk framework. Everything works fine except for an intermittent bug that I face from time to time on different devices with different iOS versions, from iOS 18 to iOS 26.2 Beta. The next time this occurs, please capture a sysdiagnose, file a bug on this, then post the bug number back here. What you're describing sounds similar to a CallKit issue (r.157725305). A fix is being investigated for the CallKit issue, but if it's happening to the PTT system, then that's something we'd need to address. Once I leave the channel and rejoin it again, the issue is fixed and I start to receive non silent buffers of varying size, as expected. Assuming this is similar to the CallKit issue, this works because it's updating the audio session ID that callservicesd uses to activate your audio session. Unfortunately, that also means that it's basically the only thing that WILL work. __ Kevin Elliott DTS Engineer, CoreOS/Hardware
Topic: App & System Services SubTopic: General Tags:
49m
Reply to Check whether app is built in debug or release mode
[quote='866973022, SoumyaMahunt, /thread/807924?answerId=866973022#866973022, /profile/SoumyaMahunt'] I think more appropriate solution for me will be deciding based on the way app was signed [/quote] OK. That’s easy to do on macOS, using SecCodeCopySigningInformation. On iOS the story isn’t as rosey. Historically there’s been no supported way to do this on iOS. Thinking about this today, I believe that recent iOS API additions make it possible, albeit in a non-obvious way. I got a proof of concept working today, and it looks promising. Unfortunately I don’t have time to flesh it out. But, honestly, it sounds like a fun weekend project so, with any luck, I’ll have an answer for you on Monday. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
8h
PushToTalk session sometimes returns silence data after activation
Hello! Thank you for bringing the new iPhone experience with the PushToTalk framework. I have a working walkie talkie app based on the PushToTalk framework. Everything works fine except for an intermittent bug that I face from time to time on different devices with different iOS versions, from iOS 18 to iOS 26.2 Beta. Sometimes the app goes into a state where the AVAudioInputNode input node tap returns buffers with a constant size that contain only silence. Leaving and rejoining a channel helps, but relaunching or reinstalling (from Xcode) the app does not. Rebooting the device or deleting and reinstalling the app also helps. I do not activate the audio session in my app. I only configure it on launch using setCategory(.playAndRecord, options: [.defaultToSpeaker, .allowBluetooth]) So the flow is: channelManager?.requestBeginTransmitting(channelUUID: globalChannelUUID) func channelManager( _ channelManager: PTChannelManager, channelUUID: UUID, didBeginTransmittingFrom source: PTChannelTransmitRequestS
1
0
27
13h
UIKit Crash During Navigation Transition After Changing UIView.appearance().semanticContentAttribute (Arabic RTL) — iOS 17.2.1
Device: iPhone 11 iOS Version: 17.2.1 Frameworks: UIKit, Auto Layout App Behavior: App supports Arabic (RTL). User can switch language in-app. When language is switched, the app sets UIView.appearance().semanticContentAttribute and fully rebuilds the window’s rootViewController. Problem Summary I update the global semantic direction only when the user explicitly switches language inside the app — e.g.: // Only run when user switches language inside the app UIView.appearance().semanticContentAttribute = .forceRightToLeft // or .forceLeftToRight // then rebuild the window's rootViewController I do not change UIView.appearance().semanticContentAttribute during navigation transitions. Despite that, after switching the language (and rebuilding the root), the app sometimes crashes during a subsequent UINavigationController push/pop animation. The crash appears to be caused by UIKit’s Auto Layout engine removing or updating directional constraints while a navigation transition is running. Crash Log (most re
0
0
14
14h
Local Wi-Fi UDP discovery works in Debug but stops working in TestFlight (React Native app)
Hi everyone, I am building a React Native iOS app that discovers audio devices on the local Wi-Fi network using UDP broadcast + mDNS/Bonjour lookup (similar to the “4Stream” app). The app works 100% perfectly in Debug mode when installed directly from Xcode. But once I upload it to TestFlight, the local-network features stop working completely: UDP packets never arrive Device discovery does not work Bonjour/mDNS lookup returns nothing Same phone, same Wi-Fi, same code → only Debug works, TestFlight fails react-native-udp for UDP broadcast react-native-dns-lookup for resolving hostnames react-native-xml2js for parsing device responses
0
0
16
15h
Mac Catalyst: AUv3 Extension no longer works on MacOS, still works on iOS
I have a Catalyst app ('container') which hosts an embedded AUv3 Audio Unit extension ('plugin'). This used to work for years and has worked with this project until a few days ago. it still works on iOS as expected on MacOS the extension is never registered/installed and won't load extension won't show up with AUVal seems to have stopped working with the 26.1 XCode update I'm fairly certain the problem is not code related (i.e. likely build settings, project settings, entitlements, signing, etc.) I have compared all settings with another still-working project and can't find any meaningful difference (I can't request code-level support because even the minimal thing vastly exceeds the 250 lines of code limit.) How can I debug the issue? I literally don't know where to start to fix this problem, short of rebuilding the entire thing and hope that it magically starts working again.
0
0
96
16h
Reply to Phone unlock/lock detection
First off, a clarification here: When the phone is locked, then WhatsApp routes calls through Apple’s native CallKit. When unlocked, pressing accept essentially redirects to WhatsApp, and then WhatsApp handles the call from there. Are you sure this isn't the standard CallKit flow? Have you tested this with Speakerbox? It's possible I'm misunderstanding, but what you're describing sounds like how CallKit works by default. More specifically, accepting a call on an unlocked device opens the target app (as well as starting the call), and most apps present their own call UI when this open happens. Keep in mind that you can't actually implement a good call experience without using CallKit. For example, without CallKit, any other incoming call from any other app will immediately interrupt your call, effectively hanging up your current call. Note that this is not a theoretical problem but is in fact the primary developer complaint that led us to create CallKit. The problem is that if the phone has been recen
1d
Reply to iOS folder bookmarks
[quote='856443022, DTS Engineer, /thread/797469?answerId=856443022#856443022'] No, I'm talking about withoutImplicitStartAccessing. We explicitly say it does not apply to security-scoped bookmarks: [/quote] This option causes an implicit call to startAccessingSecurityScopedResource() on the returned URL when it’s ready to use the resource. The way this is written makes it sound like there will be a call to startAccessingSecurityScopedResource somewhere, so that a subsequent pair of explicit startAccessingSecurityScopedResource and stopAccessingSecurityScopedResource will still leave access at 1, leaking kernel resources. It his not the case? Is this consistent across macOS and iOS? This option isn’t applicable to security-scoped bookmarks. The documentation phrasing isn't clear about whether it's talking about NSURLBookmarkResolutionWithSecurityScope specifically (which is only available on macOS), or if it also applies to iOS (where all bookmarks are security scoped AFAIU from your earlier messages)
Topic: App & System Services SubTopic: Core OS Tags:
1d
Issue: Plain Executables Do Not Appear Under “Screen & System Audio Recording” on macOS 26.1 (Tahoe)
Summary I am investigating a change in macOS 26.1 (Tahoe) where plain (non-bundled) executables that request screen recording access no longer appear under: System Settings → Privacy & Security → Screen & System Audio Recording This behavior differs from macOS Sequoia, where these executables did appear in the list and could be managed through the UI. Tahoe still prompts for permission and still allows the executable to capture the screen once permission is granted, but the executable never shows up in the UI list. This breaks user expectations and removes UI-based permission management. To confirm the behavior, I created a small reproduction project with both: a plain executable, and an identical executable packaged inside an .app bundle. Only the bundled version appears in System Settings. Observed Behaviour 1. Plain Executable (from my reproduction project) When running a plain executable that captures the screen: macOS displays the normal screen-recording permission prompt. Before grantin
1
0
143
1d
Guideline 1.4.1 - Safety - Physical Harm
Hello everyone The application we developed is for pet medical care and is aimed at veterinarians The main function of the app is an AI conversation app, where the user talks to the AI. The AI answer content may involve disease diagnosis and treatment suggestions for pets. When we submitted it to the apple store for review, we received a 1.4.1 rejection notice (the app must clearly disclose data and methods to support accuracy claims related to health measurements) Our solutions Before entering the app, we have added a pop-up window (the pop-up window introduces that the output content of our app is generated by AI and cannot replace the malicious veterinary consultation and diagnosis. If you have health problems, please consult offline certified veterinarians and other content to ensure the safety of pets in a timely manner). Users must agree before proceeding to the next step of using the app. Our AI model has been registered with the algorithm (and we have also uploaded screenshots of the
1
0
157
1d
Reply to Are read-only filesystems currently supported by FSKit?
Are read-only filesystems currently supported by FSKit? I think the tricky part here is what support here actually means. Let me start by what this actually does: pass the -r or -o rdonly options to the mount(8) command. Passing that to mount should mean that the VFS layer itself is prevented from writing to the device. In FSKit terms, that means FSBlockDeviceResource.writable should be false and that all write methods should fail. If either of those behave differently, then that's a HUGE bug that we'd need to fix ASAP. However, the confusing point here is that mounting a volume readonly doesn't necessarily define/change how the file system presents itself to the higher level system. That is, strictly speaking, nothing prevents a volume being mounted readonly... but that file system itself allowing itself to be fully modifiable. That might sound a bit strange, but as a concrete example, you could implement a resettable file system by using the on-disk file system as the starting structure, routing al
Topic: App & System Services SubTopic: Core OS Tags:
2d