We are using the MPNowPlayingInfoCenter API to provide information to the “Now Playing” system UI. This works as expected, except that when the app is manually terminated, the information is removed from the UI. Our question is: Some apps (for example, Audible) are able to appear in the “Recently Played” section of the UI. This section seems to show a history of apps that previously provided “Now Playing” information but are not currently playing anything. We would like to know which API is used to achieve this behavior.

Has anyone seen this issue? We have a user who changed their Apple ID password about 5 days ago. Now when they authenticate via MusicKit JS: authorize() succeeds and returns a user token Immediately calling any /me/ endpoint returns 403 "Invalid authentication" (code 40300) Developer token works fine on catalog endpoints User has active Apple Music subscription Other users work fine through the same flow App doesn't appear in user's "Apps Using Your Apple ID" We've tried: Calling unauthorize() before authorize() Clearing localStorage/sessionStorage/cookies Multiple re-auth attempts over several days The token is freshly issued but Apple's API immediately rejects it. Anyone encountered this after a password change? Any workarounds?

Hey everyone. Ever since installed OS26 (and 26.1 now) - whenever I fast play any video on 1.25x, 1.5x, 2x on the AppleTV - the audio gets massively distorted on HomePods. Be it on YouTube, Difuse, or any supporting app. I even tried mirroring from iPhone -same issue. Anyone else experiencing the same? I noticed no posts about troubleshooting.

