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://developer.apple.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.

Hi there, I have a developer program subscription but somehow when I log into the website it shows me to enrol again. My subscription renew date is on feb 27. I think is some kind of problem of syncronism or something like that but I need to sort this out ASAP because my business app depends on this. Has anyone had the same problem before? Thanks anyway.

Hi, I've been trying for days to create a developer account to upload an app to the store. I receive the verification code on my phone without any problem, I accept the terms, and when I tap "continue," I always get the message "We are unable to process your request." I also have two-factor authentication enabled, and the problem persists.

Hello everyone, I hope you're doing well. I'm looking for some guidance regarding the Apple Developer account conversion process. Nearly one month ago, we submitted a request to convert our Apple Developer account from Individual to Organization. We also contacted Apple Support and provided the required information. Since then, we have been patiently waiting, but we have not received any updates or feedback via email or through the support process. A few weeks ago, we also created a post here on the Apple Developer Forums hoping to receive some guidance, but unfortunately, we have not received any response there either. At this point, we would simply like to know: Is it normal for the conversion process to take this long? Has anyone experienced a similar delay? Is there anything else we should do, or should we continue waiting for Apple's response? We understand that these requests may require additional review, and we truly appreciate the work of the Apple team. We would just be grateful for any update or advice from the community or Apple staff. Thank you in advance for your time and assistance. Any suggestions or shared experiences would be greatly appreciated. Best regards.

Hello Apple Developer Community, I am looking for guidance regarding an Apple Developer Program organization enrollment issue. I am enrolling as a Company / Organization for my US LLC. My organization has a valid D-U-N-S Number, and Apple Developer's D-U-N-S lookup successfully recognizes my company information. I also received confirmation from Apple Developer Relations that my D-U-N-S information can be used for organization enrollment. However, my organization enrollment was declined without a clear explanation. During the previous review process, there was also a technical issue with my company email server, and I may have missed some communication from Apple Developer Support. The email issue has now been resolved. I am the founder and authorized representative of the company, and I can provide any required company documents or verification information. Has anyone experienced a similar situation where: D-U-N-S verification was successful, company information matched, but organization enrollment was still declined? Any advice on how to request a proper manual review would be appreciated. Thank you.

As of May 8th, 2026, after I upgraded to "codex-cli 0.129.0" via Xcode, I can no longer sign into my ChatGPT account in Xcode Intelligence Settings. The Log In window is always successful, but the settings never update to show the login being successful. It's a constant loop. Perhaps a hand-shake fail. Versions: Tahoe 26.3.1, Xcode 26.4.1, codex-cli 0.129.0.

