I typically avoid NSMetadataQuery because I always found the API to be a bit peculiar but for this feature I'm working on I'm not sure it is worth the effort to implement this functionality in my own way. Plus it seems pretty fast. What I find strange is I set the operationQueue to get notifications off the main thread. But also when I set the queue the system yells at me anytime I make a change to NSMetadataQuery that alters the query. So I found this recommendation (requirement) in the documentation : NSMetadataQuery *query = // Initialize and set up a query [query.operationQueue addOperationWithBlock:^{ [query startQuery]; }]; I find this API design to be odd, but maybe I'm just weird. So there are a bunch of properties that can be changed while the query is already running (predicate etc.) and they implicitly stop/start the query and it seems all these calls need to be routed through the query.operationQueue like above? For example if I change the predicate while the query is already started it seems I have to: [query.operationQueue addOperationWithBlock:^{ query.predicate = predicate; }]; The query already knows its operationQueue. Why does the caller have to plumb these calls through the operation queue manually? -stopQuery does not result in an error/warning when called off the operationQueue but is doing so safe? Or do I have to do: [query.operationQueue addOperationWithBlock:^{ [query stopQuery]; }]; Really what I was expecting was to provide a queue for the notification callbacks. I wasn't expecting to manually have to confine the query to its own queue.

I just updated my testing device OS to iOS 26.5 and was trying to validate if our sdk is working fine or not and we found Call blocking is not at working for this update. I already seen some of the post regarding call blocking will not work if call to the expected block number is initiated from testing device. So just to clarify that is not the case in our findings.

In my app, I implemented a screen recording functionality. But there was an unexpected crash. 0 CoreFoundation _CFRelease.cold.1 + 16 1 CoreFoundation ___CFTypeCollectionRelease 2 ReplayKit ___56-[RPScreenRecorder captureHandlerWithSample:timingData:]_block_invoke + 148 3 libdispatch.dylib __dispatch_call_block_and_release + 32 4 libdispatch.dylib __dispatch_client_callout + 16 5 libdispatch.dylib __dispatch_lane_serial_drain + 740 6 libdispatch.dylib __dispatch_lane_invoke + 388 7 libdispatch.dylib __dispatch_root_queue_drain_deferred_wlh + 292 8 libdispatch.dylib __dispatch_workloop_worker_thread + 540 9 libsystem_pthread.dylib __pthread_wqthread + 292

Hello, We have received reports from a few of our customers that they received a notification from macOS that our app 24 Hour Wallpaper would not be compatible with future macOS versions. As I understand it from public documentation, this alert shows if an app or any of its components are still using Intel x86 code. However our app has supported Apple Silicon from day one and has no intel-only components. I confirmed that the customers had not elected to run the app using Rosetta accidentally, and that they were running current versions that support Apple Silicon. Beyond what is already written here: https://support.apple.com/en-us/102527 Can anyone be very specific about what actually triggers this alert? Are there known instances of the alert showing erroneously? Thank you, -josh

We have an app that uses CallKit for outgoing Voip calls. One of our users started experiencing an issue, where he sometimes receives an UnknownCallProvider error from CallKit 10 seconds after the transaction request. This happens both after the app stays open for a while, and on fresh launches. A device restart didn't help as well. He is not on any other call during that time. It seems to happen only to him, and only sometimes. Any estimation what could be the cause? Or how to find out? What are the possible reasons that produce this error?

