Original discussion pre iOS 26 Our app uses Auth0 with HTTPS callback, we've found the issue where AASA file is not ready immediately when app is initially launched, which is the exact issue from the above link. The issue seems mostly fixed on later versions on iOS 18, however, we are seeing some indications of a regression on iOS 26. Here's some measurement over the last week. | Platform | iOS 18 | iOS 26 | |---------------|----------|--------| | Adoption rate | 55% | 45% | | Issue seen | 1 | 5 | | Recover? | Yes | No | This only 1 iOS 18 instance was able to recover after 1 second after the first try, however, all iOS 26 instances were not able to recover in couple tens of seconds and less than 1 minute, the user eventually gave up. Is there a way to force app to update AASA file? Are there some iOS setting (like using a VPN) that could potentially downgrade the AASA fetch? Related Auth0 discussion: https://community.auth0.com/t/ios-application-not- recognizing-auth0-associated-domain/134847/27

Hello everyone, My app has been stuck in "Waiting for Review" for a long time, and I would like to know whether this is normal or whether I should take any additional action. App name: ختمة يومية Submission date: March 7, 2026 at 3:34 AM Current status: Waiting for Review I have already completed the required app information, including the TestFlight/App Review details, and there are no visible missing items in App Store Connect. I would like to ask: Is this review delay normal at the moment? Has anyone experienced a similar delay recently? Is there anything else I should check in App Store Connect? Would contacting App Review again help in this case? I would appreciate any advice or shared experience. Thank you.

Hey I wanted to ask how long is the waitinguntil the request will be approved. Im waiting 12 hours already and I seems like smth is wrong thank u

Hi team: I recently update to Xcode 26.4, and I encountered crash when running to < iOS 26.4 both for physical device and Simulator with this log: dyld[1257]: Symbol not found: _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF Referenced from: <164CCEB0-E1F8-3CE2-A934-2096C19C0A9A> /private/var/containers/Bundle/Application/EA709A68-F76F-4D97-85C6-B71D61D68389/xxx.app/xxx.debug.dylib Expected in: <9E5EC9BB-5828-329C-A2BC-038B67060298> /System/Library/Frameworks/MetricKit.framework/MetricKit Symbol not found: _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF Referenced from: <164CCEB0-E1F8-3CE2-A934-2096C19C0A9A>x /private/var/containers/Bundle/Application/EA709A68-F76F-4D97-85C6-B71D61D68389/xxx.app/xxx.debug.dylib Expected in: <9E5EC9BB-5828-329C-A2BC-038B67060298> /System/Library/Frameworks/MetricKit.framework/MetricKit dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/usr/lib/libViewDebuggerSupport.dylib but iOS 26.4 works well. Env: Xcode: 26.4 Simulator/Physical Device: < 26.4 macOS: 26.3 Thanks for giving any help.

HTTP status code: 401. Invalid credentials. Username or password is incorrect. Use the app-specific password generated at appleid.apple.com. Ensure that all authentication arguments are correct. I double checked every thing but still getting same error

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.

Hi everyone, I'm building an iOS app that uses a DeviceActivityMonitor app extension as part of the Screen Time / Family Controls API. Every time I try to upload my IPA to App Store Connect, the validation fails with this error: "Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of 'Alexandria.app/PlugIns/AlexandriaActivityMonitor.appex' is invalid." Error Domain=IrisAPI Code=-19241, iris-code=STATE_ERROR.VALIDATION_ERROR What I have verified (everything looks correct): NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = AlexandriaActivityMonitor.AlexandriaActivityMonitorExtension (correctly resolved in the compiled binary, verified with plutil -p) The Swift class correctly subclasses DeviceActivityMonitor CFBundleShortVersionString matches the main app Both the main app and extension provisioning profiles explicitly contain com.apple.developer.family-controls = true (verified by inspecting embedded.mobileprovision inside the IPA) The binary code signature itself contains com.apple.developer.family-controls = true (verified with codesign -d --entitlements :-) Family Controls entitlement was requested and approved in the Developer Portal for both App IDs Tested with both Xcode 26.2 (iOS 26 SDK) and Xcode 16.4 (iOS 18 SDK) — same error in both cases The IPA is structurally correct. The error comes purely from Apple's server-side IrisAPI validator and does not correspond to anything I can identify or fix in the code or configuration. Has anyone successfully submitted an app with a DeviceActivityMonitor extension to App Store Connect recently? Is there a backend approval requirement for com.apple.deviceactivity.monitor beyond the standard Family Controls entitlement approval? Could this be a known validator bug for this specific extension type? Any help appreciated.

