Updating the thread... Using an app group works just fine for sharing preferences but that shouldn't be required between an app and included appex. If I can make a reduced test case I'll file a feedback on it.

Thanks edford. The issue is that I've found very few developers that have updated the plugins on the store as most missed this in the release notes. I've sent messages to the ones that I use that never updated, but none have replied. The situation as it stands is that most of the Xcode plugins in the MAS don't work with Xcode 12 on BS. It's not an ideal look. Thanks again, Josh

It's part of the Authentication Services - https://developer.apple.com/documentation/authenticationservices/ascredentialproviderviewcontroller. It's been around on iOS since 12, but it is new to the Mac on macOS BS.

There are a few different pods and SPM packages out there for the current OpenSSL builds. I would caution you though if you are a Swift developer because the current codebase of OpenSSL changes all the base types from C-structs you can poke around in to OpaquePointers that you end up needing to cast back and forth through AnyObject in order to get to any data.

I miss the pinned topics in categories. There were several great resources that you could really only find that way.

@eskimo We've opened a radar on the same topic, FB8310522. We see the same two points that lead to the failure. The mismatching for a privileged mech as non-privileged. The new helper that tries to run the mech thinks it's on Tiger still and only looks in /System. I included logs for regression testing back to macOS BS B1, a fresh copy of NullAuthPlugin as a reduced test case, and client seat impact data. Just adding us to the dogpile.

As a US citizen I would say that asking for someone’s SSN is never acceptable outside of a US government use. Even for government use the full number is rarely requested. I normally see requests for the last 4 digits along with several other bits of information to prove identity.

As an observation, I've noticed that in all the threads about rejections, investigations, or removals that nobody ever says what the apps are. Every now and then someone will say something like "It's just a simple game." but that still isn't much of a description.I think it would be helpful to share what sorts of apps and features seem to attract red flags. That way these sorts of issues can be avoided by more people in the future.

Well, this is exactly what a bunch of the SIP and Hardened Runtime provisions were explicitly made to prevent from happening.There are lots of instructions out there on the internet about attaching debuggers to things you aren't activly developing, but I'll leave those as an exercise for the reader.

In the post at least, your AppGroups identifier has a typo in the second one where it is missing a dot between the team ID and the bundle ID. The first one actually has two dots between them.That would keep them from matching and from being able to access the shared space, which is what the logs are complaining about.

Typically I see apps like this using Sparkle, or something similar, to handle updates.

You can't force enable a Safari extension. The best you can do is check to see if it is enabled with:getStateOfSafariExtension(withIdentifier:compeltionHandler:) when your container app is launched.Then you can prompt the user to enable it if they need to.

I would take a look at the troubleshooting documentation from Apple. It will walk you through the process to verify the signing and the notarization steps.

The simplest path is just to update the app with the new profile.You can also push out the new provisioning profile with MDM if your organization has a server that supports the operation.

I think it's just them gathering info as to how the program is being used. It's probably in response to the public outing of companies that were using enterprise distribution to avoid the App Store terms of service and restrictions.