Overview

Dear Screen Time Team! The current 6 MB memory limit for the DeviceActivityMonitor extension no longer reflects the reality of modern iOS devices or the complexity of apps built on top of the Screen Time framework. When Screen Time APIs were introduced with iOS 15, hardware constraints were very different. Since then, iPhone performance and available RAM have increased significantly…but the extension memory limit has remained unchanged. My name is Frederik Riedel, and I’m the developer of the screen time app “one sec.” Our app relies heavily on FamilyControls, ManagedSettings, and DeviceActivity to provide real-time interventions that help users reduce social media usage. In practice, the 6 MB limit has become a critical bottleneck: The DeviceActivityMonitor extension frequently crashes due to memory pressure, often unpredictably. Even highly optimized implementations struggle to stay within this constraint when using Swift and multiple ManagedSettings stores. The limit makes it disproportionately difficult to build stable, maintainable, and scalable architectures on top of these frameworks. This is not just an edge case…it directly impacts reliability in production apps that depend on Screen Time APIs for core functionality. Modern system integrations like Screen Time are incredibly powerful, but they also require a reasonable amount of memory headroom to function reliably. The current limit forces developers into fragile workarounds and undermines the robustness of apps that aim to improve users’ digital wellbeing. We would greatly appreciate if you could revisit and update this restriction to better align with today’s device capabilities and developer needs. Thank you for your continued work on Screen Time and for supporting developers building meaningful experiences on top of it. Feedback: FB22279215 Best regards, Frederik Riedel (one sec app)

Kevin's Guide to DEXT Signing The question of "How do I sign a DEXT" comes up a lot, so this post is my attempt to describe both what the issues are and the best current solutions are. So... The Problems: When DEXTs were originally introduced, the recommended development signing process required disabling SIP and local signing. There is a newer, much simpler process that's built on Xcode's integrated code-signing support; however, that newer process has not yet been integrated into the documentation library. In addition, while the older flow still works, many of the details it describes are no longer correct due to changes to Xcode and the developer portal. DriverKit's use of individually customized entitlements is different than the other entitlements on our platform, and Xcode's support for it is somewhat incomplete and buggy. The situation has improved considerably over time, particularly from Xcode 15 and Xcode 16, but there are still issues that are not fully resolved. To address #1, we introduced "development" entitlement variants of all DriverKit entitlements. These entitlement variants are ONLY available in development-signed builds, but they're available on all paid developer accounts without any special approval. They also allow a DEXT to match against any hardware, greatly simplifying working with development or prototype hardware which may not match the configuration of a final product. Unfortunately, this also means that DEXT developers will always have at least two entitlement variants (the public development variant and the "private" approved entitlement), which is what then causes the problem I mentioned in #2. The Automatic Solution: If you're using Xcode 16 or above, then Xcode's Automatic code sign support will work all DEXT Families, with the exception of distribution signing the PCI and USB Families. For completeness, here is how that Automatic flow should work: Change the code signing configuration to "Automatic". Add the capability using Xcode. (USB & PCI) Edit your Entitlement.plist to include the correct "Development Only" configuration: USB Development Only Configuration: <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <string>*</string> </dict> </array> PCI Development Only Configuration: <key>com.apple.developer.driverkit.transport.pci</key> <array> <dict> <key>IOPCIPrimaryMatch</key> <string>0xFFFFFFFF&amp;0x00000000</string> </dict> </array> If you've been approved for one of these entitlements, the one oddity you'll see is that adding your approved capability will add both the approved AND the development variant, while deleting either will delete both. This is a visual side effect of #2 above; however, aside from the exception described below, it can be ignored. Similarly, you can sign distribution builds by creating a build archive and then exporting the build using the standard Xcode flow. Debugging Automatic Code-signing In a new project, the flow I describe above should just work; however, if you're converting an existing project, you may get code signing errors, generally complaining about how the provisioning profile configuration doesn't match. In most cases, this happens because Xcode is choosing to reuse a previously downloaded profile with an older configuration instead of generating a new configuration which would then include the configuration changes you made. Currently, you can find these profile files in: ~/Library/Developer/Xcode/UserData/Provisioning Profiles ...which can make it easier to find and delete the specific profile (if you choose). However, one recommendation I'd have here is to not treat the contents of that folder as "precious" or special. What automatic code signing actually does is generate provisioning profiles "on demand", so if you delete an automatic profile... Xcode will just generate it again at the next build. Manually generating profiles is more cumbersome, but the solution there is to preserve them as a separate resource, probably as part of your project data, NOT to just "lose" them in the folder here. If they get deleted from Xcode's store, then you can just copy them back in from your own store (or using Xcode, which can manually download profiles as well). The advantage of this approach is that when profiles "pile up" over time (which they tend to do), you can just delete[1] all of them then let Xcode regenerate the ones you're actually trying to investigate. In terms of looking at their contents, TN3125: Inside Code Signing: Provisioning Profiles has the details of how to see exactly what's there. [1] Moving them somewhere else works too, but could indicate a fear of commitment. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hi there, I'm planning to develop a simple underwater compass app for Apple Watch Ultra 2, intended for recreational scuba diving down to 40 meters. The app itself does not need depth or pressure measurements beyond 6 meters. Its primary function is compass navigation using heading data. During a dive, however, I would like the app to: remain frontmost and visible throughout the dive; use Water Lock; use an underwater-depth WKExtendedRuntimeSession; continue receiving compass heading updates; allow interaction through physical controls such as the Digital Crown and Action Button; remain operational below 6 meters, potentially down to 40 meters. I understand that the Shallow Depth and Pressure capability limits CMWaterSubmersionManager depth/pressure data to approximately 6 meters, while access to depth/pressure data down to 40 meters requires the full Submerged Depth and Pressure entitlement. My question is: If my app does not require depth/pressure measurements beyond 6 meters, is the full Submerged Depth and Pressure entitlement still required simply to keep the underwater extended runtime session, UI, compass heading updates, and physical-control interaction working below 6 meters? In other words, does the 6-meter entitlement limit apply only to depth/pressure data, or does it also limit the ability of an underwater compass app to remain operational during a scuba dive below 6 meters? Target hardware: Apple Watch Ultra 2. Thanks in advance!

