When attempting to open sysdiagnose logs collected from an iPhone running iOS 26 beta 3 on macOS Console, the application consistently crashes. Crash report has been added for reference. Apple Feedback- FB18834450

Pretty much the title. I am a noob in apple app development and currently starting it out. I got stuck in this. Can anyone let me know that how can i generate the token for starting live activity in terminated state? I have tried multiple times to find that this one is not working in terminated state. How can I overcome this? Is there any solution or workaround?

On WWDC25 session "Meet Liquid Glass", two Liquid Glass variants are mentioned: "regular" and "clear". "Regular" seems to be the default setting for UIGlassEffect, but I was not able to find an option for clear. Is there a native element that uses clear? Is it coming to later betas for iOS 26?

I'm encountering an issue with our legacy Objective-C codebase that uses UIApplicationDelegate. Here are the steps to reproduce the issue: Uninstall the application from the device. Install and launch the application. As part of the launch event, the client requests notification permission. The permission prompt is still displayed, even though the client receives a remote notification token (which appears to be a cached one). I followed the same steps with a sample app built with Swift (SwiftUI), and this issue did not occur. In the Swift app, I consistently received a delegate<didRegisterForRemoteNotificationsWithDeviceToken> call after the user allowed the notification permission. Could you please provide some insights into why this might be happening with only our client?

Good day everyone. I have a react native app which works on dev mode on my device - Iphone 13 pro version: 18.5, but when deployed to TestFlight and installed on same device it crashes when ever I click on any TextInput. I downloaded the crash file but finding it difficult to pinpoint the problem. I want to know what the problem is, if it's related to an installed package or code base or any other. Any help will be appreciated!!! Thanks. crashlog.crash

Visual Studio 2022 is attempting to use port 11000 instead of 62078, but the port on iOS 18.5 is not listening for VS's Hot Reloading. Is this allowable? If so, how?

I have attached two images of two screens below. In one screen, bar button are enclosed within separate, distinct, rounded-rectangle 'liquid glass' capsules. In other screen, bar buttons are enclosed within separate, distinct, rounded-rectangle "liquid glass" capsules. They are not visually merged into one larger capsule. Both are having same code. But why it is not same ?

We are using a TabView as the TabBarController in our app for main navigation. On one of the tabs we have a view that consists of a TabView with .tabViewStyle(.page) in order to scroll horizontally between pages inside of that specific tab. The .tabBarMinimizeBehavior(.onScrollDown) works on all the other TabItem views, but for this one it does not recognise any vertical scrolling in any of the pages, in order to minimize the TabBar. I believe this is a bug? If we don't wrap the views inside the TabView with .page style, we are able to get the expected behaviour using the tabBarMinimizeBehavior. Please let us know if this is going to be fixed in a future iOS 26 beta release.

We have a client with an application that includes a main application, NSEs (Notification Service Extensions) as an extension, and framework1 embedded within the main application. The NSEs also require framework1 as a dependency. When we embedded framework1 within the NSEs, the App Store Connect validation failed with the following error: Validation failed (409) CFBundleIdentifier Collision. There is more than one bundle with the CFBundleIdentifier value 'com.test.xyz-LoggerUtility' under the iOS application 'test.app'. (ID: -----------) We've observed an issue specifically when uploading to App Store Connect. We're able to debug and distribute the application without any problems using our enterprise distribution.

Hello We use Datadog Mobile Vitals in our app and I'm trying to run some tools in Instruments for comparison. I'm not sure what tool should I use for some of those metrics: Slow Renders Description: With slow renders data, you can monitor which views are taking longer than 16ms or 60Hz to render. Instruments equivalent: Hangs including microhangs (?) CPU ticks per second Description: RUM tracks CPU ticks per second for each view and the CPU utilization over the course of a session. The recommended range is <40 for good and <80 for moderate. Instruments equivalent: CPU Profiler (?) Frozen Frames - Description: Frames that take longer than 700ms to render appear as stuck and unresponsive in your application. These are classified as frozen frames. Instruments equivalent: Hangs with > 500ms (?) Memory Utilization Description: The amount of physical memory used by your application in bytes for each view, over the course of a session. The recommended range is <200MB for good and <400MB for moderate. Instruments equivalent: Allocation (?)

