I've been wondering what is the memory limit for network extensions. Specifically, I'm using the NEPacketTunnelProvider extension point.The various posts on this forum mention 5 MB and 6 MB for 32-bit and 64-bit respectively. However I find that (at least on iOS 10) the upper limit seems to be 15 MB. Is this the new memory limit for extensions?

Background: We are developing a cross-platform mobile application that communicates with a custom NFC-enabled hardware device. The hardware expects ISO7816-style APDU commands for data exchange and functions correctly with Android using the IsoDep protocol. Observed Issue on iOS: On iOS, the tag is only detectable via NFCNdefReaderSession, which provides access to INFCNdefTag. Attempting to use NFCTagReaderSession with NFCPollingOption.Iso14443 (which is required for APDU communication) results in no tag detection. As a result, the tag is inaccessible for APDU-based communication on iOS. Since NFCNdefReaderSession does not support APDU, we are unable to establish the required command channel. Constraints: The hardware firmware cannot be changed to support NDEF-based command interpretation. The device expects raw ISO-DEP APDU commands (i.e., Class-Instruction-Param1-Param2-Data-Le). Impact: The lack of ISO7816 tag detection on iOS prevents the app from sending APDU commands, resulting in a platform-specific feature limitation. Functionality that relies on secure, structured APDU communication is unavailable to iOS users, even though it works seamlessly on Android.

Hi all, I am adding the following StoreKit 2 code to my app, and I don't see anything in Apple's documentation that explains the unverified case. When is that case exercised? Is it when someone has tampered with the app receipt? Or is it for more mundane things like poor network connectivity? // Apple's docstring on `shared` states: // If your app fails to get an AppTransaction by accessing the shared property, see refresh(). // Source: https://developer.apple.com/documentation/storekit/apptransaction/shared var appTransaction: VerificationResult<AppTransaction>? do { appTransaction = try await AppTransaction.shared } catch { appTransaction = try? await AppTransaction.refresh() } guard let appTransaction = appTransaction else { AppLogger.error("Couldn't get the app store transaction") return false } switch appTransaction { case .unverified(appTransaction, verificationError): // For what reasons should I expect this branch to be entered in production? return await inspectAppTransaction(appTransaction, verifiedByApple: false) case .verified(let appTransaction): return await inspectAppTransaction(appTransaction, verifiedByApple: true) } Thank you, Lou

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'm unable to view Changes or Diff View in the Deploy Schema Changes Dialog due to an Internal Error.

macos 15.4 beta claims to support FSKit. Is there an FSKit sample available? I don't see anything useful in the published docs.

We have a that relies on accurate GPS location but we’ve noticed that every now and then the location ‘jumps’ a few hundred meters to a different location but reports horizonal accuracy less than 10m. we think the device is picking up a rough location from a local WiFi rather than internal gps sensors. can we a) disable WiFi location Updates? b) identify WiFi location Updates? thank You

All the threads only contain system calls. The crashed thread only contains a single call to my app's code which is main.swift:13. What could cause such a crash? crash.crash

We are trying to extend our app with Push To Talk functionality by integrating the Push To Talk framework. We are extensively testing what happens if the app is running in the foreground, in the background or not running at all. When the app is in the foreground, and the user has joined a channel we maintain an open connection to our server. When a remote participant starts streaming audio, we immediately call setActiveRemoteParticipant on our PTChannelManager instance. The PTT system will than call our delegate's channelManager:didActivate audioSession method and we can successfully play the incoming audio. When the app is not running at all, there is of course no active connection initially. When another participant starts talking we send a push notification. The PTT system will start our app in the background, call the incomingPushResult method on our delegate, after returning the remote participant the PTT framework will then call the channelmanager:didJoin delegate method which we will use to re-establish the server connection, the PTT framework then calls our channelManager:didActivate audioSession delegate method and we can then successfully play audio. Now the problem. When the application was initially in the foreground and has an established server connection, we initially keep the server connection active when the app enters the background state, until a certain timeout or the system decides our app needs to be killed / removed from memory. This allows us to finish an incoming audio stream, quickly react on incoming responses etc. When we then receive an incoming audio stream after a certain delay (for example 5 seconds) we call the channelManager.setRemoteParticipant method (using try await syntax). This finishes successfully, without any error, however the channelManager:didActivate audioSession delegate method is never called. Manually setting up an audio session is not allowed either and returns an error. Our current workaround for this issue is to disconnect the server connection as soon as the app goes into the background. This will make sure our server sends a push notification, which is successful in activating the audio session after which we can play audio. However, this means we need to re-establish the connection which will introduce an unnecessary delay before we can start playback (and currently means we loose some audio). This also means we need to do extra checks when going to the background to make sure there is no active incoming stream. After each incoming stream we have to check again if we are in the background and disconnect immediately to make sure we get a push notification next time. This can of course also lead to race conditions in an active conversation where we might need to disconnect between incoming streams and if we don't do this in time we might never get an activated audio session. Now this might be by design, as Apple might not want us to keep the server connection active when the application enters the background state. But if that's the case I would expect the channelManager.setRemoteParticipant method to throw an error, but it doesn't. It returns successfully after which we would expect the audio session to get activated as well. So maybe we are not setting the capabilities of our project correctly (we might need other background permissions as well, although we already experimented with that), or we need to do something else to make this work?

