[abdulraqeeb33]

Description

One Line Summary

Reject null and empty identity strings through one shared helper.

Details

Motivation

Fixes SDK-5426.

Empty strings were stored as aliases, tags, triggers, and app ids. Null and empty are rejected together on the identity APIs below, matching the other client SDKs under SDK-5327.

Scope

OSInputGuard rejects null and empty for:

• initialize(appId). "" returns before cached app id setup and before remote logging is configured. nil still means the app id has not been provided.
• addAlias / addAliases (label and id)
• removeAlias / removeAliases
• addTag / addTags (key only). An empty tag value is allowed, including one that contains a null byte. These methods take [String: String], so an ObjC NSNull or NSNumber crashes in the Swift bridge before the guard. That crash is pre-existing.
• removeTag / removeTags
• addEmail / removeEmail and addSms / removeSms (empty only, not format checks)
• addTrigger / addTriggers (key only). An empty trigger value is allowed. A null trigger value is rejected. addTriggers also rejects NSNull.
• removeTrigger / removeTriggers
• trackEvent(name)
• login(externalId). "" and a null byte are both rejected.

Whitespace is still allowed. One blank map or list entry rejects the whole call. A null byte is rejected everywhere isMissing runs. An empty tag or trigger value may still contain one.

setLanguage("") is not rejected. It is the reset to the device language.

Testing

Unit testing

OSInputGuardTests covers nil, empty, whitespace, a null byte, and blank map or list entries. InputGuardUserTests resets the shared user and checks aliases, tags, email, SMS, login, and trackEvent(""). In-app message tests cover a blank trigger key and a nil trigger value.

Manual testing

Not run. This is a guard before native storage, covered by unit tests.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

[cursor]

Multi-model review (Claude Sonnet 5.5, GPT 5.6 Sol, Grok 4.7) of SDK-5426. Shared OSInputGuard correctly rejects empty identity strings on the Swift User APIs, and the follow-up keeps a nil trigger value out of the dictionary.

Consider (2/3 Sonnet+Grok): initialize("") / setAppId("") now return before setLaunchOptions: and init, and no longer fall back to storedAppId. The old !newAppId || length == 0 path already refused to persist "" and used the cache. The PR documents the cache skip, but the initialize early return also drops cold-start launch options; a later initialize(realAppId, nil) cannot restore them. No test covers "" vs nil.

Consider (3/3): addTrigger:withValue: only rejects a nil pointer. [NSNull null] is stored, while addTriggers: rejects NSNull. testNilTriggerValueIsNotStored covers only nil.

Consider (2/3 Sonnet+GPT): User addTag / addTags take non-optional String. ObjC nil bridges to "" and is stored. The helper’s NSNull check is not on this path, so the “null tag value is rejected” contract is not enforced at the public ObjC boundary.

Noted: NSNull in a typed [String: String] / [String] can trap in the Swift bridge before the guard (pre-existing). setAppId logs initialize: appId. IAM tests mutate the shared controller.

  

_{Sent by Cursor Automation: PR Reviews}

[nan-li]

Should we add NUL byte to have parity with Android? The report of that issue was sampled on Android SDK 5.1.20 but it could come from any platform.

[abdulraqeeb33]

Should we add NUL byte to have parity with Android? The report of that issue was sampled on Android SDK 5.1.20 but it could come from any platform.

Its added in Android OneSignal/OneSignal-Android-SDK@de6f7d1

[nan-li]

Should we add NUL byte to have parity with Android? The report of that issue was sampled on Android SDK 5.1.20 but it could come from any platform.

Its added in Android OneSignal/OneSignal-Android-SDK@de6f7d1

Yes so should we add that to this PR as well?

[abdulraqeeb33]

Added in 7bb6d3d. isMissing rejects a null byte, including login. An empty tag or trigger value can still contain one, matching Android allowEmptyValue.

[fadi-george]

• Non-blocking: OneSignalUserManagerImpl.swift addTags/addAliases/removeTags/removeAliases, ObjC callers passing NSNumber or NSNull values crash in the Swift bridge before OSInputGuard runs ("Could not cast value of type 'NSNull' to 'NSString'"). Pre-existing on main. The NSNull branch in hasMissingEntries only applies to triggers, so the "null tag value is rejected" line in the description doesn't hold for addTags.

[abdulraqeeb33]

Agreed. addTags takes [String: String], so NSNull and NSNumber crash in the bridge before the guard. That is pre-existing. The description now says the null-value reject is the trigger path only. An empty tag value, including one with a null byte, stays allowed.