Following up on my earlier thread about non-blocking interventions. I ran a clean, isolated test on iOS 26.5.2: I start DeviceActivityCenter.startMonitoring with a single event whose threshold is 2 minutes of usage for a selected app (includesPastActivity = false), with actions on eventDidReachThreshold. Result: the event's recorded trigger time is +0 seconds from monitoring start (immediate), it fires without any real usage, and after 2 minutes of actual use no notification and no ManagedSettings shield are applied. This matches the regression discussed in Forum thread 808470 / FB18061981. Concretely, the feature we want to build: while a user is using a selected app, deliver a repeating local notification every N minutes of usage (e.g., every 15 minutes) whose body states how many minutes they've used that app today (e.g., "You've used TikTok for 45 minutes today"). This is a gentle, factual awareness nudge — no blocking. This is exactly what eventDidReachThreshold with multiple thresholds (15/30/45 min…) + sendNotification would do, but that path is broken by the regression above. Questions: Is there a fix timeline for the eventDidReachThreshold immediate-fire regression (iOS 26.x)? Any FB to watch? What is the supported way to implement the feature above — a repeating notification every N minutes of usage, containing the cumulative minutes used today for that app — without relying on the broken threshold event? Specifically: a. How should we obtain the cumulative usage minutes for a selection to put in the notification body? Is the only source a DeviceActivityReport (which renders in an extension and isn't readable as a value in the app)? b. How should we trigger every N minutes of usage if threshold events are unreliable? Is there any usage-based trigger other than eventDidReachThreshold? Until a fix, is a DeviceActivitySchedule-based (wall-clock) approach the only reliable path? Is applying a ManagedSettings shield from the DeviceActivityMonitor extension expected to interrupt an app that is already in the foreground (mid-use), or only at next launch? Our app is non-blocking by design (a brief "pause" nudge + factual usage reminders), fully on-device, Family Controls (Distribution) approved. We'd rather build on a supported path. Thank you.

I'm building a consumer iOS app that helps users be more intentional about opening distracting apps. It never hard-blocks; it only nudges. I have Family Controls (Distribution) approved and a working TestFlight build using FamilyControls / DeviceActivity / ManagedSettings. I've confirmed from testing and the forums that: ShieldActionResponse is only .none / .defer / .close (no supported way to open my main app from the shield extension — threads 719905, 793060). ShieldConfiguration is a static snapshot (no countdown/animation; FB14237883). DeviceActivityMonitor events are threshold/schedule based and cannot hook "the app was just opened," and on iOS 26 eventDidReachThreshold fires immediately/incorrectly (thread 808470). I'd like to confirm the supported approaches for these UX patterns (each = every-app-open vs on-a-schedule): On app open, present my own full-screen UI (a brief non-blocking "pause") without requiring the user to manually create a Shortcuts personal automation. Is there any supported API for this, or is a user-created Shortcuts automation the officially recommended path? On app open, deliver a local notification (rather than UI) — supported only via a user-created Shortcuts automation, or is there another way? On a schedule / at fixed intervals, automatically bring my app's UI to the foreground (e.g., re-show a screen every N minutes) — I believe this is not allowed (apps can't self-foreground); can you confirm, and is a user-tapped notification the only path? On a schedule / at fixed intervals, send repeating local notifications while a usage limit is exceeded — given the iOS 26 eventDidReachThreshold regression, what's the recommended way to reliably detect "over limit" and drive repeating reminders? Some third-party apps appear to open their main app from a shield/monitor context. Is there any supported mechanism enabling that which I may have missed? I'd rather build on a supported path than risk anything review-sensitive. Guidance (or where to file an enhancement request) is appreciated. Thank you.

Hi, I’m using FamilyControls + DeviceActivity. Users select apps/categories/web domains via FamilyActivitySelection. I need to show today’s total usage for that selected group only, not the device’s full Screen Time. Setup: A visible DeviceActivityReport shows today’s per-app list with a daily DeviceActivityFilter for the selected tokens. This visible list is usually accurate and updates quickly. A separate hidden DeviceActivityReport uses the same filter to compute an aggregate total by summing app.totalActivityDuration in makeConfiguration(representing:). The extension sends that total to the main app via notify_set_state + Darwin notification. DeviceActivityMonitor is only used as a fallback. Problem: The visible app list stays current, but the aggregate total for the same selected apps sometimes lags by several minutes or updates only after new selected-app usage occurs. Sometimes the total appears temporarily frozen while the app list still looks correct. Questions: Is a hidden DeviceActivityReport a supported way to compute a selected-app aggregate total? Is makeConfiguration expected to run often enough for a near-live total? Why would the visible per-app report update while a hidden report with the same filter does not? What is the recommended architecture for a reliable, non-inflated today total for selected apps only? Thanks!

Summary: When applying a configuration profile that uses allowListedAppBundleIDs to permit a defined set of apps, essential Apple Watch apps are unexpectedly removed from the paired Watch — even though their associated iPhone bundle IDs are explicitly included. This issue occurs with a minimal profile, and has been consistently reproducible on the latest versions of iOS and watchOS. Impact: This behavior severely limits the use of Apple Watch in managed environments (e.g., education, family management, accessibility contexts), where allowlisting is a key control mechanism. It also suggests either: Undocumented internal dependencies between iOS and watchOS apps, or A possible regression in how allowlists interact with Watch integration. Steps to Reproduce: Create a configuration profile with a Restrictions payload containing only the allowListedAppBundleIDs key. Allow a broad list of essential system apps, including all known Apple Watch-related bundle IDs: com.apple.NanoAlarm com.apple.NanoNowPlaying com.apple.NanoOxygenSaturation com.apple.NanoRegistry com.apple.NanoRemote com.apple.NanoSleep com.apple.NanoStopwatch com.apple.NanoWorldClock (All the bundles can be seen in the Attached profile) Install the profile on a supervised or non-supervised iPhone paired with an Apple Watch. Restart both devices. Observe that several core Watch apps (e.g. Heart Rate, Activity, Workout) are missing from the Watch. Expected Behavior: All apps explicitly included in the allowlist should function normally. System apps — especially those tied to hardware like Apple Watch — should remain accessible unless explicitly excluded. Actual Behavior: Multiple Apple Watch system apps are removed or hidden, despite their iPhone bundle IDs being listed in the allowlist. Test Environment: iPhone running iOS 18 Apple Watch running watchOS 11 Profile includes only the allowListedAppBundleIDs key Issue confirmed on fresh devices with no third-party apps Request for Apple Engineering: Please confirm whether additional internal or undocumented bundle IDs are required to preserve Apple Watch functionality when allowlisting apps. If this behavior is unintended, please treat this as a regression or bug affecting key system components. If intentional, please provide formal documentation listing all required bundle IDs for preserving Watch support with allowlisting enabled. Attachment: .mobileconfig profile demonstrating the issue (clean, minimal, reproducible) Attached test profile = https://drive.google.com/file/d/12YknGWuo1bDG-bmzPi0T41H6uHrhDmdR/view?usp=sharing

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

Case ID: 102924093872 Case ID: 102924089648 Hi Apple Support Team, I’m reaching out regarding a critical issue that is blocking my app testing and affecting hundreds of users. I cannot receive the two-factor authentication code for my Apple Developer account. My mobile operator has confirmed that SMS messages from Apple are not reaching their network at all. I also receive no calls. Since my account is not logged in on any device, SMS is the only way I can verify my identity - and it’s not working. I have already submitted two support cases but have not received any response yet. Here is the impact this is having right now: • 250+ people are waiting to get access to test my app • 400 users are already using the app • I cannot sign the new agreement that appeared in App Store Connect • Because of this, TestFlight is completely blocked - both the 10,000 user limit and the 100 user internal testing • Even when I add someone to my team and grant them access, it still doesn’t work for them either I have been building this app for almost 7 months. We are in the final testing stage before I plan to release it for sale. Every day without access is a day my users are waiting and I cannot move forward. I am asking you to please help me resolve this as quickly as possible. I really need your support right now. Thank you so much for your time. Best regards, Tata

I am currently testing Managed Open-In restrictions in an MDM-managed environment on iPadOS 27 beta. I have observed that the restrictions "allowOpenFromManagedToUnmanaged" and "allowOpenFromUnmanagedToManaged", even when set to false, are still being bypassed in certain scenarios. Specifically, I observed two issues: Photos App – Images opened from a managed application can still be saved using the Save to Photos option. Shortcuts App – Custom Shortcuts triggered from the Share Sheet can accept managed content, compress it into an archive, and share that archive with unmanaged applications, effectively bypassing the Managed Open-In restrictions. According to the iPadOS 27 beta release notes, both of these issues were marked as resolved. However, they remain reproducible in my testing on a supervised MDM-enrolled device. I have submitted a detailed report with a sys diagnose log via the Feedback Assistant (FB ID:FB23316986).

I'm building a cross-device parental-control app: separate child and parent devices in the same Family Sharing group. I want to show the child's per-app (and per-category) Screen Time usage on the parent device. After extensive testing I can only get the child's total minutes across, and I'd like to confirm the supported architecture before building further on a path the framework may intentionally forbid. Authorization / setup Child device: AuthorizationCenter.shared.requestAuthorization(for: .child) — approved. Confirmed authorized: my app appears under Settings → Screen Time on the child, and the child's own DeviceActivityReport(users: .all) renders full per-app data. Parent device: separate device in the same family. Targets: main app + DeviceActivityReport extension + DeviceActivityMonitor extension, all with com.apple.developer.family-controls and a shared App Group. Physical devices, iOS 26.4.1. Xcode ⟦version⟧. What works: only the child's total minutes reach the parent — and only via my own relay: a DeviceActivityMonitor extension on the child writes aggregate totals to the App Group, the host app syncs them through CloudKit. No Screen Time API itself delivers the child's app/category breakdown to the parent. ⸻ Finding 1 — the report extension computes correct per-app data but cannot export it. On the child, makeConfiguration(representing:) iterates the results and produces correct per-app durations: LumicoActivityReport makeConfiguration done — 1 activityData, 1 segments, 5 apps, 17 min total Writing those aggregates to the shared App Group from inside the extension is then denied by the sandbox: Couldn't write values for keys ("screen_time_per_app_json") in CFPrefsPlistSource (Domain: group.servusjon.Lumico.shared …): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access (UserDefaults.set doesn't throw — the write silently no-ops; only this CFPrefs log reveals the denial.) Q1: Is there any supported way to surface aggregated, non-identifying per-app usage (app name + minutes + category) computed inside the DeviceActivityReport extension to the host app, given that App Group writes from the extension are denied? Or is the DeviceActivityMonitor extension (threshold events) the only supported way to get any usage signal out of the Screen Time sandbox? Finding 2 — on the parent, users: .children shows the parent's OWN data. On the parent I embed DeviceActivityReport(_:filter:) with DeviceActivityFilter(users: .children, …). The report renders, but shows the parent's own apps/categories — no child data. FamilyActivityPicker on the parent behaves the same (lists the parent's own apps). The identical code on the child (users: .all) returns the child's full data — so the pipeline works; only the cross-device delivery to the parent fails. Q2: What is required for DeviceActivityReport(users: .children) to deliver a child's activity to a third-party app on the parent device? Must the parent app hold a specific FamilyControls authorization (which FamilyControlsMember)? What conditions make FamilyActivityPicker surface a child's apps (not just categories) from the family on the parent device — authorization type, Family Sharing roles, child managed status, sync timing? ⸻ Already ruled out: physical devices (not Simulator); Screen Time data present on the child; extension correctly embedded (ExtensionKit com.apple.deviceactivityui.report-extension) and running makeConfiguration normally; family-controls + App Group present on app and both extensions; iCloud container named conventionally iCloud.. Core question: What is the supported architecture for showing a child's per-app usage on a parent's device in a third-party app? I want to build on the sanctioned path rather than a workaround. Thanks!

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

Hi. I am going through my first App publishing. I had an issue that they cannot login but I don’t understand the issue. For my app login is not required. I have a password needed one time to get in and I provided that in the notes. They shared back the password did not work but I validated again and it is the right password. Any thoughts or feedback. Not really sure what to else to do.

I am seeing a reproducible App Switcher rendering artifact with ManagedSettingsUI shield customization. When a Screen Time shield is customized with ShieldConfiguration.backgroundColor, the shield appears with an uncropped rectangular background layer in the iOS App Switcher. Square corners become visible around the shield card/background layer. This disappears when backgroundColor is nil, and reappears as soon as any UIColor is provided. I also observed the same behavior in another Screen Time app that customizes its shield background, so this does not appear to be specific to my app. Minimal repro: Create an iOS app using FamilyControls, ManagedSettings, and ManagedSettingsUI. Add a ShieldConfigurationDataSource extension. Return a ShieldConfiguration with backgroundColor set to any UIColor. Shield an app and open the shielded app. Open the iOS App Switcher. Example: return ShieldConfiguration( backgroundBlurStyle: .regular, backgroundColor: UIColor(red: 246/255, green: 238/255, blue: 227/255, alpha: 1) ) Expected: The shield background should be clipped consistently with the App Switcher card/screen corner mask. Actual: The shield background appears as a full rectangular layer in the App Switcher, exposing square corners. Control tests: backgroundColor = nil: no square-corner artifact. backgroundColor = UIColor(...): square-corner artifact appears. The issue occurs regardless of backgroundBlurStyle, including nil, .regular, and .systemUltraThinMaterialLight. I filed this through Feedback Assistant as well. Has anyone found a workaround that still allows a custom shield background color?

Hello, I’m trying to clarify whether the new Age Range / Age Assurance Setup Assistant pane can be skipped on macOS when using a standard MDM Device Enrollment flow, not Automated Device Enrollment. Environment: Platform: macOS Tahoe 26.5.1 Enrollment type: MDM Device Enrollment, not ADE / DEP MDM: Microsoft Intune Profile deployment channel: Device profile Payload type: com.apple.SetupAssistant.managed Key used: SkipSetupItems Skip items tested: AgeAssurance AgeBasedSafetySettings The configuration profile installs successfully on the Mac as a device profile. I can confirm that the com.apple.SetupAssistant.managed payload is present on the device and includes the tested SkipSetupItems values. However, the Age Range / age-related Setup Assistant pane is still shown to the user. Example payload content: <dict> <key>PayloadType</key> <string>com.apple.SetupAssistant.managed</string> <key>PayloadIdentifier</key> <string>com.example.setupassistant.managed</string> <key>PayloadUUID</key> <string>REDACTED-UUID</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadDisplayName</key> <string>Managed Setup Assistant</string> <key>SkipSetupItems</key> <array> <string>AgeAssurance</string> <string>AgeBasedSafetySettings</string> </array> </dict> What I expected: When the com.apple.SetupAssistant.managed payload is installed as a device-level profile and includes the relevant age-related skip keys, the Age Range / Age Assurance pane should be skipped during Setup Assistant, or Apple documentation should state clearly that this pane can only be skipped in ADE. What actually happens: The profile installs, but the Age Range / age-related Setup Assistant pane still appears to the user on macOS 26.5.1. Documentation ambiguity: Apple’s Setup Assistant payload documentation says: The supported payload identifier is com.apple.SetupAssistant.managed Supported operating systems/channels include macOS device and macOS user Supported enrollment methods include User Enrollment, Device Enrollment, and Automated Device Enrollment SkipSetupItems is a list of Setup Assistant panes that can be skipped Apple’s macOS Tahoe 26 enterprise notes say: “The new Age Range setup pane is automatically skipped for devices using Automated Device Enrollment.” That wording clearly mentions ADE, but I have not found documentation that explicitly states whether the Age Range pane is intentionally unsupported for non-ADE macOS MDM enrollment, or whether there is a separate skip key required for macOS. Third-party MDM/tooling documentation appears to reference the following newer skip keys: AgeAssurance AgeBasedSafetySettings However, it is unclear whether those keys are supported on macOS, iOS/iPadOS only, ADE only, or all MDM enrollment methods. Questions: Are AgeAssurance and AgeBasedSafetySettings valid SkipSetupItems values on macOS 26.5.1? If yes, are they supported only during Automated Device Enrollment, or should they also work with standard MDM Device Enrollment? If these keys are iOS/iPadOS-only, what is the correct macOS skip item for the Age Range / age-related Setup Assistant pane? Is the Age Range pane intentionally only auto-skipped in ADE on macOS? Should Apple’s public Device Management / SkipKeys documentation be updated to list the correct key names, supported platforms, minimum OS versions, and enrollment requirements? This is important for Mac deployments where devices are enrolled into MDM but are not assigned through Apple Business Manager / Automated Device Enrollment. At the moment, it is difficult to determine whether the behavior is expected, unsupported, or a bug in macOS / Setup Assistant / MDM profile handling. Thanks.

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.

Some of our users encounter an issue after updating their iPhone/iPad to iOS 17.5.1. The tokens passed in the Shield Configuration extension don't match the tokens they selected in my app using the FamilyPicker before updating to iOS 17.5.1. It seems the tokens changed for no reason. My app can't match the token from the ShieldConfigurationDataSource to any tokens stored on my end, causing my shield screens to turn blank. The same applies to tokens in the Device Activity Report extension. The only workaround I've found is to tell affected users to unselect and reselect apps and websites to block in my app. This gets them new tokens from the FamilyActivityPicker, which solves the issue. However, for some users, the bug reoccurs a few days later. Tokens seem to change again, causing the same issue in the Shield Configuration extension. I am not able to reproduce the issue on my test devices so I have no sysdiagnose to attach. However, this issue is affecting other screen time apps: https://developer.apple.com/forums/thread/732845 https://forums.developer.apple.com/forums/thread/756440 FB14082790 FB14111223 A change in iOS 17.5.1 must have triggered this behaviour. Could an Apple engineer give us any updates on this?