Hi team,
I’m having an issue with my iOS app related to local network communication and connecting to a Wi-Fi speaker.
My app works similar to the “4Stream” application. The speaker and the mobile device must be on the same Wi-Fi network so the app can discover and connect to the speaker.
What’s happening:
When I run the app directly from Xcode in debug mode, everything works perfectly.
The speaker gets discovered.
The speaker gets connected successfully.
The connection flow completes without any problem.
But when I upload the same build to TestFlight, the behaviour changes completely.
The app gets stuck on the “Connecting…” screen.
The speaker is not discovered.
But the same code is working fine on Android
It never moves forward from that state.
So basically:
Debug Mode: Speaker is detected and connected properly
TestFlight: Stuck at “Connecting…”, speaker does NOT get connected
This makes me believe something related to local network access, multicast, Wi-Fi info permissions, or Bonjour discovery is not being applied correctly in the release/TestFlight environment.
Below is my current Info.plist and Entitlements file, which already include Local Network Usage, Bonjour services, Location usage for SSID, multicast entitlements, wifi-info, etc.
My Info.plist
<key>CADisableMinimumFrameDurationOnPhone</key>
<true/>
<key>CFBundleDevelopmentRegion</key>
<string>en</string>
<key>CFBundleDisplayName</key>
<string>Wanwun</string>
<key>CFBundleExecutable</key>
<string>$(EXECUTABLE_NAME)</string>
<key>CFBundleIdentifier</key>
<string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>$(PRODUCT_NAME)</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>$(MARKETING_VERSION)</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>$(CURRENT_PROJECT_VERSION)</string>
<key>LSRequiresIPhoneOS</key>
<true/>
<!-- Allow HTTP to devices on LAN -->
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
<key>NSExceptionDomains</key>
<dict>
<key>local</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<key>NSIncludesSubdomains</key>
<true/>
</dict>
<key>localhost</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
<key>NSIncludesSubdomains</key>
<true/>
</dict>
</dict>
</dict>
<!-- Local Network Usage -->
<key>NSLocalNetworkUsageDescription</key>
<string>This app needs local network access to discover and control your sound system device over Wi-Fi.</string>
<!-- Bonjour services for discovery -->
<key>NSBonjourServices</key>
<array>
<string>_http._tcp.</string>
<string>_wrtn._tcp.</string>
<string>_services._dns-sd._udp.</string>
</array>
<!-- Location for SSID Permission -->
<key>NSLocationWhenInUseUsageDescription</key>
<string>This app requires location access to read the connected Wi-Fi information.</string>
<!-- Camera / Photos -->
<key>NSCameraUsageDescription</key>
<string>This app needs camera access to capture attendance photos.</string>
<key>NSPhotoLibraryAddUsageDescription</key>
<string>This app saves captured photos to your gallery.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>This app needs access to your gallery to upload existing images.</string>
<!-- Bluetooth -->
<key>NSBluetoothAlwaysUsageDescription</key>
<string>This app uses Bluetooth to discover nearby sound system devices.</string>
<key>NSBluetoothPeripheralUsageDescription</key>
<string>This app uses Bluetooth to connect with your sound system.</string>
<!-- Launch screen -->
<key>UILaunchStoryboardName</key>
<string>LaunchScreen</string>
<!-- Device Capabilities -->
<key>UIRequiredDeviceCapabilities</key>
<array>
<string>arm64</string>
</array>
<!-- Orientation -->
<key>UISupportedInterfaceOrientations</key>
<array>
<string>UIInterfaceOrientationPortrait</string>
<string>UIInterfaceOrientationLandscapeLeft</string>
<string>UIInterfaceOrientationLandscapeRight</string>
</array>
<key>UIViewControllerBasedStatusBarAppearance</key>
<false/>
My Entitlements
What I need help with:
I want to understand why the app behaves correctly in debug mode (where the speaker connects without issues), but the same functionality fails in TestFlight.
Is there something additional required for:
Local network discovery on TestFlight?
Multicast networking?
Reading the Wi-Fi SSID?
Bonjour, service scanning?
Release build / TestFlight network permissions?
If any extra entitlement approval, configuration, or specific service type is needed for TestFlight builds, please guide me.
Thank you for your help.
Overview
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
System Information in macOS from 26.0 to 26.2 RC no longer provides Wi-Fi SSIDs; instead, it displays "< redacted> " for every SSID on my two MacBooks.
This issue has been fixed in macOS 26.1 beta and macOS 26.2 beta, but it returns in the RC and the Final Release versions. Is it an expected behaviour or a bug in the Release Candidate?
MacBook Air 2025:
MacBook Pro 2021:
Hi, We are trying to use Apple Security API for KeyChain Services.
Using the common App Group : Specifying the common app group in the "kSecAttrAccessGroup" field of the KeyChain query, allowed us to have a shared keychains for different apps (targets) in the app group, but this did not work for extensions.
Enabling the KeyChain Sharing capability : We enabled the KeyChain Sharing Ability in the extensions and the app target as well, giving a common KeyChain Access group. Specifying this in the kSecAttrAccessGroup field also did not work. This was done in XCode as we were unable to locate it in the Developer portal in Indentifiers.
We tried specifying "$AppIdentifier.KeyChainSharingGroup" in the kSecAttrAccessGroup field , but this did not work as well
The error code which we get in all these 3 cases when trying to access the Keychain from the extension is error code 25291 (errSecNotAvailable). The Documentation says this error comes when "No Trust Results are available" and printing the error in xcode using the status says "No keychain is available.
The online Documentation says that it is possible to share keychain with extensions, but by far we are unable to do it with the methods suggested.
Do we need any special entitlement for this or is there something we are missing while using these APIs?
We really appreciate any and all help in solving this issue!
Thank you
I encountered a concurrency compilation warning when calling the TranslationSession.translations(from: [TranslationSession.Request]) API, and I'm don't know how to resolve it. I reviewed the official demo, but it appears identical.
I got this email from Apple
"Due to the discontinuation of content associated with your vendor number x, your payments have been paused. We will continue to monitor this account and release your payments once customer refunds have been settled."
Does anyone know what happened? I didn't discontinue any content.
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect
I originally created my Apple Developer account when I was living in Canada (years ago). Now that I live in the U.S. I want to renew it, but I can't - because it thinks I'm still in Canada. When I go to change my contact information, I get a screen that says:
"Unauthorized
Your account can’t access this page.
There may be certain requirements to view this content.
If you’re a member of a developer program, make sure your Account Holder has agreed the latest license agreement."
What do I do?
Hello,
I'm experiencing a significant delay getting the Family Controls entitlement approved for my Shield Configuration Extension, and I'm hoping someone here can help or has experienced something similar.
Background:
I'm developing an app that uses the Screen Time API with Family Controls. My main app bundle (lukedev.Bloka) was approved for Family Controls (Distribution) and works perfectly.
The Problem
My Shield Configuration Extension (lukedev.Bloka.Shield) has been stuck waiting for approval for over 2 weeks:
Request ID: 6C8LD22UVM
Submitted: November 20, 2025
Status: Still "Submitted"
Current State: Only shows "Family Controls (Development)" in capabilities
What I've Tried
✅ Submitted entitlement request via the proper channels
✅ Contacted Apple Developer Support (case #102762028251)
✅ Verified the main app has full Family Controls approval
✅ Deleted and regenerated all provisioning profiles multiple times
✅ Confirmed the App ID configuration is correct in the Developer Portal
The Issue
Without Family Controls (Distribution) approval for the Shield extension, I cannot:
Test the complete app functionality on physical devices
Submit the app to App Store Connect
Move forward with development
The error I'm getting during provisioning:
Provisioning profile failed qualification
Profile doesn't include the com.apple.developer.family-controls entitlement
Questions
Has anyone experienced multi-week delays for Shield extension entitlements? Is this normal?
Should Shield extensions automatically inherit entitlements from the main app, or do they really require separate approval? The documentation isn't clear on this.
Are there any known workarounds to test Shield Configuration Extensions during development while waiting for distribution approval?
How can I escalate this request? Developer Support initially told me I already had approval (for the main app) but didn't address the extension's separate bundle ID.
Technical Details
Xcode: 16.2
Target: iOS 18+
Main App: Family Controls (Distribution) ✅ Approved
Shield Extension: Family Controls (Development only) ❌ Stuck
Why This Matters
The Shield Configuration Extension is a core component of Screen Time API apps - it's not optional. Without it, the app cannot properly display blocking interfaces. The fact that it requires a separate 2+ week approval process (after the main app was already approved) seems like a significant oversight in Apple's review process.
Has anyone successfully navigated this situation or found a way to expedite the review?
Any help or insights would be greatly appreciated!
Thanks,
Luca
Topic:
Developer Tools & Services
SubTopic:
Apple Developer Program
Tags:
Entitlements
Family Controls
Managed Settings
Screen Time
Hello,
I've discovered a buffer initialization bug in AVAudioUnitSampler that happens when loading presets with multiple zones referencing different regions in the same audio file (monolith/concatenated samples approach).
Almost all zones output silence (i.e. zeros) at the beginning of playback instead of starting with actual audio data.
The Problem
Setup:
Single audio file (monolith) containing multiple concatenated samples
Multiple zones in an .aupreset, each with different sample start and sample end values pointing to different regions of the same file
All zones load successfully without errors
Expected Behavior:
All zones should play their respective audio regions immediately from the first sample.
Actual Behavior:
Last zone in the zone list: Works perfectly - plays audio immediately
All other zones: Output [0, 0, 0, 0, ..., _audio_data] instead of [real_audio_data]
The number of zeros varies from event to event for each zone. It can be a couple of samples (<30) up to several buffers.
After the initial zeros, the correct audio plays normally, so there is no shift in audio playback, just missing samples at the beginning.
Minimal Reproduction
1. Create Test Monolith Audio File
Create a single Wav file with 3 concatenated 1-second samples (44.1kHz):
Sample 1: frames 0-44099 (constant amplitude 0.3)
Sample 2: frames 44100-88199 (constant amplitude 0.6)
Sample 3: frames 88200-132299 (constant amplitude 0.9)
2. Create Test Preset
Create an .aupreset with 3 zones all referencing the same file:
Pseudo code
<Zone array>
<zone 1> start : 0, end: 44099, note: 60, waveform: ref_to_monolith.wav;
<zone 2> start sample: 44100, note: 62, end sample: 88199, waveform: ref_to_monolith.wav;
<zone 3> start sample: 88200, note: 64, end sample: 132299, waveform: ref_to_monolith.wav;
</Zone array>
3. Load and Test
// Load preset into AVAudioUnitSampler
let sampler = AVAudioUnitSampler()
try sampler.loadAudioFiles(from: presetURL)
// Play each zone (MIDI notes C4=60, D4=62, E4=64)
sampler.startNote(60, withVelocity: 64, onChannel: 0) // Zone 1
sampler.startNote(62, withVelocity: 64, onChannel: 0) // Zone 2
sampler.startNote(64, withVelocity: 64, onChannel: 0) // Zone 3
4. Observed Result
Zone 1 (C4): [0, 0, 0, ..., 0.3, 0.3, 0.3] ❌ Zeros at beginning
Zone 2 (D4): [0, 0, 0, ..., 0.6, 0.6, 0.6] ❌ Zeros at beginning
Zone 3 (E4): [0.9, 0.9, 0.9, ...] ✅ Works correctly (last zone)
What I've Extensively Tested
What DOES Work
Separate files per zone:
Each zone references its own individual audio file
All zones play correctly without zeros
Problem: Not viable for iOS apps with 500+ sample libraries due to file handle limitations
What DOESN'T Work (All Tested)
1. Different Audio Formats:
CAF (Float32 PCM, Int16 PCM, both interleaved and non-interleaved)
M4A (AAC compressed)
WAV (uncompressed)
SF2 (SoundFont2)
Bug persists across all formats
2. CAF Region Chunks:
Created CAF files with embedded region chunks defining zone boundaries
Set zones with no sampleStart/sampleEnd in preset (nil values)
AVAudioUnitSampler completely ignores CAF region metadata
Bug persists
3. Unique Waveform IDs:
Gave each zone a unique waveform ID (268435456, 268435457, 268435458)
Each ID has its own file reference entry (all pointing to same physical file)
Hypothesized this might trigger separate buffer initialization
Bug persists - no improvement
4. Different Sample Rates:
Tested: 44.1kHz, 48kHz, 96kHz
Bug occurs at all sample rates
5. Mono vs Stereo:
Bug occurs with both mono and stereo files
Environment
macOS: Sonoma 14.x (tested across multiple minor versions)
iOS: Tested on iOS 17.x with same results
Xcode: 16.x
Frameworks: AVFoundation, AudioToolbox
Reproducibility: 100% reproducible with setup described above
Impact & Use Case
This bug severely impacts professional music applications that need:
Small file sizes: Monolith files allow sharing compressed audio data (AAC/M4A)
iOS file handle limits: Opening 400+ individual sample files is not viable on iOS
Performance: Single file loading is much faster than hundreds of individual files
Standard industry practice: Monolith/concatenated samples are used by EXS24, Kontakt, and most professional samplers
Current Impact:
Cannot use monolith files with AVAudioUnitSampler on iOS
Forced to choose between: unusable audio (zeros at start) OR hitting iOS file limits
No viable workaround exists
Root Cause Hypothesis
The bug appears to be in AVAudioUnitSampler's internal buffer initialization when:
Multiple zones share the same source audio file
Each zone specifies different sampleStart/sampleEnd offsets
Key observation: The last zone in the zone array always works correctly.
This is NOT related to:
File permissions or security-scoped resources (separate files work fine)
Audio codec issues (happens with uncompressed PCM too)
Preset parsing (preset loads correctly, all zones are valid)
Questions
Is this a known issue? I couldn't find any documentation, bug reports, or discussions about this.
Is there ANY workaround that allows monolith files to work with AVAudioUnitSampler?
Alternative APIs? Is there a different API or approach for iOS that properly supports monolith sample files?
Hi Team,
We are planning to implement the age verification logic in our iOS app and our app rating in AppstoreCoonnect is 16+. Our app is like eComm Application. Our customer can login into our application and order the products. Now we want to introduce the Age verification logic when user tries to purchase products from App. Could you suggest which API we should use to adhere the Age verification in our Application?
SMBClient-593 introduces a crtitical bug.
When reading and writing data at high volume, the SMBClient no longer properly receives and handle responses from the server.
In some cases, the client mishandles the response packet and the following errors are seen in the logs:
2025-12-02 21:36:04.774772-0700 localhost kernel[0]: (smbfs) smb2_smb_parse_write_one: Bad struct size: 0
2025-12-02 21:36:04.774776-0700 localhost kernel[0]: (smbfs) smb2_smb_write: smb2_smb_read_write_async failed with an error 72
2025-12-02 21:36:04.774777-0700 localhost kernel[0]: (smbfs) smbfs_do_strategy: file.txt: WRITE failed with an error of 72
In other cases, the client mishandles the response packet and becomes completely unresponsive, unable to send or receive additional messages, and a forced shutdown of the computer is required to recover.
This bug is only present on macos 26. We believe the operative change is in the latest commit, SMBClient-593 beginning at line now 3011 in smb_iod.c. The issue seems to be a race, and occurs much more frequently once throughput exceeds around 10Gbps, and again more frequently above 20Gbps.
I'm having trouble with the app review process. My app has been in "Pending Review" status for almost 30 days, when normally it would be completed within 12 hours. We have a big launch event coming up, and this delay is significantly impacting our plans.
I recently deleted my old review request and resubmitted it and it's still in Waiting for review status I need help
Has anyone else experienced similar delays recently? Any advice on how to speed up the process or report the issue to Apple would be appreciated.
Structs are value types, and the SwiftUI gets reinitialized many times throughout its lifecycle. Whenever it gets reinitialized, would the reference that the delegator has of it still work if the View uses @State or @StateObject that hold a persistent reference to the views data?
protocol MyDelegate: AnyObject {
func didDoSomething()
}
class Delegator {
weak var delegate: MyDelegate?
func trigger() {
delegate?.didDoSomething()
}
}
struct ContentView: View, MyDelegate {
private let delegator = Delegator()
@State counter = 1
var body: some View {
VStack {
Text("\(counter)")
Button("Trigger") {
delegator.trigger()
}
}
}
func didDoSomething() {
counter += 1 //would this call update the counter in the view even if the view's instance is copied over to the delegator?
}
}
Mình muốn tạo một áp cho thương hiệu bên mình: rượu ngoại thì có khó khăn gì không
Topic:
App Store Distribution & Marketing
SubTopic:
General
Apple reported a problem with my App that they are getting certain issue, While logging into the app. My App is built on Ionic Cordova.
I tried to reproduce the issue on Simulators, Actual Devices and Test Flight. But the app is functional. What do I do? Apple is not approving the builds
Topic:
App Store Distribution & Marketing
SubTopic:
App Review
My development team admin requested the Enterprise API for camera access on the vision pro. We got that granted, got a license for usage, and got instructions for integrating it with next steps.
We did the following:
Even when I try to download and run the sample project for "Accessing the Main Camera", and follow all the exact instructions mentioned here: https://developer.apple.com/documentation/visionos/accessing-the-main-camera
I am just unable to receive camera frames.
I added the capabilities, created a new provisioning profile with this access, added the entitlements to info.plist and entitlements, replaced the dummy license file with the one we were sent, and also have a matching bundle identifier and development certificate, but it is still not showing camera access for some reason.
"Main Camera Access" shows up in our Signing & Capabilities tab, and we also added the NSMainCameraDescription in the Info.plist and allow access while opening the app. None of this works. Not on my app, and not on the sample app that I just downloaded and tried to run on the Vision Pro after replacing the dummy license file.
Dear Apple Developer Support Team,
I hope you are doing well.
We are reaching out to request clarification and guidance regarding the In-App Purchase (IAP) requirements for our upcoming iOS application.
Our app offers paid access to digital video content. Each video has a dynamic price determined by our backend based on multiple factors (such as duration, category, and promotions). Additionally, users are allowed to select and purchase multiple videos at the same time, which results in a combined total price that varies per transaction.
Challenges we face with IAP on iOS
Dynamic pricing:
Apple requires IAP products to have static pricing defined in App Store Connect.
Our video prices change frequently and cannot be represented by fixed IAP product SKUs.
Multiple-item purchases:
iOS does not support a single purchase that includes multiple different IAP products.
Processing many separate IAP transactions in sequence results in a poor user experience and is likely to cause failures.
Product creation limitations:
Since our catalog contains many videos with frequently changing prices, it is not feasible to create individual IAP products per video.
Given these restrictions, we are unclear how to remain compliant while still providing a functional purchase flow for our users.
Question
In this scenario, where:
video prices are dynamic,
users may purchase multiple videos together, and
IAP does not support multi-item purchases or dynamic pricing,
are we allowed to use Stripe or another external payment provider to handle these purchases?
If not, we would appreciate Apple’s guidance on what the recommended and compliant approach would be for apps that must price digital content dynamically and allow bulk purchasing.
We want to ensure full compliance with App Store Review Guidelines and would like confirmation on the correct implementation strategy before proceeding.
Thank you for your time, and we look forward to your clarification.
Kind regards,
Muhammad Adnan
Koderlabs
Regarding the Background Assets capability on iOS:
In the install scenario, resources defined as the "install" type are incorporated into the App Store download progress. Do resources of the "update" type in the update scenario also get incorporated into the App Store download progress in the same way?
If an exception occurs during the download of install-type resources and the download cannot proceed further, will the system no longer actively block users from launching the app and instead enable the launch button?
Currently, if a user has enabled automatic updates on their device, after the app is updated and released on the App Store, will the Background Assets download start immediately once the automatic update completes? Or does Background Assets have its own built-in scheduling logic that prevents it from running concurrently with the automatic update?
Platforms: macOS 15.x (Sequoia), Intel-Based
App type: Endpoint Security (ES) client, notarized Developer ID app + LaunchDaemon
Goal: Boot-time ES client that runs on any Mac (managed or unmanaged)
Summary
Our ES client launches and functions when started manually (terminal), but when loaded as a LaunchDaemon it fails to initialize the ES connection with:
(libEndpointSecurity.dylib) Failed to open service: 0xe00002d8: Caller lacks TCC authorization for Full Disk Access
We can’t find a supported way to grant Full Disk Access (SystemPolicyAllFiles) to a system daemon on unmanaged Macs (no MDM). Local installation of a PPPC (TCC) profile is rejected as “must originate from a user-approved MDM server.”
We’re seeking confirmation: Is MDM now the only supported path for a boot-time ES daemon that requires FDA? If so, what’s Apple’s recommended approach for unmanaged Macs?
Environment & Artifacts
Binary (path placeholder):
/Library/Application Support///App/.app/Contents/MacOS/
Universal (x86_64 + arm64)
Notarized, hardened runtime; Developer ID Team <TEAM_ID>
Entitlements include:
com.apple.developer.endpoint-security.client (present)
Daemon plist (simplified; placeholders used):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
<key>Label</key> <string>com.example.esd</string>
<key>Program</key>
<string>/Library/Application Support/<VENDOR>/<PRODUCT>/Platform/<daemon-exec></string>
<key>WorkingDirectory</key>
<string>/Library/Application Support/<VENDOR>/<PRODUCT>/Platform</string>
<key>RunAtLoad</key><true/>
<key>KeepAlive</key><true/>
</dict></plist>
Designated requirement (abridged & masked):
identifier "<BUNDLE_ID>" and anchor apple generic and certificate 1[...] and
certificate leaf[...] and certificate leaf[subject.OU] = "<TEAM_ID>"
What works
Launching the ES client manually (interactive shell) succeeds; ES events flow.
Signature, notarization, entitlements, Gatekeeper: all OK.
What fails (daemon)
launchctl print system/ shows it starts, but Console logs:
(libEndpointSecurity.dylib) Failed to open service: 0xe00002d8:Caller lacks TCC authorization for Full Disk Access
System TCC DB shows ES consent rows but no allow for TCCServiceSystemPolicyAllFiles for the daemon binary.
Installing a PPPC mobileconfig locally (system scope) is blocked as “must originate from a user-approved MDM server.”
Repro (minimal)
Install app bundle + LaunchDaemon plist above (placeholders).
Verify entitlements & notarization:
codesign -dvvv --entitlements :- ""
spctl --assess --type execute -vv ""
Start daemon & watch logs:
sudo launchctl bootstrap system "/Library/LaunchDaemons/.plist"
log stream --style compact --predicate 'process == "" OR subsystem == "com.apple.TCC"' --info
Observe FDA denial message only in daemon context.
Attempt to add FDA via PPPC profile (system scope) → rejected unless installed by user-approved MDM.
Questions for Apple
On macOS 14/15, is Full Disk Access for system daemons strictly MDM-only via PPPC (i.e., not installable locally)?
Under what conditions would libEndpointSecurity report a Full Disk Access denial at client initialization, given ES consent is distinct from FDA?
For unmanaged Macs needing boot-time ES processing, does Apple recommend a split: root LaunchDaemon (ES subscription; no protected file I/O) + per-user LaunchAgent (user-granted FDA) via XPC for on-demand disk access?
Would moving ES connection code into a System Extension change FDA requirements for unmanaged devices, or is FDA still governed by PPPC/MDM?
If behavior changed across releases, can Apple confirm the intended policy so vendors can document MDM requirements vs. unmanaged install paths?
What we’ve tried
Verified signature, notarization, hardened runtime, ES entitlement present.
Confirmed context difference: manual run OK; daemon fails.
Inspected system TCC: ES consent rows present; no FDA allow for daemon.
Tried installing system-scoped PPPC locally → blocked as “must originate from a user-approved MDM server.”
Considered LaunchAgent-only, but ES needs root; evaluating daemon+agent split to keep ES in root and put FDA-gated work in user space.
What we need
A definitive statement on the supported way to grant FDA to a system daemon on macOS 14/15.
If MDM PPPC is required, we’ll ship “daemon mode requires MDM” and provide a daemon+agent fallback for unmanaged devices.
If a compliant non-MDM path exists for daemon FDA on unmanaged Macs, please share exact steps.
Thanks! Happy to provide additional logs privately if helpful.
I am facing a persistent issue with an Endpoint Security (ES) extension that is crashing only when processing the ES_EVENT_TYPE_AUTH_OPEN event. Other event types, including ES_EVENT_TYPE_NOTIFY_OPEN and ES_EVENT_TYPE_NOTIFY_MMAP, work without any problems.
func startMonitoring() {
guard !isMonitoring else { return }
let result = es_new_client(&gClient) { (client, message) in
guard message.pointee.action_type == ES_ACTION_TYPE_AUTH else { return }
let pid = audit_token_to_pid(message.pointee.process.pointee.audit_token)
if pid == gSelfPID {
es_respond_flags_result(client, message, 0x7FFFFFFF, true)
var token = message.pointee.process.pointee.audit_token
es_mute_process(client, &token)
return
}
guard message.pointee.event_type == ES_EVENT_TYPE_AUTH_OPEN else {
es_respond_auth_result(client, message, ES_AUTH_RESULT_ALLOW, true)
return
}
let pathData = message.pointee.event.open.file.pointee.path
guard let pathPtr = pathData.data else {
es_respond_flags_result(client, message, 0x7FFFFFFF, true)
return
}
if shouldSkipPath(pathPtr, length: pathData.length) {
es_respond_flags_result(client, message, 0x7FFFFFFF, true)
return
}
if !hasBlockedExtension(pathPtr, length: pathData.length) {
es_respond_flags_result(client, message, 0x7FFFFFFF, true)
return
}
guard let execPathPtr = message.pointee.process.pointee.executable.pointee.path.data else {
es_respond_flags_result(client, message, 0x7FFFFFFF, true)
return
}
if isGoogleChrome(execPathPtr) {
es_respond_auth_result(client, message, ES_AUTH_RESULT_DENY, true)
} else {
es_respond_flags_result(client, message, 0x7FFFFFFF, true)
var token = message.pointee.process.pointee.audit_token
es_mute_process(client, &token)
}
}
guard result == ES_NEW_CLIENT_RESULT_SUCCESS, let client = gClient else { return }
es_clear_cache(client)
muteNoisyPaths(client: client)
let events: [es_event_type_t] = [ES_EVENT_TYPE_AUTH_OPEN]
let subResult = es_subscribe(client, events, UInt32(events.count))
guard subResult == ES_RETURN_SUCCESS else {
es_delete_client(client)
gClient = nil
return
}
isMonitoring = true
}
So I noticed this:
A sheet window is presented.
The sheet window has some UI that makes it expandable say a little arrow expandable button.
Click the little expandable button. Now the sheet window controller calls - (void)setFrame:display:animate: on its window to resize.
The parent window flies across the screen to the lower left corner.
I'm on Tahoe 26.1. Seems to be related to NSSheetMoveHelper. Not sure how long this bug has been around. Workaround is to call -setFrame:display:animate: and pass NO to the animate flag. Then the sheet window resizes (but not animated which doesn't look as good as the old behavior but better than suddenly disappearing).
I think Apple may already knows about this bug b/c in an Apple app on Tahoe I see a sheet resizing being done with no animation...