Overview

Hi Team, If I want to create a command line app in swift which needs to be invoked using sudo, will I be able to sandbox this app?

Since updating to macOS 27 beta 3 (build 26A5378j), my Mac is unable to establish any new TCP connections. This affects all outbound traffic regardless of destination or protocol, while ICMP (ping) continues to work normally. Steps to reproduce: Update to macOS 27 beta 3 (26A5378j) Connect to a standard home Wi-Fi network (no VPN, no proxy, no enterprise MDM profile) Attempt any outbound TCP connection (curl, git pull, ssh) Expected behavior: Connections to any HTTPS endpoint or SSH server should establish normally. Actual behavior: curl -4 -v https://github.com curl -4 -v https://google.com both hang indefinitely at "Trying [IP]..." — the TCP handshake never completes git pull over both HTTPS and SSH remotes times out with "Failed to connect... Timeout was reached" ping github.com and ping google.com both succeed normally and immediately This confirms the issue is isolated to TCP connection establishment, not DNS resolution or general network connectivity Issue persists identically across multiple reboots System info: macOS 27.0 beta 3, build 26A5378j Connected via personal home Wi-Fi (Bbox router) No VPN, no proxy, no enterprise security software Additional context: Multiple other users have reported identical symptoms on this same build across MacRumors forums and Reddit, describing broken connections in Firefox, Opera, Dropbox, Telegram, and Music/iTunes purchases, while Safari continues to work. Reported workarounds from other affected users include: Disabling "Limit IP Address Tracking" on the network interface Disabling all Network Extensions under System Settings → General → Login Items & Extensions Uninstalling CrowdStrike Falcon or similar EDR/security software (where present) This was working correctly on both beta 1 and beta 2, the regression appears to have been introduced specifically in beta 3.

I have a production app that originally used Core Data + CloudKit and was later migrated to SwiftData. The SwiftData migration preserved the existing SQLite store by explicitly pointing ModelConfiguration at the original database: let configuration = ModelConfiguration(url: storeURL) let container = try ModelContainer(for: schema, configurations: configuration) Because of this, my app does not use the higher-level ModelConfiguration(groupContainer:cloudKitDatabase:) initializer. I would now like to migrate the store into an App Group so it can be shared with widgets. During the WWDC26 SwiftData Group Lab (around 18:53), the guidance was: Moving to an App Group container is more involved: it's a different directory and entitlements can't be aligned to the old location, so you'll get a new container and must copy the existing data over into the group container, then start from there. However, I couldn't find documentation describing how Apple recommends performing that copy for a SwiftData application that already uses an explicit SQLite URL. Why the Core Data APIs don't seem applicable The obvious approach would be to use Core Data APIs such as: replacePersistentStore migratePersistentStore However, these APIs require a Core Data stack and a managed object model (.momd). After migrating completely to SwiftData, I no longer have a .momd in my project, so creating an NSPersistentContainer solely to move an existing SQLite store doesn't appear to be possible. Is there a supported way to use these APIs with a SwiftData store, or are they no longer intended for this scenario? Experiment Since the migration happens before creating the ModelContainer, I experimented with simply moving the entire persistence package using FileManager before SwiftData is initialized. Specifically I move: Store.sqlite Store.sqlite-wal Store.sqlite-shm .Store_SUPPORT Store_ckAssets from the application's Application Support directory into the App Group container, and then initialize SwiftData using: let configuration = ModelConfiguration(url: appGroupStoreURL) let container = try ModelContainer(for: schema, configurations: configuration) After doing this: all existing data is present; new data can be created successfully; if I run an older build that still points to Application Support, SwiftData simply creates a brand-new empty store there, which suggests the original store was indeed moved successfully. So from a local persistence perspective, this appears to work. Remaining concern Although this approach appears to preserve the SQLite store unchanged, I don't know whether it is actually safe for CloudKit. Specifically: Does moving the complete persistence package with FileManager preserve all CloudKit metadata needed for continued synchronization? Is there any risk that CloudKit will treat the moved store as a different store and re-upload or duplicate records? Are there additional files or directories that must also be moved besides: Store.sqlite Store.sqlite-wal Store.sqlite-shm .Store_SUPPORT Store_ckAssets Is there an Apple-recommended migration path for this scenario that avoids introducing a temporary Core Data model purely to move the store? In other words: What is the recommended migration path for an existing production SwiftData application using an explicit SQLite URL to move into an App Group while continuing to use CloudKit? One additional question The SwiftData documentation provides two different ways to configure persistent storage: ModelConfiguration( groupContainer: ..., cloudKitDatabase: ... ) and ModelConfiguration( url: ..., cloudKitDatabase: ... ) My understanding is that when using the groupContainer initializer, SwiftData may automatically handle moving the persistent store into the App Group when the application is updated. However, when using the url initializer, the application is explicitly responsible for choosing the store location. Is that understanding correct? If so: Is there any supported automatic migration mechanism when using ModelConfiguration(url:), or is manual migration expected? If manual migration is expected, is moving the complete persistence package (.sqlite, -wal, -shm, .Store_SUPPORT, Store_ckAssets) before creating the ModelContainer the recommended approach? Or is there another Apple-recommended migration path for this scenario? My related posts/questions https://developer.apple.com/forums/thread/769835 https://developer.apple.com/forums/thread/769676

