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

For some reason since watchOS 26.5 my workout app can no longer receive action button presses during a workout unless the action button is configured to start a specified activity type. If the action button is configured to just open the app but not start an activity then at the start of a workout the app donates a StartWorkoutIntent. The result parameter is set to a 'NextButtonPress' intent so that the app is notified when the action button is pressed. This has been working fine since the action button first appeared back in 2022, but has suddenly stopped working with watchOS 26.5. Now when the app tries to donate the intent then it fails with the following error: The operation couldn’t be completed. (LNTranscriptErrorDomain error 1003.) Does anyone know what has changed and how I can get around it? Thanks.

iOS 26.5 regression: DisplayRepresentation.Image not rendering in OptionsCollection picker Apple's official sample Accelerating App Interactions with App Intents no longer renders entity images on iOS 26.5. Repro: Build the unmodified sample on iOS 26.5 sim (or device). Shortcuts app → add Get Trail Conditions → tap the Trail parameter. Expected (works on 26.3): Each trail in the Favorites picker shows its image via DisplayRepresentation.Image(named:) from TrailEntity.displayRepresentation.

[FB22327481] We are observing a rare issue where alarms scheduled using AlarmKit occasionally fire exactly at 12:00 AM, even though the alarm was scheduled for a different time. This issue happens only for a very small number of users (for example, 1–2 users per several thousand per day), but multiple reports confirm that the alarm goes off exactly at midnight. We also found that other developers are experiencing the same issue: https://developer.apple.com/forums/thread/815714 Observed behavior For a small number of users: Alarm fires at exactly 00:00 (midnight) This happens even when the scheduled alarm time is something like 7:30 AM Happens rarely Hard to reproduce internally Appears to happen only on real devices in production Additional notes We are using AlarmKit fixed schedules (not relative) Dates passed to AlarmKit are correct at scheduling time We do not intentionally create midnight alarms Issue seems random Question Are there any known limitations or edge cases with AlarmKit fixed schedules that could cause alarms to fire at midnight? For example: Invalid date fallback? Schedule expiration fallback? Time zone changes? Background refresh timing? Maximum schedule window? Any guidance would be appreciated, as this is affecting real users but is difficult to reproduce.

Hello, I submitted a Family Controls Distribution entitlement request on May 1st, 2026 and received the generic confirmation page. It has now been 13 days with no approval, rejection or status update. Timeline: May 1st: Submitted request via developer.apple.com/contact/ request/family-controls-distribution → Received confirmation page May 8th: Opened Entitlements ticket via Developer Support → No response after 6 days (despite the stated 2 business day response time) My app Knipsi is a parental control app for the DACH market. It helps families manage screen time by letting children earn credits through completing real-world tasks, with parents approving via Face ID. The app is 100% finished and ready for TestFlight — this entitlement is the only remaining blocker. App Details: Team ID: 5GW9CM8T7U Bundle ID: aquilano.Knipsi Case: 102883106983 Frameworks: FamilyControls, ManagedSettings, DeviceActivity I understand the entitlement review takes time — but what concerns me is that the support ticket opened under Entitlements has also gone unanswered for 6 days, despite the advertised 2 business day response time. Could anyone share how long the Family Controls Distribution approval currently takes? And is there a recommended way to follow up when support tickets go unanswered? Thank you

I am getting bug reports from users that occasionally the AlarmKit alarms scheduled by my app are going off exactly at midnight. In my app, users can set recurring alarms for sunrise/sunset etc. I implement this as fixed schedule alarms over the next 2-3 days with correct dates pre-computed at schedule time. I have a background task which is scheduled to run at noon every day to update the alarms for the next 2-3 days. Are there any limitations to the fixed schedule which might be causing this unintended behavior of going off at midnight?

I have a barcode scanning app with keyboard extension app. The keyboard has a button Barcode from which we can navigate to app for scanning the barcode. The keyboard can be used in app that can input text. Now after clicking the button and navigating to barcode scanning app, after successful completion of scanning isn't there a way to auto navigate to host application . At present, we are showing a pop up asking user to click on back button on top left corner.

Last week our Universal Links stopped working. We made some changes and uploaded a new AASA file, but https://app-site-association.cdn-apple.com/a/v1/(domain) still returns 404 Not Found for all our domains. When I query directly from our server like domain/.well-known/apple-app-site-association, it returns 200 and the file is accessible. Could you help us resolve this issue? Our app relies on working Universal Links (deep links). Thank you!

