Post

Replies

Boosts

Views

Activity

"Failed to register bundle identifier" for teammates — caused by App Groups/HealthKit forcing an explicit App ID?
I'm trying to let a few teammates build and run my app on their own devices, and I'd like to understand the correct approach for our situation. Setup We are a small team. Each of us uses a free personal Apple Developer team (individual Apple IDs, no paid membership yet). The app (an iOS app with a Watch app and a WidgetKit extension) uses App Groups and HealthKit. Bundle IDs: com.example.MyApp, com.example.MyApp.watchkitapp, com.example.MyApp.Widget. App Group: group.example.MyApp. It builds fine for me. When a teammate opens the project and tries to run on device, they get: Failed Registering Bundle Identifier The app identifier "com.example.MyApp" cannot be registered to your development team because it is not available. Change your bundle dentifier to a unique string to try again. What I've observed My other apps that have no entitlements build fine for every teammate. Looking at their embedded profiles, those sign with a wildcard profile (TEAMID.*). This app signs with an explicit profile (TEAMID.com.example.MyApp). If a teammate removes HealthKit and App Groups from all targets, the app builds for them under their own team using the same bundle ID. My understanding (please correct me) App Groups and HealthKit require an explicit App ID, which can only be registered to one team. Since I registered com.example.MyApp first, no other personal team can register the same explicit App ID hence the error. My questions Is that understanding correct — that an entitled (explicit) App ID can only ever belong to a single team? Is there any supported way to keep the same bundle identifier and keep App Groups + HealthKit while teammates build under their own separate personal teams? Or is moving to an Organization account (everyone as members of one shared team) the only way to share an entitled bundle ID across multiple developers? For free personal-team development, is the recommended pattern to give each developer a unique bundle ID + App Group (e.g. via per-developer .xcconfig), keeping entitlements intact? Just want to confirm I'm choosing the right approach before committing to it. Thanks!
1
0
23
2d
Xcode fails to compile Blender-exported USDZ in .rkassets with misleading "permission" error — Xcode 26.3
The error: When building a RealityKitContent package that contains a USDZ file exported from Blender, Xcode throws the following error: error: [xrsimulator] Exception thrown during compile: Cannot get rkassets content for path .../RealityKitContent.rkassets because 'The file "RealityKitContent.rkassets" couldn't be opened because you don't have permission to view it.' error: Tool exited with code 1 The error message mentions "permission" — but permissions are not the issue. This appears to be a misleading error from realitytool masking a USD validation failure. What I've ruled out File permissions — all files are -rw-r--r--, user has Read & Write on the folder Extended attributes / quarantine flag — other files with the same @ flag work fine Corrupted archive — unzip -t confirms the USDZ is valid (board.usdc + textures) Stale build cache — deleted DerivedData and com.apple.DeveloperTools cache, no change Key observations The same file builds successfully on my colleague's machine running identical Xcode 26.3 - MacOS 26.3 Other USDZ files in the same .rkassets bundle (downloaded from Sketchfab, or created in Reality Composer Pro) compile without any issue. Only USDZ files exported directly from Blender are affected. When the file is placed in Bundle.main and loaded via Entity(named:in:.main), it works perfectly — no errors Reality Converter flags the file with two errors: UsdGeomPointInstancers not allowed, and root layer must be .usdc with no external dependencies The confusing part: the same file compiles fine on an identical Xcode 26.3 setup and importing method. This suggests either a machine-specific difference in Xcode's validation behavior, or a cached .reality bundle on my colleague's machine that isn't being recompiled. Current workaround: Loading from Bundle.main instead of the RealityKitContent package bypasses realitytool entirely and works, but loses Reality Composer Pro integration: if let entity = try? await Entity(named: "test", in: Bundle.main)
1
0
1.6k
Mar ’26
"Failed to register bundle identifier" for teammates — caused by App Groups/HealthKit forcing an explicit App ID?
I'm trying to let a few teammates build and run my app on their own devices, and I'd like to understand the correct approach for our situation. Setup We are a small team. Each of us uses a free personal Apple Developer team (individual Apple IDs, no paid membership yet). The app (an iOS app with a Watch app and a WidgetKit extension) uses App Groups and HealthKit. Bundle IDs: com.example.MyApp, com.example.MyApp.watchkitapp, com.example.MyApp.Widget. App Group: group.example.MyApp. It builds fine for me. When a teammate opens the project and tries to run on device, they get: Failed Registering Bundle Identifier The app identifier "com.example.MyApp" cannot be registered to your development team because it is not available. Change your bundle dentifier to a unique string to try again. What I've observed My other apps that have no entitlements build fine for every teammate. Looking at their embedded profiles, those sign with a wildcard profile (TEAMID.*). This app signs with an explicit profile (TEAMID.com.example.MyApp). If a teammate removes HealthKit and App Groups from all targets, the app builds for them under their own team using the same bundle ID. My understanding (please correct me) App Groups and HealthKit require an explicit App ID, which can only be registered to one team. Since I registered com.example.MyApp first, no other personal team can register the same explicit App ID hence the error. My questions Is that understanding correct — that an entitled (explicit) App ID can only ever belong to a single team? Is there any supported way to keep the same bundle identifier and keep App Groups + HealthKit while teammates build under their own separate personal teams? Or is moving to an Organization account (everyone as members of one shared team) the only way to share an entitled bundle ID across multiple developers? For free personal-team development, is the recommended pattern to give each developer a unique bundle ID + App Group (e.g. via per-developer .xcconfig), keeping entitlements intact? Just want to confirm I'm choosing the right approach before committing to it. Thanks!
Replies
1
Boosts
0
Views
23
Activity
2d
Xcode fails to compile Blender-exported USDZ in .rkassets with misleading "permission" error — Xcode 26.3
The error: When building a RealityKitContent package that contains a USDZ file exported from Blender, Xcode throws the following error: error: [xrsimulator] Exception thrown during compile: Cannot get rkassets content for path .../RealityKitContent.rkassets because 'The file "RealityKitContent.rkassets" couldn't be opened because you don't have permission to view it.' error: Tool exited with code 1 The error message mentions "permission" — but permissions are not the issue. This appears to be a misleading error from realitytool masking a USD validation failure. What I've ruled out File permissions — all files are -rw-r--r--, user has Read & Write on the folder Extended attributes / quarantine flag — other files with the same @ flag work fine Corrupted archive — unzip -t confirms the USDZ is valid (board.usdc + textures) Stale build cache — deleted DerivedData and com.apple.DeveloperTools cache, no change Key observations The same file builds successfully on my colleague's machine running identical Xcode 26.3 - MacOS 26.3 Other USDZ files in the same .rkassets bundle (downloaded from Sketchfab, or created in Reality Composer Pro) compile without any issue. Only USDZ files exported directly from Blender are affected. When the file is placed in Bundle.main and loaded via Entity(named:in:.main), it works perfectly — no errors Reality Converter flags the file with two errors: UsdGeomPointInstancers not allowed, and root layer must be .usdc with no external dependencies The confusing part: the same file compiles fine on an identical Xcode 26.3 setup and importing method. This suggests either a machine-specific difference in Xcode's validation behavior, or a cached .reality bundle on my colleague's machine that isn't being recompiled. Current workaround: Loading from Bundle.main instead of the RealityKitContent package bypasses realitytool entirely and works, but loses Reality Composer Pro integration: if let entity = try? await Entity(named: "test", in: Bundle.main)
Replies
1
Boosts
0
Views
1.6k
Activity
Mar ’26
Foundation Models compatibility with Swift Playground
There is a week left for end of the Swift Student Challange submissions. I've built an app which uses FoundationModels but unfortunately there is no support for it in the Swift Playground. Is there any chance it might be coming up in the following days?
Replies
1
Boosts
0
Views
525
Activity
Feb ’26