I can develop a PacketTunnelProvider on Mac with xcode. I work with my self codesign. But when I sign it with Developer ID after read https://developer.apple.com/forums/thread/737894 , it still fail when I turn on the vpn .

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?

Could someone please explain how to use a custom sound when setting up an alarm using AlarmKit? It keeps playing a default sound. Also, I keep having an issue where the alarm sound plays but doesn’t show the alarm interface buttons unless the screen is locked.

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 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?

Hello, I'm trying to adopt the new BGContinuedProcessingTask API, but I'm having a little trouble imagining how the API authors intended it be used. I saw the WWDC talk, but it lacked higher-level details about how to integrate this API, and I can't find a sample project. I notice that we can list wildcard background task identifiers in our Info.plist files now, and it appears this is to be used with continued tasks - a user might start one video encoding, then while it is ongoing, enqueue another one from the same app, and these tasks would have identifiers such as "MyApp.VideoEncoding.ABCD" and "MyApp.VideoEncoding.EFGH" to distinguish them. When it comes to implementing this, is the expectation that we: a) Register a single handler for the wildcard pattern, which then figures out how to fulfil each request from the identifier of the passed-in task instance? Or b) Register a unique handler for each instance of the wildcard pattern? Since you can't unregister handlers, any resources captured by the handler would be leaked, so you'd need to make sure you only register immediately before submission - in other words register + submit should always be called as a pair. Of course, I'd like to design my application to use this API as the authors intended it be used, but I'm just not entirely sure what that is. When I try to register a single handler for a wildcard pattern, the system rejects it at runtime (while allowing registrations for each instance of the pattern, indicating that at least my Info.plist is configured correctly). That points towards option B. If it is option B, it's potentially worth calling that out in documentation - or even better, perhaps introduce a new call just for BGContinuedProcessingTask instead of the separate register + submit calls? Thanks for your insight. K Aside: Also, it would be really nice if the handler closure would be async. Currently if you need to await on something, you need to launch an unstructured Task, but that causes issues since BGContinuedProcessingTask is not Sendable, so you can't pass it in to that Task to do things like update the title or mark the BGTask as complete.

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

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.

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 have set up a trivial test project to try Apple-hosted background assets following the instructions in the three articles at https://developer.apple.com/documentation/backgroundassets. When I run the local mock server with xcrun ba-serve and set the URL override in Settings as described in the "Testing asset packs locally" article, I am able to download a test pack on my iOS devices. On the Mac that I use to run the mock server, however, the same call to AssetPackManager.shared.assetPack(withID: "TestAssetPack") that works on iOS always reports The asset pack with the ID “TestAssetPack” couldn’t be looked up: No asset pack with the ID “TestAssetPack” was found. even when not running the mock server, which led me to believe that it may not be hitting it at all. In fact, the macOS app will download asset packs uploaded to App Store Connect even when running the local server and setting the xcrun ba-serve url-override to the exact same string as in Settings on iOS. My initial suspicion was that something is wrong with the URL override, so I have tried all combinations of the Mac's hostname, IP address or "localhost" (with the corresponding SSL certificates) with and without port 443, always prefixing with "https://" for the url-override. All the same. Does anyone have an idea what may be the issue here? My asset pack has the following manifest: { "assetPackID": "TestAssetPack", "downloadPolicy": { "onDemand": {} }, "fileSelectors": [ { "file": "TestAsset.txt" } ], "platforms": [ "iOS", "macOS" ] } I am running v26.1 for macOS, iOS & Xcode. Edit: Just to be clear, my assumption here is that the URL overrides (in Settings on iOS or via ba-serve on macOS) is what should cause the app to hit the mock server. Is that correct or am I missing something?

Security scoped bookmarks that were created before updating to macOS 14.7.5 cannot be resolved anymore after updating to macOS 14.7.5. Reproduction: Sandboxed app on macOS version 14.7.4 Create and store a security scoped bookmark to a user selected folder: let url: URL = <user selected url from NSOpenPanel> let data = try url.bookmarkData(options: [.withSecurityScope], includingResourceValuesForKeys: nil, relativeTo: nil) <persistently store data> Update to macOS 14.7.5 Resolve the previously stored bookmark: let data: Data = <restore data from persistent storage> var stale: Bool = true let url = try URL(resolvingBookmarkData: data, options: [.withSecurityScope], relativeTo: nil, bookmarkDataIsStale: &stale) Expected: The bookmark is resolved correctly and the resulting url can be used to access the folder/file in the sandboxed app after starting access. Observed: URL(resolvingBookmarkData:) throws an error: Error Domain=NSCocoaErrorDomain Code=259 "The file couldn’t be opened because it isn’t in the correct format." New security scoped bookmarks created on macOS 14.5.7 can be resolved without issue. The same appears to happen with macOS 13.7.5. Entitlements: com.apple.security.app-sandbox com.apple.security.files.bookmarks.app-scope com.apple.security.files.user-selected.read-write This is very disruptive, as it appears that Sandboxed apps cannot access any previously stored bookmarks anymore. Particularly after the recent ScopedBookmarkAgent issues in 14.7.1 and 15.0, which were resolved in 14.7.3/15.1 respectively: https://developer.apple.com/forums/thread/764435

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.

~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.

I'm using a Mac Studio in a homelab context and use Homebrew to manage the installed services. The services include things that access the local network, for example Prometheus which monitors some other servers, a reverse proxy which fronts other web services on the network, and a DNS server which can use another as upstream. Local Network Access permissions make it impossible to reliably perform unattended updates of services because an updated binary requires a GUI login to grant local network permissions (again). I use brew services to manage the services as launchd agents, i.e. they run in a non-root GUI context. I know that I can also use sudo brew services which instead installs the services as launchd daemons, but running services as root has negative security implication and generally doesn't look like a good idea to me. If only there was a way to disable local network access checks altogether…

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'm trying to implement Unwanted SMS and Calls reporting in an app I'm doing in my idle time. If I place a UITextField or UITextView inside a ILClassificationUIExtensionViewController, every time I select on such control the extension crashes without any logs. The closet idea I have on why it crashes it has something to do with iOS requesting the dictation feature. I'm using the latest (beta 8 at the time) iOS 16.0 beta on my iPhone 13 pro. Attaching my code here if you want to try for yourself: github

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.)

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.

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?

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!