Reference: FB21797091 / Related to thread 807695 Hello, I have already submitted a report regarding this issue via Feedback Assistant (FB21797091), but I would like to share the technical details here to seek further insights or potential workarounds. We are experiencing a technical regression where Universal Links and Shared Web Credentials fail to resolve for Internationalized Domain Names (IDN) specifically on iOS 16 and later. This issue appears to be identical to the one discussed in thread 807695 (https://developer.apple.com/forums/thread/807695). Technical Contrast: What works vs. What fails On the exact same app build and iOS 16+ devices, we observe a clear distinction: Standard ASCII Domain (onelink.me): Works perfectly. (Proves App ID and Entitlements are correct) Internal Development Domain (Standard ASCII): Works perfectly. (Proves our server-side AASA hosting and HTTPS configuration are correct) Japanese IDN Domain (xn--[punycode].com): Fails completely. (Status: "unspecified") Note: This IDN setup was last confirmed to work correctly on iOS 15 in April 2025. Currently, we are unable to install the app on iOS 15 devices for live comparison, but the regression starting from iOS 16 is consistent. This "Triple Proof" clearly isolates the issue: the failure is strictly tied to the swcd daemon's handling of IDN/Punycode domains. Validation & Diagnostics: Validation: Our Punycode domain passes all technical checks on the http://Branch.io AASA Validator (Valid HTTPS, valid JSON structure, and Content-Type: application/json). sysdiagnose: Running swcutil on affected iOS 16+ devices shows the status as "unspecified" for the IDN domain. Symptoms: Universal Links consistently open in Safari instead of the app, the Smart App Banner is not displayed, and Shared Web Credentials for AutoFill do not function. Request for Resolution: We request a fix for this regression in the swcd daemon. If this behavior is a specification for security reasons, please provide developers with a supported method or workaround to ensure IDN domains function correctly. We have sysdiagnose logs available for further investigation. Thank you.

Hello everyone, We are migrating our KEXT for a Thunderbolt storage device to a DEXT based on IOUserSCSIParallelInterfaceController. We've run into a fundamental issue where the driver's behavior splits based on the I/O source: high-level I/O from the file system (e.g., Finder, cp) is mostly functional (with a minor ls -al sorting issue for Traditional Chinese filenames), while low-level I/O directly to the block device (e.g., diskutil) fails or acts unreliably. Basic read/write with dd appears to be mostly functional. We suspect that our DEXT is failing to correctly register its full device "personality" with the I/O Kit framework, unlike its KEXT counterpart. As a result, low-level I/O requests with special attributes (like cache synchronization) sent by diskutil are not being handled correctly by the IOUserSCSIParallelInterfaceController framework of our DEXT. Actions Performed & Relevant Logs 1. Discrepancy: diskutil info Shows Different Device Identities for DEXT vs. KEXT For the exact same hardware, the KEXT and DEXT are identified by the system as two different protocols. KEXT Environment: Device Identifier: disk5 Protocol: Fibre Channel Interface ... Disk Size: 66.0 TB Device Block Size: 512 Bytes DEXT Environment: Device Identifier: disk5 Protocol: SCSI SCSI Domain ID: 2 SCSI Target ID: 0 ... Disk Size: 66.0 TB Device Block Size: 512 Bytes 2. Divergent I/O Behavior: Partial Success with Finder/cp vs. Failure with diskutil High-Level I/O (Partially Successful): In the DEXT environment, if we operate on an existing volume (e.g., /Volumes/MyVolume), file copy operations using Finder or cp succeed. Furthermore, the logs we've placed in our single I/O entry point, UserProcessParallelTask_Impl, are triggered. Side Effect: However, running ls -al on such a volume shows an incorrect sorting order for files with Traditional Chinese names (they appear before . and ..). Low-Level I/O (Contradictory Behavior): In the DEXT environment, when we operate directly on the raw block device (/dev/disk5): diskutil partitionDisk ... -> Fails 100% of the time with the error: Error: -69825: Wiping volume data to prevent future accidental probing failed. dd command -> Basic read/write operations appear to work correctly (a write can be immediately followed by a read within the same DEXT session, and the data is correct). 3. Evidence of Cache Synchronization Failure (Non-deterministic Behavior) The success of the dd command is not deterministic. Cross-environment tests prove that its write operations are unreliable: First Test: In the DEXT environment, write a file with random data to /dev/disk5 using dd. Reboot into the KEXT environment. Read the data back from /dev/disk5 using dd. The result is a file filled with all zeros. Conclusion: The write operation only went to the hardware cache, and the data was lost upon reboot. Second Test: In the DEXT environment, write the same random file to /dev/disk5 using dd. Key Variable: Immediately after, still within the DEXT environment, read the data back once for verification. The content is correct! Reboot into the KEXT environment. Read the data back from /dev/disk5. This time, the content is correct! Conclusion: The additional read operation in the second test unintentionally triggered a hardware cache flush. This proves that the dd (in our DEXT) write operation by itself does not guarantee synchronization, making its behavior unreliable. Our Problem Based on the observations above, we have the conclusion: High-Level Path (triggered by Finder/cp): When an I/O request originates from the high-level file system, the framework seems to enter a fully-featured mode. In this mode, all SCSI commands, including READ/WRITE, INQUIRY, and SYNCHRONIZE CACHE, are correctly packaged and dispatched to our UserProcessParallelTask_Impl entry point. Therefore, Finder operations are mostly functional. Low-Level Path (triggered by dd/diskutil): When an I/O request originates from the low-level raw block device layer: The most basic READ/WRITE commands can be dispatched (which is why dd appears to work). However, critical management commands, such as INQUIRY and SYNCHRONIZE CACHE, are not being correctly dispatched or handled. This leads to the incorrect device identification in diskutil info and the failure of diskutil partitionDisk due to its inability to confirm cache synchronization. We would greatly appreciate any guidance, suggestions, or insights on how to resolve this discrepancy. Specifically, what is the recommended approach within DriverKit to ensure that a DEXT based on IOUserSCSIParallelInterfaceController can properly declare its capabilities and handle both high-level and low-level I/O requests uniformly? Thank you. Charles

I can reproduce the bug that CallKit doesn't active audiosession after the outgoing call put on hold because of an incoming call. VoIP calling with CallKit Steps to reproduce: Download SpeakerBox example app from the link above and start it with XCode Start a new outgoing call Call your phone from other phone Hold and Accept the call After a few secs finish the call from the other phone The outgoing call will be still on hold Click on the call and click Toggle Hold The call won't be active again because the audiosession is activated. Logs: Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Requested transaction successfully Starting audio Type: stdio AURemoteIO.cpp:1162 failed: 561017449 (enable 3, outf< 1 ch, 44100 Hz, Float32> inf< 1 ch, 44100 Hz, Float32>) Type: Error | Timestamp: 2024-08-15 12:20:29.949437+02:00 | Process: Speakerbox | Library: libEmbeddedSystemAUs.dylib | Subsystem: com.apple.coreaudio | Category: aurioc | TID: 0x19540d AVAEInternal.h:109 [AVAudioEngineGraph.mm:1344:Initialize: (err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)): error 561017449 Type: Error | Timestamp: 2024-08-15 12:20:29.949619+02:00 | Process: Speakerbox | Library: AVFAudio | Subsystem: com.apple.avfaudio | Category: avae | TID: 0x19540d Couldn't start Apple Voice Processing IO: Error Domain=com.apple.coreaudio.avfaudio Code=561017449 "(null)" UserInfo={failed call=err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)} Type: Notice | Timestamp: 2024-08-15 12:20:29.949730+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d Route change: Type: Notice | Timestamp: 2024-08-15 12:20:30.167498+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d ReasonUnknown Type: Notice | Timestamp: 2024-08-15 12:20:30.167549+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d Previous route: Type: Notice | Timestamp: 2024-08-15 12:20:30.167568+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d <AVAudioSessionRouteDescription: 0x302c00bc0, inputs = ( "<AVAudioSessionPortDescription: 0x302c01330, type = MicrophoneBuiltIn; name = iPhone Mikrofon; UID = Built-In Microphone; selectedDataSource = (null)>" ); outputs = ( "<AVAudioSessionPortDescription: 0x302c004d0, type = Receiver; name = Vev\U0151; UID = Built-In Receiver; selectedDataSource = (null)>" )> Type: Notice | Timestamp: 2024-08-15 12:20:30.167626+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d

I have this code in my Virutalization application let process = Process() process.executableURL = URL(fileURLWithPath: "/usr/sbin/diskutil") process.arguments = ["image", "create", "blank", "--fs", "none", "--format", "ASIF", "--size", "2GiB", url.path ] try process.run() process.waitUntilExit() if process.terminationStatus == 0 { print("✅ Disk image creation succeeded.") } else { print("❌ Disk image creation failed with exit code \(process.terminationStatus)") } } catch { print("Process failed to launch: \(error.localizedDescription)") return } this code was working fine until Tahoe 26.2. with the update of 26.3 the system freezes at process.waitUntilExit() The code never exits and i get beech balls. This is working fine with intel macs. i am getting the problem in apple silicon m4 mac mini. Any help would be appreciated.