When I use MatterSupport to configure a Tread device for networking, the selectThreadNetwork callback in MatterAddDeviceExtensionRequestHandler returns my own Tread network(.network(extendedPANID:), but I cannot successfully add the device to my own Tread network.

I'm implementing the PushToTalk framework and have encountered an issue where channelManager(_:didActivate:) is not called under specific circumstances. What works: App is in foreground, receives PTT push → didActivate is called ✅ App receives audio in foreground, then is backgrounded → subsequent pushes trigger didActivate ✅ What doesn't work: App is launched, user joins channel, then immediately backgrounds PTT push arrives while app is backgrounded incomingPushResult is called, I return .activeRemoteParticipant(participant) The system UI shows the speaker name correctly However, didActivate is never called Audio data arrives via WebSocket but cannot be played (no audio session) Setup: Channel joined successfully before backgrounding UIBackgroundModes includes push-to-talk No manual audio session activation (setActive) anywhere in my code AVAudioEngine setup only happens inside didActivate delegate method Issue persists even after channel restoration via channelDescriptor(restoredChannelUUID:) Question: Is this expected behavior or a bug? If expected, what's the correct approach to handle incoming PTT audio when the app is backgrounded and hasn't received audio while in the foreground yet?

While preparing my app for Declared Age Range capability usage, I've noticed a weird behaviour: the same code works for iOS, but not for macOS. My project uses same target for both platforms, so the capability is enabled for both platforms. The business logic layer is also shared across between platforms. Both UI layers are writter in SwiftUI. The iCloud account used for testing on iOS and macOS devices is the same, so even the consent is shared across both devices. While requestAgeRange(ageGates:) seems to work just fine for iOS app, for macOS app it always throws Not available error (DeclaredAgeRange.AgeRangeService.Error.notAvailable) Am I missing something? Could the API be somehow unavailable for macOS? Should I use AgeRangeService.shared.requestAgeRange(ageGates:in:) for macOS instead of SwiftUI's @Environment-based approach? Also, after giving permission, is there a way to actually revoke it? In Age Range for Apps menu I can only view the list of apps that have my consent to share my age range, but not the ability to revoke it.

We are seeing a strange lifecycle issue on multiple MDM-managed iPads where application(_:didFinishLaunchingWithOptions:) is not called after the device is idle overnight. Even if we terminate the app manually via the app switcher, the next morning the system does not perform a cold launch. Instead, the app resumes directly in: applicationDidBecomeActive(_:) This causes all initialization logic that depends on didFinishLaunching to be completely skipped. This behavior is consistent across four different supervised MDM devices. Environment Devices: iPads enrolled in MDM (supervised) iOS version: 18.3 Xcode: 16.4 macOS: Sequoia 15.7.2 App type: Standard UIKit iOS app App: Salux Audiometer (App Store app) Expected Behavior If the app was terminated manually using the app switcher, the next launch should: Start a new process Trigger application(_:didFinishLaunchingWithOptions:) Follow the normal cold-start lifecycle Actual Behavior After leaving the iPad idle overnight (8–12 hours): The next launch skips didFinishLaunching The app resumes directly in applicationDidBecomeActive No new process is started App behaves as if it had been suspended, even though it was manually terminated Logs (Relevant Extracts) Day 1 — Normal cold launch [12:06:44.152 PM] PROCESS_STARTED [12:06:44.214 PM] DID_FINISH_LAUNCHING_START launchOptions=[] [12:06:44.448 PM] DID_FINISH_LAUNCHING_END We then used the app and terminated it via app switcher. Day 2 — Unexpected resume without cold start [12:57:49.328 PM] APP_DID_BECOME_ACTIVE No PROCESS_STARTED No didFinishLaunching No cold-start logs This means the OS resumed the app from a previous state that should not exist. Reproducible Steps Use an MDM-enrolled iPad. Launch the app normally. Terminate it manually via the multitasking app switcher. Leave the device idle overnight (8–12 hours). Launch the app the next morning. Observe that: didFinishLaunching does not fire applicationDidBecomeActive fires directly Questions for Apple Engineers / Community Is this expected behavior on MDM-supervised devices in iOS 18? Are there any known OS-level changes where terminated apps may be revived from disk/memory? Could MDM restrictions or background restoration policies override app termination? How can we ensure that our app always performs a clean initialization when launched after a long idle period? Additional Information We have full logs from four separate MDM iPads showing identical behavior. Happy to share a minimal reproducible sample if required.

For other permission prompts in the iOS ecosystem, we have the option to configure the text shown in the prompt via keys in the Info.plist. This does not appear to be the case with regards to the age range permission prompt. The text of the prompt implies the app includes a differentiated experience for child or teen content and that confirming age unlocks more features (making it seem optional for using the app). Is there a plan for app developers to be able to update that permission prompt similarly to how we can configure others? If so, is there any timeline we can expect that on?

We are using AgeRangeService.requestAgeRange(ageGates:in:) with an age gate of 18 to verify adult users. The system prompt always displays the lower-bound wording (“17 or Younger”), even when the app’s requirement is to verify users who are 18 or older. We understand the UI is system-controlled; however, this wording causes confusion for users, QA, and product teams, as it appears to indicate a child-only flow even when requesting adult verification. Based on the demonstration video, it appears that they have another more coherent message. In Apple's example, it is different, and it is correct that we need to specify 18 years or older in the implementation. A little more context might be helpful, but we are creating a kind of wrapper with React Native that receives that value as a parameter, which is 18.

CloudKit CKRecordZone Deletion Issue Problem: CloudKit record zones deleted via CKDatabase.modifyRecordZones(deleting:) or CKModifyRecordZonesOperation are successfully removed but then reappear. I suspect they are automatically reinstated by CloudKit sync, despite successful deletion confirmation. Environment: SwiftData with CloudKit integration Custom CloudKit zones created for legacy zone-based sharing Observed Behavior: Create custom zone (e.g., "TestZone1") via CKDatabase.modifyRecordZones(saving:) Copy records to zone for sharing purposes Delete zone using any CloudKit deletion API - returns success, no errors Immediate verification: Zone is gone from database.allRecordZones() After SwiftData/CloudKit sync or app restart: Zone reappears Reproduction: Tested with three different deletion methods - all exhibit same behaviour: modifyRecordZones(deleting:) async API CKModifyRecordZonesOperation (fire-and-forget) CKModifyRecordZonesOperation with result callbacks Zone deletion succeeds, change tokens (used to track updates to shared records) cleaned up But zones are restored presumably by CloudKit background sync Expected: Deleted zones should remain deleted Actual: Zones are reinstated, creating orphaned zones

Trying to support undo & redo in an app that utilizes Swift Data and as with anything other than provided simplistic Apple demo examples the experience is not great. The problem: Im trying to build functionality that allows users to add items to an item group, where item and item group have a many-to-many relationship e.g. item group can hold many items and items can appear in multiple groups. When trying to do so with relatively simple setup of either adding or removing item group from items relationship array, I am pretty consistently met with a hard crash after performing undo & redo. Sometimes it works the first few undo & redos but 95% of the time would crash on the first one. Could not cast value of type 'Swift.Optional<Any>' (0x20a676be0) to 'Swift.Array<App.CodableStructModel>' (0x207a2bc08). Where CodableStructModel is a Codable Value type inside Item. Adding and removing this relationship should be undoable & redoable as typical for Mac interaction and is "supported" by SwiftData by default, meaning that the developer has to actively either wholly opt out of undo support in their modelContainer setup or do it on a per action scale with the only thing I know of: modelContext.processPendingChanges() modelContext.undoManager?.disableUndoRegistration() ..... modelContext.processPendingChanges() modelContext.undoManager?.enableUndoRegistration() General rant on SwiftData: Random crashes, inconsistencies, random cryptic errors thrown by the debugger and general lack of production level stability. Each update breaks something new and there is very little guidance and communication from the Swift Data team on how to adapt and more importantly consideration for developers that have adopted Swift Data. If SwiftData is not ready for production, it would go a long way to clearly communicate that and mark it as Beta product.

This is just an FYI in case someone else runs into this problem. This afternoon (12 Dec 2025), I updated to macOS 26.2 and lost my network. The System Settings' Wi-Fi light was green and said it was connected, but traceroute showed "No route to host". I turned Wi-Fi on & off. I rebooted the Mac. I rebooted the eero network. I switched to tethering to my iPhone. I switched to physical ethernet cable. Nothing worked. Then I remembered I had a beta of an app with a network system extension that was distributed through TestFlight. I deleted the app, and networking came right back. I had this same problem ~2 years ago. Same story: app with network system extension + TestFlight + macOS update = lost network. (My TestFlight build might have expired, but I'm not certain) I don't know if anyone else has had this problem, but I thought I'd share this in case it helps.

