[dsheikherev]

Merge only after the iOS SDK 7.0 GA. The code builds against the 7.0 betas as well, so merging early breaks nothing. The title is there so this lands with the GA SDK bump.

Why

iOS SDK 7.0 GA trims the public headers before the API freezes. The cross-platform wrapper contract is not app API, so it moves out of Bugsee.h into the explicit submodule Bugsee.SPI (BugseeSPI.h). That covers BGSWrapperChannel, BGSReportContract, BGSAttachmentContract, BGSDataRequestResultCallback, BGSCallback, BGSLogEventSource, BugseeWrapper, +[Bugsee setWrapper:] and the rest. import Bugsee / <Bugsee/Bugsee.h> no longer brings it in; a wrapper asks for it with #import <Bugsee/BugseeSPI.h>. The bugsee-cocoa change is bugsee/bugsee-cocoa#309.

Change

#import <Bugsee/BugseeSPI.h> under #if __has_include(<Bugsee/BugseeSPI.h>), right after the existing Bugsee import, in:

• packages/react-native/ios/BugseeModule.mm
• Support/Sources/BugseeRNSupport/include/BGSRNReportOps.h, BGSRNReportHandlerBridge.h, BGSRNWrapperChannelHolder.h (the .m files get it through these)
• Support/Tests/BugseeRNSupportTests/BGSRNWrapperChannelHolderTests.m, BGSRNReportHandlerBridgeTests.m, BGSRNFakeReport.h

Also (fd0f5bd): 7.0 GA deletes the iOS BGSIssueType enum, which the SDK never used. A report's type reaches BGSReportContract.type as the string bug, crash or error. scripts/cli-extract-option-keys.ts read that enum from BGSContracts.h, so regenerating ios-enums.json against GA would throw. The extraction, the fixture entry and the IssueType parity test are removed; IssueSeverity and CrashHandlerType stay. The enum tests (enum-parity, ios-enums, options/enums) pass: 31 tests.

No behaviour change. The Feedback package is not affected: it uses the BugseeFeedback SPM product, which bugsee-cocoa updates itself.

Checked

• All 62 BugseeRNSupport sources and tests: clang -fsyntax-only against an SDK build with Bugsee.SPI and one without (where Bugsee.h still declares the contract). 62/62 compile in both.
• Not compiled: BugseeModule.mm, which needs the React Native headers. Its change is the same import line as above.
• Not run: the support package tests, the example apps and e2e. Those need the GA SDK published to the SPM repo.

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 7531ac32-2076-438c-afc2-7438e94223a5

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Claude finished @dsheikherev's task in 2m 44s —— View job

---

Review of #178: import the wrapper contract from Bugsee.SPI

I found no blocking issues. I read the diff and the surrounding code, and I did not build or run anything. The SDK with BugseeSPI.h isn't available here, so none of the compile claims could be checked on my side.

What I checked

• All 7 hunks are the same guarded import placed after the existing Bugsee.h import (@import Bugsee in the tests).
  • #if __has_include(<Bugsee/BugseeSPI.h>) is false on the betas, so nothing changes there.
  • On GA the import is true and brings in the contract.
• I searched the iOS tree for every use of the moved symbols (BGSWrapperChannel, BGSReportContract, BGSAttachmentContract, BGSCallback, BGSDataRequestResultCallback, BGSLogEventSource*, BugseeWrapper). Every file that uses one gets the SPI import directly or through a changed header.

File	How it gets the contract
BGSRNReportHandlerBridge.m, BGSRNReportOps.m, BGSRNWrapperChannelHolder.m	the matching .h
BGSRNFakeReport.m	BGSRNFakeReport.h
BugseeModule.mm	its own import
BGSRNCreatedReportOps.h, BGSRNEventBus.h, BGSRNWrapper.h, BGSRNSecureRectanglesTests.m, BGSRNMainThreadTests.m	not needed; they only mention the symbols in comments, so leaving them unchanged is correct

• BGSRNWrapper.h deliberately avoids conforming to BugseeWrapper, and BugseeModule.mm adds the conformance. That is why the import is needed in the module and not in BGSRNWrapper.h.
• The tests import <Bugsee/BugseeSPI.h> after @import Bugsee;. That is the right way to reach an explicit submodule, because @import Bugsee no longer brings it in.

Residual risks (P3, not blockers)

