I am trying to solve an issue when converting an existing project to use Buildable Folders: Our current project have some custom file types that have specialized build rules, as described here: https://developer.apple.com/documentation/xcode/creating-build-rules-for-custom-file-types We previously added each of these file types, to the target's Compile Sources phase and everything was running well. Now we wish to move these files into a Buildable Folder, but I cannot find a way to make it work ... as only files with a specific file extensions are ever built in a Buildable Folder, and despite having a custom rule for this file type, it seems like Xcode never runs the rule. Is there some way to tell Xcode to treat specific extensions in a Buildable Folder as source extension?

Getting a weird build failure with Xcode 26 beta 5 that I haven't seen before. Build works fine locally but fails in CI when building with xcodebuild with this error: build description signature: 7cb0bf47dd6decc14090f5ae23d66594 Build description path: /Users/user/Library/Developer/Xcode/DerivedData/ProjectName-dpklhpaqruhpwdbkihszqtqogzfb/Build/Intermediates.noindex/XCBuildData/7cb0bf47dd6decc14090f5ae23d66594.xcbuilddata error: Failed to decode version info for '/Applications/Xcode-beta.app/Contents/Developer/usr/bin/actool': The data couldn’t be read because it is missing. (stdout: '<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.ibtool.version</key> <dict> <key>bundle-version</key> <string>24118.1</string> <key>short-bundle-version</key> <string>26.0</string> </dict> </dict> </plist> ', stderr: '' The thing is, the data is definitely there - actool is outputting valid XML: <key>com.apple.ibtool.version</key> <dict> <key>bundle-version</key> <string>24118.1</string> <key>short-bundle-version</key> <string>26.0</string> </dict> But xcodebuild keeps saying it's missing. This error repeats like 15 times in the build log. Build command: set -o pipefail && xcodebuild -workspace "ProjectName/ProjectName.xcworkspace" -scheme "ProjectNameDeviceTests" -configuration "Debug" -destination "generic/platform=iOS" -resultBundlePath "Build for device/result_bundle.xcresult" -verbose TREAT_WARNINGS_AS_ERRORS=YES COMPILER_INDEX_STORE_ENABLE=NO -IDEBuildLocationStyle=Custom -IDECustomBuildLocationType=Absolute -IDECustomBuildProductsPath="$PWD/test_package" OTHER_SWIFT_FLAGS='${inherited} -Xfrontend -debug-time-function-bodies -Xfrontend -debug-time-expression-type-checking' SWIFT_COMPILATION_MODE=wholemodule clean build-for-testing The issue seems to come and go, sometimes cleaning the derived data and/or reset helps, sometimes it doesn't. Anyone else hitting this? Seems like a parsing bug in the beta where it can't read its own version info properly.

The appTransactionID was recently introduced and is documented here: https://developer.apple.com/documentation/storekit/apptransaction/apptransactionid From the documentation: "The App Store generates a single, globally unique appTransactionID for each Apple Account that downloads your app and for each family group member for apps that support Family Sharing." This seems like a really useful identifier, so I was wondering about some edge cases of when using it: What happens if a user logs out of his AppStore account and keeps using the app? Is it available when the app is installed from Xcode? is it possible to set it to some value using StoreKit testing? Thanks

I am trying to develop a system extension. During development process I often like to create a version, debug it, fix some issue, and then try a new version. This is a normal flow for development, but it doesn't seem to work for me when developing a system extension. It seems like removing a system extension using the systemextensionsctl only registers it for removal after the next restart, which means I need to restart my machine for every code change. it also seems like calling OSSystemExtensionRequest.activationRequest(forExtensionWithIdentifier: queue: ) with the new extension version will not replace the running one despite the _ request: OSSystemExtensionRequest, actionForReplacingExtension existing: OSSystemExtensionProperties, withExtension ext: OSSystemExtensionProperties ) being called on the OSSystemExtensionRequestDelegate So is there another way to iterate on app extension versions?

MTLStorageModeManaged textures requires blit passes to synchronize the CPU and GPU according to the doc here. Since in Apple Silicon macs, there is just a single unified memory architecture, do we still need to synchronize? does the texture really exist in two copies in the memory? or is it just in order to provide code compatibility with Intel mac? (and the texture are essentially shared texture under the hood?)

Trying to call [MTLDevice newTextureWithDescriptor:iosurface:plane:] on an Apple Silicon mac, where the descriptor specifies MTLStorageModeShared, I am getting a failed assertion error: -[MTLDebugDevice newTextureWithDescriptor:iosurface:plane:]:2387: failed assertion `Texture Descriptor Validation IOSurface textures must use MTLStorageModeManaged I don't really understand why we have this limitation, MTLStorageModeShared textures are supported on Apple silicon (despite the documentation in https://developer.apple.com/documentation/metal/mtldevice/1433378-newtexturewithdescriptor?language=objc which claims overwise.

Hi, I have been following the steps presented in https://developer.apple.com/documentation/coremediaio/creating_a_camera_extension_with_core_media_i_o to create a core media I/O camera. However when calling let activationRequest = OSSystemExtensionRequest.activationRequest( forExtensionWithIdentifier: identifier, queue: .main ) activationRequest.delegate = installDelegate OSSystemExtensionManager.shared.submitRequest(activationRequest) The delegate's request(_ request: OSSystemExtensionRequest, didFailWithError error: Error) method is being called with error code 9 (OSSystemExtensionError.Code.validationFailed) and the system dialog does not appear.