Using the same app group ID with another team?

Hi,

Just a quick one. I am working with a client who doesn't share his team's credentials like certificates, mobile provisioning, etc. He even refused to add me as one of the developer in his Apple Dev account. So, I am creating a new scheme for me that will use my own personal team and app ID to build it. While the main app's original scheme is basically unusable since I don't have the credentials to build it. The client still needs it for his CI/CD though.

Now, the app has a Notification Service extension that will share UserDefaults via App Group. When I try to create a container with the same group ID as his, it always failed. It seems like we can't use it because it has already been taken by the clent. How do I fix this so I can just change the scheme to switch between the client's and mine?

Thanks.

Accepted Reply

It seems like we can't use it because it has already been taken by the [client].

Right. App groups can only be used to share data between apps from the same team. Thus, if Team A creates an app group, Team B can’t use it [1].

He even refused to add me as one of the developer in his Apple Dev account.

That’s going to make things tricky. The process I generally recommend for working with clients is:

  1. Have them add you to their team.

  2. Use that for development.

  3. You send them an Xcode archive.

  4. They use the Xcode organiser to publish the app based on that.

This process means that the client is fully in charge of distribution, but you have access to all the development credentials you need.

Note For info on how the client can set up your permissions, see Developer > Support > Program Roles.

If you can’t accomplish step 1 then life gets tricky. During development you’ll have to use a different bundle ID. You’ll also need to use different values for all shared identifiers, like this app group ID. That means you can’t use the Xcode archive process described above, because the built app contained within the archive will have the wrong IDs. So, you have to send them source code and they’ll have to build it themselves. And that means setting up your source so that these IDs are parameters of the build system.

Not impossible, but tricky.

If I were in your shoes I’d have a frank discussion with the client as to how much their policy choice is going to cost them (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I assume we’re on iOS here. The story on macOS is more nuanced. For the gory details, see App Groups: macOS vs iOS: Fight!.

  • Unfortunately, they rejected the idea of sharing the access. It's their closed-door policy that prevented it. Thank you for the answer.

Add a Comment

Replies

It seems like we can't use it because it has already been taken by the [client].

Right. App groups can only be used to share data between apps from the same team. Thus, if Team A creates an app group, Team B can’t use it [1].

He even refused to add me as one of the developer in his Apple Dev account.

That’s going to make things tricky. The process I generally recommend for working with clients is:

  1. Have them add you to their team.

  2. Use that for development.

  3. You send them an Xcode archive.

  4. They use the Xcode organiser to publish the app based on that.

This process means that the client is fully in charge of distribution, but you have access to all the development credentials you need.

Note For info on how the client can set up your permissions, see Developer > Support > Program Roles.

If you can’t accomplish step 1 then life gets tricky. During development you’ll have to use a different bundle ID. You’ll also need to use different values for all shared identifiers, like this app group ID. That means you can’t use the Xcode archive process described above, because the built app contained within the archive will have the wrong IDs. So, you have to send them source code and they’ll have to build it themselves. And that means setting up your source so that these IDs are parameters of the build system.

Not impossible, but tricky.

If I were in your shoes I’d have a frank discussion with the client as to how much their policy choice is going to cost them (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I assume we’re on iOS here. The story on macOS is more nuanced. For the gory details, see App Groups: macOS vs iOS: Fight!.

  • Unfortunately, they rejected the idea of sharing the access. It's their closed-door policy that prevented it. Thank you for the answer.

Add a Comment