Disable assertions in release builds for SPM targets

[DesmondLime]

Changes in this pull request

Disable assertions in release builds for SPM targets.

Our app has used IGListKit for years via CocoaPods, and recently switched to Swift Package Manager. Shortly after, we started seeing a meaningful number of production crashes originating from assertions inside IGListKit.

The cause turned out to be a difference in how the two integration methods are built. Both the IGListKit.xcodeproj and the project CocoaPods generates set ENABLE_NS_ASSERTIONS = NO in their release configurations, which makes Xcode pass -DNS_BLOCK_ASSERTIONS and compile out the NSCAssert calls behind IGAssert and friends. SwiftPM has no equivalent build setting for C and Objective-C targets, so release builds of the package ship with every assertion still live — debug-only checks become production crashes.

This is not something consumers can work around on their own: build settings such as OTHER_CFLAGS and GCC_PREPROCESSOR_DEFINITIONS set in the app project do not propagate into a Swift package's targets.

This PR defines NS_BLOCK_ASSERTIONS for the IGListDiffKit and IGListKit targets in the release configuration, so that SPM matches the behaviour the Xcode project and CocoaPods have always had. Debug builds are unaffected, so the assertions keep doing their job during development and in the test suite.

We do recognise that finding and fixing the root cause of each assertion would be the better outcome. In practice these failures are tied to specific device models and hard-to-reach states, and as a small team we have not been able to reproduce them locally. Regardless of that, we think release builds behaving differently depending on the integration method is a bug worth fixing on its own.

Issue fixed: N/A

Checklist

• All tests pass. Demo project builds and runs.
• I added tests, an experiment, or detailed why my change isn't tested.
• I added an entry to the CHANGELOG.md for any breaking changes, enhancements, or bug fixes.
• I have reviewed the contributing guide

[meta-cla]

Hi @DesmondLime!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!