Overview

It's been over 2 weeks and I still don't have the option to download the Mac or iOS 27 betas. All I see is the option for the current public betas for Tahoe and iOS 26. I am a registered developer and thought I would get access to the betas. I've submitted 2 tickets through the feedback assistant and both were closed with the comment "investigation complete - working as designed". I don't know where else to go. Is it true that not every developer gets access to beta software or that developer betas are released in phases? I've never read that anywhere nor heard that once released that beta software isn't available to all developers in the Apple dev program (not the public beta program). Can anyone shed light on this? is this true? Are betas released in phases to developers? At this rate as a developer I will have to wait until the public beta. Help!

I recognize that Apple has put out documentation on how to do things with the new Age APIs, but I have no idea what my apps are supposed to do to be in compliance with this law. Most of the law sounds like it applies to App Store developers like Apple, more than it pertains to individual app devs. If the age rating of an app changes, wouldn't we just put it in App Store Connect and have Apple disable those apps on the devices of the underage kids?

In my UIKit apps, collection view cells that have a context menu gain an Ask Siri item in iOS 27 without me doing anything. In my SwiftUI app I have a LazyVGrid containing a ForEach of CellView which is a Button that has a contextMenu, yet there’s no Ask Siri button in the context menu. What determines whether or not it will be added? What do I need to do to allow the system to add it?

Bluetooth does not show device options, whereas wifi shows the wifi options in control center.

My iPhone 14 Pro (running iOS 27 beta 1) is not booting after discharge of battery (due to not being used for about 10 days). How to restart and update to beta 2 or use it otherwise? I have kept it connected to wall outlet charger for the past 2 hours, and have tried Forced restart (press and quickly release the Volume Up button, press and quickly release the Volume Down button, then press and hold the Side (Power) button until the screen goes black and the Apple logo appears). But nothing works, and the iPhone remains dead.

When I tried to use Xcode to compile an app for my iPhone, it also compiled a macOS version, but they don't work. I tried to delete them from the Applications folder, but they're not there. According to the Xcode logs, I found that they're located in /private/var/folders/ and there are some deprecated projects. How should I delete them?

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.

I know Xcode 27 is in beta but it appears that in Device Hub you can no longer drag and drop enterprise security certificates onto the simulators like you could in Xcode 26 (and earlier) simulators. I did put in a feedback request in (FB23369006) but I was wondering if anyone found a workaround. This hampers testing for enterprise users who don't have a physical device to test on.

Hello Apple Developer Support Team, We understand from the Declared Age Range documentation that, in some regulated regions, the system automatically provides the person’s age range and they can’t decline sharing it with the app. We have implemented the API as prescribed in the documentation. For certain users in Texas, the API returns: isEligibleForAgeFeatures == true declaredAgeRangeRequired == true However, in our testing we observe that these Texas users can still decline sharing their age range, either via the system prompt or later via Settings, which results in no age range being provided to the app. This behavior appears inconsistent with the documentation’s statement that, in regulated regions, the person “can’t decline” sharing their age range, and it also raises questions for us about how this aligns with the applicable legal requirements in Texas. Could you please clarify: Whether this behavior (Texas users being able to decline sharing their age range even when declaredAgeRangeRequired is true) is expected, and Under what exact conditions the “they can’t decline sharing” behavior is enforced for Texas accounts (for example, only for new Apple Accounts created in Texas after a certain date, or only for particular age categories)? Any guidance on how we should interpret isEligibleForAgeFeatures and declaredAgeRangeRequired in this scenario would be greatly appreciated. Thank you.