I’m implementing StoreKit External Purchase Custom Links (EU) and so far it is really painful. I am running into a strange, device-specific issue. On 3/4 devices it works. On one device I never get a token at launch nor before a transaction. isEligible is true everywhere. All devices have versions 18.5 and are located in Germany. Info.plist: SKExternalPurchaseCustomLinkRegions is set to EU storefront codes and I have followed every step in the documentation: https://developer.apple.com/documentation/storekit/externalpurchasecustomlink Good device: At launch → ACQUISITION = nil, SERVICES = token present. Works consistently. Faulty device: At launch → ACQUISITION = nil, SERVICES = nil. Same before transaction. No token ever reaches my server from this device. isEligible is true on both devices. Any experts or help on the matter?

I have an app that uses BLE to connect to access doors. Since iOS 26, when it hasn't connected to any doors for a while, it deactivates, whereas in older versions of iOS it continues to work all day without stopping. Has anyone else experienced this? I've found problems with people who have had the same issue since upgrading to the latest version of iOS 26. Is there a known issue with BLE in iOS 26? I haven't found any official information. thnks

Hello, Recently we got a question about the keyboard sensor data collection in our research project: "For the typing statistics, was any typing included or only messaging and notes? E.g., typing in the browser, phone search, calendar, etc?" While I believe it should be any typing included, I was not able to find a document explicitly stating that. Could you help to confirm it or guide me to any documentation explaining it? Thanks!

