Summary xcrun simctl install <valid.app> fails even though the app's Info.plist contains a correct, well-formed CFBundleIdentifier — verified independently with plutil -p. The app builds successfully via xcodebuild twice, under two different signing configurations. This is purely an install-time failure. ERROR · EVERY ATTEMPT An error was encountered processing the command (domain=IXErrorDomain, code=13): Simulator device failed to install the application. Missing bundle ID. Underlying error (domain=IXErrorDomain, code=13): Failed to get bundle ID from /QuestionsWeCarry.app Missing bundle ID. Environment MACOS 26.5.2 · Build 25F84 XCODE 26.6 · Build 17F113 SIMULATOR RUNTIME iOS 26.5 (23F77) HARDWARE Apple M5 KERNEL Darwin 25.5.0 arm64 XCODE.APP / SIMULATOR PLATFORM both freshly installed Xcode.app and the iOS Simulator platform were both freshly installed immediately before this was discovered — this may be a first-run / first-boot issue specific to this Xcode 26.6 + iOS 26.5 combination. Project being built A SwiftUI iOS app target generated via XcodeGen from project.yml, depending on a local Swift Package with four library products. Nothing exotic — no third-party SDKs, no CocoaPods, no entitlements file. PROJECT.YML — RELEVANT TARGET BLOCK PROJECT.YML targets: QuestionsWeCarry: type: application platform: iOS deploymentTarget: "17.0" sources: - path: App/Sources - path: App/Resources type: folder buildPhase: resources info: path: App/Info.plist properties: CFBundleDisplayName: "Questions We Carry" UILaunchScreen: {} ITSAppUsesNonExemptEncryption: false UIApplicationSceneManifest: UIApplicationSupportsMultipleScenes: false settings: base: PRODUCT_BUNDLE_IDENTIFIER: com.brodywolfstudio.questionswecarry MARKETING_VERSION: "1.0.0" CURRENT_PROJECT_VERSION: "1" SWIFT_VERSION: "5.10" TARGETED_DEVICE_FAMILY: "1,2" CODE_SIGN_STYLE: Manual CODE_SIGN_IDENTITY: "-" CODE_SIGNING_REQUIRED: NO CODE_SIGNING_ALLOWED: YES dependencies: - package: QWCKit product: QWCCore - package: QWCKit product: QWCEngine - package: QWCKit product: QWCStore - package: QWCKit product: QWCUI BUILD COMMAND THAT SUCCEEDS SHELL xcodebuild -project QuestionsWeCarry.xcodeproj -scheme QuestionsWeCarry -configuration Debug -destination "platform=iOS Simulator,id=" -derivedDataPath DerivedData build Result: BUILD SUCCEEDED, produces DerivedData/Build/Products/Debug-iphonesimulator/QuestionsWeCarry.app. INFO.PLIST INSIDE THE BUILT .APP (VIA PLUTIL -P) INFO.PLIST { "BuildMachineOSBuild" => "25F84" "CFBundleDevelopmentRegion" => "en" "CFBundleDisplayName" => "Questions We Carry" "CFBundleExecutable" => "QuestionsWeCarry" "CFBundleIdentifier" => "com.brodywolfstudio.questionswecarry" "CFBundleInfoDictionaryVersion" => "6.0" "CFBundleName" => "QuestionsWeCarry" "CFBundlePackageType" => "APPL" "CFBundleShortVersionString" => "1.0" "CFBundleSupportedPlatforms" => [ 0 => "iPhoneSimulator" ] "CFBundleVersion" => "1" "DTCompiler" => "com.apple.compilers.llvm.clang.1_0" "DTPlatformBuild" => "23F81a" "DTPlatformName" => "iphonesimulator" "DTPlatformVersion" => "26.5" "DTSDKBuild" => "23F81a" "DTSDKName" => "iphonesimulator26.5" "DTXcode" => "2660" "DTXcodeBuild" => "17F113" "ITSAppUsesNonExemptEncryption" => false "MinimumOSVersion" => "17.0" "UIApplicationSceneManifest" => { "UIApplicationSupportsMultipleScenes" => false } "UIDeviceFamily" => [ 0 => 1 1 => 2 ] "UILaunchScreen" => { } } CFBundleIdentifier is present, correctly formed, and matches PRODUCT_BUNDLE_IDENTIFIER. file confirms this is a valid Apple binary property list, not corrupted. CODESIGN -DV ON THE BUILT APP CODESIGN -DV Executable=/QuestionsWeCarry.app/QuestionsWeCarry Identifier=QuestionsWeCarry-******* Format=bundle with Mach-O thin (arm64) CodeDirectory v=20400 size=338 flags=0x2(adhoc) hashes=3+3 location=embedded Signature=adhoc Info.plist=not bound TeamIdentifier=not set Sealed Resources version=2 rules=13 files=4 Internal requirements count=0 size=12 Note Info.plist=not bound — unclear whether this is expected for an ad-hoc-signed bundle app (as opposed to a framework), or is itself a symptom of the underlying problem. Reproduction Minimal, reproducible with the plain command-line tool — no Claude tooling involved in this step: SHELL xcrun simctl install "iPhone 17 Pro" "/DerivedData/Build/Products/Debug-iphonesimulator/QuestionsWeCarry.app" Result (100% reproducible, every attempt): STDERR An error was encountered processing the command (domain=IXErrorDomain, code=13): Simulator device failed to install the application. Missing bundle ID. Underlying error (domain=IXErrorDomain, code=13): Failed to get bundle ID from /QuestionsWeCarry.app Missing bundle ID. Also reproduced with xcrun simctl launch, which fails as a consequence: Isolation steps taken All of the following were tried, and none changed the outcome — the exact same "Missing bundle ID" error occurs every time: 01 Two signing configurations — unsigned/linker-signed (Sealed Resources=none) vs. proper ad-hoc sign (Sealed Resources version=2 rules=13 files=4), plus a manual codesign --force --deep --sign - re-sign pass. Same failure every time. 02 Two simulator destinations — generic/platform=iOS Simulator and a concrete device id for iPhone 17 Pro. 03 Two never-before-used simulator devices — iPhone 17 Pro and iPhone Air — ruling out per-device CoreSimulator state corruption. 04 Erase + cold boot — simctl shutdown, erase, boot immediately before a fresh install attempt. 05 Real Simulator.app GUI running — not just a headless simctl boot — ruled out a CoreSimulatorService/GUI dependency. 06 Path with no spaces — copied the .app out of a path containing "Application Support" — ruled out a path-quoting issue. The build itself is never in question — xcodebuild reports BUILD SUCCEEDED every time; only the subsequent simctl install step fails. What I'd like feedback on Is this a known issue with this specific Xcode 26.6 / iOS 26.5 Simulator runtime combination — both very recently installed, so possibly a fresh-install/first-boot bug? Is there a required build setting for this Xcode version not yet reflected in commonly-documented XcodeGen/xcodebuild recipes — e.g. an entitlements file now required even for simulator-only, no-team builds, or a different expected code-signing identity/format? Is Info.plist=not bound in the codesign -dv output actually abnormal for an app bundle (as opposed to a framework), and could that be the root cause simctl is choking on?