Hello, I released a new build for my app but it fails to run on iOS 12.5.8 (tested on iPad Air, iPhone 6, iPhone 5s). The launch storybard is shown, then the app stops abruptly. There is no crash log. It runs fine on iOS 13 or higher. Xcode 26.3 was showing a call stack (something with UIView) that did not include any app code. Now with Xcode 26.4 (and its new command line tools) there is an info popup with a debug metadata dump. However, I don’t intend to focus on Xcode here because it officially does not support iOS 12. It’s ok if I cannot debug, I just want the app to run on the device like the previous build did. Since there is no crash log, and the console is showing a bootstrap error, I believe my app code has not been executed and is therefore not at fault. Build 674 released on 23-Mar-2026: worked fine on iOS 12, built with Xcode 26.3 Build 675 released on 29-Mar-2026: Bootstrap error as described, with both Xcode 26.3 and 26.4 Deployment target = 12.4 Tried Instruments but it fails as soon as I hit record. In the console I found BKSProcessErrorDomain code 1. Here on the forum I found a post where the cause was no internet access but my device does have internet access. I made only very little code changes to my app between 674 and 675, no storyboard updates. I get the impression the loader does not even begin to execute my code. At this point I wonder if: some certificate has expired (see release dates above), or if something is incompatible in my main storyboard (though I did not change anything there), or the device ran out of memory (1 GB) Note: The app has 4 targets: main app target framework AU app extension intents app extension Thanks, Sven PS: Misclicked subtopic which should have been General (sorry). Here’s the redacted console excerpt: standard 22:21:13.187990+0200 SpringBoard Evaluate: making new window key: <SBMainSwitcherWindow: 0x159e5f640>, for reason: push standard 22:21:13.188303+0200 SpringBoard Removed: <FBUIApplicationSceneDeactivationAssertion: 0x283c9dfe0; reason: systemAnimation; all scene levels; hasPredicate: NO> standard 22:21:13.198299+0200 assertiond Submitting new job for "com.example.app" on behalf of <BKProcess: 0x141d15d50; SpringBoard; com.apple.springboard; pid: 48; agency: SystemShell; visibility: foreground; task: running> standard 22:21:13.198867+0200 SpringBoard Bootstrapping com.example.app with intent foreground-interactive standard 22:21:13.201136+0200 assertiond Submitted job with label: UIKitApplication:com.example.app[0x1d9f][58] standard 22:21:13.201244+0200 SpringBoard Icon touch canceled (tap gesture may still succeed): <private> fehler 22:21:13.201329+0200 SpringBoard [com.example.app] Bootstrap failed with error: <NSError: 0x283e4cd80; domain: BKSProcessErrorDomain; code: 1 (bootstrap-failed); reason: "Failed to start job"> fehler 22:21:13.201421+0200 SpringBoard Bootstrapping failed for <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> with error: Error Domain=BKSProcessErrorDomain Code=1 "Unable to bootstrap process with bundleID com.example.app" UserInfo={NSLocalizedDescription=Unable to bootstrap process with bundleID com.example.app, BKSProcessExitReason=0, NSLocalizedFailureReason=Failed to start job, NSUnderlyingError=0x283e4c5d0 {Error Domain=NSPOSIXErrorDomain Code=3 "No such process" UserInfo={BKLaunchdOperation=launch_get_running_pid_4SB, NSLocalizedDescription=Unable to get pid for label UIKitApplication:com.example.app[0x1d9f][58], BKLaunchdJobLabel=UIKitApplication:com.example.app[0x1d9f][58], NSLocalizedFailureReason=No such process}}, BKSProcessJobLabel=UIKitApplication:com.example.app[0x1d9f][58], BSErrorCodeDescription=bootstrap-failed} standard 22:21:13.201507+0200 SpringBoard Adding: <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> standard 22:21:13.201606+0200 SpringBoard <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> exited. standard 22:21:13.202002+0200 assertiond Unable to get pid for 'UIKitApplication:com.example.app[0x1d9f][58]': No such process (3) fehler 22:21:13.202145+0200 assertiond Failed to start job with error <NSError: 0x141e1aba0; domain: NSPOSIXErrorDomain; code: 3; reason: "No such process"> { description = "Unable to get pid for label UIKitApplication:com.example.app[0x1d9f][58]"; failureReason = "No such process"; userInfo = { BKLaunchdJobLabel = UIKitApplication:com.example.app[0x1d9f][58]; BKLaunchdOperation = launch_get_running_pid_4SB; } } standard 22:21:13.202238+0200 assertiond Deleted job with label: UIKitApplication:com.example.app[0x1d9f][58] standard 22:21:13.202804+0200 SpringBoard Removing: <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> standard 22:21:13.221231+0200 SpringBoard Application process state changed for com.example.app: <SBApplicationProcessState: 0x28336f0a0; pid: -1; taskState: Not Running; visibility: Unknown> standard 22:21:13.221566+0200 SpringBoard Process exited: <FBApplicationProcess: 0x15d13b3e0; com.example.app; pid: -1> -> <FBApplicationProcessExitContext: 0x283e37b10; exitReason: (none); terminationReason: (none)> { stateAtExit = <FBProcessState: 0x28337c760; pid: -1; taskState: Unknown; visibility: Unknown>; }

