Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello Apple Developer Technical Support / Core Location Team, I’m requesting clarification on the effective timing of the Info.plist key NSLocationDefaultAccuracyReduced. We shipped Version A with NSLocationDefaultAccuracyReduced = YES (reduced accuracy by default). In Version B we changed it to NO. After updating to Version B, on devices/users that have not previously granted location authorization for our app, the first authorization flow still behaves as if reduced accuracy is the default (i.e., the same behavior as Version A). Could you please confirm: When iOS evaluates/caches NSLocationDefaultAccuracyReduced (install time, app launch, or at first authorization prompt)? After an update changes this key from YES to NO, should the new value apply to users who have never authorized location for the app? Environment: Iphone 16 (IOS 26.0) I can provide a sysdiagnose and additional logs if needed. Thank you, Jack

I've written an PDF viewing app, and there seems to be a correlation between files opened by the app and files that Time Machine says couldn't be backed up. The files can still "not be backed up", even after the app has closed them. Is there anything I specifically need to do to sever the link between the file and the app?

I received this message "Your app provides a limited user experience as it is not sufficiently different from a web browsing experience." It needs to be more robust and native. When submitting this the app had: Push Notifications Core Location Phone Contact access So now I am adding: Haptic feedback Quick touch actions A more robust add to calendar function. (the app does scheduling) But is this enough for resubmission? I am not really sure what is considered "robust" and "more native".... that is vague.

I have to continuously disable Limit IP Tracking on my local Wi-Fi network. When it's enable I am not able to access some services on the same subnet that falls under rfc1918. Accessing remote network, over site to site vpn, is not affected, just my local network. I opened FB21483619 for this. I would expect to see rfc1918 subnets not included. Also would expect all DNS queries to be sent to the servers provided in DHCP.

Does our app need to check the location or can we fully reply on this API to decide whether we wanna comply for the law of places that requires age range information? Looks like it's only covering Texas now..? would it add other places by apple..? And also this API is really hard to test a user in other places, Iike I don't know a user in Brazil gonna return true for false now, but the law in Brazil also requires the age information.

Description: I have identified a specific issue when recording acoustic guitar and other instruments on the iPhone 17 Pro Max using native applications (Voice Memos, Camera). The recordings contain an unnatural metallic resonance (ringing artifacts) that should not be present. Testing and Methodology: Hardware Verification: Initially, I suspected a hardware defect in the audio chip or microphone. However, extensive testing with third-party software suggests this is likely a software-level issue. AudioShare Test: I conducted a test using the AudioShare app in "Measurement Mode" (which bypasses standard iOS system-wide audio processing). In this mode, the audio remains perfectly clean, and the metallic ringing disappears entirely. Conclusion: The issue is rooted in the DSP (Digital Signal Processing) algorithms that iOS applies for noise suppression or voice enhancement. These algorithms appear to misinterpret the high-frequency overtones of acoustic instruments as background noise and attempt to "filter" them, resulting in audible digital artifacts. Comparison Results: This issue has not been observed on devices from other brands or on older iPhone models (preliminary tests suggest older versions handle this better). Notably, the problem persists even in GarageBand, as the app still utilizes certain system-level processing layers. Proposed Solution: I suggest adding a "Raw Audio" or "Instrument Mode" toggle within the Microphone/Audio settings for native apps. This mode should disable aggressive DSP processing, similar to how the AVAudioSession.Mode.measurement works in specialized apps. Attachments: I am attaching 4 archives, including a final "Measurement Mode" folder with comparative samples (Measurement Mode vs. Standard Mode). The artifacts are most prominent when monitored through headphones.

I have a problem generating the domain certificate for a merchant id it gives me an error but when using the URL that Apple uses to validate said within the .well-known if the file can be loaded

Memory leak in CarPlay when using CPTabBarTemplate Reproduced using the code example "Integrating CarPlay with Your Music App" from the official Apple documentation - https://developer.apple.com/documentation/carplay/integrating-carplay-with-your-music-app Steps to reproduce the leak: Download and run the example on CarPlay. Select the Settings tab. Click the first item in the list "Use Apple Music". Click Back button. Repeat steps 3 and 4 several times. Open Debug Memory Graph in xCode and search for "CPGridTemplate" - the count will be greater than 0. Conditions under which the memory leak disappears: If you open and switch to all tabs one by one, the leak disappears.

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) We are using JamF MDM profile with VPN payload for deployment. With this MDM profile, we are observing an issue, ie TransparentProxy extension is not enabled when user performs logout and login and only in Sonoma. By analyzing it further we are noticing that in Sonoma some times, the system invokes NETransparentProxyProvider's stopProxy delegate once or twice with NEProviderStopReason as 12 ie userLogout. Due to this after login the system extension is not activated.

