User Profile

Hi! In my Xcode Cloud workflow, I have the TestFlight Internal Testing post-action with “App Store Connect Users” included in Groups. I expected the action would make the builds available for internal testing automatically (just as the builds uploaded from Xcode are). However, they don’t appear in TestFlight: in build history, I don’t see the ASC Users group next to my Xcode Cloud build, and in order to make it available for testing, I have to add the group manually. After the group is added, the build is published right away, without any extra steps (e.g. export compliance certification, etc.). Am I doing something wrong here? I’ve tried removing and re-adding the group in the post-action, and even re-creating the entire workflow—all to no avail.

My iOS app consists of one app target and several local SPM packages. Previously, I had a test plan which only included the app target’s tests, while the packages’ tests were launched separately using the packages’ scheme names. Now, I’m trying to switch to test plans entirely. I included the test targets defined in the packages in the test plan. However, doing so resulted in the following error message, attributed to @testable import statements: Testing failed: Module '<***>' was not compiled for testing Command CompileSwiftSources failed with a nonzero exit code Testing cancelled because the build failed. If I understand it correctly, the error occurs because the Enable Testability (ENABLE_TESTABILITY) build setting defaults to NO, preventing the packages’ internal symbols from being exposed with @testable imports. Since Swift packages do not use Xcode project files, I’m confused about where I should define this setting. Besides that, testability is expected to be enabled only for test and not release builds, while Swift packages don’t support build configurations. Am I missing something? Is there a way to make Swift packages and test plans play nice together?

My app was rejected twice. The first time I left code calling into private APIs (namely LSApplicationWorkspace) in a production build, so this rejection seems legitimate. However, the second time the app was rejected, all uses of private APIs were inside #if DEBUG conditions. I believe code inside #if DEBUGs does not make it into the build, given that the DEBUG flag isn’t specified for the configuration. Taking into consideration the fact it took nearly three weeks—during which my app was “in review,” without any updates or requests from the reviewers—and two inquiries into the status (including an expedited review request) to have the new build reviewed, I’m not even sure it was actually reviewed—the experience was so frustrating I wouldn’t be surprised if the build got rejected “just because.” So, I’ve got a few questions: Am I correct in that #if DEBUGged code cannot end up in a production build (i.e. a build whose configuration doesn’t include the DEBUG flag)? Is it possible the App Store review team had access to more symbols than actually exist in the build? How could my app get rejected because of code that’s not in the build? Is it worth spending time on engaging in a conversation with the review team to figure out what’s going on?