Overview

In iOS 27, willTransition(to:with:), registerForTraitChanges(), and other mechanisms to monitor size classes do not change when an iPhone interface is resized. Only viewWillTransition(to:with:) is invoked with a new size. And this only happens on the iPhone: the iPad continues to work as it has in the past. It appears that this is intended behavior. That is not to say that it's intuitive behavior. Many experienced developers are encountering the "horizontal size is always compact" behavior and immediately thinking "this must be a beta bug": https://fatbobman.com/en/posts/from-size-class-to-available-space/ But it's not. I get that the new size class behavior is expressing static device semantics and is no longer a dynamic size indicator. The problem is that the tools we have been using to build layouts for the past decade use size classes as dynamic sizing indicators. Storyboards can contain variations that specify whether a constraint is used for regular or compact widths/ heights. Developers have used this ability to automatically adjust layouts as the size classes change. In one case, I use this capability to adjust a top-over-bottom layout in a portrait configuration to a side-by-side in a landscape configuration: switching centering, leading/trailing, and aspect ratios to fit the available size. I suspect that many developers who have taken the time to create a unique layout for an iPad are doing something similar. (Ironically, the folks who treated an iPad as a big iPhone are the ones least affected by this change.) When iPadOS got the ability to resize interfaces (as UIScene windows), I made sure that the automatic size class contraints worked correctly and made adjustments as necessary. That work now has to be discarded and switched over to something more universal. If this is truly the intended behavior going forward, time needs to be invested in updating the tooling behind automatic constraint variations: There should be warnings when the storyboard is compiled. I have dozens of automatic contraints embedded in the storyboard: and they're hard to find (each subview has its own contraints, so it's a manual traversal of a huge tree). There should be runtime warnings that your code that inspects size classes won't be executed. This was the biggest "what the hell is going on?" when trying to resize the interface the first time. At a higher level, Apple engineers have described what is happening. They have not explained why the iPhone is behaving differently than an iPad. And that's the root of this whole situation being unintuitive. We've got no clue. And developers without a clue are unlikely to adopt a new technology. It's essential that Apple explains this change in more detail. Yes, you're going to have to obfuscate it and make us read between the lines, but it's got to be done. (Everyone understands the changes regarding mainScreen wink wink, for example.) A reply in this thread would be a good place to start this explanation.

I've hit a dead end with normal Apple support channels. I wrote up a radar for it (FB23333685). I used curl -v https://developer.apple.com/forums/ on my Mac via my phone's hotspot (working) and via Spectrum (not working) (some irrelevant stuff elided to shrink post): Working: % curl -v https://developer.apple.com/forums/ * Host developer.apple.com:443 was resolved. * IPv6: 2620:149:a06:f000::134, 2620:149:a06:f000::139 * IPv4: 17.253.31.140, 17.253.31.139 * Trying [2620:149:a06:f000::134]:443... * Connected to developer.apple.com (2620:149:a06:f000::134) port 443 <elided> > GET /forums/ HTTP/1.1 > Host: developer.apple.com > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < Server: Apple < Date: Mon, 22 Jun 2026 23:22:30 GMT < Content-Type: text/html;charset=utf-8 < Vary: Accept-Encoding < Set-Cookie: oid-dev-forums=; Path=/; Domain=.apple.com; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Max-Age=0; Secure; HttpOnly < Expires: Mon, 22 Jun 2026 23:22:29 GMT < X-Frame-Options: DENY < Strict-Transport-Security: max-age=31536000; includeSubDomains < Service-Worker-Allowed: / < User-Type: anonymous < Cache-Control: private,no-cache,no-store, must-revalidate, max-age=0 < Last-Modified: Mon, 22 Jun 2026 23:22:29 GMT < X-Content-Type-Options: nosniff < Content-Security-Policy: <elided> < Vary: Accept-Encoding < X-XSS-Protection: 1; mode=block < Vary: Origin < Vary: Access-Control-Request-Method < Vary: Access-Control-Request-Headers < Content-Language: en-US < X-Request-ID: 41b2b91a2a2c5e8be35787ec7b349db8 < Edge-Control: !no-store,max-age=3600 < X-Request-ID: 41b2b91a2a2c5e8be35787ec7b349db8 < Set-Cookie: myacinfo=; Path=/; Domain=.apple.com; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Max-Age=0; Secure; HttpOnly < Set-Cookie: asc_user=; Path=/; Domain=.apple.com; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Max-Age=0; Secure < Set-Cookie: XID=<redacted>; Path=/; Domain=.apple.com; Expires=Wed, 22 Jul 2026 23:22:29 GMT; Max-Age=2592000; Secure; HttpOnly < Set-Cookie: df_shld_btm_prd=<redacted>; Expires=Tue, 23 Jun 2026 11:22:30 GMT; Max-Age=43200; Domain=apple.com; Path=/; SameSite=Lax; Secure < Age: 2 < Via: https/1.1 ussea4-edge-mx-005.ts.apple.com (acdn/302.16436), https/1.1 ussea4-edge-fx-007.ts.apple.com (acdn/302.16436) < X-Cache: miss, miss < CDNUUID: 42f00814-9cfb-4675-a0fa-4f3aa5ba89da-2134634100 < Transfer-Encoding: chunked < Connection: keep-alive < <!DOCTYPE html> … Failing: % curl -v https://developer.apple.com/forums/ * Host developer.apple.com:443 was resolved. * IPv6: (none) * IPv4: 17.253.83.137, 17.253.83.132 * Trying 17.253.83.137:443... * Connected to developer.apple.com (17.253.83.137) port 443 <redacted> * SSL certificate verify ok. * using HTTP/1.x > GET /forums/ HTTP/1.1 > Host: developer.apple.com > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off < HTTP/1.1 403 Forbidden < Server: Apple < Date: Mon, 22 Jun 2026 23:16:25 GMT < Content-Type: text/html < Content-Length: 146 < Cache-Control: private, no-cache, no-store, max-age=0 < Age: 0 < Via: https/1.1 uslax1-edge-mx-005.ts.apple.com (acdn/302.16436), https/1.1 uslax1-edge-fx-015.ts.apple.com (acdn/302.16436) < X-Cache: miss, miss < CDNUUID: 4da2a4a9-3bd4-4135-b895-6b58b6d7f53b-1614544808 < Connection: keep-alive < <html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> <hr><center>Apple</center> </body> </html> * Connection #0 to host developer.apple.com left intact The Spectrum response never reached the forums app at all — it was rejected at the edge node itself (uslax1-edge-mx-005 / uslax1-edge-fx-015, both LA-area). The working request happened to land on a Seattle-area edge (ussea4) via anycast routing. So this isn't an app-level or account-level block — it's a deny rule sitting on (or upstream of) the LA edge PoP for my specific IP. Thing is, I don’t know how to get help on this issue.

I have a personal iOS project that I also compile for macOS with Catalyst. When built with Xcode 26.x, everything is linked correctly. When built with Xcode 27 betas, the following runtime error occurs: Termination Reason: Namespace DYLD, Code 4, Symbol missing Symbol not found: _UIFontTextStyleCallout Referenced from: <046ED276-F81A-31B4-82FF-6DC82E9041BC> /Applications/Photo Library.app/Contents/MacOS/Photo Library Expected in: <298B64F6-9BC0-3BFB-BE72-EBDC2BE0FF19> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit Any assistance? Thanks

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.

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.

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!