feat(ios): expose contentTypes include-filter on message query methods

[yewreeka]

Summary

The FfiListMessagesOptions.contentTypes field is fully supported by the Rust FFI layer but was never wired through in the Swift SDK. The excludeContentTypes parameter was exposed, but the include-filter was always hardcoded to nil.

Changes

Adds a contentTypes: [StandardContentType]? = nil parameter to the following methods on Group, Dm, and Conversation:

• messages()
• messagesWithReactions()
• enrichedMessages()
• countMessages()

The parameter is passed through to FfiListMessagesOptions.contentTypes.

Backward Compatibility

Fully backward-compatible — all existing call sites continue to work unchanged since the new parameter defaults to nil.

Example Usage

// Get only text messages
let texts = try await group.messages(contentTypes: [.text])

// Get only custom/unknown content types  
let custom = try await dm.messages(contentTypes: [.unknown])

// Combine with existing exclude filter
let filtered = try await conversation.messages(
    contentTypes: [.text, .reply],
    excludeContentTypes: [.readReceipt]
)

Note

Expose contentTypes filter parameter on iOS message query methods

Adds an optional contentTypes: [StandardContentType]? parameter to messages, messagesWithReactions, enrichedMessages, and countMessages on Group, Dm, and Conversation. When provided, the parameter is forwarded to FfiListMessagesOptions to filter results by content type; passing nil preserves existing behavior.

^{Macroscope summarized 67422e9.}

[claude]

Claude finished @yewreeka's task —— View job

---

PR Review Complete

Todo List

• Read modified Swift files
• Analyze code quality and consistency
• Check for potential bugs or issues
• Review performance and security considerations
• Assess test coverage
• Provide final review feedback

---

Review Feedback

Review Date: March 4, 2026, 06:03 UTC

✅ Code Quality

The implementation is clean, consistent, and follows existing patterns perfectly. The contentTypes parameter is correctly wired through all four methods across all three files with proper nil defaults for backward compatibility.

✅ Implementation Consistency

All three files (Group.swift, Dm.swift, Conversation.swift) follow identical patterns:

• Parameter added in same position (after deliveryStatus)
• Same type signature: [StandardContentType]? = nil
• Consistently passed to FfiListMessagesOptions.contentTypes
• All four methods updated: messages(), messagesWithReactions(), enrichedMessages(), countMessages()

✅ No Bugs Detected

• Parameter correctly assigned to options.contentTypes in all cases (Group.swift:610,683,774,802 | Dm.swift:393,455,571,486 | Conversation.swift:320,332,379,391,433,445,467,477)
• No logic errors or type mismatches
• Proper handling of optional values

✅ Performance & Security

• No performance concerns—parameter is simply passed through to FFI layer
• No security issues—filtering by content type is a legitimate query operation
• No additional allocations or computational overhead

⚠️ Test Coverage

Missing test coverage. The PR adds a new public API parameter but includes no tests. Recommended additions:

1. Unit tests verifying contentTypes filter works correctly:

   • Filter for single content type (e.g., .text)
   • Filter for multiple content types
   • Verify nil returns all content types (backward compatibility)
   • Combine with excludeContentTypes to ensure both filters work together

2. Integration tests for all four affected methods across Group, Dm, and Conversation

Test location: sdks/ios/Tests/ (based on standard iOS project structure)

---

Summary: Implementation is solid and production-ready from a code quality perspective. The only gap is test coverage, which should be added before merging to ensure the feature works as expected and prevent regressions.

---