Summary A crash occurs in ViewBridge framework when a TUINSRemoteViewController object receives -release message after being deallocated. This appears to be a reference counting issue within the ViewBridge framework's internal autorelease pool management. Environment macOS Version: [15.0.0] Application: Custom Qt-based application using Chromium Embedded Framework (xcode version: xcode 15; QT version: 6.5.4 ; CEF version: 138.0.47+g2728d53+chromium-138.0.7204.221) Steps to Reproduce Users are typically using the app normally, but a crash occasionally occurs when they activate and click on the application. This happens infrequently, but it occurs roughly every day. Currently, only a few specific users experience this crash, and it may appear for several consecutive days before disappearing for several days. We cannot reliably reproduce this issue but have collected crash logs from affected users. Crash Analysis Zombie Detection Log: Zombie <TUINSRemoteViewController: 0x338708020> received -release Deallocation Stack Trace (when object was first released): 0 Chromium Embedded Framework 0x000000014283a7f4 rust_png$cxxbridge1$ResultOfWriter$operator$sizeof + 933592 1 AppKit 0x000000019eac0d80 -[NSResponder dealloc] + 340 2 AppKit 0x000000019ebb5e34 -[NSViewController dealloc] + 276 3 ViewBridge 0x00000001a3f6ab9c -[NSRemoteViewController dealloc] + 92 4 AppKit 0x000000019eada4b4 -[NSViewController release] + 236 5 ViewBridge 0x00000001a3eda130 -[NSRemoteViewController release] + 380 6 libobjc.A.dylib 0x000000019aa8806c objc_autoreleasePoolPop + 56 7 CoreFoundation 0x000000019aefc7c0 _CFAutoreleasePoolPop + 32 8 Foundation 0x000000019c0d14f4 -[NSAutoreleasePool drain] + 136 9 ViewBridge 0x00000001a3ed609c __CONSIDER_WHO_REQUESTED_THIS_WAIT_BEFORE_SENDING_BUG_TO_VIEWBRIDGE__ + 24 10 ViewBridge 0x00000001a3f82a10 deferredBlockOpportunity_block_invoke_2 + 436 11 CoreFoundation 0x000000019af3dfa0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 12 CoreFoundation 0x000000019af3deb0 __CFRunLoopDoBlocks + 356 13 CoreFoundation 0x000000019af3d330 __CFRunLoopRun + 2432 14 CoreFoundation 0x000000019af3c334 CFRunLoopRunSpecific + 572 15 HIToolbox 0x00000001a63740cc RunCurrentEventLoopInMode + 292 16 HIToolbox 0x00000001a6379ebc ReceiveNextEventCommon + 636 17 HIToolbox 0x00000001a637a020 _BlockUntilNextEventMatchingListInModeWithFilter + 76 18 AppKit 0x000000019ea7fa70 _DPSNextEvent + 660 19 AppKit 0x000000019f3a57b8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 Crash Stack Trace (second release attempt): 0 Chromium Embedded Framework 0x14a03a37c rust_png$cxxbridge1$ResultOfWriter$operator$sizeof + 932448 1 Chromium Embedded Framework 0x14a03a04c rust_png$cxxbridge1$ResultOfWriter$operator$sizeof + 931632 2 CoreFoundation 0x19af1cbe8 ___forwarding___ + 200 3 CoreFoundation 0x19af1ca60 _CF_forwarding_prep_0 + 96 4 libobjc.A.dylib 0x19aa8bd94 AutoreleasePoolPage::releaseUntil(objc_object**) + 204 5 libobjc.A.dylib 0x19aa88138 objc_autoreleasePoolPop + 260 6 CoreFoundation 0x19aefc7c0 _CFAutoreleasePoolPop + 32 7 Foundation 0x19c0d14f4 -[NSAutoreleasePool drain] + 136 8 ViewBridge 0x1a3ed609c __CONSIDER_WHO_REQUESTED_THIS_WAIT_BEFORE_SENDING_BUG_TO_VIEWBRIDGE__ + 24 9 ViewBridge 0x1a3f82a10 deferredBlockOpportunity_block_invoke_2 + 436 10 CoreFoundation 0x19af3dfa0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 11 CoreFoundation 0x19af3deb0 __CFRunLoopDoBlocks + 356 12 CoreFoundation 0x19af3d330 __CFRunLoopRun + 2432 13 CoreFoundation 0x19af3c334 CFRunLoopRunSpecific + 572 14 HIToolbox 0x1a63740cc RunCurrentEventLoopInMode + 292 15 HIToolbox 0x1a6379ebc ReceiveNextEventCommon + 636 16 HIToolbox 0x1a637a020 _BlockUntilNextEventMatchingListInModeWithFilter + 76 17 AppKit 0x19ea7fa70 _DPSNextEvent + 660 18 AppKit 0x19f3a57b8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 19 AppKit 0x19ea72b7c -[NSApplication run] + 480 20 libqcocoa.dylib 0x1057b7514 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2156 21 QtCore 0x109bb55c4 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 532 22 QtCore 0x109babff8 QCoreApplication::exec() + 112 23 HoYowave 0x1009fc740 QWidgetFrameAdapter::RunMessageLoop() + 132 24 HoYowave 0x1008ae908 0x10088c000 + 141576 25 HoYowave 0x1008b7038 0x10088c000 + 176184 26 HoYowave 0x1008a3544 0x10088c000 + 95556 27 HoYowave 0x1008a294c 0x10088c000 + 92492 28 dyld 0x19aad4274 start + 2840 Technical Analysis The crash pattern indicates: A TUINSRemoteViewController was autoreleased multiple times During autorelease pool drain, the first release triggered dealloc Subsequent release attempts accessed the deallocated object (zombie) This is entirely within ViewBridge framework's internal code path The function name __CONSIDER_VIEW_SERVICE_BEFORE_SENDING_BUG_TO_VIEWBRIDGE__ in the stack trace suggests this is a known problematic area. Questions Is this a known issue in ViewBridge framework? Is there any workaround or mitigation we can apply from the application side? Could you provide guidance on what might trigger this condition? I have report this in Feedback Assistant FB21809243