My latest app version may have a bug that happens very rarely when opening/closing the app and AVAudioPlayer.init(contentsOf:fileTypeHint:) is called (note that everything related to audio player is protected inside try/catch blocks). But the app does start again. I tested on my Intel Mac and Mac mini 2024 without any problems. In fact we have more than 2000 Mac users that use our app daily without any problems. But we have 3 customers that have a serious problems. They have apple silicon Macs with macOS 15.7.7 and 26.5. So the app does not ever start again, after working for years. Uninstalling and deleting all hidden files over the entire hard drive related to our app and reinstalling it from the store. Does not make it start again. I saw many macOS bugs happening. Killing/Closing the app then rebooting the Mac without the option to reopen the apps. When the reboot is done our app is opened, we see a little dot underneath (nothing exists to start it on boot). I saw display problems in Monitor app. For one customer, after uninstalling our app, it does appear in App Store, but the "get" button is grey and cannot be clicked. Our app is not on the SSD and not in the garbage bin. I compiled a special version of my app with no sound, all the code related to the possible crash completely commented. I gave it to 2 users and the app does not start. After cleaning everything, rebooting and reinstalling the app, I have one customer that gets a message that the previous opening of the app crashed. But the 2 choices (do not open or reopen) don't work. It juste either do nothing or crash again and again. My Theory is that there is an old bug in macOS that my app triggered. And from that moment on, macOS will stop behaving properly. My app was compiled with the lasted Xcode and apple libraries (I only use the basic Apple libraries, no 3rd party stuff) as of last month. My customers are angry and I tell them to get help from Apple customer service. The problem is not in my app, but something get stuck in macOS that makes the app never start again. The app was working, even my latest update, then after 1 crash it never start again, even after cleaning, rebooting and reinstalling the app. I can't fix this on my side, an app that crashes should not ever break the entire OS. I want to reiterate that my app does work for me an thousands of people and that even a new version without any possible problem manually put on desktop does not start either. When we uninstall and reinstall an app, it should work as it did, not leave behind some hidden crap that makes it never start again.

We have developed a Parental/Self control app using Screen time API. We have used individual authentication to authorize the app, using the instructions here: https://developer.apple.com/documentation/familycontrols/authorizationcenter The problem is , that individual auth can be disabled easily , by the following steps: enter Settings app. in Settings app, click on the Parental/Self control app. click to disable screen time restriction. show the device owner's face/fingerprint. (or pin code) Why is that a problem: Parental control apps, or self-control apps, are about giving control to the software, To make it hard for the user to disable the restrictions. So using the flow I have introduced above, it's super-easy for a user to disable his Parental control restrictions, which misses the entire point of Parental/Self control idea. Furthermore, not only the user have the means to unlock his screen time restrictions, he also MUST have the means to unlock it. This makes Screen time (with individual auth) useless: I have a code ready to make a great parental control app for my clients, with amazing ideas, but I can't use the Screen time API unless this problem is fixed. Why child-parent auth is not enough: My clients are grownups people between ages of 15-40, that are interested in self-control, so they don't have iCloud child accounts. also, the child-parent auth solution forces my clients to give some control to other person, and my clients prefer their privacy. Some of them prefer self-control and not parental-control. What I suggest as a solution: 1: Give more options to users how to disable the Screen time restrictions. including: a second faceID / FingerPrint (that isn't the same as the one used to unlock the device) a second pin password. a string password 2: Give the users the option to choose to not have the device's owner Face/Finger/Pincode ID , as a method to disable the Screen time restrictions.

Hello, we’re seeing a rather serious regression on iOS 26.6: The issue appears to reproduce with a single named ManagedSettingsStore: import ManagedSettings let store = ManagedSettingsStore(named: ManagedSettingsStore.Name("specific")) store.webContent.blockedByFilter = .specific([ WebDomain(domain: "specific-domain-marker.example") ]) Expected behavior: Only the explicitly configured .specific(...) web domain filter should be reflected in the effective ManagedSettings / ManagedConfiguration state. Observed behavior: After configuring this single store with .specific(...), I’m seeing unexpected additional websites being blocked (mostly adult content) which should only happen when using the .auto(…) API. Documented under FB22890915 with Sample Project and Sysdiagnose.

I have a app that has both mobile and watch versions. Recently some testers report that the watch app could not be launched if the put the app in the background and then resume. And if they kill the app and try to launch again, there is no any response when tapping the app icon. I managed to export some system logs by installing a sysdiagnose profile, and this info looks suspicious

