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

I enabled the WeatherKit capability on my App ID (com.saimcan.darkweather, Team 6SWSD6V4ZC) about 12 hours ago. The entitlement is embedded in the binary and the provisioning profile authorizes it, but every request fails at the JWT generation step. Error from the logs: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Relevant log excerpt (iOS 26.4 Simulator, same result on a physical device): [AuthService] Calling process is 3rd party process and has the correct entitlement ... accepting the connection [AuthService] Received proxy request for generating a jwt token. url=https://weatherkit.apple.com [WeatherDataService] Starting to generate JWT token request. bundleIdentifier=com.saimcan.darkweather [AuthService] Signed successfully [WeatherDataService] Make new JWT token request. requestIdentifier=... [AuthService] Failed to generate jwt token ... Code=2 What I have verified: Active Apple Developer Program membership (renewed through April 2027) All agreements accepted WeatherKit capability enabled on the App ID codesign -d --entitlements confirms com.apple.developer.weatherkit in the built binary embedded.mobileprovision also includes com.apple.developer.weatherkit App Group (group.com.saimcan.darkweather.shared) correctly bound to both the app and widget App IDs Since "Signed successfully" is logged, the device-side auth plumbing is working. The rejection appears to be server-side. Could someone from the WeatherKit team check whether JWT minting is enabled for this Team ID / Bundle ID? Team ID: 6SWSD6V4ZC Bundle ID: com.saimcan.darkweather

I’m curious what framework and rendering technique you’re using for the photo album’s grid zoom in and out. Why is it so incredibly smooth? I can’t seem to pull that off 🤦‍♂️

Hi everyone, Just recently we started having issues in our integration environment with publicly available well known files not being fetched properly by the Apple CDN. The CDN keeps returning an SWCERR00301 Timeout fault. I noticed a very similar thread around the same time it went wrong with us as well: https://developer.apple.com/forums/thread/821908 However, the fault is ever so slightly different. Note that for security reasons, the actual domain has been redacted and replaced by the generic "domain.com" When calling the command curl -i https://app-site-association.cdn-apple.com/a/v1/domain.com The following is returned HTTP/1.1 404 Not Found Server: AppleHttpServer/2caa77a6bc2e755fca0e0f63e4d67e53390f9184 Date: Thu, 21 May 2026 10:44:08 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://domain.com/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: eb38e1901a83ad9b Strict-Transport-Security: max-age=31536000 Expires: Thu, 21 May 2026 10:44:18 GMT Age: 712 Via: http/1.1 defra2-vp-vst-004.ts.apple.com (acdn/302.16436), https/1.1 defra2-vp-vfe-007.ts.apple.com (acdn/302.16436), https/1.1 nlams2-edge-lx-007.ts.apple.com (acdn/302.16436), https/1.1 nlams2-edge-bx-021.ts.apple.com (acdn/302.16436) X-Cache: hit-fresh, hit-stale, hit-stale, hit-stale CDNUUID: 859e620c-7e2c-438c-a43d-68b6344e890c-1593129103 Connection: keep-alive Not Found Where other issues on the forum specifically target "waiting on headers", it does not in our case. We checked our internal infrastructure, we clearly see incoming requests from the ASAA-bot requesting the well known file. These requests hit our backends as they should and return a 200 OK. All within a couple of milliseconds. Again - nothing changed here. After this validation, I read the Tech notes: TN3155: Debugging universal links | Apple Developer Documentation but it does not provide anything we did not already check. Besides on our side, hosting wise and content-wise, nothing changed. This is not new material. I ultimately enabled developer mode on my test device, pushed the Integration app version causing the issues. When keeping the entitlements asis, the apple CDN is called from the iOS device (verified through ProxyMan) but the redirects do not work (as the CDN contains 404 Not Found) When changing the entitlements, and adding "?mode=developer", the CDN is of course skipped and our backend is called directly (as verified through ProxyMan). Now the redirects work as intended, the universal links were fetched properly. (the embedded universal link tester on the iOS device in settings - Developer still did not validate the universal link correctly though. But this seems an issue in the tool. The working production universal link also does not validate while it definitely works) To make sure our backend is not too 'slow' (internal logging shows requests are handled within 100 ms), I checked against UAT. Same processing times, there no issues with CDN. We conducted a very thorough investigation on our side and I do not see any reason as to why the CDN should be throwing timeout exceptions. As we cannot flush the CDN cache and do not see issues on our side, there is no way for us to validate why this is going wrong. Does anyone have any clues on what else I can do? Thanks