1. BugseeModule.mm also uses BGSBugseeExchangeFactory (line 2115) and +[Bugsee getExchangeFactory]. The PR text lists the moved symbols but ends with "and the rest". If the exchange factory also moved to Bugsee.SPI, this file would now compile. If it moved elsewhere, it would not. Because BugseeModule.mm was not compiled (it needs the React Native headers), the example-app build against the GA SDK is the first place this would show. Please confirm against the bugsee-cocoa branch feat/public-api-spi.
2. Package.swift pins bugsee/spm to exact: "7.0.0-beta7". That is expected, since the GA bump is meant to land with this PR (hence the title). Make sure the bump and any BugseeReactNative.podspec version change go in together. Until then, the new import does nothing in CI.
3. The tests will not catch a missing import until the GA SDK is the one resolved. On the betas the __has_include branch is false, so the support tests and e2e only exercise the new path after the bump. The plan to run them after GA publishes, as the PR says, covers this.

Summary

1. Overall risk: Low. It is a purely additive, guarded import with no behaviour change.
2. Merge recommendation: Approve in principle. Hold the merge until the iOS SDK 7.0 GA is published, as the title says, and do the GA SDK bump in the same change.
3. Most important thing to do: After the bump, run the BugseeRNSupport tests and a full example-app build. That is the only thing that compiles BugseeModule.mm. Check the getExchangeFactory question above.
4. Positives: The change is small and uniform, and the comments say why it is guarded and when the guard can go. The guard keeps the code building on both the betas and GA, so it can merge early without risk. The PR description is clear about what was and wasn't verified.

[claude]

Claude finished @dsheikherev's task in 29s —— View job

---

Review of #178 (re-review after push of fd0f5bd)

No blocking issues. I read the diff, the surrounding code and the extractor/test scripts. I did not build or run anything. The Bugsee SDK, the React Native headers and node_modules are not available here.

What changed since my last review
fd0f5bd drops the iOS IssueType enum check:

• ios-enums.json no longer has IssueType.
• cli-extract-option-keys.ts no longer extracts BGSIssueType from BGSContracts.h.
• enum-parity.test.ts no longer pins it, and stripPrefix only strips BugseeSeverity.

I looked for anything that still depends on it:

• A repo-wide search for IssueType and BGSContracts finds no remaining consumer of iosEnums.IssueType. The Android hits are the Android enum, which is unaffected.
• scripts/__tests__/ios-enums.test.ts still uses BGSIssueType, but only as inline sample input to the generic parseObjcEnums parser, so it does not depend on the fixture.
• enums.test.ts reads only CrashHandlerType from ios-enums.json. That key is still there.
• The new comment says the report type arrives as a string. BGSRNReportHandlerBridge.m:68 does return report.type; with no enum mapping. That agrees with the comment, though I could not check the string values themselves.
• The parity check had been pinning values the SDK itself no longer has (it is gone in GA). Removing it is correct, and the extractor change keeps it from failing on GA headers.

Earlier findings: none were posted inline, and nothing in the new commit changes the P3 notes from my previous review. Those stay open until the GA bump:

• Confirm that BGSBugseeExchangeFactory and +[Bugsee getExchangeFactory] (used in BugseeModule.mm) are still reachable with the GA headers.
• Make sure the GA bump in native-versions.json and Package.swift, and any podspec change, land together with this PR.

New finding

• P3 Low: stale comments, documentation only. Three comments still name BGSContracts.h as the contract's home:

  • BGSRNReportOps.h:31
  • BGSRNReportDeadlines.h:8
  • BugseeModule.mm:2252

  On GA the contract is in BugseeSPI.h. Nothing breaks, but someone checking the "lock-synchronized" claim would open the wrong header. Fix: reword these to BugseeSPI.h when the GA bump lands. They are not in the diff, so I could not post this as an inline comment.

Summary

1. Overall risk: Low. The change is a guarded, additive import plus the removal of a fixture and test for an enum that no longer exists on GA.
2. Merge recommendation: Approve in principle. Hold the merge until the GA SDK is published, as the title says.
3. Most important to do: After the bump, run the BugseeRNSupport tests and a full example-app build. That is the only thing that compiles BugseeModule.mm, and it settles the exchange-factory question. Re-run cli-extract-option-keys.ts against the GA checkout to confirm the regenerated ios-enums.json matches the committed one.
4. Positives: The import change is uniform and small. The IssueType removal is clean, with no leftover references in the code, and the new comment explains why the check is gone.