See crash details here:- https://pastebin.com/i9u5PE4X There's a comprehensive thread here, folks! https://discussions.apple.com/thread/255651156?sortBy=oldest_first Thanks for any thoughts.

Hi and help needed! I updated my iPhone 16 Pro max to iOs 26. When I go to the software update section, the beta developer tab is gone, and it says "Unable to check for update" I reset my network settings and restarted the device. No change. Any help would be appreciated.

Hello, Title states it basically. I have a java program (launched via shell script) running as a service using launchd which is running as a user (not root) and it does not request Local Network permissions ever. I feel like i'm missing something here. I combed through all of the Local Network FAQs and don't really see this use case addressed. I do see that there is an open ticket for an API to trigger the request, but no update on that and the ticket is not visible publicly. Is there is a way to accomplish this for java or other programs running via launchd with a user other than root? something like an entitlement or an API to seed the permission of Local Network when installing the service via launchctl etc?

When I've tried to use UIDevice on my Mac running my Catalyst application, testing code UIDevice *d=UIDevice.currentDevice; for (NSString *k in @[@"name", @"systemName", @"systemVersion", @"model", @"localizedModel"]) NSLog(@"%@ -> %@", k, [d valueForKey:k]); to my great surprise I am getting name -> iPad systemName -> iPadOS systemVersion -> 26.3 model -> iPad localizedModel -> iPad What the. How do I determine the real values? Thanks!