Hi everyone! After about 4-5 months of development, I released WatchBlocks v1.5 today. The project started as an experiment to answer a simple question: Could you build a real sandbox survival game that runs well on Apple Watch? It eventually grew into a cross-platform game supporting Apple Watch, iPhone, iPad, and Mac. Some of the technical challenges I enjoyed solving included: Optimizing rendering and gameplay for watchOS. Designing controls around the Digital Crown and the watch display. Building multiplayer across Apple platforms. Creating a content system that lets players make and share their own blocks, items, mobs, and biomes. The new update also transitions the game to a free-to-start model, making it easier for people to try it before deciding whether to unlock the full experience. I’d love to hear from other developers building for watchOS. It’s a platform that doesn’t get much attention for games, but I think there’s a lot of untapped potential. If anyone has questions about developing games for Apple Watch, I’m happy to answer them. App Store: https://apps.apple.com/us/app/watchblocks-craft-build/id6760209351

I am having a root TabView with tabs. One of the tabs has a TabBar with page style as the root view and each Page has a ScrollView. Unfortunately the scroll view get's clipped by the parent TabView size. But I want to make the ScrollView content to go behind the root TabView's tab bar like it would work if I would have the ScrollView as direct child to the root TabBar I tried using ignoreSafeArea on the page style TabView and there are other weird bugs, it stops reacting to the Binding pageIndex I am having as a State. The custom page index view disappears Sample code: https://github.com/BProg/TabViewScrollViewBug.git

