build disappears

should mention we seem to have lost alot of previously uploaded builds in test flight

As of 26.1.0 the error has disappeared, however an attempt to create bookmarkData for / now results in a wrong bookmark for /.nofollow/. Yes. This is a different issue, which was fixed in macOS 26.2. See this thread for more details. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hi @BrianMcDonald Are you building for visionOS? RealityKit attachments are only available in visionOS, and you will encounter the above error if you try building for a non-supported platform, such as iOS or macOS. If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant and post the FB number here. Thanks!

Thank you for your reply. Unfortunately, creating a package using productbuild results in the same zero-byte file written to /Applications. I used the command: productbuild --sign --component /Applications Interestingly, if my coworker creates the application on his machine, I can then use his application in my pkgbuild script and the installation succeeds. Both his application and the application I build on my machine are signed with the same company Developer ID Application and are notarized. Both applications also run on my machine and have the same functionality, as their source was pulled from the same branch. We are both using XCode 16.2. This problem only started to happen on my machine last week. Does the pkgbuild command have a cache that can be deleted? Thank you for your time.

Apple sent this response on 18 November 2025: We believe this issue has been addressed. Please verify this matter is resolved after updating to iOS 26.2 beta 3. iOS 26.2 beta 3 (Build: 23C5044b) Posted Date: November 17, 2025 In my testing, the issue seems resolved indeed! Thank you! It is great and encouraging news for SpriteKit users. The issue FB20808104, where both SpriteKit and RealityKit drop frames under SwiftUI views, still holds. I will continue to look for updates on the Feedback Assistant.

[quote='868615022, Charita, /thread/805901?answerId=868615022#868615022, /profile/Charita'] It would be helpful if you could suggest a way in which this can be handled at my end. [/quote] I can suggest various options, but there are no good options here. I outlined the reasons for that in my previous post. Ignoring all the build-time stuff for the moment, let’s focus purely on the runtime aspects. You only want one version of this vendor’s code in the client app’s process. Where should that code be? If you statically link it in your framework then the client can’t access it in the normal way. If the client statically links it into their app then your framework can’t easily access it. There’s no standalone framework available from the vendor, so that’s not an option. I see three potential options: You statically link the code into your framework and provide the necessary infrastructure for the client to access it from there. You create a standalone framework from this code, ship it to your clients, an

In our case we have been pending weeks to fix a problem that was broken with iOS 26.1 but resolved by a SwiftUI modifier with a new parameter available in Xcode 26.2: extension View { func apply(@ViewBuilder _ block: (Self) -> V) -> V { block(self) } } TabView { // Some tabs } .apply { if #unavailable(iOS 26.1) { // Previous approach that stopped working in iOS/iPadOS 26.1 $0.tabViewBottomAccessory() { if viewModel.showAccessoryView { // accessory content } else { EmptyView() } } } else { // When compiled with Xcode 26.2+ for iOS/iPadOS 26.1+ $0.tabViewBottomAccessory(isEnabled: viewModel.showAccessoryView) { // accessory content } } } So we are further frustrated by this longer than typical delay to open submissions to an RC build.

As of 26.1.0 the error has disappeared, however an attempt to create bookmarkData for / now results in a wrong bookmark for /.nofollow/.

As of 26.1.0 the error has disappeared, however an attempt to create bookmarkData for / now results in a wrong bookmark for /.nofollow/.

Resolution (fixed) App Store Connect was rejecting my build with “RPBroadcastProcessMode … key was not specified” even though the key/value appeared in the IPA and in swinfo. The root cause was the key’s location in the Upload appex Info.plist. ASC expects the key directly under NSExtension, not inside NSExtensionAttributes. Incorrect (what I had originally): NSExtension └─ NSExtensionAttributes └─ RPBroadcastProcessMode = RPBroadcastProcessModeSampleBuffer Correct (what ASC expects): NSExtension ├─ NSExtensionPointIdentifier = com.apple.broadcast-services-upload ├─ NSExtensionPrincipalClass = $(PRODUCT_MODULE_NAME).SampleHandler └─ RPBroadcastProcessMode = RPBroadcastProcessModeSampleBuffer Minimal working Info.plist for the Upload appex: CFBundlePackageType XPC! CFBundleExecutable $(EXECUTABLE_NAME) CFBundleIdentifier $(PRODUCT_BUNDLE_IDENTIFIER) CFBundleShortVersionString $(MARKETING_VERSION) CFBundleVersion $(CURRENT_PROJECT_VERSION) MinimumOSVersion 26.0 NSExtension NSExtensionPointIdentifi