~5% of our users when downloading the iOS application from the Apple Store for the first time are unable to enrol a Passkey and experience an error saying the application is not associated with [DOMAIN]. The error message thrown by the iOS credentials API is "The operation couldn't be completed. Application with identifier [APPID] is not associated with domain [DOMAIN]" We have raised this via the developer support portal with case id: 102315543678 Question: Why does the AASA file fail to fetch on app install and is there anything that can be done to force the app to fetch the file? Can this bug be looked at urgently as it is impacting security critical functionality? Other Debugging Observations We have confirmed that our AASA file is correctly formatted and hosted on the Apple CDN. Under normal circumstances the association is created on install and Passkey enrolment works as intended. We have observed that when customers uninstall/reinstall the app this often, but not always, resolves the issue. We also know this issue can resolve itself overtime without any intervention. We have ruled out network (e.g VPN) issues and have reproduced the issue across a number of different network configurations. We have ruled out the Keychain provider and have reproduced it across a variety of different providers and combinations of. We observed this across multiple versions of the iOS operating system and iPhone hardware including the latest hardware and iOS version.

When a VPN is active, RCS messaging does not work on iOS 18. I work on an iOS VPN app, and we were very appreciative of the excludeCellularServices network flag that was released during the iOS 16 cycle. It's a great solution to ensure the VPN doesn't interfere with cellular network features from the cellular provider. Separately - As a user, I'm excited that iOS 18 includes RCS messaging. Unfortunately, RCS messaging is not working when our VPN is active (when checking on the iOS 18 release candidate). My guess is that RCS is not excluded from the VPN tunnel, even when excludeCellularServices is true. It seems like RCS should be added in this situation, as it is a cell provider service. Can RCS be added as a service that is excluded from the VPN tunnel when excludeCellularServices is true? (I've also sent this via feedback assistant, as 15094270.)

We have received some information that with the release of iOS 18, there have been notable changes in how this API behaves, can apple team shed some light on this? on ios 17 this worked without much issues, what has changed on ios 18?