Hello, We are planning to transfer an app to a different Apple Developer account and had several questions regarding Apple App Site Association (AASA) and Universal Links behavior after the transfer. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. We currently support Universal Links through our Apple App Site Association (AASA) configuration. Could you clarify the following: After the app transfer, will existing Universal Links continue functioning for users who already have the app installed? Will we need to update our AASA file to include the recipient account’s new Team ID in order for Universal Links to continue functioning properly? If so, is there a recommended transition strategy for supporting both existing installed app instances and newly installed versions during the migration period? Any clarification on the expected Universal Links and AASA transition behavior during and after an app transfer would be greatly appreciated. Thank you.

Hello, I'm an iOS developer currently working on an application in Xcode. I submitted a Capability Request for Family Controls (Distribution) through App Store Connect, but the status has remained "Submitted" with no approval to date. My oldest request was filed on April 21, 2026, so it has now been almost a month. Approval of this request is essential for releasing my application, and the length of this review process has become a significant source of stress. Based on what I've seen from other developers, most requests are approved within four weeks at the latest. I would like to know when I can expect a decision on my requests. The Request IDs in question are the following five: AS9LZVLSRX, 2UB9RY7AJF, LJ5TWZ6HH3, DGA3UBV6W9, ANZD3T8X23 Please note that some of these are duplicate submissions for the same identifier, so I'd appreciate it if you could check and consolidate them as needed. Thank you in advance for looking into this. Best regards, Tomo

Hi everyone, I submitted my Family Controls (Distribution) entitlement request on April 19 and it's been stuck on "Submitted" for over 4 weeks now, no approval, no rejection, nothing. My app is an anti-doomscrolling app that uses the Screen Time API to block distracting apps until the user completes a workout. Individual use, not parental control. I have Family Controls (Development) approved on all targets, but Distribution is still stuck on Submitted for all of them: com.kmgzora.replock com.kmgzora.replock.MORADeviceActivityMonitor com.kmgzora.replock.MORAShieldAction com.kmgzora.replock.MORAShieldConfig The app is fully ready to ship, this is my last step. I've seen a few threads here where DTS engineers helped people in similar situation, hoping someone can take a look. Thanks in advance.

There’s a general UTI category for archives. Does an archive type HAVE to compress the file data, or can the data be stored 1:1? I’m asking because some of the descriptions suggest the category is for compressed archives, but my archive type is 1:1.

I am using SCScreenshotManager.captureImage to capture image of an app window. i have the sleep settings that sleeps the display but not the system. when the display sleeps taking screenshot using SCScreenshotManager.captureImage does not work. Is there a way i can take screenshot of window when the display sleeps? Thanks

In iOS 18, requesting Contacts access via CNContactStore.requestAccess(for:) triggers a two-stage authorization flow: First stage: the standard "Allow / Don't Allow" alert Second stage: a sheet titled "How do you want to share contacts?" with two options — "Select Contacts" and "Share All [N] Contacts" My question is about the second-stage sheet specifically. It does not appear to have a Cancel or Close button, and swipe-down to dismiss does not work on the devices I've tested (iOS 18.x). If a user reaches this second prompt and decides they don't want to choose either option, how are they expected to dismiss it? Is this intentional behavior?