We need help to structure our project to start using apple standard way to create Xcode project. let me first express how currently we are creating Xcode project. As of today, we are using CMake to generate our xcode project which we can open in XCODE IDE and build/debug/run/etc. XCode IDE can open those project but we notice that some build setting does not seem to have correct value while looking into XCODE IDE but it somehow builds. There are some other issues also. Along with those issues, we also could not share this xcodeproject generated via CMake to AppleDTS support team as Apple does not support project created via some third party tool (like CMake or others). Let me also express why we decided to use CMake at first place to generate Xcode projects. Our project is layered architecture project where in upper layers uses lower layer artifacts. Each layer has its own set of build targets . And each layer can have both C++ and Swift files. And each layer would have most of the compiler flag common, but we could also have compiler flag specific to each layer also. To achieve all these, we have developed our own tool, which basically creates CMakeLists.txt (for project model- all targets, dependency, etc) and CMakePresets.json (for all compiler and linker flags). Now this tool scans through repos/source folders on each layer and then creates these files (CMakeLists.txt and CMakePresets.json). This tool uses inputs to decide compiler/linker/other properties from one centralized location. Which means every developer would use these same input files and thus they all can have same compiler/linker/other properties set consistent. This makes generated build system consistent on all developer machine and it allows confidence of saying if build works on one developer's machine would also work on other developer’s machine and if build does NOT work on one developer's machine, it would NOT work on other developer’s machine also. So, it’s consistent. That was the main reason to use CMake to generate xcode project. So, our internal tools creates meta data for CMake (which is CMakeLists and CMakePresets) and then CMake generates Xcode build system using XCode generator. Now we want to move to xcode native way to create projects but at the same time we also want this consistency that each of my developer would use exact same compiler/linker/other properties. If we ask developer to use XCode IDE to create xcode project, we cannot guarantee that they all will use same compiler/linker/etc flags and thus we would end up having inconsistent behaviour on different developer machines. We need your help to figure out how we can achive this ? We read some ways that we can create some template project and then we can create some .xcconfig files and use them to set target properties but honestly, we are able to stich them together. So please help us directionally on this , how should we proceed ? Basically we need to know how can we have all my developer use same xcodeproject. I was also thinking how would I be setting my CI for apple builds if I have to use XCode IDE to create xcode project and since CI environments are non interactive and it can happen n number of times in day (if I have setup to run sanity for all Pull Requests). Any help/direction on this is highly appreciated.

Dear Apple Developer Support, I am developing and maintaining an iOS application. In iOS 26, we understand that setting UIDesignRequiresCompatibility to true in the Info.plist file allows an app to opt out of the Liquid Glass design. However, we also understand that during WWDC25 Platforms State of the Union, Apple stated: "We intend this option to be removed in the next major release." We would appreciate clarification on the following points. Questions Should the phrase "next major release" be interpreted as iOS 27? Is it currently Apple's plan to make UIDesignRequiresCompatibility unavailable or remove it in iOS 27? Or is the statement above only an intended direction, with the actual removal schedule still subject to change? If there is any publicly shareable information regarding the future availability or deprecation timeline of UIDesignRequiresCompatibility, could you please provide it? Background We develop and maintain a business application that contains a large number of custom screens and UI components. Adapting the entire application to the Liquid Glass design system will require significant design review, implementation effort, and testing. As a result, the future availability of UIDesignRequiresCompatibility is a critical factor in our development planning and resource allocation. For this reason, we would greatly appreciate any guidance you can provide regarding Apple's current plans for this compatibility option. Thank you for your time and assistance. Best regards, Toshiyuki

Hello Everyone, I am a student from India who is passionate about technology, coding, and design. I would like to propose a precise hardware and software design enhancement regarding the "LED Flash for Alerts" feature on the iPhone. Current Limitation: The existing feature utilizes the main camera flash/torch. While functional, it is incredibly bright and harsh, causing visual discomfort in dark rooms, study spaces, or classrooms. My Specific Idea: Instead of using the blinding main flash, Apple could integrate a subtle, soft white LED indicator directly inside or underneath the small black circle element located on the camera module (the sensor/microphone area). When a notification or call arrives, this exact black circle should softly pulse or glow with a clean, ambient white light. Benefits: Precision & Aesthetics: It utilizes an existing design element to create a beautiful, minimalist, and non-disruptive visual alert. User Experience: It provides a soft indicator that doesn't blind the user or disturb others in low-light environments. Power Efficiency: Illuminating a tiny dedicated ring/circle consumes significantly less battery than firing the main camera torch. As a student, I believe this subtle refinement would make the iPhone experience feel even more premium and thought-out. I would love to hear what Apple engineers and the developer community think about this!

We are an Apple Pay consumer and observed elevated response times and intermittent timeouts affecting the create‑session API (apple-pay-gateway.apple.com/paymentservices/paymentSession) between approximately 8:01 PM and 8:35 PM PST today. We are reaching out to understand whether there were any service disruptions during this timeframe, as we do not see corresponding updates on the system status pages. We would like to confirm whether this behavior was related to a broader Apple Pay issue or specific to our integration.

Yesterday I checked the screen time of the previous day and I thought it was 7h.But it is presented to be 10h and a half today.I'm confusing why the ended screen time could change.

