Overview

Hello Apple Developer Community, I’m currently trying to convert my Apple Developer Program membership from Individual to Organization. I have already submitted the required information and contacted Apple Developer Support regarding the conversion. My support case ID is: 102986110424 I received an automated confirmation that my support request was received, but I have not yet received a response or an update regarding the conversion. I would like to ask: How long does the Individual → Organization conversion normally take? Has anyone recently completed this conversion? Is there anything else I should provide to Apple to help complete the process? Is it better to continue waiting for the existing support case, or should I submit another request? I would appreciate any recent experience or advice from developers who have gone through the same process. Thank you.

I'm building a two-iPhone app that times a 40-yard (36.576 m) sprint — one phone at the start, one at the finish. Before timing, I need to verify the phones are at least 40 yards apart (no external hardware, no Wi-Fi infrastructure — they talk over my own relay, clocks already synced). I want this to work on as many iPhone models as possible. Questions, by device generation: iPhone 11–14 (1st-gen Ultra Wideband): can these reliably range at ~36.6 m outdoors with Nearby Interaction, or does precise ranging at this distance effectively require 2nd-gen? iPhone 15+ (2nd-gen UWB / Extended Distance Measurement): has anyone measured real-world accuracy at ~30–40 m outdoors? Can it reliably distinguish ~39.9 yd from ~40.1 yd? Which distance-quality signals do you gate a hard pass/fail on (when to trust NINearbyObject.distance, convergence/averaging)? No Ultra Wideband (e.g., iPhone 16e): any Apple-supported approach for approximate phone-to-phone distance at this range, or do you mark the feature unsupported there? After hands-on results at 30 m+ especially — most threads cover indoor/short range. Thanks!

I am developing a watch-only bedside clock for an Apple Watch running watchOS 27.0.1. The user needs to remove the watch in hot weather and still see the time without having a charger available. The requirements are: wrist detection remains enabled; the watch is off wrist and unplugged; the app is opened manually on the watch; the clock remains visible without periodic touches or any Mac/developer connection. Covering the screen should turn it off. The UI contains only the time, date, and battery level. It does not need protected data, HealthKit access, or programmatic unlocking. Independent physical testing still ends in the app transitioning to the background and the display turning off. Always On configuration and background runtime are not sufficient in the tested off-wrist state. Experimental idle-display requests either have no visible effect or extend the visible period to approximately 60 seconds. Updating the native scene's requested idle duration every 20 seconds does not renew the observed display deadline, despite the local readback showing the requested values. Is there a supported public API or system-owned presentation surface that can keep a nonsensitive clock visible in this situation while preserving wrist detection and authentication? If this requires an approved entitlement or a platform capability, is one available to third-party developers for this use case? Please distinguish keeping the process alive, retaining the frontmost app, and keeping the physical display visible after removal from the wrist. I have not claimed additional entitlements or changed the watch's authentication settings. I would appreciate clarification of the supported platform boundary before undertaking further device experiments.

In Xcode 27.1 RC 1 the native keyboard layout has been changed and now it shows the globe button. It looks like a bug but I'm not sure. Is the keyboard going to display the globe button in the final release? On top of that, the keyboard extension tells not to show its own globe button, so it's another point confirming that this is RC 1 regression bug. Xcode 27.1 Beta 1: Xcode 27.1 RC 1:

What we are building We maintain an append-only on-disk store. Every update has the same shape: write a temporary file and make its contents durable; rename() it to its final name; only then publish the new state to the rest of the system. Step 3 is the one we must get right. Once we publish, other components treat the preceding step as committed. If power is lost after we publish but the renamed entry was not yet durable, we would have published a state the filesystem can no longer support after reboot. Our question is therefore narrow: after rename() returns, what does Apple document about when the resulting directory entry may be treated as durable across power loss? Two cases matter, and we would like them distinguished wherever the answer differs: the target name did not exist before — an entry is added; the target name already existed and is replaced — an entry is replaced and an older link is removed. We are not asking you to review or endorse our protocol — only what the platform documents. What we have read, and where we stopped fsync(2) here causes "all modified data and attributes of fildes to be moved to a permanent storage device", then warns that after power loss an application "may find that only some or none of their data was written". fcntl(2) says of F_FULLFSYNC that "data that had been fsync'd on the same device before is guaranteed to be persisted when this call returns", and lists APFS as supported. rename(2) "guarantees that an instance of new will always exist, even if the system should crash in the middle of the operation". In what we read, we did not find a statement connecting a successful synchronisation call on a descriptor that refers to a directory with the durability of a name added, removed or replaced in that directory. We are not claiming no such statement exists — only that we did not find one, which is why we are asking. Three questions, independent of one another Q1 — How are these calls supported on a directory descriptor? On APFS, how are fsync(2) and fcntl(fd, F_FULLFSYNC) supported when fd refers to a directory (for example one obtained with O_DIRECTORY)? Please treat the two calls separately, since they carry different documented guarantees. "Supported", "not supported" and "not specified for this use" are all useful answers to us. Q2 — If such a call succeeds, what does it cover? If the call in Q1 returns successfully, which changes are guaranteed to have been completed — the directory's own attributes; the entries added, removed or replaced; related metadata? We are asking for the documented scope, not the implementation. Q3 — Is there a documented sequence an application can rely on? Is there a sequence of calls that Apple documents for an application that needs the name resulting from a rename() to survive power loss before it publishes its next state? If so, we would appreciate the reference, the conditions it depends on — filesystem, device, call ordering — and its stated limits. If there is no public commitment of this kind, we would rather be told so plainly, together with whatever level you are able to confirm, including "this is not currently specified" if that is the accurate answer. One distinction we do not want to get wrong rename(2) uses the word crash. We do not want to read a statement about crash behaviour as one about power loss, since the two can differ at the device layer. If a documented guarantee covers one and not the other, that distinction is exactly what we need. We also note the device-level caveat in the same manual page — certain drives "have also been known to ignore the request to flush their buffered data" — and we are not asking you to speak for any particular drive. Environment macOS 26.3, build 25D125, APFS — read on our own development machine and reported here as such; not independently verified by a third party. Deliberately outside this request A rename() between two different directories touches a source directory and a target directory. Whether a guarantee would have to cover both is tracked separately and is not asked here, so that an answer about one directory is not read as covering two. We have not fixed where the temporary file lives, and we are not asking you to choose that layout. Nor do we assume your answer is independent of it: if any of the above depends on whether the source and target directories are the same directory or two different ones, please say so explicitly. We would rather be told the answer is conditional than read an unconditional answer into it.