Hi, I submitted my Family Controls entitlement requests on April 21 for my iOS app, but I still haven’t received an approval, rejection, or any status update. This is blocking my ability to properly test and move forward with the app, since it depends on the Screen Time / Family Controls APIs. Has anyone had a similar delay recently? Is the recommended next step to file a code-level support request with my Team ID, or should I continue waiting? Thanks.

Hi Im creating an app with Alarmkit, the idea is to have the hardware buttons react like they do in Alarmclock with a snooze or if the buttons can just mute without intent. right now, hardware button end and dismisses the Alarm. its instinct to click that button. apple needs to update or do something.

I have Family Controls (Distribution) and (Development) on my main app. The shield overlay, shield actions, and ManagedSettingsStore all work correctly. My app concept: the user selects a specific time (e.g. 7:00 AM) at which their selected apps (Instagram, TikTok, Snapchat, etc.) should be blocked until they complete an action. The blocking should happen everyday automatically at the chosen time without the user needing to open my app. What actually happens: at 7:00 AM nothing happens. The selected apps remain accessible. The blocking only activates when the user manually opens my app and then closes it. Has anyone found a reliable way to make intervalDidStart fire every day at the scheduled time in the background? Is there a known workaround? I have seen similar reports from other developers but no confirmed solution. Any guidance from Apple engineers would be greatly appreciated.

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

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, I submitted a request for Family Controls (Distribution) approval, and it has now been over 12 days without any update on the status. I understand that review times can vary, but I wanted to check if this delay is expected or if there’s anything I might need to do on my end to help move the process forward. Could anyone from the Apple team or the community provide insight into: Typical processing times for Family Controls distribution requests Whether delays beyond a few days are common Any steps I should take to follow up or expedite the review For reference: Status: Submitted Submission time: April 29, 2026 Any guidance would be greatly appreciated. Thank you!

Hi, I’m seeing WeatherKit fail on device with a JWT permission error even though the app appears to be signed correctly with the WeatherKit entitlement. Error: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Setup verified: iOS physical device, tested after clean install/reboot Tested on more than one physical device Bundle ID: com.elilindenDinematch.Al-Outfits Team ID: FYGW4LHN42 App ID has WeatherKit capability enabled Fresh provisioning profile includes: application-identifier = FYGW4LHN42.com.elilindenDinematch.Al-Outfits com.apple.developer.team-identifier = FYGW4LHN42 com.apple.developer.weatherkit = true Signed app binary entitlements also include com.apple.developer.weatherkit = true codesign -dv confirms TeamIdentifier=FYGW4LHN42 Cleared DerivedData and regenerated/reinstalled with a fresh profile Toggled WeatherKit capability off/on in Developer portal and regenerated profile The failure occurs when calling: let weather = try await WeatherKit.WeatherService.shared.weather(for: location) The request takes a few seconds before failing, which makes it seem like the WeatherKit daemon is reaching Apple’s auth service but being rejected during JWT generation. Has anyone seen WeatherKit entitlement propagation get stuck server-side for a specific Team ID + Bundle ID? Is there anything else I can verify locally, or does this require Apple to inspect the WeatherKit auth service registration for this App ID?

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've been stuck on Guideline 2.3 for two weeks now and I'm running out of ideas. My app is iPhone-only (UIDeviceFamily = [1]) and has been on the App Store since January. Version 2.1.9 passed review fine. The only change in 2.1.10 is adding two DeviceActivity extensions — a DeviceActivityMonitor and a DeviceActivityReport — for screen time-based stress detection. Every build since then gets rejected with the same message: "The UIRequiredDeviceCapabilities key in the Info.plist is set up in such a way that the app will not install on the device used in review." Review devices: iPhone 14 Pro, iPhone 17 Pro Max, iPad Air M3. Here's what I've tried across 13+ submissions: UIRequiredDeviceCapabilities as ["arm64"] (array) — rejected Empty array [] — rejected Removed the key entirely — upload validation fails, Xcode re-injects arm64 anyway Post-build script to force ["arm64"] — rejected Dictionary format {"arm64": true} — rejected Added com.apple.developer.family-controls to extension entitlements — rejected Enabled Family Controls (Distribution) on extension bundle IDs — rejected Fixed CFBundleVersion mismatch between host app and extensions — rejected Set TARGETED_DEVICE_FAMILY=1 on all targets including extensions — rejected Tried GENERATE_INFOPLIST_FILE=YES with minimal plists — rejected Tried ExtensionKit type for the report extension — rejected In the exported IPA, every target has UIRequiredDeviceCapabilities = ["arm64"] and UIDeviceFamily = [1]. The entitlements, provisioning profiles, and code signing all look correct. arm64 is supported on every review device they listed. The previous version (2.1.9) without DeviceActivity extensions passes review with the exact same UIRequiredDeviceCapabilities and signing configuration. Has anyone shipped an app with DeviceActivityMonitor + DeviceActivityReport extensions successfully? Is there something specific about these extension types that affects device capability validation? Or is there a known issue with the review system and FamilyControls extensions? I've replied to the review team multiple times asking which specific capability is causing the failure, but the response is always the same generic template. Any guidance would be really appreciated — I'm completely blocked on shipping this update.