I'm seeing what appears to be different UISceneAppIntent behavior between iOS and Designed for iPad on macOS, and I'd like to confirm whether this is expected. I'm working on an iOS app that defines an AppIntent conforming to UISceneAppIntent from the AppIntents framework. The intent is handled by a scene delegate conforming to both UIWindowSceneDelegate and AppIntentSceneDelegate. On iOS, everything works as expected: If the app is launched for the first time from Shortcuts, the intent is available via connectionOptions.appIntent in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is called. However, when running the same iOS app on macOS in Designed for iPad mode, the behavior is different: If the app is launched from Shortcuts, connectionOptions.appIntent is always nil in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is never called, even though the application is successfully activated. Is this expected behavior? I noticed that the AppIntents framework explicitly marks both AppIntentSceneDelegate and UISceneAppIntent as unavailable on macOS: @available(iOS 26.0, tvOS 26.0, *) @available(macOS, unavailable) @available(watchOS, unavailable) public protocol AppIntentSceneDelegate : UISceneDelegate Since the app is running on macOS in Designed for iPad mode and still uses the iOS binary, I wasn't sure whether these scene-based APIs are expected to work in this environment or whether they are intentionally unsupported. Has anyone from Apple or the community been able to confirm whether this behavior is by design, or whether it should be considered a bug? I'd appreciate any clarification.

Hello, I'm implementing an NSFileProviderReplicatedExtension (iOS 26 and macOS 26) and would like to validate my approach. What I do To make my uploads efficient I batch them: instead of uploading file-by-file inside each createItem / modifyItem, I ingest all local changes into my extension's local state quickly and upload the content blobs in the background in batches. Concretely, for both createItem and modifyItem: I persist the item to my local store, write its content blob to a local cache, and schedule the upload in my internal queue. I call the completionHandler right away before uploading the item, returning the NSFileProviderItem with isUploaded = false. Once the upload succeeds, I flip the item to isUploaded = true and call signalEnumerator(for: .workingSet) so the change is delivered through the working-set enumerateChanges. This works in my testing, but I'm unsure it is the intended approach, and I have the following questions. Question 1 — Honoring the Progress object I call the completion handler early (step 2) and run the upload afterwards. The convenient part for my batched uploads is that I don't seem to need to honor the returned Progress at all — I never report into it and I just drop it, yet in my testing the upload still completes. I'd like to confirm two things: (a) Can I ignore the Progress? I'd like to never report into the returned Progress and simply drop it: I coalesce uploads into batches drained from a persisted queue, so I can't map one Progress to one upload, and retaining thousands of them is itself a cost. Is that allowed? What makes me unsure is that the docs read a little asymmetrically — for createItem the progress is "presented in the user interface until the completion handler is called", whereas for modifyItem it is "expected to include the upload progress … even if the provider chose to call the completion handler before the upload finishes". (b) If I ignore it, am I still granted execution time to finish the upload? This is what worries me, because the "Execution time" clause couples the two: the system "will grant enough time … to upload the file" but "will interrupt the call if it stops making progress." If I report no progress, does the system stop granting runtime? Question 2 — Upload pipeline depth When calling the completion handler before finishing the upload, both createItem and modifyItem are no longer gated by the NSExtensionFileProviderUploadPipelineDepth limit, and I can have thousands of items pending upload. This is crucial for my approach. Is this behaviour correct and intended?

Our current business goal is to improve the success rate of iBeacon wake-up on iOS. Apple's official iBeacon specification recommends a standard broadcast interval of 100ms; Now we are planning to shorten the broadcast frequency to 50ms, and we would like to consult the full dimensional impact of this change, and whether it can really improve the success rate of beacon identification and pull trigger on iOS devices.

I activated the Paid Apps Agreement today along with banking and tax information. My app uses react-native-purchases (RevenueCat) with StoreKit 2. When tapping purchase buttons in TestFlight I still get "Product not available - Could not load this product." Products show "Waiting for Review" in App Store Connect. Sandbox tester is configured. Is there a delay after activating the Paid Apps Agreement before sandbox purchases work? How long should I expect to wait?