Hello everyone, I’m currently stuck in App Review and would appreciate input from anyone who has dealt with a similar situation. App setup iOS app, SwiftUI, StoreKit 2 No user accounts (no login, no username/password, no backend) No subscriptions Monetization model: App was paid before version 1.0.5 Since 1.0.5 the app is free Unlocking full functionality is done via a non-consumable, one-time IAP (“Pro Unlock”) Existing users who bought the app when it was paid are automatically granted Pro access New users get a 24-hour local trial, then must purchase the non-consumable IAP All state is local / device-based, no server There is no concept of an account, subscription renewal, or expired subscription in the app. Rejection from App Review Apple rejected the app with the following message: Guideline 2.1 – Information Needed We are not able to continue our review because we need access to a demo account with an expired subscription to review the entire purchase flow. Please provide a user name and password for a demo account with expired subscriptions in the App Review Information section of App Store Connect. This is where I’m confused. Why this doesn’t seem applicable The app does not use subscriptions The app does not have user accounts The IAP is non-consumable, one-time purchase Trials are not subscription-based and expire automatically on-device There is no “expired subscription account” that could exist technically StoreKit testing is done via sandbox Apple IDs, but those are: not app-level accounts not usernames/passwords inside the app only used in the Apple purchase sheet Additional complication Because old paid users are automatically recognized as “Pro” via AppTransaction.originalAppVersion, the Unlock Pro button is hidden once Pro is active. This means that on some devices (including mine), the purchase sheet never appears anymore because the app already considers the user entitled. This might be confusing App Review and causing them to assume the app uses subscriptions and gated accounts. Questions Has anyone seen App Review request a demo account with expired subscription for an app that uses only non-consumable IAPs? Is there a correct way to respond other than explicitly explaining that: there are no accounts there are no subscriptions StoreKit sandbox Apple IDs are sufficient? Would providing a sandbox Apple ID (clearly labeled as such) help, or is that inappropriate since Apple reviewers already have sandbox accounts? Is this likely just a misclassification by App Review, or is there something in Apple’s guidelines that I’m missing? What I’ve already tried Explained the purchase flow step-by-step in App Review notes Clarified that the Paid Apps Agreement is already accepted Clarified that Pro access is automatically granted to previous paid users Verified that the IAP is correctly configured and available in App Store Connect At this point I’m unsure whether I should: escalate / push back on the incorrect assumption, or modify the UI to make the purchase path permanently visible even for entitled users Any insight from people who have gone through similar review issues would be greatly appreciated. Thanks in advance.

