Our app uses Face ID to optionally secure access to the app for device owner. This not the new 'Require Face ID' feature of iOS 18 - this is our own custom implementation that has some other related logic for authentication handling. Starting in iOS 18.3.1, starting the app results in multiple Face Id checks being fired - sometimes just a couple but sometimes many more. Curiously, this is happening even when I completely disable any code we have that prompts for Face ID. It appears to come from nowhere. This does not happen on prior iOS 18 releases so, while I might be doing something improper in the code, something specific has changed in iOS 18.3.1 to cause this issue to manifest. I'm looking for advice as to what could be occurring here, how to debug a Face Id check that appears to come from nowhere, and what, if any, workarounds exist.

I cannot add myself as a TestFlight user to my own app. When I open the invite link on my device, or manually enter the redeem code on device (obtained from opening the invite link on macOS), I get "This invitation has been revoked or is invalid". I've tried going to App Store Connect and removing myself from both the testing group and the list of 'All testers', both to no avail. Apple folks: this is not user error and you must have thousands of bug reports on this by now. Why don't you prioritize a fix for this incredibly annoying issue?

In my organization we limit the ability for any production-use private credentials from being used in a developer environment. This creates a challenge with APNs keys due to their apparent intended use being a single key across all apps of the org, with the 2nd allowed key being only for the key rotation use case. One idea I have to satisfy all concerns is to take advantage of the two key limit in a slightly different way: Generate the maximum two keys, and use one for dev environments and one for prod environments (with the key being secured according to our policies so that developers never get to see it). If we need to revoke the prod key at any point, we revoke the dev key, regenerate it and make that one the new prod key. Likewise, once that key is deployed in prod, revoke the old prod key and make that the new dev key. Does this seem like a viable approach? Are there any better ways to achieve a fully isolated setup where the production APNs key doesn't appear on a developer environment?

In Xcode 14, there seem to be two ways to configure how any particular piece of source code from the app module is available in a test target: Add the source file to both the app target and the test target Add the source file only to the app target, import the app module into each test class, and configure the test target to run use the app as the Host Application (including checking the 'Allow testing Host Application APIs' checkbox) Going with the first method seems to be better in my testing, as it produces a much faster run time. Option (2) when using the default (and very much desired) parallelization setting causes multiple simulator launches, which slows things down terribly. The downside of option (1) is that we'll be compiling source files twice. We really want to be testing precisely what was compiled in the app module, but it seems the lesser issue to contend with. So, neither of these options seem ideal to me – what we really want is a dumb anonymous test target that simply links to the compiled app module. This would avoid the extra compile step, allow me to avoid using a Host Application, and test precisely what's compiled into the app module. Am I missing something, or is there no way to achieve this?