Hello, In 2026, is there any way to ensure that a thread runs on a particular CPU core and stays on that core? I've noticed that this question was asked a few times years ago and the answers were negative but I'm curious if the situation has changed. Thanks.

When saving in-app events in App Store Connect, I am geting "Country or Region Availability couldn't be saved. Try again later. " Have tried many times. But still stuck there. Any idea? Thanks.

I'm building a podcast app (AVPlayer, .playback + .spokenAudio). When the user asks Siri a non-media question, such as "What is the capital of France?", our audio pauses as expected. But the interruption-ended notification with .shouldResume, and on iOS 27 the resumption recommendation, arrive only when the user dismisses Siri's answer card. If the card is left up, we stay paused indefinitely. Under the same conditions (same device, same question, card left up), these apps resume within a few seconds while the card is still visible: Apple Music Apple Podcasts Pocket Casts (its log shows interruption-ended with shouldResume 3–7 s after began) Overcast Our app, installed through TestFlight, and a minimal AVPlayer sample both wait for dismissal. What we've ruled out (each changed one variable, no effect): Mode .spokenAudio vs .default (with .default, playback continues but stays ducked until dismissal) Route-sharing policy .longFormAudio vs .default AVPlayer vs AVAudioEngine Calling pause() on interruption vs letting AVPlayer pause itself Now Playing registration on or off Calling setActive(false) 5 s after the interruption began SiriKit: Siri capability plus in-app INPlayMediaIntent handling (Siri found the app and started playback through our handler; no change) Our app responds within 0.05 s once the signal arrives, so the delay is entirely in delivery. AVAudioSession.promptStyle reads .short from Siri's answer until dismissal, then returns to .normal at the same moment our end notification arrives. Seen on iPhone with iOS 27.0 and 27.0.1, and on iPad with iPadOS 26.6, so it isn't new in iOS 27. Questions: What determines whether an interrupted session receives interruption-ended while Siri's answer card is still visible? Is this related to App Store vs TestFlight/development distribution, or is there something an app needs to adopt? A focused sample project is available. I also have an open DTS case on this.