Application is getting Crashed: AXSpeech EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000056f023efbeb0 Crashed: AXSpeech 0 libobjc.A.dylib 0x4820 objc_msgSend + 32 1 libsystem_trace.dylib 0x6c34 _os_log_fmt_flatten_object + 116 2 libsystem_trace.dylib 0x5344 _os_log_impl_flatten_and_send + 1884 3 libsystem_trace.dylib 0x4bd0 _os_log + 152 4 libsystem_trace.dylib 0x9c48 _os_log_error_impl + 24 5 TextToSpeech 0xd0a8c _pcre2_xclass_8 6 TextToSpeech 0x3bc04 TTSSpeechUnitTestingMode 7 TextToSpeech 0x3f128 TTSSpeechUnitTestingMode 8 AXCoreUtilities 0xad38 -[NSArray(AXExtras) ax_flatMappedArrayUsingBlock:] + 204 9 TextToSpeech 0x3eb18 TTSSpeechUnitTestingMode 10 TextToSpeech 0x3c948 TTSSpeechUnitTestingMode 11 TextToSpeech 0x48824 AXAVSpeechSynthesisVoiceFromTTSSpeechVoice 12 TextToSpeech 0x49804 AXAVSpeechSynthesisVoiceFromTTSSpeechVoice 13 Foundation 0xf6064 __NSThreadPerformPerform + 264 14 CoreFoundation 0x37acc CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 15 CoreFoundation 0x36d48 __CFRunLoopDoSource0 + 176 16 CoreFoundation 0x354fc __CFRunLoopDoSources0 + 244 17 CoreFoundation 0x34238 __CFRunLoopRun + 828 18 CoreFoundation 0x33e18 CFRunLoopRunSpecific + 608 19 Foundation 0x2d4cc -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 20 TextToSpeech 0x24b88 TTSCFAttributedStringCreateStringByBracketingAttributeWithString 21 Foundation 0xb3154 NSThread__start + 732 com.livingMedia.AajTakiPhone_issue_3ceba855a8ad2d1af83655803dc13f70_crash_session_9081fa41ced440ae9a57c22cb432f312_DNE_0_v2_stacktrace.txt 22 libsystem_pthread.dylib 0x24d4 _pthread_start + 136 23 libsystem_pthread.dylib 0x1a10 thread_start + 8

How can I tell which DNG opcode belongs to which OpcodeList for a RAW image captured by AVPhotoOutput? I couldn't find any of the OpcodeList1, OpcodeList2 or OpcodeList3 tags in the DNG metadata inside AVCapturePhoto.metadata, but when exporting the photo into a DNG file to disk and extracting that DNG file's metadata using exiftool on a computer, I could see the opcodes in their respective opcode lists. Can I get the opcode lists without exporting into DNG data representation and then parsing the DNG file?

Hi, I've been trying to request the PassKit NFC certificate on our organization Apple Developer account for some time. We submit our request at https://developer .apple.com/contact/passkit/ and usually within 1-2 weeks I get a response saying the request was denied for reasons that can't be shared, but we can resubmit. We have resubmitted several times, doing our best to guess at how to revise the application each time, and each time get the same response. Just wondering if this is a new thing or something others have experienced. Am I really supposed to just keep guessing? Is there an appropriate escalation path? Thank you.

I am using Virtualization framework for running Golden Gate VM in swift ui window with VZVirtualMachineView. i have set the automaticallyReconfiguresDisplay to true. but when i resize the window the resolution of Golden Gate does not change automatically to fit the window. This works fine for Tahoe. Golden Gate is not respecting the automaticallyReconfiguresDisplay. Any help in fixing this bug would be very helpful to me. Thanks in advance

Hey guys i think am not the only one experiencing this delays from Apple review team , it has been like that now +10 days , does anyone know, what is going on??

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 ?