I'm building a sleep tracker for couples — the headline feature is a notification to your partner the moment you fall asleep (and another when you wake up), detected on the Apple Watch from accelerometer and heart-rate data. The detection has to happen within minutes of onset for the product to make sense. My setup HKObserverQuery on heart rate with enableBackgroundDelivery(.immediate), re-registered on foreground. WKApplicationRefreshBackgroundTask rescheduled every 15 minutes. CMSensorRecorder.recordAccelerometer(forDuration: 12 * 3600) re-armed on every wake. A van Hees-style stillness classifier reading the last ~35 minutes of the buffer, with heart rate as a soft confirmer. HealthKit and Motion & Fitness authorized on both iPhone and watch. The observer's completionHandler() is called on every branch and the handler stays well under the 15-second watchdog. No HKWorkoutSession as my app is not a workout. Questions Is CMSensorRecorder paused or deprioritized while the Apple Watch's automatic sleep detection has classified the user as asleep? On a worn watch with the recorder armed for 12 hours, accelerometerData(from:to:) over a 35-minute window inside the auto-detected sleep period returns zero samples. The exact same call an hour later, once the watch has decided the user is awake, returns roughly ten thousand samples for an equivalent window. The user never activated Sleep Focus or Theater Mode — the only sleep-related state at play is the watch's own automatic detection, the same one that writes Core / REM / Deep stages into Apple Health. Is this documented power management I missed, or is it unexpected? Happy to file Feedback with a sysdiagnose during the window if you confirm it shouldn't behave this way. Is there a sanctioned non-workout path on current watchOS for detecting sleep onset within a few minutes of it happening? A full night recently produced a five-hour stretch with zero observer callbacks and zero background-refresh deliveries between bedtime and wake. The historical guidance to third-party sleep apps has been to reconstruct nights post-hoc from sleepAnalysis samples rather than attempt live detection. Is that still the recommendation today, or is there an API I've missed that would give an onset-focused app tighter wakes around bedtime? What is the current App Store review stance on HKWorkoutSession for sleep tracking? Would an app that auto-starts a .other / indoor workout only when its own classifier detects pre-sleep signals at the user's typical bedtime, ends the session as soon as onset is confirmed, never starts one outside that gated condition, and explicitly discloses "sleep tracking via workout session" in the App Store metadata — be an acceptable pattern, or grounds for rejection regardless of disclosure?

Dear Developer Technical Support, I wanted to ask for technical advice regarding the DeviceActivityMonitor which is part of the DeviceActivity framework: The DeviceActivityMonitor has a very strict memory limit of 6MB. That’s not a lot and it doesn't leave a lot of room for any kind of code that accesses permanently stored data. I would therefore like to ask for advice on best-practices on how to share information between the main app and that extension: Is UserDefaults a good idea to use here? Can/should we use CoreData or SwiftData? Should we build super small file-based data sharing (e.g. via .plists)? Why is it necessary to share data? This can be simple things that inform the decision of the device activity monitor in intervalDidStart, intervalDidEnd, eventDidReachThreshold, eventWillReachThresholdWarning. For example a setting where the user decides if they want to receive a push notification on eventWillReachThresholdWarning. Or the list of tokens that is supposed to be blocked in eventDidReachThreshold or intervalDidStart. I’m asking because even though we are super careful and conservative about memory allocations in our DeviceActivityMonitor we are regularly seeing it being killed due to memory pressure. What’s the best way to approach this? I’m grateful for any kinds of hints! Thanks a lot and have a great day! – Frederik

Hello, with macOS' and iOS' recent updates (26.4.x), Handoff in my app appears to have become dysfunctional, as I receive the following message in the logs: getContinuationStreamsWithCompletionHandler(), inputStream=(null) outputStream=(null) error=Error Domain=NSPOSIXErrorDomain Code=94 "Bad message" UserInfo={NSLocalizedDescription=Could not set up internal streams} It ONLY works: From a Mac with 15.x to other Macs or iOS devices (on 26.4.x). All other combinations (see below) do NOT work: iOS (26.4.x) > iOS (26.4.x) iOS (26.4.x) > Mac (26.4.x) iOS (26.4.x) > Mac (15.x) Mac (26.4.x) > iOS (26.4.x) The Handoff prompt is shown in the Dock on Mac, in the app switcher on iOS, and in the Dock on iPadOS, but once I click/press it, I get the continuationStreams error. Now, is it my app, or the OS? Thank you kindly, – Matthias