I'm building an app that integrates with Reminders using EventKit, but I can't find a way to access two important structures from EventKit: The groups that contain reminder lists The sections inside each reminder list (available since iOS 17) Any help or guidance would be appreciated.

Starting March 24, the API is incorrectly returning 302 Moved Temporarily" redirecting the API to Location: https://aninterestingwebsite.com/weatherkit/ This is incorrect, it should be giving an API JSON response as specified by: https://aninterestingwebsite.com/documentation/weatherkitrestapi/get-api-v1-weather-language-latitude-longitude Is this happening for anyone else? Here's reproduction steps curl -vvv -H "Authorization: Bearer YOUR_OWN_TOKEN_HERE" "https://weatherkit.apple.com/api/v1/weather/en/43.741667/-79.373333?dataSets=currentWeather&timezone=UTC&units=si" Here's what the output is: * Host weatherkit.apple.com:443 was resolved. * IPv6: (none) * IPv4: 23.58.127.73, 23.58.127.72, 23.58.127.75, 23.58.127.81, 23.58.127.80, 23.58.127.74, 23.58.127.83, 23.58.127.120, 23.58.127.82 * Trying 23.58.127.73:443... * Connected to weatherkit.apple.com (23.58.127.73) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF * ALPN: server accepted http/1.1 * Server certificate: * subject: C=US; ST=California; O=Apple Inc.; CN=weather-data.apple.com * start date: Feb 13 19:20:40 2026 GMT * expire date: Aug 19 17:49:59 2026 GMT * subjectAltName: host "weatherkit.apple.com" matched cert's "weatherkit.apple.com" * issuer: C=US; O=Apple Inc.; CN=Apple Public Server ECC CA 1 - G1 * SSL certificate verify ok. * using HTTP/1.x > GET /api/v1/weather/en/43.741667/-79.373333?dataSets=currentWeather&timezone=UTC&units=si HTTP/1.1 > Host: weatherkit.apple.com > User-Agent: curl/8.7.1 > Accept: */* > Authorization: Bearer ***SNIP*** > * Request completely sent off < HTTP/1.1 302 Moved Temporarily < Server: Apple < Content-Length: 0 < X-Frame-Options: SAMEORIGIN < Strict-Transport-Security: max-age=31536000; includeSubdomains < X-XSS-Protection: 1; mode=block < Access-Control-Allow-Origin: * < X-Content-Type-Options: nosniff < Content-Security-Policy: default-src 'self'; < X-REQUEST-ID: 2f605f12-8331-92fc-c7c1-acfb332b50b6 < X-Apple-Origin: 010decd0-02a4-34fc-8414-ac2bcd4692b9 < Cache-Control: must-revalidate,no-cache,no-store < Location: https://aninterestingwebsite.com/weatherkit/ < Date: Wed, 25 Mar 2026 18:55:51 GMT < X-Cache: TCP_MISS from a23-58-127-87.deploy.akamaitechnologies.com (AkamaiGHost/22.4.4-cf5672731e69c345796af56199edfb50) (-) < Connection: keep-alive < * Connection #0 to host weatherkit.apple.com left intact