Hi everyone, I am seeking clarification regarding the communication capabilities between an ESP32 microcontroller and Apple's latest devices, specifically the iPhone 16 Pro Max and iPad Pro, both equipped with USB-C ports. Background: MFi Certification: Historically, establishing communication between external devices and iOS devices required MFi (Made for iPhone/iPad) certification. But I remember this being necessary in the Lightning Cable to USB era. With the introduction of USB-C ports in recent iPhone and iPad models, there is an indication that MFi certification may no longer be necessary for certain peripherals. Perhaps I'm not confident on the terminology here: https://mfi.apple.com/en/who-should-join Project Requirements: I am working on a sensor research project that necessitates the collection of low-latency time-series data from an ESP32 microcontroller, which features a USB-C port. The data needs to be transmitted to an iPhone 16 Pro Max or iPad Pro. Bluetooth communication has proven insufficient due to its limited data transfer rates (~1.2 Mbps with L2CAP). While NEHotspot could be an alternative, it restricts the iPad's internet connectivity. Therefore, establishing a direct USB-C connection between the ESP32 and the iOS device appears to be the most viable solution. Questions: MFi Certification Necessity: Is MFi certification still required for an ESP32 microcontroller to communicate with iPhone 16 Pro Max or iPad Pro via USB-C? USB-C Communication Support: Do the iPhone 16 Pro Max and iPad Pro natively support serial communication over USB-C with microcontrollers like the ESP32? If not, are there recommended protocols or interfaces to facilitate this communication? App Development Considerations: Would developing a custom iOS application be necessary to handle data transmission from the ESP32 over USB-C? If so, are there specific APIs or frameworks provided by Apple to support this functionality? Data Transfer Rates: Considering the need for high-speed data transfer, are there any limitations or considerations regarding the data transfer rates achievable through a USB-C connection between the ESP32 and iOS devices? Thank you!

I'm building a custom keyboard extension that offers voice dictation. Because keyboard extensions are constrained (memory cap ~30–48 MB, restricted audio session access), I delegate recording to my container app: User in a host app (e.g., Safari) taps the mic in my keyboard extension. The keyboard calls extensionContext.open(URL("myapp://dictation")) to launch the container app. The container app records audio via AVAudioEngine + SFSpeechRecognizer, writes the final transcript to the App Group, and signals completion via a Darwin notification. 4. The user is expected to be returned to the original host app (Safari) automatically so they can keep typing. The problem (step 4): On iOS 26.4 I can no longer identify which app was the host. Every previously-known path returns nil for the keyboard extension's host: parent.value(forKey: "_hostBundleID") → returns the literal string parent.value(forKey: "_hostApplicationBundleIdentifier") → returns NSNull xpc_connection_copy_bundle_id on the underlying XPC connection (via PKService.defaultService.personalities[…]) → returns NULL NSXPCConnection.processBundleIdentifier on extensionContext._extensionHostProxy._connection → returns nil proc_pidpath(hostPID, …) → EPERM from the keyboard sandbox LSApplicationWorkspace.frontmostApplication → selector unavailable from the extension RBSProcessHandle.handleForIdentifier:error: → returns an RBSServiceErrorDomain error Without the host's bundle ID, the container app has no way to call LSApplicationWorkspace.openApplicationWithBundleID: (the technique that worked on iOS 25 and earlier). UIApplication.suspend() correctly sends the container to background, but iOS treats us as a "fresh launch" — it returns the user to the Home Screen instead of Safari, because the container app was launched by an extension, not directly by Safari. KeyboardKit's maintainer reached the same conclusion (issue #1014) and shipped 10.4 without the feature. My questions: Is there a public, App-Store-safe API in iOS 26+ for a custom keyboard extension to identify its host application, or for the container app (launched via the extension's openURL) to identify which app initially hosted the extension that opened it? UIOpenURLContext.options.sourceApplication reports the extension's own container, not the actual host. 2. Is there a public mechanism for "return to source app" when the container app was launched by an extension's openURL? Equivalent to the ← Source affordance iOS shows for normal inter-app openURL, but triggered programmatically by the launched app. 3. Some popular keyboards (e.g., 微信输入法 / WeChat Keyboard) still appear to round-trip through their container app on iOS 26.4 and return the user to the original host — including the iOS ← WeChat back affordance in the host's status bar afterward. What's the recommended approach to achieve this? If it requires a specific scene-activation flow, NSUserActivity pattern, or extension-context configuration, please point at the relevant docs. 4. If there is no public path today, is FB22247647 (or a related radar) the right place to track this? Should developers in this position migrate to in-extension audio capture (which has its own significant constraints in keyboard extensions)? I'd much rather not rely on private APIs. Concrete guidance — or even an acknowledgment of which direction Apple intends — would help thousands of custom-keyboard developers who currently have a degraded voice-input experience on iOS 26.4+. Tested on iPhone 12 Pro Max running iOS 26.4.2 (build 23E261), Xcode 26.x, Swift 5. Thanks!