Hello, I am experiencing an issue with the App Intents framework where a parameter of type [String] (String Array) fails to persist user input in the Shortcuts app action editor. Issue Description: When adding an item to the String Array parameter in the Shortcuts app action editor, the input text automatically clears/resets to empty within less than 1 second. This happens spontaneously while the keyboard is still active, or immediately after typing, making it impossible to input any values. Environment: Xcode Version: 26.2 (17C52) iOS Version: 26.2.1 Device: iPhone 17 Code Snippet: import AppIntents import SwiftUI struct TestStringArrayIntent: AppIntent { static var title: LocalizedStringResource = "Test Array Input Bug" static var description: IntentDescription = "Reproduces the issue where String Array input clears automatically." // PROBLEM: // Input for this parameter vanishes automatically < 1s after typing. @Parameter(title: "Test Strings", default: []) var strings: [String] func perform() async throws -> some IntentResult & ReturnsValue<String> { return .result(value: "Count: \(strings.count)") } } Steps to Reproduce: Build and install the app containing the code above. Open the Shortcuts app and create a new shortcut. Add the "Test Array Input Bug" action. Tap the "Test Strings" parameter to add a new item. Type any text (e.g., "Hi"). Observe: Wait for about 1 second Observed Behavior: The text field clears itself automatically. The array remains empty ([]). Expected Behavior: The text should remain in the field and be successfully added to the array. **Filed as Feedback:**FB21808619 Thank you.

I tried making a concurrency-safe data queue. It was going well, until memory check tests crashed. It's part of an unadvertised git project. Its location is: https://github.com/CTMacUser/SynchronizedQueue/commit/84a476e8f719506cbd4cc6ef513313e4e489cae3 It's the blocked-off method "`memorySafetyReferenceTypes'" in "SynchronizedQueueTests.swift." Note that the file and its tests were originally AI slop.

We are having an issue with the Local Network permission pop-up not getting triggered for our apps that need to communicate with devices via local network interfaces/addresses. As we understand, apps using UDP should trigger this, causing macOS to prompt for access, or, if denied, fail to connect. However, we are facing issues with macOS not prompting this popup at all. Here are important and related points: Our application is packaged as a .app package and distributed independently (not on the App Store). The application controls hardware that we manufacture. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware on the local network, and the hardware responds with a message back. However, the popup (to ask for permission) never shows up. The application is not able to find the hardware device. It is interesting to note that data is still sent out to the network (without the popup) but we receive back the wrong data. The behaviour is consistent macOS Sequoia (and above) with both Apple And Intel silicon. Workarounds that have been tried: Manual Authorization: One solution suggested in various blogs was to go to "Settings → Privacy and Security-> Local network", find your application and grant access. However, the application never shows up in the list here. Firewall: No difference is seen in behaviour with firewall being ON OR OFF. Setting NSLocalNetworkUsageDescription: We have also tried setting the Info.plist adding the NSLocalNetworkUsageDescription with a meaningful string and updating the NSBonjourServices. Running Via terminal (WORKS): Running the application via terminal sees no issues. The application runs correctly and is able to send UDP and receive correct data (and find the devices on the network). But this is not an appropriate solution. How can we get this bug/issue fixed in macOS Sequoia (and above)? Are there any other solutions/workarounds that we can try on our end?

Are there some undocumented (or, well, documented, but overlooked by me) prerequisites to the readValueWithCompletionHandler: method? The reason I ask is that occasionally I am getting the Read/Write operation failed error in the callback, even in cases where direct, non-deferred reading of the value worked properly. It seems to happen very consistently with some accessories and characteristics, not randomly; thus, it is not likely a temporary quirk in the communication with the device. Probably I am overlooking something of importance, but it does not make a good sense to me. My code (is it right, or can you see anything wrong in there?) // in an HMCharacteristic category if ([self.properties containsObject:HMCharacteristicPropertyReadable]) { id val=self.value, ident=[NSString stringWithFormat:@" [%@] %@ (%@)", self.uniqueIdentifier, self.localizedDescription, self.service.accessory.name]; NSLog(@"nondeferred '%@'%@", val, ident); if (self.service.accessory.reachable) { [self readValueWithCompletionHandler:^(NSError * _Nullable error) { if (error) NSLog(@"deferred ERROR %@ -> %@", ident, error); else NSLog(@"deferred '%@'%@", self.value, ident); }]; } } for most accessories/characteristics works properly, but for some of them I am consistently getting results like nondeferred '70.5' [64998F70-9C11-502F-B8B4-E99DC5C3171B] Current Relative Humidity (Vlhkoměr TH) deferred '70.5' ERROR [64998F70-9C11-502F-B8B4-E99DC5C3171B] Current Relative Humidity (Vlhkoměr TH) -> Error Domain=HMErrorDomain Code=74 "Read/Write operation failed." UserInfo={NSLocalizedDescription=Read/Write operation failed.} Do I do something wrong in my code, or is that normal with some devices? If the latter, is there perhaps a way to know beforehand that I should not use readValueWithCompletionHandler: (for it is bound to fail anyway), and instead I should simply use self.value non-deferred? For some time it seemed to me it happens with bridged accessories, but not really, this hypothesis proved wrong by further testing. Thanks!

I'm building out a live activity that has a button which is meant to update the content state of the Live Activity. It calls a LiveActivityIntent that runs in the app process. The push server starts my live activity and the buttons work just fine. I pass the push token back to the server for further updates and when the next update is pushed by the server the buttons no longer work. With the debugger I'm able to verify the app intent code runs and passes the updated state to the activity. However the activity never updates or re-renders. There are no logs in Xcode or Console.app that indicates what the issue could be or that the update is ignored. I have also tried adding the frequent updates key to my plist with no change. I'm updating the live activity in the LiveActivityIntent like this: public func perform() async throws -> some IntentResult { let activities = Activity<WidgetExtensionAttributes>.activities for activity in activities { let currentState = activity.content.state let currentIndex = currentState.pageIndex ?? 0 let maxIndex = max(0, currentState.items.count - 1) let newIndex: Int if forward { newIndex = min(currentIndex + 1, maxIndex) } else { newIndex = max(currentIndex - 1, 0) } var newState = currentState newState.pageIndex = newIndex await activity.update( ActivityContent( state: newState, staleDate: nil ), alertConfiguration: nil, timestamp: Date() ) } return .result() } To sum up: Push to start -> tap button on activity -> All good! Push to start -> push update -> tap button -> No good...

My MacBook Pro M5 running MacOS Tahoe 26.3 beta fails to detect two identical ASUS ROG Swift OLED PG32UCDM monitors simultaneously. Only one display is recognized at a time. One potential root cause might be that both monitors report identical binary EDID serial numbers (0x01010101), and the MacBook Pro M5 appears to use this value exclusively for display identity rather than combining it with other more detailed information (e.g., port, or alphanumeric serial number). I've verified that the monitor EDID binary serial numbers are in fact identical -- however the alphanumerical serial numbers are not identical. NOTE: This behavior is specific to the MacBook Pro M5 — when connecting both monitors via usb-c to a Mac Mini M4 Pro running the same MacOS Tahoe 26.3 beta, the monitors work fine. The OS detects both and assigns different names to them (PG32UCDM (1) and PG32UCDM (2)). NOTE: I could be wrong about this root cause, I don't have a way to disprove it, though the fact the monitors work fine on a Mac Mini is suspicious. What I have tried: Connecting the two monitors using different monitor ports (one on DisplayPort, another on HDMI, etc.), and different MacBook ports (one on HDMI, another on USB-C, etc.) Bumping down the resolution on the monitors to "1920x1080 (low resolution)" and 30Hz to rule out bandwidth issues. Connecting one, or both, monitors to CalDigit TS5 Plus dock. Neither alternate configuration yields the device recognizing both screens. Using BetterDisplay to import a manually-edited EDID for the screen, with a different binary EDID value, manufacturer name, etc. I've also verified that if I plug in my Apple Studio Display as one of the monitors, then the MacBook recognizes both one of the PG32UCDM monitors and the Studio Display at the same time. The issue seems to occur only when both monitors plugged into it are the same PG32UCDM model. When I have both monitors plugged into my MacBook, each time I disconnect the cable to whichever monitor is currently recognized, it immediately recognizes the other monitor. Plugging the cable for the disconnected monitor back in has no effect. I'm at a loss. Has anyone run into this issue and found a successful workaround that is not one of the approaches I've described above?

Hello, I have a .app NSApplication which is ran as a LaunchDaemon, in it's lifecycle I never call any AppKit functions (I start it with CFRunLoopRun). (mentioned on this post as well). I intercept a couple of signals using signal(s) in order to trigger CFRunLoopStop(CFRunLoopGetCurrent()) to do some cleanup. This LaunchDaemon has the purpose of providing VPN connectivity, as such I call connect functions that trigger the "Add VPN configuration" dialog (I can't provide extra details about this, as I integrate another SDK so I'm not sure what happens under the hood) and I noticed that whenever it is displayed, after allowing it, during the lifecycle of the application when it's time to send the signal, the signal isn't received. I tried re-adding the NSApp callbacks in order to investigate, but it looks like those aren't called as well. I'm interested in knowing more about this scenario and what happens... I couldn't really find information about this dialog... Thanks!