By analysis the log, seems the following 3 calls has been ended by system callkit (Not mainly trigger the end call): @apple Do you have similar report that the iOS CallKit End the call withtour user action? Device info: iPhone18,1（iPhone 16 Pro） iOS 26.2 RCAppMobile/25.4.30.995 CTRadioAccessTechnologyNR（5G NR）

I'm trying to implement Unwanted SMS and Calls reporting in an app I'm doing in my idle time. If I place a UITextField or UITextView inside a ILClassificationUIExtensionViewController, every time I select on such control the extension crashes without any logs. The closet idea I have on why it crashes it has something to do with iOS requesting the dictation feature. I'm using the latest (beta 8 at the time) iOS 16.0 beta on my iPhone 13 pro. Attaching my code here if you want to try for yourself: github

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://aninterestingwebsite.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

Hello, I am starting work on adding AlarmKit to an existing project. During testing, I ran into an issue that if I hit Deny during the authorization request, I can't find any way to turn the alarm back on in settings. The only way I can get an authorization request again is by uninstalling the app and installing it again. I would like to be able to prompt my users where they can turn the Alarm back on if they accidentally hit Deny. Am I just not seeing the settings to change this somewhere?

Summary I'm using Background Assets to download Apple-hosted Asset Packs(downloadPolicy = onDemand). The first download cancellation succeeds, but on the second and subsequent downloads, progress.cancel() fails to work and the download completes to the end. Environment iOS 26.0 – 26.3 RC (all produce the same result) Xcode Version 26.2 (17C52) Using Apple-hosted Asset Packs Steps to Reproduce Start downloading an Asset Pack Call progress.cancel() during download → Succeeds Start downloading the same Asset Pack again Call progress.cancel() during download → Fails (download completes to the end) Observed Error Logs After 1st cancellation: A download with the ID "X-XXXXXXXX-XXX" failed: Error Domain=NSURLErrorDomain Code=-999 "cancelled" ↑ This is expected (cancellation succeeded) The fact that version 0 of the asset pack with the ID "X-XXXXXX-XXX" finished being downloaded couldn't be reported: Error Domain=NSCocoaErrorDomain Code=3851 "Property list invalid for format: 200 (property lists cannot contain objects of type 'CFError')" ↑ Problem: Unable to serialize CFError to plist 2nd cancellation attempt: The download with the ID "X-XXXXXX-XXX" couldn't be canceled: Error Domain=BAErrorDomain Code=113 "The requested download operation failed because the download object did not exist." ↑ The download object we're trying to cancel supposedly doesn't exist Implementation Code // Cancel implementation func cancel(tag: String) async { let statusUpdates = AssetPackManager.shared.statusUpdates(forAssetPackWithID: tag) for await statusUpdate in statusUpdates { if case .downloading(_, let progress) = statusUpdate, progress.isCancellable { progress.cancel() } } } Analysis It appears that when the first cancellation occurs, the system internally tries to save the cancellation state to a plist, but fails to serialize the CFError object. This seems to cause an inconsistent internal state, preventing the system from correctly recognizing the download object on subsequent downloads. Questions Is there a workaround? Is there a planned fix for a future iOS version?