Hi Apple Developer Support / WeatherKit team, I’m trying to use native iOS WeatherKit through WeatherService.shared in a SwiftUI app. Every request fails before weather data is returned because WeatherDaemon cannot generate the WeatherKit JWT. I am not using the REST API or manually generating a JWT. This is the native Swift WeatherKit API. import WeatherKit import CoreLocation let current = try await WeatherService.shared.weather( for: CLLocation(latitude: 25.76, longitude: -80.19), including: .current ) I also tested the same pattern used in Apple’s sample project, “Fetching weather forecasts with WeatherKit,” which calls: WeatherService.shared.weather(for: location, including: .current) The error I get is: 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; error=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors 2 Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Setup details: Paid Apple Developer Program account Native iOS SwiftUI app Physical iPhone, not Simulator WeatherKit capability enabled in Developer portal App ID has WeatherKit enabled Xcode Signing & Capabilities includes WeatherKit Automatic signing enabled Provisioning profile regenerated through Xcode App deleted and reinstalled after configuration changes Clean Build Folder / DerivedData cleanup attempted Bundle ID in Xcode matches the App ID in Developer portal Tested .current, .hourly, and .daily WeatherKit subset requests Ensured I am not running on “My Mac Designed for iPhone/iPad” I verified the built app’s entitlements. They include: application-identifier = [REDACTED_TEAM_ID].[REDACTED_BUNDLE_ID] com.apple.developer.team-identifier = [REDACTED_TEAM_ID] com.apple.developer.weatherkit = true get-task-allow = true The embedded provisioning profile also includes: com.apple.developer.weatherkit = true Because the entitlement and provisioning profile appear correct, and the failure happens during JWT generation before weather data is returned, this seems like either a WeatherKit entitlement propagation issue or a backend authorization issue. Can Apple staff clarify what WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 means, and whether there is a way to verify that WeatherKit JWT generation is enabled for my App ID? I can provide my Team ID, Bundle ID, provisioning profile details, and full device logs privately if needed.

Hello, We are currently developing a macOS application and evaluating Managed Background Assets for delivering additional downloadable content. Our preference is to rely on Apple-hosted asset delivery as much as possible, rather than maintaining a separate CDN or server infrastructure. While reviewing the documentation and forum discussions, we found a few areas that are still unclear and would appreciate your guidance. 1. Scope of the 200GB Apple-hosted asset pack limit Some documentation and discussions seem to describe the 200GB limit as applying per Apple Developer Program team/account, while others suggest it is a per-app bundle limit. Could you clarify the exact scope of this limit? Is the 200GB quota applied per individual app bundle ID? Or is it shared across all apps under the same Apple Developer Program account? References: [LINK1] [LINK2] [LINK3] 2. Storage expansion and hybrid hosting Are there any plans to expand the Apple-hosted asset pack limits in the future, or is there an official process to request additional hosting capacity? If an app eventually exceeds the Apple-hosted limit, is it acceptable or technically possible to use a hybrid approach (i.e., using Apple hosting for some assets while self-hosting the rest)? 3. Recommended strategy for older macOS versions As we understand, Managed Background Assets are only available starting from newer OS releases. However, our application also supports older macOS versions, and we would ideally like to avoid maintaining a completely separate asset delivery backend for them. From Apple’s perspective, what is the recommended strategy in this situation? Is it expected that developers continue using Unmanaged Background Assets for older OS compatibility? Is it acceptable to support Managed Background Assets only on newer systems, while older OS versions simply do not receive the same downloadable-content functionality? Or is there another recommended migration/compatibility approach for apps supporting both newer and older macOS versions? Thank you in advance for your clarification!