Hi everyone, I want to share what the last year has been like, partly to be heard, and partly because I think other solo developers should know this can happen. Two years ago, I was driving Uber in New Zealand. Somewhere during those long shifts, talking to passengers and thinking about the same idea every single day, I decided to build my own ride-hailing platform. I had no background in coding. None. I just started. I hosted my own server. I learned to build a backend. Then a frontend. Then a whole driver app and a whole rider app. My daily routine was this: I'd drive with my MacBook sitting on the dash of my Prius. When rides were quiet, I'd pull over to the side of the road and code. I drove close to 70,000 km around New Zealand while building these apps. I gave up a large part of my time with my family, and there are moments with my baby girl that I won't get back. My family supported me the whole way, and they were proud of me. After nine months, I had four apps built. The Android versions went live and have been running with no issues, no complaints, and no flags. Then I built the iOS versions too, got them through TestFlight and into production. The first time they were live, I felt something I'd never felt before—that I'd actually made something. I showed them to friends, family, and even my Uber passengers. That feeling of accomplishment was everything. I had two apps: A driver app for drivers. A rider app that riders use to hail taxis. We had live tracking and every feature that Uber had. The only thing I assume I did wrong (since I was inexperienced) was that I gave login credentials to the Apple review team so they could access my driver app. So far, so good. I wanted them to experience the full flow of the app, so I decided to dispatch demo (dummy) offers so they could see the complete journey. A new offer would appear whenever they tapped Go Online, repeating every two or three minutes. My intention was for them to see the incoming offer and go through the different stages of the app—receiving an offer, accepting it, driving to the destination, ending the trip, seeing the reward card, fare, and so on. They would never have seen all of this if I hadn't created a dummy offer. This mechanism was activated only for the Apple reviewer credentials. No one else would ever experience it. I think they assumed I was giving fake offers or misrepresenting the app. A human reviewer, understanding the intent, would hopefully have recognised what I was trying to demonstrate. At the very least, I wish they had flagged it and given me a chance to explain instead of terminating my account overnight. Based on this, I recreated the exact timeline from my backend logs. Here's exactly what happened: Time (NZ) 15:03:47 — Logged in — ✅ 200 15:03–15:04 — Browsed earnings, job history, past trip #1164, payouts, and Stripe status — ✅ All fine 15:04:23 — Tapped Go Online — ✅ 15:04:23 — Backend seeded a fake ride offer (#1038) — Offer appears 15:04:27 — Rejected the offer (after 4 seconds) — ✅ 15:06:00 — Last seen timestamp — Last successful moment 15:06:10 — A second Apple login (17.185.64.86) accessed the same account — First session disconnected 15:06:12–15:07:47 — Reviewer's live connection failed 7 times ("session_token mismatch" → 403) — ❌ Broken 15:06:13 — Tried to go offline — ❌ 401 15:06–15:12 — Received a new fake offer approximately every 2 minutes; attempted to reject them but received 400 errors — ❌ ~15:13 — Reviewer left — Nothing completed Then one day, I got a notice from Apple. My Developer Program membership was terminated under Section 3.2(f). All my apps were pulled from the App Store overnight. Here's the part I want other solo founders to understand, because it's the part that still keeps me up: There was no warning. No email first. No "this looks wrong, can you explain or fix it?" Just termination, and everything was gone in one moment. I filed an appeal through the official channel. It came back as a final denial, and they said there would be no further appeals on the account. From my own server logs, I could see that between the termination and the denial, no reviewer ever opened the app again. The decision was made from their records, not from a fresh look. So there was genuinely nothing I could have shown them—no fix, no explanation—that would have been seen. I'm not writing this to argue that Apple has no right to protect its platform. It does. But for a one-person team, a Section 3.2(f) termination means your entire business can disappear overnight, with no warning and no practical way back. I don't think many solo developers realise how final and how fast that is until it happens to them. So I wanted to ask the community a few honest questions: Has anyone here been through a Section 3.2(f) account termination? What happened next? Is there genuinely any path forward once an appeal is marked final—a separate entity, a legal channel, or anything else? And a broader question: do you think there should be a warning, or a short window to fix things, before a lifetime ban, especially for solo developers whose whole livelihood is on the line? This has been one of the hardest stretches of my life. I put everything into this. If even a few people read it and it saves them from the same fall, or if someone genuinely knows a path forward, that would mean a lot. Thank you for reading.