Can somebody tell me if I'm doing something wrong or SwiftUI's scrollTo(id:anchor:) just doesn't work if the ScrollView is scrolling? I have a trivial example that demonstrates the issue: import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct Item: Identifiable { let id = UUID() let timestamp: Date let text: String } struct ContentView: View { @State private var items: [Item] = (0...10_000).map{ .init(timestamp: Date(), text: "Row \($0)") } @State private var scrollPosition = ScrollPosition(idType: Item.ID.self) @State private var newMessage: String = "" var body: some View { ScrollView { LazyVStack { ForEach(items) { item in ItemView(item: item) } }.scrollTargetLayout() } .defaultScrollAnchor(.bottom, for: .initialOffset) .scrollPosition($scrollPosition, anchor: .bottom) .safeAreaBar(edge: .bottom) { HStack { TextField("Type here", text: $newMessage, axis: .vertical) .textFieldStyle(.roundedBorder) Button("Send", action: { let trimmed = newMessage.trimmingCharacters(in: .whitespacesAndNewlines) guard !trimmed.isEmpty else { return } newMessage = "" items.append(.init(timestamp: .now, text: trimmed)) withAnimation(.smooth) { scrollPosition.scrollTo(id: items.last!.id, anchor: .bottom) } }) }.padding() } } } struct ItemView: View { let item: Item var body: some View { VStack(alignment: .leading) { Text(item.text) Text(item.timestamp.formatted()) }.padding() .frame(maxWidth: .infinity, alignment: .leading) .background(Color(red: .random(in: 0...1), green: .random(in: 0...1), blue: .random(in: 0...1))) } } #Preview { ContentView() }

Hi, We have found a nasty issue with SwiftUI List and Equatable reference types. In such scenarios List might resurface stale objects from some internal cache when inserting new equal instances, which can lead to outdated cells on screen. Detailed information can be found in our bug report (FB23923342). Since List is quite a widespread component we thought dropping a few lines here in addition to our report could be helpful, especially if you have been bitten by this issue in the past.

Hello! I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators. When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar. On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator. Here's a clip from a simulator: Here's the code that reproduced the bug I experienced in our app. #Preview { NavigationStack { ScrollView { TextField("", text: .constant("")) .padding() .background(Color.secondary) TextField("", text: .constant("")) .padding() .background(Color.green) } .padding() .safeAreaInset(edge: .bottom, content: { Color.red .frame(maxWidth: .infinity) .frame(height: 40) }) .toolbar { ToolbarItem(placement: .keyboard) { Button {} label: { Text("test") } } } } }

Environment: iOS Version: iOS 27.0 Framework: ActivityKit Xcode Version: Xcode 26.1 Issue Description: In iOS 27, Live Activities fail to adapt to the system colorScheme. Regardless of whether the system theme is set to Light or Dark mode, @Environment(.colorScheme) inside the Live Activity view always returns .dark. This behavior worked as expected on iOS 26, where the Live Activity correctly responded to light/dark mode changes and rendered the appropriate theme. Expected Behavior: The Live Activity view should respect the system's current colorScheme (returning .light when the system is in Light Mode) on iOS 27, consistent with the behavior on iOS 26. Actual Behavior: The Live Activity view strictly defaults to .dark mode on iOS 27, even when the device is explicitly set to Light Mode. struct LockScreenView<T: BaseLiveActivityAttributes>: View { let context: ActivityViewContext<T> @Environment(\.colorScheme) var colorScheme var isLight: Bool { colorScheme == .light } var body: some View { Color(isLight ? .white : .black) .overlay(alignment: .topTrailing) { VStack(alignment: .trailing, spacing: 2) { Text("colorScheme: \(String(describing: colorScheme))") } .font(.system(size: 9, weight: .bold, design: .monospaced)) .foregroundColor(.yellow) .padding(4) .background(Color.black.opacity(0.6)) .cornerRadius(4) .padding(.trailing, 8) .padding(.top, 4) } } } Any insights or workarounds would be greatly appreciated. Thanks!

When switching to a SwiftUI app (built with Xcode 26.5) from an app with an active keyboard, the target app's tab bar incorrectly floats above the keyboard safe area. This layout issue occurs even though the target app does not display a keyboard and contains only a tab bar and scroll views.

I'm using PDFKitView: NSViewRepresentable to present the pdf page in SwiftUI. Seems we already have some useful built-in functions in the context menu. However, the highlight manipulation functions are not functional - I can neither delete the highlight annotation nor change the color/type of the current pointed highlight annotation. The "Add Note" and other page display changing functions work well.

Hello Apple Developer Community, My name is Chris, and I’m an independent developer building games, educational tools, and utility apps for Apple platforms. I’d like to share some of the applications I have released so far: ADVENT Text Game for Mac A retro-inspired text adventure designed specifically for macOS. View on the App Store ADVENT Text Game for iPhone and iPad Explore mysterious caves, discover hidden passages, collect treasures, and solve puzzles in a classic-inspired text adventure. View on the App Store iFrappe View on the App Store China Driving Exam Trainer A study and practice application for learners preparing for the Chinese driving licence theory examination. View on the App Store Ur: The Royal Game A digital interpretation of the ancient Royal Game of Ur. View on the App Store I’m also currently developing Steel Maze, a retro maze-based tank battle game for iPhone, iPad, and Mac. Each project has helped me explore different parts of Apple development, including SwiftUI, SpriteKit, Mac Catalyst, responsive layouts, Game Center, gameplay design, and App Store distribution. I would be happy to receive feedback from other developers and connect with people working on similar independent projects. You can find my current app portfolio here: CK My Apps Thank you for taking a look!

Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.