Hello Apple App Review Team, I’m reaching out to request an update on the review status of my app, LetsGo Cayman.

Hi App Review team, Our new iOS app was rejected on September 30, 2026 under Guideline 2.1(a) related to demo account access. We replied in App Store Connect with clarifying questions that same day and have not received a response in nearly a week. We also opened Case ID 102983881736 on Friday with no reply yet. The reviewer ran into two separate sign-in issues: Sign in with Apple: Our app is a companion app for an existing web platform, so it currently only allows sign in for accounts already set up on our website. The reviewer's Apple ID showed the expected "Please sign in on the web app to continue" message. Since Sign in with Apple uses the reviewer's own Apple ID, we can't provide standalone credentials for it. Google: Our Google demo account was hit with a Google "Verify it's you" security challenge. That prompt comes from Google, not our app. We can't reliably provide Google or Microsoft demo credentials, because we can't control when those providers trigger security checks during review. To solve both issues, we've built invite code support into the sign-in flow. When a user successfully signs in with Google, Microsoft, or Apple and no account exists for that email in our system, the app now prompts for an invite code instead of showing the "Please sign in on the web app to continue" message. For review, the reviewer would sign in with their own account and enter an invite code from our App Review Information notes, which links their OAuth sign-in to a fully seeded demo account. Before resubmitting, we need answers to two questions: Is this invite code approach acceptable for review? Does the reviewer need to test all three sign-in methods (Google, Microsoft, and Apple), or is one enough? This tells us whether to provide one invite code or a separate code for each method. We'd like to confirm this before resubmitting so the next review goes smoothly, but our launch is on hold until we hear back, so a reply soon would be greatly appreciated. All other fixes are complete. Once we have an answer, we will add the invite code(s) to our App Review Information notes and resubmit with a new build right away. Thank you.

Hi everyone, I am currently enduring Day 39 of an absolute nightmare trying to get my first app published. My app finally moved to "In Review," but it has now been completely frozen in that exact state for 10 consecutive days with absolutely zero communication, no testers reaching out, and no rejections. Here is the exact timeline of this 39-day struggle: 17 Days: Wasted waiting for an enrollment system glitch to be resolved. 12 Days: Frozen on "Waiting for Review" despite an officially approved Expedited Review. 10 Days (Current): Permanently stuck "In Review" in total silence. A 10-day "In Review" freeze is not a normal wait time; it clearly indicates that my submission is locked in a backend system bug. Standard email support only sends automated templates and ignores my active escalation cases. Can any Apple Engineer, App Store Connect Specialist, or Moderator here please manually look into my account and clear this technical lock? I am desperate for human intervention to end this suffering. Team ID: 8A9595UHD7 Open Cases: 102987332129, 102986862146 Thank you to anyone who can help.

Hi, I have an user experiencing networkError(Foundation.URLError(_nsError: Error Domain=NSURLErrorDomain Code=-1008 "(null)")) when my app calls AppTransaction.shared on macOS 15.6. They have tried multiple internet connections, but the issue persists. What could be the root cause ?

Hello, Our app Virtual Pro Association has been stuck in “Waiting for Review” since September 28, 2026 at 21:46. We requested an Expedited App Review, and Apple confirmed that the request was accepted with the message: “We’ll expedite review for Virtual Pro Association.” Despite this, almost 6 days have passed and the submission has still not moved to “In Review.” We have also contacted App Review Support regarding the review status and are currently waiting for a response. App: Virtual Pro Association Version: 1.0 Build: 72 Apple ID: 6809065140 There are no messages, rejections, or actions required in App Store Connect. Has anyone experienced a similar delay recently, especially after an expedited review was granted? Is there anything else we should do, or should we simply keep waiting? Thank you.

