fix(nitrogen/ios): optional number release build error

[moskalakamil]

fixes a bug where a std::optional<double> (used to represent number | undefined) would not work correctly in Release mode due to a Swift C++ interop issue.

Even though std::optional<double> is an optional type, it is not always detected by needsSpecialHandling, which caused the generated bridging to follow the generic path. This worked in Debug, but Release builds triggered a Swift interop bug causing the optional number to be interpreted incorrectly.

A previous attempt to fix this (see #1065) introduced the following pattern:

has_value() ? .pointer : nil

However, this did not address the issue - the Swift C++ interop layer still failed in Release mode.

A reproducible example of the failing case is here:
moskalakamil@bef989c

Instead of using .pointer, this PR switches to:

if bridge.has_value_${bridge.specializationName}(${cppParameterName}) {
    let __unwrapped = bridge.get_${bridge.specializationName}(${cppParameterName})
    return ${indent(wrapping.parseFromCppToSwift('__unwrapped', language), '    ')}
} else {
    return nil
}
}()

cc @hyochan

[vercel]

@moskalakamil is attempting to deploy a commit to the Margelo Team on Vercel.

A member of the Team first needs to authorize it.

[mrousavy]

Thanks for the fix - a few notes;

1. CI is failing - you didn't lint properly. Run bun lint in the root
2. Is there a reason why you put this into the react-native-nitro-test-external package? I would prefer to keep this in react-native-nitro-test, unless it specifically only happens when using an external type from another package

[moskalakamil]

in my case, the bug only appeared when two nitro packages were linked together. Building each package individually in release mode worked fine, but once they depended on each other the issue surfaced immediately. This is very similar to what happened in PR #1065; when you added optional number handling there, the problem did not show up because the package was isolated. Not sure how it looks in react-native-nitro-sound (cc again @hyochan)

[mrousavy]

Since it happens in react-native-nitro-sound and @hyochan does not use external dependencies (as far as I know?) i am not fully sure if this is a deterministic way to test this.

I'll build a release version of this tomorrow and check if it can be reliably reproduced, then we'll see

[moskalakamil]

hey @mrousavy, have you had a chance to take a look?