I started a fresh “Sticker Pack App” project, add one image to it and it wouldn’t show up on emulator or device. From what I remember, there shouldn't be any coding involved, just drag and drop images of the correct format and dimensions and it should work. I tried changing the file format, dimensions etc while consulting with web and AI assistant searches and but still didn’t work. Apple support also didn't reply with anything useful but to post in the forum. I'm guessing I'm missing something trivial where a lot of us here have encountered before. Appreciate your help here, thank you in advance!

We are developing an MDM agent app that uses FamilyControls with .individual authorization to enforce Screen Time restrictions (app blocking, domain blocking via ManagedSettingsStore and DeviceActivityCenter). The Problem We are actively subscribing to AuthorizationCenter.shared.$authorizationStatus to detect authorization changes. However, when the user revokes the app's FamilyControls authorization through Settings (either via Settings > Screen Time > Apps With Screen Time Access, or Settings > Apps > [Our App]), the publisher does not emit any value. All ManagedSettingsStore restrictions are lifted immediately by the system, but our app receives no notification of this change. The only scenario where the publisher reliably emits is when a debugger is attached (i.e., running directly from Xcode). Without the debugger, the publisher is completely silent — even when the app returns to foreground. Code Example We tried subscribing directly to AuthorizationCenter.shared.$authorizationStatus with no intermediary, exactly as shown in the documentation: AuthorizationCenter.shared.$authorizationStatus .sink { status in print("[DIRECT] authorizationStatus emitted: \(status)") } .store(in: &cancellables) This subscription is set up at app launch and stored in cancellables. The result is the same — the publisher does not emit when the user revokes authorization in Settings without a debugger attached. Documentation Reference The documentation for authorizationStatus states: "The status may change due to external events, such as a child graduating to an adult account, or a parent or guardian changing the status in Settings." And: "The system sets this property only after a call to requestAuthorization(for:) succeeds. It then updates the property until a call to revokeAuthorization(completionHandler:) succeeds or your app exits." This suggests the publisher should emit when the status is changed via Settings, but in our testing it does not — unless a debugger is attached. What We Verified We tested with a development-signed build (which includes the com.apple.developer.family-controls entitlement), launched from Xcode, then disconnected the debugger, killed the app, and relaunched from the home screen. Scenario Publisher emits on revocation? Running from Xcode (debugger attached) Yes, immediately Development-signed build (no debugger) No — silent even on foreground return We also confirmed: MDM configuration profiles can disable Screen Time entirely, but cannot restrict the per-app authorization toggle — the user can always freely revoke the app's Screen Time access The Security Gap This creates a significant gap for parental controls use cases: User leaves the app (app goes to background) User goes to Settings and disables Screen Time access for the app All restrictions are immediately lifted User uses the device freely User re-enables Screen Time access and opens the app Everything syncs back to normal — administrator never knows Questions Is there any supported mechanism to receive a notification (background or foreground) when FamilyControls individual authorization is revoked? We are subscribing to AuthorizationCenter.shared.$authorizationStatus but it does not emit. Is the $authorizationStatus publisher expected to work only when a debugger is attached? Is this a known limitation or a bug? Can DeviceActivityMonitor extension detect authorization revocation? Based on documentation it appears limited to schedule/threshold events, but we haven't confirmed this. Is there a planned API improvement to address this gap? Environment iOS 26.2 Xcode 26.3 Swift 6.2.4 FamilyControls .individual authorization Related Threads Screen time API can be disabled easily Changing Screen Time Passcode does not protect apps

From the Developer Guide page 12 for the entitlements. The footnote mentions that CarPlay EV charging app and CarPlay fueling app entitlements may be combined in a single app Does this mean that i can implement both fuelling and EV charging feature in the same app ? How will the entitlement process to get this be done ? should i make 2 request for each of the entitlement ?