I can no longer use Codex within Xcode anymore because it says it's unsupported. gpt-5.5 has been out for several months...please update for support for it. I don't want to have to jump through a bunch of hoops using Terminal just to be able to use Codex in Xcode.

In a CarPlay app using the driving-task entitlement, an enabled CPButton in a CPListTemplateDetailsHeader does not respond across its full visible area. Tapping the upper part of the button (above the title text) invokes the handler. Tapping the text, or the area below it, does nothing. I can reproduce this in both the CarPlay Simulator and on a real CarPlay display. Environment Xcode 27.0 (27A266a), macOS 27.0 iOS 27.0 Entitlement: com.apple.developer.carplay-driving-task Sample project A minimal project that reproduces it is attached. It builds a CPListTemplate with a CPListTemplateDetailsHeader containing a single action button ("Continue Trip" on the trip screen, "Next Stop" on the day screen). When the handler fires, the app presents a CPAlertTemplate, logs to the console, and increments a counter on the phone screen, so a successful tap is unambiguous. Relevant code let image = UIImage(systemName: "calendar.badge.clock") ?? UIImage() let button = CPButton(image: image) { [weak self] _ in self?.showAlert("Continue Trip handler called") } button.title = "Continue Trip" button.isEnabled = true let header = CPListTemplateDetailsHeader( thumbnail: thumbnail, title: "Coastal Road Trip", subtitle: "Sep 23 – Sep 25", bodyVariants: bodyVariants.map { NSAttributedString(string: $0) }, actionButtons: [button] ) header.wantsAdaptiveBackgroundStyle = true let template = CPListTemplate(title: "Coastal Road Trip", listHeader: header, sections: [], assistantCellConfiguration: nil) Steps to reproduce Run the project on an iOS 27 iPhone with CarPlay connected, or use the CarPlay Simulator. Open the app on CarPlay and select Coastal Road Trip from Trips. Tap different parts of the Continue Trip button in the header. After a successful tap, dismiss the alert and try another part of the button. Select a day card and repeat with Next Stop in the day details header. Compare taps that show the alert / log a console message with taps that produce no response. Expected: the action fires when any part of the visible, enabled button is tapped. Actual: only part of the button (the upper region) fires the handler. The tappable area appears misaligned with the visible button. What I've checked The header and button are the system-provided CPListTemplateDetailsHeader and CPButton, so I have no access to the underlying view hierarchy or constraints. An overlapping view of my own is not possible. The button is enabled and has both an image and a title. Questions Is this a known issue with CPListTemplateDetailsHeader action buttons in iOS 27? Is there any supported configuration (image-only button, different image size, no bodyVariants, etc.) that avoids the misaligned hit area? Apple DTS case: 22419931. Thanks!

Hello, I paid for my Apple Developer Program membership on September 28, 2026. As of October 6, my enrollment is still pending, and my account continues to show “Purchase your membership” and the message that payment may take up to 48 hours to process. I have contacted Apple Developer Support several times but have not received a response or a callback. Xcode still only shows my Personal Team. What is the appropriate way to escalate this enrollment issue and have the existing payment and enrollment reviewed? I can provide payment details privately through an official support channel if needed. Thank you.

Hello Apple Developer Support, Our app is ready for testing, but our organization enrollment remains unresolved more than two weeks after submitting the requested documents. The delay and lack of a clear status are frustrating both our client and our development team. Company: Al Rakaiz Al Bashariyya Company For Recruitment Enrollment ID: ZAB5P7U3NR Support Case ID: 102985809833 I uploaded the requested ID, commercial registration, authorization letter, and engagement verification on September 20, 2026. However, I received further document reminders on September 27 and October 4. I contacted support on October 4 and still have no substantive response. Could an Apple staff member please review this case and confirm what is actually blocking enrollment? Have the documents been received and linked to our application? Is anything missing, or is a response from the organization’s verification contact still required? We are ready to resolve any outstanding requirement immediately. We need a clear status and a specific next step so we can move forward. Thank you.