Hi Apple Support, We're reaching out to clarify what appears to be unexpected behavior in the AdServices token attribution API, specifically around reinstall attribution for apps with high reinstall rates. The problem For an app with a high reinstall rate, our ASA install counts are significantly higher than what the Apple Ads dashboard reports. Total install counts across all sources match closely — the discrepancy is specifically in ASA-attributed installs. What we tested To investigate, we ran a controlled experiment: Installed an app by tapping an Apple Search Ads ad. Deleted the app. Reinstalled the app approximately 15 minutes later directly from the App Store, without tapping any ad. Fetched a new AdServices token and exchanged it with Apple's attribution API. The API returned attribution: true with the original campaign details (same campaignId, adGroupId, keywordId) and conversionType: Download. The reinstall was attributed to the ASA campaign even though the user did not interact with any ad before the second install. Question about documentation The Apple Ads help page defines a tap-through Redownload as: "A redownload is when a user downloads your app, deletes it, then downloads it again on the same device or a different one following an ad tap." Could you clarify: does "following an ad tap" mean the redownload must be directly triggered by a tap on an ad? Or does it mean any redownload that occurs within the 30-day attribution window of a prior ad tap? Question about intended token API behavior Is the AdServices token API intended to return attribution: true for installs where the user did not tap an ad before that specific install, but had interacted with an ad within the past 30 days? In other words, is the token API designed to attribute all installs within the 30-day window regardless of whether the current install was ad-driven, or should it only attribute installs that were directly preceded by an ad interaction? We would appreciate any clarification on the intended behavior, as this directly impacts how we reconcile install counts between the AdServices API and the Apple Ads dashboard. Thank you for your time.

Just curious if there is anyway to expedite the FamilyControl entitlement. I have seen few people stuck in this step for few days. I submit mine on the 4/18, and my Case ID: 102874096254 Just want to see if I can see any estimate time for my request. Thanks, Jing

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.

Hey . So i'm building a screentime app whereby users can add an accountability partner who will be able to see their total screentime.(no app breakdowns included) . This will require me to send the data to firebase realtime database and retrieve for the accountability partner to see. Problem is , I've literally tried everything but the screentime still shows 0m on the accountabiliy partner's end. I need the data to be displayed rounded down to the nearest 0.5 e.g 1hr43mins ->1.5hrs+ ,2.0hrs+ ,3.5hrs+ , meaning it only moves when a threshold is crossed by the user. (this is to save database costs). Anyway i'd really appreciate if someone could help me out here. Thanks

Hello everyone. I use Translation Framework in my application. During development everything was fine, Translation framework worked well, but after two or three days of using the production version (that was published in AppStore and available for others also!) - my application stopped working. Translation framework gives errors: Error sending 1 paragraphs Error Domain=TranslationErrorDomain Code=16 "Translation failed" UserInfo={NSLocalizedDescription=Translation failed, NSLocalizedFailureReason=Offline models not available for language pair} Failed to translate input 0; returning error: Error Domain=TranslationErrorDomain Code=16 "Translation failed" UserInfo={NSLocalizedDescription=Translation failed, NSLocalizedFailureReason=Offline models not available for language pair} Received unbridged NSError to API, converting to .internalError: Error Domain=TranslationErrorDomain Code=16 "Translation failed" UserInfo={NSLocalizedDescription=Translation failed, NSLocalizedFailureReason=Offline models not available for language pair} Once again - it worked when I developed it, it was released on the AppStore, and suddenly it stopped working!

Hello everyone, I’m experiencing a WeatherKit issue that occurs consistently on both the iOS 26.2 Simulator and a real device running iOS 26.2. Environment: Xcode: latest iOS: 26.2 Occurs on: Simulator AND physical device WeatherKit usage: via WeatherService API (not manual REST) Location Services: authorized (When In Use / Always) Issue: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "The operation couldn’t be completed." Already verified: WeatherKit capability is enabled for the App ID com.apple.developer.weatherkit entitlement is present Bundle ID matches the App ID App is signed with the correct Team ID Behavior is identical on Simulator and physical device Error occurs before any WeatherKit response is returned Questions: Is this a known issue with WeatherKit on iOS 26.2? Are there any known limitations or requirements for WeatherService related to WeatherDaemon validation? Is there a recommended way to diagnose why WeatherDaemon rejects the request with Code=2? Code: private let weatherService = WeatherService()