Reference: FB21797091 / Related to thread 807695 Hello, I have already submitted a report regarding this issue via Feedback Assistant (FB21797091), but I would like to share the technical details here to seek further insights or potential workarounds. We are experiencing a technical regression where Universal Links and Shared Web Credentials fail to resolve for Internationalized Domain Names (IDN) specifically on iOS 16 and later. This issue appears to be identical to the one discussed in thread 807695 (https://aninterestingwebsite.com/forums/thread/807695). Technical Contrast: What works vs. What fails On the exact same app build and iOS 16+ devices, we observe a clear distinction: Standard ASCII Domain (onelink.me): Works perfectly. (Proves App ID and Entitlements are correct) Internal Development Domain (Standard ASCII): Works perfectly. (Proves our server-side AASA hosting and HTTPS configuration are correct) Japanese IDN Domain (xn--[punycode].com): Fails completely. (Status: "unspecified") Note: This IDN setup was last confirmed to work correctly on iOS 15 in April 2025. Currently, we are unable to install the app on iOS 15 devices for live comparison, but the regression starting from iOS 16 is consistent. This "Triple Proof" clearly isolates the issue: the failure is strictly tied to the swcd daemon's handling of IDN/Punycode domains. Validation & Diagnostics: Validation: Our Punycode domain passes all technical checks on the http://Branch.io AASA Validator (Valid HTTPS, valid JSON structure, and Content-Type: application/json). sysdiagnose: Running swcutil on affected iOS 16+ devices shows the status as "unspecified" for the IDN domain. Symptoms: Universal Links consistently open in Safari instead of the app, the Smart App Banner is not displayed, and Shared Web Credentials for AutoFill do not function. Request for Resolution: We request a fix for this regression in the swcd daemon. If this behavior is a specification for security reasons, please provide developers with a supported method or workaround to ensure IDN domains function correctly. We have sysdiagnose logs available for further investigation. Thank you.

Hello, Because our app package size is relatively large, part of our resources needs to be delivered through Apple-hosted asset packs. If we use the Background Assets framework to download these Apple-hosted packs, our app would only be able to support devices running iOS 26 or later. To maintain compatibility with a broader range of iOS versions, we chose to use iOS On-Demand Resources instead. However, during actual use, we found that even when these packs are marked with the initial install tag, there is still a fairly high probability (around 40%) that they are not available on the first screen after the app is launched for the first time. When we try to access them through conditionallyBeginAccessingResourcesWithCompletionHandler, the resources are unavailable, which forces us to download them again. During testing, we added event tracking and found that out of 22 users who downloaded the app, 9 had to re-download these resource packs on first launch. Each of these packs marked with the initial install tag is about 300 MB in size. We have also made sure to follow the NSBundleResourceRequest limitation that no more than 2000 × 1000 × 1000 bytes of resources should be accessed at the same time. We would like to understand why these packs, even though they are marked as initial install, still have such a high probability (around 40%) of being unavailable on the first screen at first launch.

When using DateFormatter with the Atlantic/Azores timezone, calling date(from: formattedString) for the date 2026-03-29 returns nil unexpectedly. codes： let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyyMMdd" // 年月日格式 dateFormatter.timeZone = TimeZone(identifier: "Atlantic/Azores") dateFormatter.locale = Locale(identifier: "en_US_POSIX") var now = Date() now -= 60 * 60 * 13 let formattedString = dateFormatter.string(from: now) let dateWithTimeZone = dateFormatter.date(from: formattedString) print(formattedString) //20260329 print(dateWithTimeZone) // nil

The documentation for NSURL -URLByAppendingPathComponent: states: "Returns a new URL by appending a path component to the original URL." Path component is singular. But this "works" : NSURL *testURL = [applicationsDirectory URLByAppendingPathComponent:@"Evil/../../" isDirectory:YES]; So my questions are: One) Was it always this way? I can't recall if it was like this before the Foundation rewrite and I just never stumbled across? and Two) Is it intended behavior? The API seems to suggest that you append one path component on the url with this method. But I guess you can append as many as you want?

I’m building an iOS app that uses FamilyControls + ManagedSettings + DeviceActivity. Goal: temporarily “unlock” a shielded app for N minutes, then automatically re-apply the shield when the timer expires. What I do: In the main app, when user picks an expiry (e.g. 15 min, 30 min). I start a non-repeating DeviceActivity schedule and remove the app’s ApplicationToken from ManagedSettingsStore().shield.applications. I also store activeUnlockBundleID etc. in an App Group so the DeviceActivityMonitor extension can re-lock at the end. Expected: DeviceActivityMonitor.intervalDidEnd(for:) is invoked when the non-repeating interval ends, and I re-add the token to the shield set. Actual: The app does not re-lock when the interval expires. I added OS logs as well as “debug local notifications” from the DeviceActivityMonitor extension in: init() intervalDidStart intervalDidEnd eventDidReachThreshold None of these logs or notifications ever appear, which suggests the extension is never invoked (or cannot schedule local notifications or OS logs). Environment: Device: iPhone 17 Pro iOS 26.3.1 Xcode 26.4 Running on a physical device Notification permissions for the app: granted App + extensions are in the same App Group entitlement. Extension Info.plist has: NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = $(PRODUCT_MODULE_NAME).DeviceActivityMonitorExtension Questions: Are there known limitations/requirements for DeviceActivityMonitor callbacks where intervalDidEnd doesn't to fire? Is posting local notifications / OS Logs from a DeviceActivityMonitor extension supported/reliable? If not, what’s the recommended way to verify the extension is invoked? If this looks like a platform bug, should I file Feedback Assistant? If so, what logs/artifacts are most useful?