I think this could be relate to previous post here https://developer.apple.com/forums/thread/848590 But in my testing it seems like most of the time spent was in loading but not compilation. Our app has multiple models but so far it seems like one of them has this issue. The model itself was only 2.2MB, but somehow loading took 50s after compilation? And on 17e it only took 2s to load. But I cannot attach the model here so please advice.

Hello, My notarization submissions have all stayed "In Progress" and produced no log. The first one has been waiting for almost a week: 07701908-cfc9-416b-93d8-783b50cb25c2, created 2026-09-29T18:11:38Z (the earliest) 11ab0aff-70d2-4cc6-a26f-8169e2f2a749, created 2026-10-04T14:23:28Z 99bfd78f-d4be-488a-aa1a-b6a81931d1c5, created 2026-10-05T15:24:00Z These are the only submissions that have been made. Team ID: YHQLC8PBT3 App: Termstead (com.pavelkhorenyan.Termstead), a macOS SSH client, universal (arm64 + x86_64) Signed with Developer ID Application, with the hardened runtime and a secure timestamp; codesign --verify --deep --strict passes Submitted as a zip with xcrun notarytool submit --wait from my Mac Could you take a look? Thank you, Pavel

I’m evaluating a native watchOS smart-alarm app and would like to clarify whether public APIs support its core requirement before building a prototype. The app would wake the user during a 20–30-minute window before their selected alarm time, using Apple Watch’s own sleep-stage classifications available through HealthKit’s sleepAnalysis category: Core, Deep, REM, and Awake. I have reviewed HKCategoryValueSleepAnalysis, HKAnchoredObjectQuery, HKObserverQuery, background delivery, and WKExtendedRuntimeSession’s Smart Alarm mode. However, I haven’t found documentation establishing when Apple-generated sleep-stage samples become available during an ongoing sleep session. Could you clarify: Are Apple-generated sleep-stage samples written to the Watch’s local HealthKit store during sleep, or only after the sleep session ends or subsequent processing? If available during sleep, is there any documented update cadence or latency that would make them suitable for a smart alarm? Should the latest sample be treated only as a retrospective classification rather than the current sleep stage? Can an app query these samples during a Smart Alarm extended runtime session while the Watch is worn and unlocked, with its display off and Sleep Focus enabled? Are there relevant execution or data-access restrictions? If this use case is unsupported, is there any public API that exposes Apple’s current sleep-stage estimate? If not, which Feedback Assistant category is appropriate for requesting this capability? The intended approach queries HealthKit directly on Apple Watch, without depending on Watch-to-iPhone synchronization, and retains a fixed latest wake-up time as a fallback. This is an API feasibility question, not a reproduced bug. I haven’t yet built or tested a prototype. Thank you.

I'm posting this here because sources say that Apple personnel have been peeking in here and I hope that's true, and can provide some guidance. I've got an app that was rejected for "Guideline 4.3(a) - Design - Spam". It isn't. It really isn't. It's not an ad generator. It's not a PII collector, etc. It's a legit application. I found a process to upgrade it to expedited at least a week ago, and did that. Still nothing. I'd love some guidance, even if that means sitting on a phone call on hold for a while in a queue or something. Any reasonable suggestions? Thanks!

I got this error when using iPhone Duo Simulator on Xcode 27.1 iPhone Duo’s iOS Simulator platform doesn’t match App.app’s supported platforms. You can change App.app’s Base SDK or Supported Platforms to support iPhone Duo. My Supported Platforms is already iOS. How to fix this one properly?