Hello, After being in the AppStore for more than a year with the app working perfectly, yesterday I started seeing that WeatherKit requests failed with Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Encountered an error when fetching weather data subset; location=<+41.40217108,+2.20023642> +/- 0.00m (speed -1.00 mps / course -1.00) @ 13/12/25, 12:20:35 Central European Standard Time, error=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors 2 Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" I checked on developer.apple.com and we still have everything turned on and No changes were made from an already deployed app; and we pay 200$ a month for WeatherKit, this is unacceptable since it's not the first time WeatherKit randomly decides to stop working. More fun facts: the widget works fine...

I want to use FileProvder to implement the function of recovering from the recycle bin (the cloud recycle bin does not move, and after the local recycle bin is restored, the upload event is triggered again), but testing shows that the current recovery from the recycle bin is through the modifyItem event, and the CreateItem event is not triggered again to upload locally restored files Implement the deletion of undelivered files (dateless) without moving them to the recycle bin, which currently appears to be achieved by granting file. dash permission. But it is possible for the content of a file to be manually verified by the user. How can this be solved? How can we dynamically monitor whether a file is dataless Thank you for your reply. Could you please help answer my question

Greetings my fellow engineers, I use SwiftData in my iOS app. The schema is unversioned and consists of a single model. I've been modifying the model for almost two years now and relying on automatic database migrations. I had no problems for all that time, but now trying to add a property to the model or even remove a property from the model results in an error which seems like SwiftData is no longer capable of performing an automatic migration. The log console has things like the following: CoreData: error: NSUnderlyingError : Error Domain=NSCocoaErrorDomain Code=134190 "(null)" UserInfo={reason=Each property must have a unique renaming identifier} CoreData: error: reason : Can't find or automatically infer mapping model for migration CoreData: error: storeType: SQLite CoreData: error: configuration: default CoreData: annotation: options: CoreData: annotation: NSMigratePersistentStoresAutomaticallyOption : 1 CoreData: annotation: NSInferMappingModelAutomaticallyOption : 1 CoreData: annotation: NSPersistentStoreRemoteChangeNotificationOptionKey : 1 CoreData: annotation: NSPersistentHistoryTrackingKey : 1 CoreData: error: <NSPersistentStoreCoordinator: 0x7547b5480>: Attempting recovery from error encountered during addPersistentStore: 0x753f8d800 Error Domain=NSCocoaErrorDomain Code=134140 "Persistent store migration failed, missing mapping model." Have you ever encountered such an issue? What are my options?

Hello, I’m reviewing the open-source mDNSResponder repository and have a question regarding licensing/provenance in mDNSCore/DNSDigest.c file. That file contains an embedded notice stating that parts of the MD5/digest implementation were derived from older OpenSSL sources and therefore include the legacy OpenSSL/SSLeay license text, even though OpenSSL itself is now Apache-2.0 starting from version 3.0. The legacy OpenSSL/SSLeay license is widely understood to impose additional attribution and notice requirements compared to Apache-2.0, and some downstream projects prefer to avoid it when a permissively licensed alternative is available. Repository: https://github.com/apple-oss-distributions/mDNSResponder File: https://github.com/apple-oss-distributions/mDNSResponder/blob/main/mDNSCore/DNSDigest.c#L66 I’d like to clarify a few points: Is the MD5/digest code in DNSDigest.c still based on pre–OpenSSL-3.0 sources, such that retaining the legacy OpenSSL/SSLeay license block is intentional and required? If the goal were to simplify licensing (Apache-2.0 only), would Apple consider replacing this MD5 implementation with an Apache-2.0–licensed alternative (for example, code derived from OpenSSL 3.x or another permissive implementation)? Are there any technical or policy reasons (compatibility, crypto policy, platform APIs) that make such a replacement undesirable? Since GitHub issues and PRs are restricted for this repository, I’m asking here for guidance. If maintainers agree that such an update would be useful, I’d be happy to help by preparing a PR for review. I've also created a feedback report for this topic, the reference ID is FB21269078. Thanks for any clarification.

Hello team, Would this mean that content filters intended for all browsing can only be implemented for managed devices using MDM? My goal would be to create a content filtering app for all users, regardless of if their device is managed/supervised. thanks.