Hello, Could someone from Apple clarify the support and behavior of the UIDesignRequiresCompatibility property? The UIDesignRequiresCompatibility documentation states that this property will be ignored for builds targeting iOS 27 or later. I have a couple of questions: Does "builds targeting iOS 27 or later" refer to an app that was built using Xcode 27 or later? iOS 27 is expected to be released in Fall 2026. Suppose that after iOS 27 is released, I create a new build using Xcode 26, with UIDesignRequiresCompatibility set to true, and install that build on an iOS 27 device. Will UIDesignRequiresCompatibility still be honored in this scenario, or will it be ignored and the app will use the Liquid Glass UI? Thanks!

I have a ScrollView with a LazyVStack with Sections. I initialize the ScrollView with a scroll position but the ScrollView starts with the first row at the top. Am I doing something wrong or is this just a bug in ScrollView? It seems to work fine if I do not use Section. struct ContentView: View { @State var scrollPosition: ScrollPosition init() { var p = ScrollPosition(idType: Int.self) p.scrollTo(id: 500, anchor: .top) scrollPosition = p } var body: some View { ScrollView { LazyVStack { ForEach(0..<sectionCount, id: \.self) { j in Section { ForEach(0..<rowCount, id: \.self) { i in RowView(text: "\(j)/\(i) [\(j*rowCount+i)]") .id(j*rowCount+i) } } header: { HeaderView(title: "\(j)") } } } .scrollTargetLayout() } .scrollPosition($scrollPosition) } }

Hello everyone, I am encountering an inconsistent typography behavior when developing for WidgetKit. Specifically, there is no native serif font fallback for Chinese characters (CJK) in the Widget environment, whereas Latin characters are fully supported. When using the .serif design modifier in SwiftUI: Text("Hello 世界").font(.system(size: 16, design: .serif)) English/Latin characters ("Hello"): System correctly renders using the pre-installed serif font (New York). Chinese characters ("世界"): System ignores the .serif design and falls back to the default sans-serif font (PingFang SC). Can I find any pre-installed native serif font for CJK in iOS that I can reliably invoke within my Widget Extension without bundling .ttf files? If not, do you have plans to map Font.design(.serif) to a pre-installed CJK serif font in future iOS releases so I can maintain design consistency across my localized widgets? Thank you for any insights or recommended workarounds.

We're getting user reports that the App Store rating prompt appears repeatedly — one user says they're prompted roughly every day, and that they still get the prompt after they've already left a rating. This contradicts the documented behavior, so I want to check whether others are seeing the same thing or whether there's a known regression. What the docs say should happen The system limits display to 3 occurrences per app within a 365-day period. For a user who has already rated/reviewed, StoreKit should only display again if the app version is new and more than 365 days have passed since their previous review. Has anyone else experience it?

I want to detect when the user stopped touching the screen. But I want it to be in a vertical ScrollView and a DragGesture isn't recognized when the view is scrolled vertically. I'm guessing this is because there wasn't anything dragged, since the view moved along with the user's finger. import SwiftUI struct TestView: View { var body: some View { ScrollView { VStack(spacing: 0) { Rectangle() .foregroundStyle(.green) .frame(height: 700) } } .gesture(DragGesture().onEnded({ _ in print("Drag gesture ended") })) } } How should I go about detecting when the user lifted their finger off the screen on a scrollview?

i've been struggling to get the SwiftUI instrument to work during the betas. It never produces any results on simulator, while on device it throws an error which prevents any results from other instruments from appearing. the error is: Failed to stop recording session: Data Providers emitted errors: Required I've tried on my iPad Pro 11-inch (M4) (iPadOS27 beta 3), and iPhone 17 Pro Max (iPadOS27 beta 2). And I get the same result running from my mac studio & MacBook air. Is this a known thing? cheers, Mike

I am profiling a simple SwiftUI test app on my new iPhone through my new MacBook Pro and everything is version 26.2 (iOS, macOS, Xcode). I run Instruments with the SwiftUI template using all of the default settings and get absolutely zero data after interacting with the app for about 20 seconds. Using the Time Profiler template yields trace data. Trying the SwiftUI template again with the sample Landmarks app has the same issue as my app.

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).

When I use an inline search bar on a screen and the keyboard is opened, we can see an odd blur in the final place first before the keyboard finishes the move