🧠 Feature Proposal: Share &amp; Delete Option for iOS Share Sheet 🔍 Problem: Many users frequently share temporary content like group photos, screenshots, or memes. After sharing, these files often stay in the Photos or Files app, leading to storage clutter. 💡 Solution: Introduce a "Share &amp; Delete" option inside the default iOS Share Sheet. 📲 How it works: User selects photo(s)/file(s) Opens the Share Sheet Sees two options: 📤 Share (Standard) 🗑️ Share &amp; Delete (New Option) After sharing, iOS prompts: "Do you want to delete these items from your device?" ✅ Benefits: Reduces storage usage Simplifies file cleanup Speeds up user workflow 🔐 Safety Considerations: Confirm deletion after successful share Show “Undo” or move to Recently Deleted 📂 Attribution: Originally proposed by Vicky on July 20, 2025. More Details &amp; UI Mockup: 👉 GitHub: https://github.com/vicky2940/share-and-delete-feature 👉 Android Tracker Submission: https://issuetracker.google.com/issues/433195069 Please consider this small but impactful UX enhancement for future iOS versions.

Hi team, while i am using below code, i am getting two searchBar at top & bottom. Kindly refer below code & attached image Code: override func viewDidLoad() { super.viewDidLoad() title = "Test Data" setupSearchData() DispatchQueue.main.asyncAfter(deadline: .now() + 2) { self.setupSearchData() } } func setupSearchData() { navigationController?.navigationBar.prefersLargeTitles = false let searchController = UISearchController(searchResultsController: nil) navigationItem.searchController = searchController } It is working fine for other iOS versions. In my real useCase, i will refresh screen after API completed, then this issue occurred in my app.

Hi everyone, I’m testing our SwiftUI app on both Xcode simulator and a real iPhone. On the simulator, everything looks clean and aligned. But when I run it on an actual iPhone (same build, iOS 18), the layout looks broken—fonts overlap, spacing is off, and elements are misaligned. Both screenshots are from the exact same screen and time. First is simulator, second is iPhone. Any idea why this difference happens? Is there something I should check in terms of rendering or layout settings? Thanks in advance!