I've filed this as FB23714849 too, but I'm running into an issue with the Toggle component when displayed in a toolbar and a more complex label is used. This worked fine in iOS 26. Minimal repro example + screenshot: struct ContentView: View { @State var toggleState1 = false @State var toggleState2 = false var body: some View { NavigationStack { Text("Hello, world!") .toolbar { // THIS ITEM (leading) WORKS AS EXPECTED ToolbarItem(placement: .topBarLeading) { Toggle("Working", systemImage: "heart", isOn: $toggleState2) } // THIS ITEM (trailing) DOES NOT TOGGLE AS EXPECTED // It always appears enabled even when it should not ToolbarItem(placement: .topBarTrailing) { Toggle(isOn: $toggleState1) { Image(systemName: "star") } } } } } } My ultimate goal is to have a menu here where I can make the menu's label appear as a selected toggle (e.g. to display that one of a few filters is enabled). This is the case as of iOS Developer Beta 3 (and I believe the prior iOS 27 betas).

Hello, We are currently developing a macOS application and evaluating Managed Background Assets for delivering additional downloadable content. Our preference is to rely on Apple-hosted asset delivery as much as possible, rather than maintaining a separate CDN or server infrastructure. While reviewing the documentation and forum discussions, we found a few areas that are still unclear and would appreciate your guidance. 1. Scope of the 200GB Apple-hosted asset pack limit Some documentation and discussions seem to describe the 200GB limit as applying per Apple Developer Program team/account, while others suggest it is a per-app bundle limit. Could you clarify the exact scope of this limit? Is the 200GB quota applied per individual app bundle ID? Or is it shared across all apps under the same Apple Developer Program account? References: [LINK1] [LINK2] [LINK3] 2. Storage expansion and hybrid hosting Are there any plans to expand the Apple-hosted asset pack limits in the future, or is there an official process to request additional hosting capacity? If an app eventually exceeds the Apple-hosted limit, is it acceptable or technically possible to use a hybrid approach (i.e., using Apple hosting for some assets while self-hosting the rest)? 3. Recommended strategy for older macOS versions As we understand, Managed Background Assets are only available starting from newer OS releases. However, our application also supports older macOS versions, and we would ideally like to avoid maintaining a completely separate asset delivery backend for them. From Apple’s perspective, what is the recommended strategy in this situation? Is it expected that developers continue using Unmanaged Background Assets for older OS compatibility? Is it acceptable to support Managed Background Assets only on newer systems, while older OS versions simply do not receive the same downloadable-content functionality? Or is there another recommended migration/compatibility approach for apps supporting both newer and older macOS versions? Thank you in advance for your clarification!

Hello. I have a problem with the FoundationModels adapter and the Apple-hosted managed asset pack via TestFlight. I have created an adapter that works fine locally by creating a model via (fileURL: URL) on a real device, but I cannot create a model using background assets by downloading the adapter via TestFlight. Every time I try to get an adapter, the creation of the adapter is interrupted by the compatibleAdapterNotFound error. The aar. archive i created using a special command - xcrun ba-package foundation-models package --adapter-path aurelius1.fmadapter --asset-pack-id fmadapter-aurelius1-9799725 --output-path ./aurelius1.aar --platforms iOS --on-demand\ after that, I replaced "OnDemand": null with "OnDemand": {} in the manifest so that the Transporter could send my archive to the App Store Connect. I followed all the recommendations in this topic - https://origin-devforums.apple.com/forums/thread/823148 ...but unfortunately unsuccessfully I would appreciate any help in solving this problem. here is the code that I use in my app -

Hello, We are currently evaluating ways to reduce the app size of the my App. The app contains approximately 200~250 MB of bundled static resources, and we are considering converting these resources into On-Demand Resources（ODR） in order to reduce the initial download and installation size of the app. However, we noticed that ODR is currently marked by Apple as a Legacy Technology. Since we would like these resources to continue being hosted and distributed through Apple CDN / App Store infrastructure, the first alternative we considered is Managed Background Assets, rather than regular Background Assets. We understand that regular Background Assets are available on iOS 16 and later, but they mainly address background download scheduling for apps. What we are specifically looking for is the resource hosting and distribution capability, similar to ODR, where assets can be hosted and delivered through Apple’s infrastructure. This is why we are considering Managed Background Assets. However, my App currently supports devices starting from iOS 14, while the key capabilities of Managed Background Assets require newer iOS versions. As a result, this solution cannot fully cover users who are still on older iOS versions, such as iOS 14 through iOS 18. Given this background, we would like to ask Apple the following questions: Does Apple have any plan to discontinue ODR-related services in the future, especially the App Store-hosted ODR asset download service? If the ODR service is changed or discontinued in the future, would it affect already released App Store apps that rely on ODR asset downloads on older iOS versions? For apps that still need to support iOS 14 and later, while also relying on Apple CDN / App Store infrastructure for resource hosting and distribution, does Apple still recommend using ODR? For apps that cannot immediately raise their minimum supported iOS version to the version required by Managed Background Assets, is there a recommended transition strategy? If ODR services are discontinued in the future, will Apple provide an alternative resource distribution solution that supports older iOS versions, or would developers need to build and maintain their own resource hosting and download system? We would like to better understand the long-term availability and potential risks of using ODR on older iOS versions, so that we can make an appropriate decision for future app size reduction and asset delivery in the App. Thank you.

I'm migrating my Push-to-Talk app from the old VoIP-push approach (PushKit PKPushTypeVoIP) to the PushToTalk framework (iOS 16+), sending apns-push-type: pushtotalk notifications with the .voip-ptt topic. My app currently has these entitlements from the old implementation: com.apple.developer.pushkit.unrestricted-voip com.apple.developer.pushkit.unrestricted-voip.ptt And I've now added: com.apple.developer.push-to-talk My questions: When migrating to the PushToTalk framework, is it mandatory to update the App ID and remove the unrestricted-voip and unrestricted-voip.ptt entitlements? Or can the new push-to-talk entitlement coexist with them? Can I submit an app update that uses only PushToTalk notifications (no VoIP pushes), while the App ID / provisioning profile still has the voip and voip-ptt entitlements enabled? Will this pass App Review, or does the presence of the old entitlements cause issues? I currently see the runtime warning "Your app must be updated to use the Push to Talk framework" — is this triggered specifically by the presence of the unrestricted-voip.ptt entitlement, and will removing it resolve the warning? Thanks in advance.

I have finished a new app that integrates Apple hosted background asset. I have tested and confirm that the assets are downloaded both locally and with a TestFlight build. App review is not able to access the background assets. I can see that the assets are updated with status "accepted". But app review is running into error "A server with the specified hostname could not be found.". These are Apple Hosted Assets. Did I miss any configuration?

I have created and tested background assets (Apple Hosted) with both "essential" and "onDemand". They works on the iPhone and iPad following the "Testing asset packs locally" steps. However, when I upload to TF; the iPad fails to download. The iPhone is able to download both "essential" and "onDemand" fine. I am adopting the manifest from xcrun ba-package template -o Manifest.json Manifest.json

Our app was rejected on June 23 under Guideline 4.3(b), the third review of our v1.0 submission from June 8. We submitted an appeal to the App Review Board the next day. When we asked for a status update on July 6, we received a general reply saying the Board contacts developers directly once they complete their investigation. It's now been 20 days since the appeal, and we still haven't received any update. We totally understand that the process can take some time, but this is our first app, we spent a long time building it, and everything on our side is ready and waiting on this decision. We're really hoping to get it online soon. Does anyone know how long it usually takes to hear back from the App Review Board? And is it okay to follow up with them at this point, or is there anything we can provide that would help the investigation along? We've also booked a one-on-one App Review consultation through Meet with Apple for next week. Thank you for any insights.

Hello, We are facing a critical issue with Apple Developer Program enrollment and would appreciate any guidance from developers who may have experienced something similar. Our organization is newly established. We obtained a new D-U-N-S Number specifically for enrolling in the Apple Developer Program. However, every time we attempt to enroll as an organization, Apple immediately withdraws the enrollment with the following message: "We've withdrawn this enrollment because [our organization] is already a member of the Apple Developer Program. Companies may hold only one membership in the Apple Developer Program. To be added to your development team, please contact the Account Holder for your company's existing membership. If you don't know who the Account Holder is contact us." The problem is that we have thoroughly verified internally: No Apple ID within our organization is enrolled in the Apple Developer Program. Our D-U-N-S Number has never been used by our organization for Apple Developer Program enrollment. We have thoroughly verified this across our organization, and there is no existing Apple Developer Program membership associated with our company. We contacted Apple Developer Support and explained the situation in detail, including confirming that we have no existing membership. The response we received was: "If you don't know who the Account Holder is, please provide your contact information. I'll forward it to the Account Holder at your request. Note that we can't guarantee a response from the current Account Holder." The issue is that we do not know who this supposed Account Holder is because, to the best of our knowledge, no such account exists within our organization. Since then: We have submitted multiple support requests. We have replied to the support emails with additional information. We have tried contacting Developer Support by phone. We have not received any further response for the past 6 days. This issue is blocking our business because we cannot publish our iOS application until the enrollment problem is resolved. Has anyone experienced a similar situation where Apple incorrectly reported that an organization already had an Apple Developer Program membership? If so: How was the issue resolved? Was there a specific team within Apple that handled it? Is there any escalation path beyond the standard Developer Support process? Any advice or shared experience would be greatly appreciated. Thank you.

On iOS 26 (reproduced on both Simulator and iPhone), the system share sheet (UIActivityViewController) displays the row of activity/app icons at a greatly oversized scale. The app's approximate hierarchy is like UIWindow.rootViewController → a plain container UIViewController → UITabBarController → an embedded container child → UINavigationController → the visible screen. When the share sheet is presented from a view controller inside such an hierarchy, the icons are oversized. When the same UIActivityViewController, with the exact same activity items, is presented from a full-screen modal view controller (modalPresentationStyle = .fullScreen / .overFullScreen), the icons render correctly. Is this a bug of iOS 26+? On iOS 27 the behaviour is the same.

I don't really know the terminology around this very well, but I was trying to test my Mac OS Catalyst app on Mac OS Sequoia, and the app kept crashing apparently due to MTL validation. I was trying to debug why using a menu (as in File, Edit, View, etc.) would crash. The stack looked roughly like this: 6 -[MTLDebugComputeCommandEncoder setBuffer:offset:attributeStride:atIndex:] MetalTools 5 _CF_forwarding_prep_0 CoreFoundation 4 ___forwarding___ CoreFoundation 3 -[NSObject doesNotRecognizeSelector:] CoreFoundation 2 objc_exception_throw libobjc.A.dylib 1 __cxa_throw b 0 _Unwind_RaiseException libunwind.dylib Both Claude and Gemini indicated that there was no flaw in my code, but rather that Xcode was responsible. Sure enough, unchecking the MTL validation checkbox in Xcode stopped the crash from happening.

recently I found crash issue on my iOS 16 device. If I kill the app process and re-launch it quickly, the app will crash occasionally without any hints nor messages this is only happed when the app's main page is attached a visual effective view on top of it. while I remove the visual effective view, the crash never happened again. could anybody tells me what is going wrong with the effective view, and how to fix it. thank you.

Hello I'm trying to create a custom component but I can't see to make It work on the RCP3. The video 'Extend Reality Composer Pro 3 functionality with Xcode' makes it seem too simple but I can't seem to work following the steps.

It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.

Area SwiftUI → Presentation / ConfirmationDialog Summary After building with Xcode 27 beta, confirmationDialog presented from a row inside a List that is embedded in a .sheet is no longer anchored to the row that triggered it. Instead, the dialog is displayed near the top of the sheet when the sheet is partially expanded, or in the center of the screen when the sheet occupies the full height. This behavior is reproducible across all tested Xcode 27 beta releases and iOS 27 beta releases (Beta 1, Beta 2, and Beta 3). Steps to Reproduce Present a SwiftUI .sheet. Place a List inside the sheet. Add a confirmationDialog to each list row. Trigger the dialog from a swipe action on any row. Observe the position where the confirmation dialog appears. A minimal reproducible sample project is attached. Expected Result The confirmationDialog should be visually associated with the row that triggered it, as it behaved in previous Xcode and iOS releases. The dialog should appear anchored to the selected list row (or as close as the platform allows), providing clear contextual feedback to the user about which item is being acted upon. Actual Result The dialog is no longer associated with the selected row. When the sheet is not fully expanded, the dialog appears near the top area of the sheet, seemingly positioned relative to the sheet itself rather than the triggering row. When the sheet is expanded to full height, the dialog appears in the center of the screen. As a result, the relationship between the selected item and the confirmation dialog is lost, creating a confusing user experience. Regression Yes. The same implementation behaved correctly in previous Xcode and iOS versions. The issue first appeared after upgrading to Xcode 27 beta and remains present in all tested iOS 27 beta releases (Beta 1–3). Impact This is a significant UX regression for existing applications that rely on contextual confirmation dialogs within lists presented inside sheets. Applications that already have production users cannot easily redesign their interaction model to compensate for this behavior change. The previous behavior provided clear context about which list item was being acted upon, while the current behavior makes that association unclear. Configuration Xcode 27 Beta (all tested beta versions) iOS 27 Beta 1 iOS 27 Beta 2 iOS 27 Beta 3 Reproduced on physical devices Reproduced using the attached minimal sample project Attachments Minimal reproducible sample project. Screenshot showing expected behavior (prior implementation). Screenshot showing current behavior on iOS 27 Beta 3. Screen recording demonstrating the regression. struct ContentView: View { @State private var sheetIsPresented = false @State private var itemPendingDeletion: Int? = nil var array = Array(0...100) var body: some View { VStack { Text("Hello, world!") Button("Show List") { sheetIsPresented = true } } .sheet(isPresented: $sheetIsPresented) { List { ForEach(array, id: \.self) { value in ListRow(for: value) .confirmationDialog("Delete?", isPresented: Binding( get: { itemPendingDeletion == value }, set: { isPresented in if !isPresented { itemPendingDeletion = nil } } ) ) { Button { } label: { Text("Delete") } } .swipeActions(edge: .trailing) { Button { itemPendingDeletion = value } label: { Image(systemName: "trash") .foregroundStyle(.red) } } } .listRowInsets(EdgeInsets()) .listRowBackground(Color.clear) } .listStyle(.inset) .contentMargins(16, for: .scrollContent) .presentationDetents([.fraction(1), .fraction(0.9)]) } } @ViewBuilder private func ListRow(for value: Int) -> some View { Text("\(value)") .foregroundStyle(.primary) .padding(.vertical) .frame(maxWidth: .infinity) .background( RoundedRectangle(cornerRadius: 26, style: .continuous) ) .padding(.vertical, 2) } } #Preview { ContentView() } Xcode 27(Beta 1,2,3) Xcode 26.5

Summary: EASession initialization consistently returns nil on iOS 27 when connecting to a MFi-certified USB accessory. The same code and accessory work correctly on iOS 26. Apple's official EADemo sample code also fails on iOS 27. Steps to Reproduce: Connect MFi-certified USB accessory to iOS 27 device via Lightning/USB-C Observe that EAAccessory is detected: connected=YES, connectionID=34951162 Confirm protocol string is in accessory.protocolStrings Call [[EASession alloc] initWithAccessory:accessory forProtocol:@"*******"] EASession returns nil Expected Results: EASession should be created successfully, allowing input/output stream configuration. This works correctly on iOS 26 with identical code and accessory. Actual Results: EASession returns nil. System log shows: "[#ExternalAccessory] ERROR - .../EASession.m:-[EASession dealloc] - 212 unable to close session for _accessory=0x1513d3bb0 and sessionID=65536" Note: sessionID=65536 indicates EASession was partially created but immediately deallocated. Configuration: Device: 所有机型 iOS Version: 27.0 beta Xcode Version: 26.3 (17C529) Build SDK: iOS 26 SDK Accessory PPID: cfc Accessory Firmware: L.B.1 Accessory Hardware: 1.0.1 App: Both our production app and Apple's official EADemo sample code Info.plist Configuration: UISupportedExternalAccessoryProtocols includes "*****" UIBackgroundModes includes "external-accessory" Device Settings: Settings > Privacy & Security > Security > Wired Accessories: "Automatically Allow When Unlocked" Additional Notes: EAAccessory object is properly created and accessible Accessory protocol string matches exactly All MFi certificates present (certSerial: 16 bytes, certData: 608 bytes) Issue reproduced with Apple's official EADemo sample code, confirming this is not an application-level bug Issue does NOT occur on iOS 26 with same device and accessory Regression: iOS 26: Works correctly iOS 27: Fails consistently