.debug() not working in custom configurations

[gkaimakas]

Describe the bug
Not sure if this an issue of CA or something I might have missed but I am facing the following:

I have created a new project, renamed debug scheme to dev and copied it to create another one called staging.
I have also edited each scheme to use the correct configuration.
I did not edit/delete/create any new Custom Flags / Active compilation conditions.

When I call .debug() in one of my reducers it does not print anything to the console.
I have also tried to use #if DEBUG directly on my project, which surprisingly, works.

To Reproduce
The behaviour I am seeing can be reproduced here:
CADebugBug.zip

Expected behavior
.debug() should print on the console.

Environment

• Xcode [Version 11.6 (11E708)]
• Swift [5.2.2]
• OS: [iOS 13.6]
• CA version: 0.7.0

[mathieutozer]

I've been experiencing this too.

[kaishin]

I have noticed this too in a similar setup.

[AlexisQapa]

IIRC SPM doesn't support custom configurations for now (only debug and release) and Xcode tries to map your configuration name to either debug or release. If you rename your configuration to DevDebug Xcode might build your SPM dependencies with the debug configuration. You might want to differentiate configurations from schemes and use only two configurations and a scheme per environment.

[kaishin]

I solved by renaming the configuration to Debug for now. Thanks for the pointer @AlexisQapa!

[stephencelis]

This is a known issue being tracked by Apple

• https://forums.swift.org/t/swift-package-manager-and-custom-build-configurations/29181/5
• https://forums.swift.org/t/custom-build-configuration-names/29167/2

I'm going to convert this to a discussion in case folks would like to share their various workarounds.

[bobspryn]

Did anyone ever determine a workaround to this that didn't include renaming configurations?

[lukeredpath]

There isn’t one currently. Xcode will still try to map a configuration name to either Debug or Release when building swift packages and how it does this is undocumented.

I would recommend sticking to Debug and Release configurations and using schemes to handle different environments.

[jshier]

It's undocumented but it's been stated that any configuration with "Debug" in the name will be treated as debug. Should be easy enough to test.

[iampatbrown]

@jshier You're right. PrefixDebug,DebugSuffix or PrefixDebugSuffix should work.

[bobspryn]

Thanks everyone!

[dahiri-farid]

I have a similar issue but with the TestStore class. it is under a DEBUG macro, however our Build Configuration for CI is Test. For that reason we have compilation errors because TestStore class in not found. This is also due to SPM not supporting Build Configurations.
I would suggest removing the DEBUG macro from TestStore and possibly replace it with a custom macro.

[jshier]

Renaming your configuration to TestDebug may allow Xcode / SPM to pick up the fact that it's a debug config and add the DEBUG condition for you. Custom conditions wouldn't help here at all since there's no way to set such conditions automatically for consumers like SPM does for DEBUG.

[mbrandonw]

As of 0.41.0 the TestStore is no longer hidden behind #if DEBUG.

[iampatbrown]

As of 0.41.0 the TestStore is no longer hidden behind #if DEBUG.

@mbrandonw does xctest-dynamic-overlay work in release mode at the moment?

[stephencelis]

@iampatbrown It does not and can not, unfortunately. We briefly allowed the runtime stuff to work in release mode, but that led to App Store rejections: pointfreeco/swift-issue-reporting#10

Really not sure the best way to work around it, but it sounds like we'd need something like a separate XCTestReleaseFriendlyDynamicOverlay module that never ships in app builds.

[mbrandonw]

It sadly does not! Everything is hidden behind #if DEBUG so that the code remains App Store friendly.

But we do have plans on splitting xctest-dynamic-overlay into two libraries, one that is safe for the App Store and so can be used with test helpers defined in application code, and another that is not App Store friendly that can be used in TestStore (which would mean TestStore needs to be broken out into some kind of test support library).