Overview

I've been trying over the past few days to use a PIV-programmed Yubikey to perform mTLS (i.e. mutual client cert auth) in my custom app. My understanding is that I need to feed NSURLSession a SecIdentity to do so. Yubico's instructions state that I need their Yubico Authenticator app for this, but this directly contradicts Apple's own documentation here. I dont need NFC/lightening support, and I only need support for my specific app. When I plug in my key to my iPhone and have TKTokenWatcher active, I DO see "com.apple.pivtoken" appear in the logs. And using Yubico's SDK, I CAN get data from the key (so I'm pretty sure my entitlements and such are correct). But using the below query to get the corresponding (fake? temporary?) keychain item, it returns NULL no matter what I do: let query: [String: Any] = [ kSecClass as String: kSecClassIdentity, kSecReturnRef as String: true, kSecAttrTokenID as String: "apple.com.pivtoken", // Essential for shared iPads kSecMatchLimit as String: kSecMatchLimitOne ] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &item) "status" is always -25300 (which is "not found"). I've also created a CTK extension (as Yubico's authenticator does) and tried to use self.keychainContents.fill(), and then tried to access it with kSecAttrTokenID as ":Yubico YubiKey OTP+FIDO+CCID", as that's what shows via TKTokenWatcher, and this also doesn't work. I've also tried just the app extension ID, and that doesn't work. Both my extension and my main app have the following entitlements: <key>com.apple.developer.default-data-protection</key> <string>NSFileProtectionComplete</string> <key>com.apple.security.application-groups</key> <array/> <key>com.apple.security.smartcard</key> <true/> <key>keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)com.apple.pivtoken</string> <string>$(AppIdentifierPrefix)myAppExtensionId</string> </array> As one final test, I tried using the yubikey in safari to access my server using mTLS, and it works! I get prompted for a PIN (which is odd because I've programmed it not to require a PIN), but the request succeeds using the key's default PIN. I just cannot get it working with my own app. Can anyone here (or preferably, at Apple) point me in the right direction? I have a feeling that the documentation I've been reading applies to MacOS, and that iOS/ipadOS have their own restrictions that I either need to work around, or which prevent me from doing what I need to do. It's obviously possible (i.e. the Yubico Authenticator sort of does what I need it to), but not in the way that Apple seems to describe in their own documentation.

Can a macOS Platform SSO extension reliably identify the original app behind a Safari or ASWebAuthenticationSession-mediated request, or does ASAuthorizationProviderExtensionAuthorizationRequest only expose the immediate caller such as Safari ? We are seeing: callerBundleIdentifier = com.apple.Safari callerTeamIdentifier = Apple audit-token-based validation also resolves to Safari So the question is whether this is the expected trust model, and if so, what Apple-recommended mechanism should be used to restrict SSO participation to approved apps when the flow is browser-mediated.

How does Associated Domains Development work on watchOS? In comparison, on iOS we have Diagnostics menu that allows to input a link and test the setup. How to achieve the same on a watch? watchOS: iOS:

We have an application that capture audio and video. App captures audio PCM on internal or external microphone and displays audio level on the screen. App was working fine for many years but after iOS 26.4 upgrade, averagePowerLevel and peakHoldLevel are stuck to -120 values. Any suggestion?

I have made a screensaver for mac in swift, but couldn't find how to add an icon the logo image that shows up on saver file) and thumbnail (the cover image that shows up in the screensaver catalogue). Currently, it just shows a default blue spiral galaxy thumbnail and no icon image

I am a professional user of the 2019 Mac Pro (7,1) with dual AMD Radeon Pro W6900X MPX modules (32GB VRAM each). This hardware is designed for high-performance compute, but it is currently crippled for modern local LLM/AI workloads under Linux due to Apple's EFI/PCIe routing restrictions. Core Issue: rocminfo reports "No HIP GPUs available" when attempting to use ROCm/amdgpu on Linux Apple's custom EFI firmware blocks full initialization of professional GPU compute assets The dual W6900X GPUs have 64GB combined VRAM and high-bandwidth Infinity Fabric Link, but cannot be fully utilized for local AI inference/training My Specific Request: Apple should provide an official, one-click deployable application that enables full utilization of dual W6900X GPUs for local large language model (LLM) inference and training under Linux. This application must: Fully initialize both W6900X GPUs via HIP/ROCm, establishing valid compute contexts Bypass artificial EFI/PCIe routing restrictions that block access to professional GPU resources Provide a stable, user-friendly one-click deployment experience (similar to NVIDIA's AI Enterprise or AMD's ROCm Hub) Why This Matters: The 2019 Mac Pro is Apple's flagship professional workstation, marketed for compute-intensive workloads. Its high-cost W6900X GPUs should not be locked down for modern AI/LLM use cases. An official one-click deployment solution would demonstrate Apple's commitment to professional AI and unlock significant value for professional users. I look forward to Apple's response and a clear roadmap for enabling this critical capability. #MacPro #Linux #ROCm #LocalLLM #W6900X #CoreML

We are seeing what looks like a signing / managed-capability mismatch for Contactless Pass Provisioning. Environment Team ID: S7AUTD2C2B Bundle IDs: com.swiftpass.ios com.swiftpass.ios.dev Xcode: 26.4 macOS: 26.4 Problem Our app has had Contactless Pass Provisioning approved by Apple for a long time, and builds were working until a few days ago. Without any intentional signing/capability changes on our side, Xcode started failing with the following error: Provisioning profile "Swiftpass prod Appstore" doesn't include the Contactless Pass Provisioning capability. Contactless Pass Provisioning capability needs to be assigned to your team and bundle identifier by Apple in order to be included in a profile. Observed behavior Xcode marks the relevant provisioning profiles as "Ineligible" in the profile selector. This affects both development/debug and release/App Store builds. If we remove Contactless Pass Provisioning from the app entitlements/capabilities, the exact same profiles immediately become eligible and the signing error disappears. Important detail The downloaded provisioning profiles already contain the entitlement that Xcode claims is missing. We verified the downloaded profile with: security cms -D -i /Users/sergej/Downloads/Swiftpass_prod_Appstore\(1\).mobileprovision and it contains: <key>com.apple.developer.contactless-payment-pass-provisioning</key> <array> <string>shareablecredential</string> </array> So the issue appears to be that the profile contents look correct the capability is still present in the developer portal but Xcode's eligibility check still says the profile does not include the capability What we verified Contactless Pass Provisioning is still enabled for the App ID in the Apple Developer portal Newly recreated / redownloaded profiles still contain the entitlement Both dev and distribution profiles are affected The behavior is reproducible across profile refreshes and local cleanup What we already tried Reinstalled Xcode Updated Xcode and macOS Updated command line tools Cleaned DerivedData Deleted local provisioning profile cache Refreshed/redownloaded profiles from Xcode Recreated provisioning profiles in the developer portal Removed and re-added the capability in Xcode Expected behavior If the downloaded provisioning profile contains com.apple.developer.contactless-payment-pass-provisioning, Xcode should treat that profile as eligible. Actual behavior Xcode reports that the capability is missing and marks the profile as ineligible, even though the entitlement is present in the downloaded profile. Question Has anyone seen this specific mismatch with Contactless Pass Provisioning or other managed capabilities? This currently looks like either: an Apple backend/App ID capability-assignment sync problem, or an Xcode eligibility-validation bug for managed capabilities Feedback Assistant ID: FB22439399. It contains screenshots that showcase the issue as well.

I'm developing a lighting control app for iOS that receives Art-Net (UDP port 6454) and sACN (UDP port 5568) packets from a lighting console and relays commands to BLE wristbands with LEDs. This is used in live event production — the participant locks their phone while in a show and expects lighting control to continue uninterrupted. The problem UDP receive stops reliably ~30 seconds after the screen locks. I understand this is by design - iOS suspends apps in the background. However, I'm trying to understand if any supported path exists for this use case. What I've already tried UIRequiresPersistentWiFi = true - helps with Wi-Fi association but doesn't prevent app suspension Silent AVAudioEngine loop with UIBackgroundModes: audio - keeps the app alive, works in testing, but risks App Store rejection and feels like an abuse of the audio background mode NWListener (Network framework) on the UDP port - same suspension behaviour Socket rebind on applicationWillEnterForeground - recovers after resume but doesn't prevent dropout What I'm asking Is there any supported background mode or entitlement for sustained UDP receive in a professional/enterprise context? (Similar to how VoIP apps get the voip background mode for sustained network activity.) Is the silent audio workaround considered acceptable for App Store distribution in a professional tools context, or will it be rejected? Is NEAppProxyProvider or another Network Extension a viable path, and if so does it require a special entitlement? Test project I have a minimal Xcode project (~130 lines) demonstrating the issue — NWListener on port 6454, packet counter, staleness timer, and silent audio toggle. I can share the test code. STEPS TO REPRODUCE In Xcode (one-time setup): Select the UDPBackgroundTest target → Signing & Capabilities → set your Team Plug in your iPhone → select it as the run destination Build & run — confirm packets appear on screen when you run 'send_test_udp.py' Lock the phone and observe the dropout Test: Open the app and run 'python3 send_test_udp.py 192.168.0.XXX' The app counts up the packages, they match the python output. 1 packet per second. lock screen & and wait 10 seconds unlock phone an see the numbers are 10 packets off

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

On iOS 26.4, I set a Screen Time passcode. However, when I go to Settings > Apps > [Our App] and turn off Screen Time Access for the app, the system asks for Face ID instead of the Screen Time passcode. As a result, Screen Time access can be disabled without entering the Screen Time passcode. Steps to Reproduce 1. Set a Screen Time passcode on iOS 26.4. 2. Open Settings > Apps > [Our App]. 3. Turn off Screen Time Access for the app. Expected Result The system should require the Screen Time passcode before allowing Screen Time access to be disabled. Actual Result The system asks for Face ID instead of the Screen Time passcode, and Screen Time access is disabled.

I'm not sure if this is a recent issue, but I discovered NSIndexSet concurrency has a bug where not all indexes are enumerated. The following is a small sample demonstrating the issue in ObjC: NSLog(@"Hello, World! %@", NSProcessInfo.processInfo.operatingSystemVersionString); for (NSUInteger i = 0, n = 10; i < n; i++) { NSUInteger total = 301; NSMutableIndexSet *all = [NSMutableIndexSet indexSetWithIndexesInRange:NSMakeRange(0, total)]; NSIndexSet *pass = [all indexesWithOptions:NSEnumerationConcurrent passingTest:^BOOL(NSUInteger idx, BOOL *stop) { return true; }]; NSCAssert(all.count == pass.count, @"Mismatch #%ld %ld != %ld", i, all.count, pass.count); } Results on Version 26.4 (Build 25E246) look like Mismatch #0 297 != 301 Disabling concurrency (options:0) is a workaround. Feedback FB22447001

We use TeamCity as our Continuous Integration (CI) solution to build and run automated tests. These are integration tests executed through our 4D application, which is properly code‑signed and notarized. These CI machines are heavily used and build multiple versions per day, making them critical to our development workflow. However, we are experiencing an issue on some machines: after a certain period of time, network communication through our application stops working, while network communication remains fully functional when using third‑party tools (for example, LDAP clients). Based on our investigation, this issue appears to be related to Local Network Privacy management. We have followed the procedure described in Apple’s Technical Note: TN3179: Understanding local network privacy | Apple Developer Documentation to reset network authorizations, but this has not been sufficient to resolve the issue. In addition, our CI environment requires acknowledging a large number of Local Network access permission prompts. Given that these machines build multiple versions per day and are intended to run unattended, this is not practical in an automated CI context. We have around ten Macs dedicated to running these tests, and manually approving these pop‑ups is not a viable solution.

Hi everyone, I am developing a macOS virtualization manager (VirtualProg) using the Virtualization.framework. The application is distributed via the Mac App Store, so it operates strictly within the App Store Sandbox. I am looking for a reliable, programmatic way to discover the IP address assigned to a guest (both macOS and Linux). Is there a recommended "Sandbox-safe" API or pattern within the Virtualization framework—or a lower-level networking entitlement—that allows a host application to retrieve the guest's assigned IP address? Ideally, I am looking for a solution that does not require the user to manually install a non-sandboxed helper tool. Thanks in advance for any insights or guidance!

Hi, All notarization submissions for our new Electron macOS app have been stuck in "In Progress" for over 24 hours, with no logs available. Environment: Team ID: T7632V8V2D Certificate: Developer ID Application (valid, identity 83AC47F44D984509D5530439DD32729076B84982) Tool: xcrun notarytool submit (Xcode CLI) App: Electron 33, signed with hardened runtime, entitlements include allow-jit and allow-unsigned-executable-memory File: zip of .app (~236MB for arm64, ~104MB for x64) codesign --verify --deep --strict passes with no issues Apple System Status shows "Developer ID Notary Service: Available" Stuck submissions (all "In Progress", no logs available): ea0fd8d4-1f2d-4266-aa84-aa3f3ba9a8fb (Apr 8, 09:40 UTC) dfaacdd2-1a11-4844-b8b7-b07bae809a7b (Apr 7, 16:49 UTC) 8256e1f0-e501-4423-8744-35b5b78ec87f (Apr 7, 10:32 UTC) a477d536-d84a-4c25-99ca-d125e0a22de1 (Apr 7, 09:07 UTC) This is our first time notarizing any app on this developer account. We understand first-time submissions may be routed to in-depth analysis, but 24+ hours with no progress on any of the 4 submissions seems unusual. Could someone from Apple check our team's queue status? Any guidance would be appreciated. Thank you.

When using the official Wi-Fi Aware demo app on iOS, with the iOS device configured as a NAN Subscriber, after successfully establishing a peer-to-peer connection with another device via Wi-Fi Aware (NAN), the network path object nwPath.availableInterfaces does not list the nan0 virtual network interface. The nan0 interface is the dedicated NAN (Neighbor Aware Networking) interface used for Wi-Fi Aware data communication. Its absence from availableInterfaces prevents the app from correctly identifying/using the NAN data path, breaking expected Wi-Fi Aware data transmission logic. log: iOS works as subscriber: [onPathUpdate] newPath.availableInterfaces: ["en0"] iOS works as publisher: [onPathUpdate] newPath.availableInterfaces: ["nan0"]

I haven't been able to find the exact name for this. In iOS 26, there's a widget called "New Reminder" in Reminders app among the Control Center widgets(Action Button also). In the Shortcuts app, name is “Show quick reminder.” It doesn't seem to be either the input window that appears when requesting parameters or the snippet view. Is it possible to implement the sheet that appears after tap this widget button? I've looked through the relevant documentation and WWDC videos but haven't found anything.

We had "Today widgets" that worked perfect for a long time. After introducing the new Widgets Extension we added a Widgets Bundle to our app. Now after every app update the old widgets disappear from "Today view" and can be bring back ONLY by rebooting the iPhone. Sometime when they disappear, in today view appears the first widget from the Widgets Bundle. I've tested other apps too and it happens every time to apps that support old and new widgets (Xiaomi Home app for example). Does anyone have a clue how to fix that?

Hello everyone I'm implementing age verification in my app to comply with upcoming age assurance laws (Utah, etc.), and I'm using AppStore.ageRatingCode from StoreKit to retrieve my app's current age rating. According to the documentation: extension AppStore { @available(iOS 26.2, macOS 26.2, tvOS 26.2, watchOS 26.2, *) public static var ageRatingCode: Int? { get async } } "Use this property to fetch the age rating for your app and compare it with the last known age rating to check if it has changed." However, calling this always returns 0 in my environment. Environment: Device: Real physical device (not simulator) iOS version: 26.4 Sandbox Apple Account: signed in via Settings → Developer → Sandbox Apple Account App Store Connect: app is registered and age rating is configured Xcode Scheme → Run → Options → StoreKit Configuration: None Code: func getAgeRatingCode() async -> Int? { guard let ageRatingCode = await AppStore.ageRatingCode else { print("Age rating code unavailable") return nil } print("ageRatingCode: \(ageRatingCode)") // always prints 0 return ageRatingCode } Questions: What integer values does ageRatingCode map to? (e.g., does 4+ = 4, 9+ = 9, 13+ = 13, etc.? Or is it a different internal code?) This mapping is not documented anywhere I can find. Is 0 a valid return value, and if so, what does it represent? Is there a known issue with this API returning 0 even when all conditions appear to be correctly configured? Any guidance from Apple engineers or developers who have successfully used this API would be greatly appreciated.

Hi Everyone, We're experiencing a persistent issue where Apple's CDN returns SWCERR00301 Timeout for some of our associated domains, while other domains hosted on the exact same server work perfectly. Note: Using aliases below for privacy. "working.example.com" and "failing.example.com" are not our actual domains. The Problem Our app has multiple associated domains. When checking Apple's CDN: Working domain: $ curl -sD - "https://app-site-association.cdn-apple.com/a/v1/www.working.example.com" -o /dev/null HTTP/1.1 200 OK Apple-Origin-Format: json Cache-Control: max-age=21600,public Failing domain (same server, same IP, same AASA content): $ curl -sD - "https://app-site-association.cdn-apple.com/a/v1/www.failing.example.com" -o /dev/null HTTP/1.1 404 Not Found Apple-Failure-Reason: SWCERR00301 Timeout Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} Apple-Try-Direct: true Cache-Control: max-age=3600,public On device, swcutil dl -d www.failing.example.com returns SWCErrorDomain error 7, confirming the CDN has no valid cache. What We've Verified Both domains are hosted on the same server (same IP) and serve identical AASA files: HTTP 200, Content-Type: application/json, 229 bytes Valid JSON with correct appID Valid SSL certificates (Amazon RSA 2048), no redirects Both registered in the app's Associated Domains entitlement Response time < 500ms from multiple locations We simulated Apple's crawler locally: $ curl -H "User-Agent: com.apple.swcd (unknown version) CFNetwork/1568.200.51 Darwin/24.1.0" --connect-timeout 5 --max-time 5 -4 --tls-max 1.2 "https://www.failing.example.com/.well-known/apple-app-site-association" Result: 200 OK, 0.25s — well within the 5-second limit. We cannot reproduce the timeout from any network we've tested. Scope Out of 43 associated domains, 5 return 404 (Timeout) on Apple CDN while the other 38 work fine. All 43 domains serve valid AASA files from the same server infrastructure. What We've Tried Verified AASA content, headers, SSL, and response times for all domains Submitted new TestFlight builds to trigger re-crawl — timeout persists The failing CDN cache (max-age=3600) expires every hour, but Apple's crawler keeps timing out on retry No WAF or rate-limiting rules that would block Apple IPs (17.0.0.0/8) Impact The failing domain is our primary email campaign domain. Universal Links not working means newsletter links open in the browser instead of the app, affecting millions of email recipients daily. Questions Is there a way to request Apple's CDN to refresh/invalidate the cache for specific domains? Could the Apple crawler be experiencing connectivity issues to our server (AWS us-west-2) for specific SNI hostnames? We have 43 associated domains — could the volume affect crawl reliability? Is there an internal team we can escalate this to for CDN-side investigation? Any guidance would be greatly appreciated. Thank you!

Hi everyone, I’m looking for advice on a repeated App Store rejection under Guideline 2.5.1. Background: We initially explored using Family Controls for a planned feature. That feature has now been fully removed from the app. We no longer provide any Screen Time related functionality. What we already cleaned up: Removed all FamilyControls / ManagedSettings / DeviceActivity code usage. Removed commented-out code and all related references from the project. Removed related capabilities and entitlements from targets. Removed related frameworks/dependencies. Performed a clean rebuild and submitted a new archive. However, App Review still says the app includes ScreenTime API in an unapproved manner and suggests removing those APIs. Questions: What are the most common hidden places where Screen Time / Family Controls traces remain? Has anyone seen this triggered by transitive dependencies or stale build artifacts? What evidence/details should I provide in App Review Notes to help the reviewer verify cleanup? Is there a recommended way to ask App Review to share the specific symbol/framework/target they detected? Any practical checklist or experience would be greatly appreciated. Thank you.