That's a sham...how about when developing the extension? Did you find a way to locally replace the extension without a reboot of the dev machine?

answering myself - according to the documentation here: https://developer.apple.com/documentation/metal/resource_fundamentals/synchronizing_a_managed_resource In a unified memory model, Metal may ignore synchronization calls completely because it only creates a single memory allocation for the resource. also according to https://developer.apple.com/documentation/metal/resource_fundamentals/choosing_a_resource_storage_mode_for_intel_and_amd_gpus In a unified memory model, a resource with an MTLStorageMode.managed mode resides in system memory accessible to both the CPU and the GPU. Still, looking here: Choosing a Resource Storage Mode for Apple GPUs it is not clear what is the distinction between shared and managed textures on Apple GPUs (in fact managed textures are not even mentioned in the documentation, despite being used by some system APIs). It is still not clear for me for instance, why it is impossible to create an IOSurface backed shared texture, but it is possible to create a managed one.

Here is a log I've got from the console when facing the same issue: Instruments: Cannot split user provided arguments. Error: working directory doesn't exist.. String to split: '-NSDocumentRevisionsDebugMode YES'. Envs: '{ "CA_ASSERT_MAIN_THREAD_TRANSACTIONS" = 0; "CA_DEBUG_TRANSACTIONS" = 0; "CFLOG_FORCE_DISABLE_STDERR" = 1; "DYLD_FRAMEWORK_PATH" = "/Users/****/Library/Developer/Xcode/DerivedData/****//Build/Products/Release-iphoneos:/Users/****//Library/Developer/Xcode/DerivedData/****/Build/Products/Release-iphoneos/PackageFrameworks"; "DYLD_LIBRARY_PATH" = "/Users//****/Library/Developer/Xcode/DerivedData/****/Build/Products/Release-iphoneos"; "DYLD_PRINT_STATISTICS" = 1; HIPreventRefEncoding = 1; "IDE_DISABLED_OS_ACTIVITY_DT_MODE" = 1; "LLVM_PROFILE_FILE" = "/dev/null"; "METAL_ERROR_CHECK_EXTENDED_MODE" = 0; MallocNanoZone = 1; "OS_ACTIVITY_TOOLS_OVERSIZE" = 1; "OS_ACTIVITY_TOOLS_PRIVACY" = 1; "OS_LOG_DT_HOOK_MODE" = 0x07; "OS_LOG_DT_HOOK_PREFIX" = "OSLOG-DC3A4553-E33F-'

This seems to arise from instruments incorrectly parsing the -NSDocumentRevisionsDebugMode YES flag that XCode automatically adds. Until they solve this bug - you can disable this flag in the app run schema - see https://stackoverflow.com/a/46103110/1614719

The issue persists in Beta 4 should we just remove CoreServices.framework ? what are the implications of the removal?

same issue here, beta5 is unusable for me

Hi Ed, thanks for the response I've created a radar in: https://feedbackassistant.apple.com/feedback/19753533 I've created a new project and can confirm the behavior is easily reproduced and consistent. Files with custom files extensions that have build rules are ignored when they are inside a buildable folder

seems to be resolved in beta 6