We are experiencing a crash in our application that only occurs on devices running iOS beta 26. It looks like a Beta problem. The crash appears to be caused by an excessive number of open File Descriptors. We identified this after noticing a series of crashes in different parts of the code each time the app was launched. Sometimes it would crash right at the beginning, when trying to load the Firebase plist file. That’s when we noticed a log message saying “too many open files,” and upon further investigation, we found that an excessive number of File Descriptors were open in our app, right after the didFinishLaunching method of the AppDelegate. We used the native Darwin library to log information about the FDs and collected the following: func logFDs() { var rlim = rlimit() if getrlimit(RLIMIT_NOFILE, &rlim) == 0 { print("FD LIMIT: soft: \(rlim.rlim_cur), hard: \(rlim.rlim_max)") } // Count open FDs before Firebase let openFDsBefore = countOpenFileDescriptors() print("Open file descriptors BEFORE Firebase.configure(): \(openFDsBefore)") } private func countOpenFileDescriptors() -> Int { var count = 0 let maxFD = getdtablesize() for fd in 0..<maxFD { if fcntl(fd, F_GETFD) != -1 { count += 1 } } return count } With this code, we obtained the following data: On a device with iOS 26 Beta 1, 2, or 3: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 256 On a device with iOS 18: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 57 In the case of the device running iOS 26 beta, the app crashes when executing Firebase.configure() because it cannot open the plist file, even though it can be found at the correct path — meaning the OS locates it. To confirm this was indeed the issue, we used the following code to close FDs before proceeding with Firebase configuration. By placing a breakpoint just before Firebase.configure() and running the following LLDB command: expr -l c -- for (int fd = 180; fd < 256; fd++) { (int)close(fd); } This released the FDs, allowing Firebase to proceed with its configuration as expected. However, the app would later crash again after hitting the soft limit of file descriptors once more. Digging deeper, we used this code to try to identify which FDs were being opened and causing the soft limit to be exceeded: func checkFDPath() { var r = rlimit() if getrlimit(RLIMIT_NOFILE, &r) == 0 { print("FD LIMIT: soft: \(r.rlim_cur), hard: \(r.rlim_max)") for fd in 0..<Int32(r.rlim_cur) { var path = [CChar](repeating: 0, count: Int(PATH_MAX)) if fcntl(fd, F_GETPATH, &path) != -1 { print(String(cString: path)) } } } } We ran this command at the very beginning of the didFinishLaunching method in the AppDelegate. On iOS 26, the log repeatedly showed Cryptexes creating a massive number of FDs, such as: /dev/null /dev/ttys000 /dev/ttys000 /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Application Support/DTX_8.191.1.1003.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Caches/KSCrash/MyAppScheme/Data/ConsoleLog.txt /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-wal /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-shm /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.01 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.11 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.12 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.13 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.14 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.15 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.16 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.17 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.18 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.19 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.20 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.21 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.22 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.23 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.24 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.25 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.26 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.29 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.30 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.31 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.32 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e … This repeats itself a lot of times. … /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40

I'm trying to update one of my apps to the new Liquid Glass effects using Xcode 26. Came across a weird issue in that I reproduced in an empty project on its own with a storyboard with a single segmented control on the initial viewController I have a UISegmentedControl with 3 options. If I click index 2, while index 0 is selected, everything works as normal However if I select index 1, and then index 2, it jumps back to index 0 instead of selecting 2. All the events fire as though I tapped index 0

I am a developer working on iOS apps. I would like to report an issue occurring in iOS 26 beta 2. Our company has Enterprise account, and we are developing apps. When we distribute these apps, and install them on a device running iOS 26 beta2, apps install successfully, but apps crashed immediately after being launched. MDM Install Application When I install the app via Xcode and trust it, apps will run. Launchd job spawn failed This issue does not occur on versions prior to iOS 26. I would like to know if this is a problem that will be resolved in future updates, or if it is a policy change.

The objective C code using the kernel API ‘sysctlbyname’ for ‘kern.osproductversion’ returns 16.0 instead of 26.0 on macOS Tahoe. sysctlbyname("kern.osproductversion", version, &size, NULL, 0) The command ‘sysctl kern.osproductversion’ returns ‘kern.osproductversion: 26.0’ on same macOS Tahoe. Note: The objective C code was built using Xcode 16.3.

Hello, I am testing an existing app on iOS 26. It hast an UITableViewController that shows a custom context menu preview using previewForHighlightingContextMenuWithConfiguration and providing an UITargetedPreview. Something along the lines like this (shortened): public override func tableView(_ tableView: UITableView, previewForHighlightingContextMenuWithConfiguration configuration: UIContextMenuConfiguration) -> UITargetedPreview? { guard let indexPath = configuration.identifier as? NSIndexPath else { return nil } let previewTableViewCell = self.getCell(for: indexPath) var cellHeight = self.getCellHeight(for: indexPath, with: maxTextWidth) // Use the contentView of the UITableViewCell as a preview view let previewMessageView = previewTableViewCell.contentView previewMessageView.frame = CGRect(x: 0, y: 0, width: maxPreviewWidth, height: cellHeight) previewMessageView.layer.masksToBounds = true let accessoryView = ... let totalAccessoryFrameHeight = accessoryView.frame.maxY - cellHeight var containerView = UIView(frame: .init(x: 0, y: 0, width: Int(maxPreviewWidth), height: Int(cellHeight + totalAccessoryFrameHeight))) containerView.backgroundColor = .clear containerView.addSubview(previewMessageView) containerView.addSubview(accessoryView) // Create a preview target which allows us to have a transparent background let previewTarget = UIPreviewTarget(container: tableView, center: ...) let previewParameter = UIPreviewParameters() // Remove the background and the drop shadow from our custom preview view previewParameter.backgroundColor = .clear previewParameter.shadowPath = UIBezierPath() return UITargetedPreview(view: containerView, parameters: previewParameter, target: previewTarget) } On iOS 18 and below this works fine and buttons that are included in the accessoryView are tapable by the user. Now on iOS 26 the preview is shown correct (although it has a bit weird shadow animation), but tapping a button of the accessoryView now closes the context menu, without triggering the touchUpInside event anymore. For me it feels like an unintended change in behavior, but maybe I am missing something? Filed FB18644353

I was excited about the new APIs added to Network.framework in iOS 26 that offer structure concurrency support out of the box and a more modern API design in general. However I have been unable to use them to create a device-to-device QUIC connection. The blocker I ran into is that NetworkListener's run method requires the network protocol to conform to OneToOneProtocol, whereas QUIC conforms to MultiplexProtocol. And there doesn't seem to be any way to accept an incoming MultiplexProtocol connection? Nor does it seem possible to turn a UDP connection into a QUIC connection using NetworkConnection.prependProtocols() as that also only works for network protocols conforming to OneToOneProtocol. I suspect this is an accidental omission in the API design (?), and already filed a Feedback (FB18620438). But maybe I am missing something and there is a workaround or a different way to listen for incoming QUIC connections using the new NetworkListener? QUIC.TLS has methods peerAuthenticationRequired(Bool) and peerAuthenticationOptional(Bool), which makes me think that peer to peer QUIC connections are intended to be supported? I would also love to see documentation for those methods. For example I wonder what exact effect peerAuthenticationRequired(false) and peerAuthenticationOptional(false) would have and how they differ.

I want a different color, one from my asset catalog, as the background of my first ever swift UI view (and, well, swift, the rest of the app is still obj.c) I've tried putting the color everywhere, but it does't take. I tried with just .red, too to make sure it wasn't me. Does anyone know where I can put a color call that will actually run? Black looks very out of place in my happy app. I spent a lot of time making a custom dark palette. TIA KT @State private var viewModel = ViewModel() @State private var showAddSheet = false var body: some View { ZStack { Color.myCuteBg .ignoresSafeArea(.all) NavigationStack { content .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .principal) { Image("cute.image") .font(.system(size: 30)) .foregroundColor(.beigeTitle) } } } .background(Color.myCuteBg) .presentationBackground(.myCuteBg) .sheet(isPresented: $showAddSheet) { AddView() } .environment(viewModel) .onAppear { viewModel.fetchStuff() } } .tint(.cuteColor) } @ViewBuilder var content: some View { if viewModel.list.isEmpty && viewModel.anotherlist.isEmpty { ContentUnavailableView( "No Content", image: "stop", description: Text("Add something here by tapping the + button.") ) } else { contentList } } var contentList: some View { blah blah blah } } First I tried the background, then the presentation background, and finally the Zstack. I hope this is fixed because it's actually fun to build scrollable content and text with swiftUI and I'd been avoiding it for years.

Macbook pro M4 - will not accept any power adapter after beta update iPhone 16 pro - same exact problem Devices are dead Tried multiple chargers - Watch and IPad appear to be taking a charge for now..

Has anyone had success using the HKWorkoutRouteBuilder in conjunction with the new iOS support for HKLiveWorkoutBuilder? I was running my watchOS code that worked now brought over to iOS and when I call insertRouteData the function never returns. This happens for both the legacy and closure based block patterns. private var workoutSession: HKWorkoutSession? private var workoutBuilder: HKLiveWorkoutBuilder? private var serviceSession: CLServiceSession? private var workoutRouteBuilder: HKWorkoutRouteBuilder? private func startRouteBuilder() { Task { @MainActor in self.serviceSession = CLServiceSession(authorization: .whenInUse) self.workoutRouteBuilder = self.workoutBuilder?.seriesBuilder(for: .workoutRoute()) as? HKWorkoutRouteBuilder self.locationUpdateTask = Task { do { for try await update in CLLocationUpdate.liveUpdates(.fitness) { if let location = update.location { self.logger.notice(#function, metadata: [ "location": .stringConvertible(location) ]) try await self.workoutRouteBuilder?.insertRouteData([location]) self.logger.notice("Added location") } } } catch { self.logger.error(#function, metadata: [ "error": .stringConvertible(error.localizedDescription) ]) } } } } I did also try CLLocationManager API with delegate which is what my current watch code uses (a bit old). Same issue. Here is what I've found so far: If the workout session is not running, and if the builder hasn't started collection yet, inserting route data works just fine I've tried different swift language modes, flipped from main actor to non isolated project settings (Xcode 26) Modified Apple's sample code and added location route building to that and reproduced the error, modified sample attached to feedback This issue was identified against Xcode 26 beta 2 and iPhone 16 Pro simulator. Works as expected on my iPhone 13 Pro beta 2. FB18603581 - HealthKit: HKWorkoutRouteBuilder insert call within CLLocationUpdate task never returns

I have a couple of (older) UIKit-based Apps using UISplitViewController on the iPad to have a two-column layout. I'm trying to edit the App so it will shows the left column as sidebar with liquid glass effect, similar to the one in the "Settings" App of iPadOS 26. But this seems to be almost impossible to do right now. "out of the box" the UISplitViewController already shows the left column somehow like a sidebar, with some margins to the sides, but missing the glass effect and with very little contrast to the background. If the left column contains a UITableViewController, I can try to get the glass effect this way within the UITableViewController: tableView.backgroundColor = .clear tableView.backgroundView = UIVisualEffectView(effect: UIGlassContainerEffect()) It is necessary to set the backgroundColor of the table view to the clear color because otherwise the default background color would completely cover the glass effect and so it's no longer visible. It is also necessary to set the background of all UITableViewCells to clear. If the window is in the foreground, this will now look very similar to the sidebar of the Settings App. However if the window is in the back, the sidebar is now much darker than the one of the Settings App. Not that nice looking, but for now acceptable. However whenever I navigate to another view controller in the side bar, all the clear backgrounds destroy the great look, because the transition to the new child controller overlaps with the old parent controller and you see both at the same time (because of the clear backgrounds). What is the best way to solve these issues and get a sidebar looking like the one of the Settings App under all conditions?

Immediately after installing iOS 26 on my iPhone 14 Pro, my phone display stopped working. It's not responding to touch, but I can see it charging. It also wakes the screen whenever I pick it up, but it's not touching at all. What do I do, or do I have to downgrade?

When using a ScrollView inside some sort of navigation (stack or split view), large navigation titles seem to get clipped to the width of the scroll content for some reason? Minimal example: struct ContentView: View { var body: some View { NavigationStack { ScrollView { Text("Scroll Content") } .navigationTitle("Navigation Title") } } } Results in: Is this a bug in the beta, or has something changed and now I’m doing things wrong?

In macOS 26 beta 2 it is possible to set an edge effect style via UIKit using the .scrollEdgeEffectStyle property. (note: I haven't tested this, I'm just looking at the documentation). See: https://developer.apple.com/documentation/swiftui/view/scrolledgeeffectstyle(_:for:) Is there an equivalent API for AppKit-based apps? I can't seem to find any additions in NSView or NSScrollView or elsewhere that seem relevant. Scroll edge effects are mentioned in the "Build an AppKit app with the new design" talk here, which heavily implies it must be possible from AppKit: https://developer.apple.com/videos/play/wwdc2025/310/?time=567

Does anyone know where I can get to the API diffs for iOS 18 -> iOS 26?

Since first beta of iOS 26 I've created a workflow where I can deploy to TestFlight the builds compiled using the iOS 26 SDK, and it has worked fine until yesterday when I started receiving this error: Unsupported SDK or Xcode version. Your app was built with an SDK or version of Xcode that isn’t supported. Although you can use beta versions of SDKs and Xcode to build and upload apps to App Store Connect, you need to use the latest Release Candidates (RC) for SDKs and Xcode to submit the app. For details on currently supported SDKs and versions of Xcode, visit: https://developer.apple.com/news/releases. I haven't changed anything in the workflow so I suspect it's a bug on Apple side? Or am I missing something? It is set to use "Latest Beta or Release" for both Xcode and macOS, archive and deploy to TestFlight Internal Testing. Thank you!

Since updating my MacBook Air to macOS Tahoe 26.0 Developer Beta 2, I’ve encountered a persistent cursor misalignment issue: When interacting with lists or contextual menus, the cursor’s visual position does not align with what it actually selects. The system registers the cursor slightly above where it appears, causing clicks to select the wrong option or fail to register. As a temporary workaround, I can sometimes position the cursor off-target and press Enter to select, but this is a frustrating and inefficient workaround. The issue persists after a restart and appears across multiple areas of the OS: Right-clicking an app in the Dock to open the contextual menu → cursor highlights an incorrect item relative to its position. In System Settings menus. Even on the Feedback Assistant site when selecting issue categories. Steps to Reproduce: 1️⃣ Update to macOS Tahoe 26.0 Developer Beta 2 on MacBook Air. 2️⃣ Right-click on any open application in the Dock. 3️⃣ Attempt to select an option from the list that appears. 4️⃣ Observe that the cursor highlights or interacts with a different option than where the cursor is visibly located. Notes: Issue is consistent across reboots. Affects workflow and general navigation. Temporary workaround using keyboard navigation is insufficient for productivity. FB Number: FB18531124 If others are seeing this as well, please confirm below so Apple can prioritize investigation.

I am writing to report multiple issues encountered after updating to Xcode 26 Beta, which have significantly impacted my project's compilation and functionality. My project can run normally in Xcode16.3 version, Below are the specific problems, along with the steps I took to address them and the subsequent errors that arose: Symbol Not Found Error for _NSUserActivityTypeBrowsingWeb After updating to Xcode 26 Beta, my project failed to build with the error: "Symbol not found: _NSUserActivityTypeBrowsingWeb." To resolve this, I removed the MobileCoreServices framework from the Build Settings, as it appeared to be related. However, this led to a new error, indicating that this change introduced further complications. Clang++ Error: No Such File or Directory 'OpenGLES' Following the resolution of the first issue, I encountered a new error: "iOS clang++: error: no such file or directory: 'OpenGLES'." To address this, I added the OpenGLES.framework to the Build Phases. While this resolved the clang++ error, it triggered additional errors, suggesting that the underlying issue persists or new dependencies are conflicting. Recurring XIB File Compilation Errors My project uses XIB files, and every time I attempt to compile and run, Xcode reports errors related to different XIB files. Notably, when I open the reported XIB file, no errors are displayed within the Interface Builder. After saving or inspecting the file, the compilation error temporarily disappears, only for another XIB file to trigger the same issue in the next build. This creates a repetitive cycle. I have confirmed this is not a caching issue, as I clean the build cache (Product &gt; Clean Build Folder) before each run. If I skip cleaning the cache, the OpenGLES-related error (Issue 2) reappears, indicating potential interactions between these problems. These issues have made development with Xcode 26 Beta extremely challenging, as each attempted fix seems to introduce new errors, and the XIB issue creates a persistent loop. My setup includes: Xcode Version: 26.0 beta 2 (17A5241o) macOS Version:15.4.1 (24E263)

App Name: Endless Zombies Platform: iOS Genre: Roguelike / Survival / Action TestFlight Link: https://testflight.apple.com/join/DEIN-CODE Status: Open Beta – limited seats available 🎮 What is Endless Zombies? Endless Zombies is a fast-paced, top-down roguelike shooter where you must survive increasingly intense zombie waves — with fully separated movement and aiming controls for maximum precision and tactical depth. Players can upgrade their weapons, unleash special attacks, and face progressively stronger threats including Baby Waves (fast mini-zombies) and Boss Battles against giant elite enemies with unique behavior. This is not just about survival — climb the global leaderboard and fight your way to the top! 🏆 Compete for high scores, dominate the kill count, and earn bragging rights (and potential rewards in future tournaments). Endless Zombies is currently in its first public beta and we’re looking for players who want to help us improve mechanics, test new systems, and shape the final experience. 🧪 Looking for beta testers to: Test gameplay fluidity and aiming responsiveness Evaluate performance on different iOS devices Provide feedback on UI, game balance, and spawn pacing Report bugs and edge-case issues 🚀 Features: 🎯 Dual control movement + aiming 🧠 Smarter, optimized enemy spawn logic ⚔️ Upgradeable weapons and energy system 👥 Online friends chat and leaderboard system (PlayFab-based) 📊 Stats, progress tracking, and UI improvements Join via TestFlight: 👉 https://testflight.apple.com/join/DEIN-CODE We’d love to hear what you think!

Summary When using .tabViewBottomAccessory in SwiftUI and conditionally rendering it based on the selected tab, the app crashes with a NSInternalInconsistencyException related to _bottomAccessory.displayStyle. Steps to Reproduce Create a SwiftUI TabView using a @SceneStorage selectedTab binding. Render a .tabViewBottomAccessory with conditional visibility tied to selectedTab == .storage. Switch between tabs. Return to the tab that conditionally shows the accessory (e.g., “Storage”). Expected Behavior SwiftUI should correctly add, remove, or show/hide the bottom accessory view without crashing. Actual Behavior The app crashes with the following error: Environment iOS version: iOS 26 seed 2 (23A5276f) Xcode: 26 Swift: 6.2 Device: iPhone 12 Pro I have opened a bug report with the FB number: FB18479195 Code Sample import SwiftUI struct ContentView: View { enum TabContent: String { case storage case recipe case profile case addItem } @SceneStorage("selectedTab") private var selectedTab: TabContent = .storage var body: some View { TabView(selection: $selectedTab) { Tab( "Storage", systemImage: "refrigerator", value: TabContent.storage ) { StorageView() } Tab( "Cook", systemImage: "frying.pan", value: TabContent.recipe ) { RecipeView() } Tab( "Profile", systemImage: "person", value: TabContent.profile ) { ProfileView() } } .tabBarMinimizeBehavior(.onScrollDown) .tabViewBottomAccessory { if selectedTab == .storage { Button(action: { }) { Label("Add Item", systemImage: "plus") } } } } }

Verbatim of a feedback report (FB18431713) I submitted, duplicated here since we can't see each other's feedbacks, and I wanted a centralized place to track the resolution of this as I'm surely not the only one facing this. When building the app using Xcode 26 beta 2 and running it in an iOS 26 simulator, I'm experiencing a retain cycle in the UINavigationController. From the data I saw in Xcode's memory graph debugger, it seems that _UIViewControllerOneToOneTransitionContext is retaining it. I base this on the fact that the line connecting a view controller and _UIViewControllerOneToOneTransitionContext has a "strong" reference, as indicated in Xcode. (However, I'm reporting this as a retain cycle in UINavigationController, as that's what seems to hold onto this transition-context.)