When I ran the following code on a physical iPhone device that supports Apple Intelligence, I encountered the following error log. What does this internal error code mean? Image generation failed with NSError in a different domain: Error Domain=ImagePlaygroundInternal.ImageGeneration.GenerationError Code=11 “(null)”, returning a generic error instead let imageCreator = try await ImageCreator() let style = imageCreator.availableStyles.first ?? .animation let stream = imageCreator.images(for: [.text("cat")], style: style, limit: 1) for try await result in stream { // error: ImagePlayground.ImageCreator.Error.creationFailed _ = result.cgImage }

My team has been debugging problems with the SwiftUI List component this week. We have found that it's performance is sub-optimal on iOS 16. You can see a simple grid of images, the scroll indicator stutters when scrolling down: Now compare it to what happens when we use a ScrollView with a LazyVStack: (An error occurred while uploading my second image, but pretend you see a scroll indicator moving smoothly down the side of the screen). You can see the scroll indicator moves smoothly without issue. We also found that the ScrollView combined with a LazyVStack properly calls onDisappear, which enables us to call a cancel method on the async image loading code that we use for our individual cells in this example. Though in a previous question, it was asserted that onDisappear cannot be reliably expected to be called in a List, I do not feel that answer is correct or proper behavior. Is this a bug, or is this expected behavior on a List? This is the cell that is being rendered: struct UserGridCell: View {   let stackId: String   let user: ProfileGridCellUIModel   let userGridCellType: UserGridCellType   @State var labelFrame: CGRect = .zero       private var isOnlineAcessibilityValue: String {     return user.isOnline == true ? "" : ""   }       init(stackId: String,      user: ProfileGridCellUIModel,      userGridCellType: UserGridCellType   ) {           self.stackId = stackId     self.user = user     self.userGridCellType = userGridCellType   }   var body: some View {     GeometryReader { containerGeometry in       ZStack(alignment: .bottom) {         HStack(spacing: 4) {                       let statusAccentColor: Color = .red                                   Circle()             .frame(width: 8, height: 8)             .foregroundColor(statusAccentColor)                       Text(String(user.remoteId) ?? "")             .lineLimit(1)             .foregroundColor(.black)             .overlay(GeometryReader { textGeometry in               Text("").onAppear {                 self.labelFrame = textGeometry.frame(in: .global)               }             })         }         .frame(maxWidth: .infinity, alignment: .bottomLeading)         .padding(.leading, 8)         .padding(.trailing, 8)         .padding(.bottom, 8)       }       .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .bottom)       .contentShape(Rectangle())       .accessibilityLabel(Text(user.name ?? ""))       .accessibilityValue(isOnlineAcessibilityValue)     }     .background(       ZStack {         AsyncProfileImage(request: URLRequest(url: URL(string: "https://picsum.photos/id/\(100 + user.remoteId)/200/300")!))       }         .accessibilityHidden(true)     )     .overlay(       RoundedRectangle(cornerRadius: 4)         .stroke(.red, lineWidth: user.hasAnyUnreadMessages ? 4 : 0)     )     .cornerRadius(4)   } } This is the code that renders each cell: struct ProfileGrid: View {   public static var AspectRatio: CGFloat = 0.75   @Environment(\.horizontalSizeClass) var horizontalSizeClass   @Environment(\.redactionReasons) private var reasons   private let stacks: [ProfileGridStackUIModel]   public init(stacks: [ProfileGridStackUIModel]   ) {     self.stacks = stacks   }       var body: some View {     let columnCount: Int = 3           // If you use a list, you will get the stutter. If you use what you see below, // it will render properly.     ScrollView {       LazyVStack {         ForEach(stacks, id: \.self) { stack in           Grid(stack: stack, columns: columnCount)         }       }     }     .buttonStyle(PlainButtonStyle())     .listStyle(PlainListStyle())   }       @ViewBuilder private func Grid(stack: ProfileGridStackUIModel, columns: Int) -> some View {     let chunks = stride(from: 0, to: stack.profiles.count, by: columns).map {       Array(stack.profiles[$0..<min($0 + columns, stack.profiles.count)])     }                   ForEach(chunks, id: \.self) { chunk in       GridRow(chunk: chunk, stack: stack, columns: columns)         .listRowInsets(EdgeInsets(top: 0, leading: 0, bottom: 0, trailing: 0))     }   }       @ViewBuilder private func GridRow(chunk: [ProfileGridCellUIModel], stack: ProfileGridStackUIModel, columns: Int) -> some View {     let emptyElements = columns - chunk.count     HStack(spacing: 8) {       ForEach(chunk) { user in         UserGridCell(stackId: "id",                user: user,                userGridCellType: .grid)         .aspectRatio(ProfileGrid.AspectRatio, contentMode: .fill)       }               if emptyElements > 0 {         ForEach(0..<emptyElements, id: \.self) { _ in           Rectangle()             .foregroundColor(Color.clear)             .contentShape(Rectangle())             .frame(maxWidth: .infinity)             .aspectRatio(ProfileGrid.AspectRatio, contentMode: .fill)         }       }     }   } }

Hello, I am running into a bit of an issue with the Screen Timeout/Screen Lock setting and would like some clarification on. First for a bit of context, I am enrolling personal iOS devices 18.0+ into the company MDM (Intune) with Account Driven User Enrollment. We are trying to set a screen timeout of 5 minutes and immediately after it asks for the passcode on the device, though this setting is not being applied and the device timeout setting can be set as "Never" on the user's end. This is a big security risk for the company I work for and and the issue with being HIPAA compliant. According to the Microsoft Intune Support, "In iOS 18, when using Account-Driven User Enrollment for BYOD (Bring Your Own Device) scenarios, the screen lock timeout setting is indeed marked as “Not Applicable”. This is because Apple’s privacy-preserving model for personal devices restricts administrative control over system-level settings like screen lock or idle timeout." I am needing clarification on the item mentioned from Microsoft Intune Support and if this setting is no longer able to be applied from the MDM with devices enrolled with Account Driven User Enrollment?

We are facing a serious issues with in app purchases in our app. We offer 3 IAP: auto-renewable subscription 1W, auto-renewable subscription 1Y, non-consumable one-time purchase (LifeTime access) In our case 90-95% of transactions fail and we mostly get SKError code=2 . Sometime purchase fails several times for the same user so it’s very hard to believe that user intentionally cancels transaction for the same product 4 or even 5 times in a row. It happens regardless iOS version, device model, our app version. We've checked multiple threads with the same issue but coudn't find any solution. We do not offer any promotions, product identifiers are valid... Some users are able to make a purchases without any issues.

I know there are several existing threads on this topic but things keep changing. The release notes for Xcode 26 beta 3 have the following statements for a couple of resolved issues: Asset Catalog Fixed: Unable to set Icon Composer icon as alternate iOS icon (153305178) (FB18025356) Icon Composer Fixed: Icon Composer icons back deploy to older versions of iOS, macOS, and watchOS with inconsistent rendering. (152258860) I had a working solution under beta 1 and beta 2 for both of these. But under beta 3, I am now seeing the new glass icons for my app when running on a simulated iOS 18 device. This is happening for both the main app icon and any alternates. This contradicts the statement that beta 3 fixes this issue. There is no documentation (that I can find) describing how you are supposed to support old icons for iOS 18 and new glass icons for iOS 26. There is no documentation for how to support alternate glass icons for iOS 26. What I'm doing at the moment (that worked before beta 3) was to have the normal iOS 18 app icons in the Asset catalog and to have the new glass icons added to the project. The filenames for the glass .icon files have the same name as the app icons in the Assets catalog. This worked under beta 1 and beta 2. And despite the Xcode 26 beta 3 release notes stating that Icon Composer icons no longer back deploy to iOS 18, I'm seeing the opposite. Beta 3 now does the opposite of that statement. Does anyone have a working solution that supports old iOS 18 app icons and new iOS 26 glass icons using Xcode 26 beta 3? Note, all of my testing is with simulated iOS devices and I'm running Xcode 26 beta 3 under macOS 15.5. Maybe that's an issue?

When using UIPageViewController inside a UITabBarController on iOS 26 with Liquid Glass adoption, visiting the PageViewController tab applies a blur effect to the navigation bar and tab bar even though the current child view controller of the pageView is not scrollable and does not reach behind these bars. Questions: Is this the expected behavior that the pageview's internal scroll view causes the bars to blur regardless of the page view's child content’s scrollability? If so, is there an official way to make the blur effect appear only when the pageview's current child view controller actually scrolls behind the navigation bar or tab bar, and not in static cases? Tried the same in SwiftUI using TabView and TabView with page style. Facing the same issue there as well. Sample screenshots for reference, Sample SwiftUI code, struct TabContentView: View { var body: some View { TabView { // First Tab: Paging View PagingView() .tabItem { Label("Pages", systemImage: "square.fill.on.square.fill") } // Second Tab: Normal View NavigationStack { ListView() } .tabItem { Label("Second", systemImage: "star.fill") } // Third Tab: Normal View PageView(color: .blue, text: "Page 3") .tabItem { Label("Third", systemImage: "gearshape.fill") } } .ignoresSafeArea() } } struct PagingView: View { var body: some View { TabView { PageView(color: .red, text: "Page 1") PageView(color: .green, text: "Page 2") PageView(color: .blue, text: "Page 3") } .tabViewStyle(.page) // Enables swipe paging .indexViewStyle(.page(backgroundDisplayMode: .always)) .ignoresSafeArea()// Dots indicator } }

Hi everyone, I've noticed a significant change in the visual behavior of List section headers between iOS 18 and iOS 26 beta that I'd like to clarify. Current Behavior: iOS 18 and earlier: Section headers with .listStyle(.plain) display with a translucent material background (regular material with blur effect) when pinned to the top during scrolling iOS 26 beta: Section headers with .listStyle(.plain) appear with a transparent/clear background even when pinned to the top Sample Code: struct ContentView: View { var body: some View { NavigationStack { List(1 ..< 5) { headerIndex in Section { ForEach(1...5, id: \.self) { rowIndex in HStack { Text("Row \(rowIndex)") .frame(height: 40) .padding(.horizontal) .background(Color.blue) Spacer() Image(systemName: "chevron.right") .foregroundStyle(.secondary) .font(.title3) } } } header: { Text("Header \(headerIndex)") .frame(height: 44) } .listRowSeparator(.hidden) } .listStyle(.plain) .clipped() } } } Questions: Is this change in header background behavior for .plain list style intentional in iOS 26? If so, what's the recommended way to maintain the previous material background appearance when headers are pinned? Should this be filed as feedback if it's unintended behavior? Testing Environment: Xcode 26.0 beta 3 (17A5276g) iOS 26 beta (23A5287g) vs iOS 18.5 Tested on simulator The translucent header background when pinned was quite useful for maintaining readability over scrolling content, so I'm hoping to understand if this is the new expected behavior or if there's a way to preserve the previous appearance. Any insights would be greatly appreciated! iOS 18.5 iOS 26 Beta