Skip to content

fix(0.83, RCTUIKit): Extend support to SwiftUI#3006

Merged
Saadnajmi merged 1 commit into
microsoft:0.83-mergefrom
Saadnajmi:hosting-controller
Jul 7, 2026
Merged

fix(0.83, RCTUIKit): Extend support to SwiftUI#3006
Saadnajmi merged 1 commit into
microsoft:0.83-mergefrom
Saadnajmi:hosting-controller

Conversation

@Saadnajmi

@Saadnajmi Saadnajmi commented Jul 6, 2026

Copy link
Copy Markdown
Collaborator

Summary:

Followup to #2958 , whose repo is still locked so we can't edit it.

Extend RCTUIKit support to SwiftUI

Test Plan:

CI should pass

@Saadnajmi Saadnajmi requested a review from a team as a code owner July 6, 2026 21:36
@Saadnajmi Saadnajmi force-pushed the hosting-controller branch from 93d8e7a to 9124597 Compare July 6, 2026 21:44
@Saadnajmi Saadnajmi mentioned this pull request Jul 6, 2026
Closed
@Saadnajmi Saadnajmi enabled auto-merge (squash) July 7, 2026 05:53
@Saadnajmi Saadnajmi merged commit 9ca5f4f into microsoft:0.83-merge Jul 7, 2026
1 check passed
Saadnajmi added a commit to Saadnajmi/react-native-macos that referenced this pull request Jul 7, 2026
@Saadnajmi
fix(0.83, RCTUIKit): make SwiftUI platform aliases visible to Swift
3539977 
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit
Objective-C module via @compatibility_alias. That works for the Obj-C
classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor),
which import into Swift fine, but it silently breaks for the SwiftUI types,
so RCTSwiftUI-macOS fails to compile:

  RCTSwiftUIContainerView.swift:
  error: cannot find type 'RCTPlatformHostingController' in scope
  error: cannot find type 'RCTPlatformViewRepresentable' in scope
  error: cannot find type 'Context' in scope (x2)

UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI
types (a generic class and a protocol). An Objective-C @compatibility_alias
to them is not imported by Swift's Clang importer (and SwiftUI is not even
imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in
Swift. The Context errors are secondary: once RCTPlatformViewRepresentable
conformance is unknown, its associated Context type can't be resolved either.

Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit):
- Add RCTUIKitCompat.swift to the React-RCTUIKit pod, declaring
  RCTPlatformHostingController and RCTPlatformViewRepresentable as Swift
  typealiases (guarded by #if os(macOS)). The pod now compiles Swift
  (SWIFT_VERSION) and links SwiftUI, so these types are exported to any
  module that does `import React_RCTUIKit`.
- Remove the two non-functional SwiftUI @compatibility_alias entries from
  RCTUIKitCompat.h (nothing in Objective-C referenced them) and leave a note
  explaining why SwiftUI types must be declared in Swift.
- Implement RCTPlatformViewWrapper with the concrete UI/NSViewRepresentable
  requirements (makeUIView/makeNSView + updateUIView/updateNSView); the
  previous makeRCTPlatformView/updateRCTPlatformView names did not satisfy
  either protocol.

iOS behavior is unchanged (RCTPlatformHostingController -> UIHostingController,
RCTPlatformViewRepresentable -> UIViewRepresentable).

Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS
target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed.

Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR
checks on merge branch too"), so the merge-branch Build RNTester / macos job
was not yet running when microsoft#3006 landed, which is why this compile break was
not caught at merge time.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Saadnajmi Saadnajmi mentioned this pull request Jul 7, 2026
Open
Saadnajmi added a commit to Saadnajmi/react-native-macos that referenced this pull request Jul 7, 2026
@Saadnajmi
fix(0.83, RCTUIKit): make SwiftUI platform aliases visible to Swift
c694fdd 
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit
Objective-C module via @compatibility_alias. That works for the Obj-C
classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor),
which import into Swift fine, but it silently breaks for the SwiftUI types,
so RCTSwiftUI-macOS fails to compile:

  RCTSwiftUIContainerView.swift:
  error: cannot find type 'RCTPlatformHostingController' in scope
  error: cannot find type 'RCTPlatformViewRepresentable' in scope
  error: cannot find type 'Context' in scope (x2)

UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI
types (a generic class and a protocol). An Objective-C @compatibility_alias
to them is not imported by Swift's Clang importer (and SwiftUI is not even
imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in
Swift. The Context errors are secondary: once RCTPlatformViewRepresentable
conformance is unknown, its associated Context type can't be resolved either.

Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit):
- Add RCTUIKitCompat.swift to the React-RCTUIKit pod, declaring
  RCTPlatformHostingController and RCTPlatformViewRepresentable as Swift
  typealiases (guarded by #if os(macOS)). The pod now compiles Swift
  (SWIFT_VERSION) and links SwiftUI, so these types are exported to any
  module that does `import React_RCTUIKit`.
- Remove the two non-functional SwiftUI @compatibility_alias entries from
  RCTUIKitCompat.h (nothing in Objective-C referenced them) and leave a note
  explaining why SwiftUI types must be declared in Swift.
- Implement RCTPlatformViewWrapper with the concrete UI/NSViewRepresentable
  requirements (makeUIView/makeNSView + updateUIView/updateNSView); the
  previous makeRCTPlatformView/updateRCTPlatformView names did not satisfy
  either protocol.

iOS behavior is unchanged (RCTPlatformHostingController -> UIHostingController,
RCTPlatformViewRepresentable -> UIViewRepresentable).

Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS
target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed.

Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR
checks on merge branch too"), so the merge-branch Build RNTester / macos job
was not yet running when microsoft#3006 landed, which is why this compile break was
not caught at merge time.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi added a commit to Saadnajmi/react-native-macos that referenced this pull request Jul 7, 2026
@Saadnajmi
fix(0.83, RCTUIKit): make SwiftUI platform aliases visible to Swift
fc73922 
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit
Objective-C module via @compatibility_alias. That works for the Obj-C
classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor),
which import into Swift fine, but it silently breaks for the SwiftUI types,
so RCTSwiftUI-macOS fails to compile:

  RCTSwiftUIContainerView.swift:
  error: cannot find type 'RCTPlatformHostingController' in scope
  error: cannot find type 'RCTPlatformViewRepresentable' in scope
  error: cannot find type 'Context' in scope (x2)

UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI
types (a generic class and a protocol). An Objective-C @compatibility_alias
to them is not imported by Swift's Clang importer (and SwiftUI is not even
imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in
Swift. The Context errors are secondary: once RCTPlatformViewRepresentable
conformance is unknown, its associated Context type can't be resolved either.

Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit):
- Add RCTUIKitCompat.swift to the React-RCTUIKit pod, declaring
  RCTPlatformHostingController and RCTPlatformViewRepresentable as Swift
  typealiases (guarded by #if os(macOS)). The pod now compiles Swift
  (SWIFT_VERSION) and links SwiftUI, so these types are exported to any
  module that does `import React_RCTUIKit`.
- Remove the two non-functional SwiftUI @compatibility_alias entries from
  RCTUIKitCompat.h (nothing in Objective-C referenced them) and leave a note
  explaining why SwiftUI types must be declared in Swift.
- Implement RCTPlatformViewWrapper with the concrete UI/NSViewRepresentable
  requirements (makeUIView/makeNSView + updateUIView/updateNSView); the
  previous makeRCTPlatformView/updateRCTPlatformView names did not satisfy
  either protocol.

iOS behavior is unchanged (RCTPlatformHostingController -> UIHostingController,
RCTPlatformViewRepresentable -> UIViewRepresentable).

Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS
target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed.

Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR
checks on merge branch too"), so the merge-branch Build RNTester / macos job
was not yet running when microsoft#3006 landed, which is why this compile break was
not caught at merge time.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi added a commit to Saadnajmi/react-native-macos that referenced this pull request Jul 7, 2026
@Saadnajmi
fix(0.83, rctuikit): make SwiftUI platform aliases visible to Swift
0bdcf00 
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit
Objective-C module via @compatibility_alias. That works for the Obj-C
classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor),
which import into Swift fine, but it silently breaks for the SwiftUI types,
so RCTSwiftUI-macOS fails to compile:

  RCTSwiftUIContainerView.swift:
  error: cannot find type 'RCTPlatformHostingController' in scope
  error: cannot find type 'RCTPlatformViewRepresentable' in scope
  error: cannot find type 'Context' in scope (x2)

UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI
types (a generic class and a protocol). An Objective-C @compatibility_alias
to them is not imported by Swift's Clang importer (and SwiftUI is not even
imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in
Swift. The Context errors are secondary: once RCTPlatformViewRepresentable
conformance is unknown, its associated Context type can't be resolved either.

Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit):
- Add RCTUIKitCompat.swift to the React-RCTUIKit pod, which now compiles Swift
  (SWIFT_VERSION) and links SwiftUI so the types are exported to any module
  that does `import React_RCTUIKit`. It declares:
    - RCTPlatformHostingController: a Swift typealias to UI/NSHostingController.
    - RCTPlatformViewRepresentable: a protocol refining UI/NSViewRepresentable
      that bridges the platform requirements (makeUIView/makeNSView, etc.) to a
      unified makeRCTPlatformView/updateRCTPlatformView. A plain typealias can't
      work here because the two base protocols use different method names, so a
      conformer named makeRCTPlatformView would satisfy neither.
- Remove the two non-functional SwiftUI @compatibility_alias entries from
  RCTUIKitCompat.h (nothing in Objective-C referenced them).
- RCTPlatformViewWrapper now conforms to RCTPlatformViewRepresentable with the
  unified makeRCTPlatformView/updateRCTPlatformView, so the consumer no longer
  needs a per-platform #if.

iOS behavior is unchanged.

Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS
target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed.

Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR
checks on merge branch too"), so the merge-branch Build RNTester / macos job
was not yet running when microsoft#3006 landed, which is why this compile break was
not caught at merge time.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi added a commit to Saadnajmi/react-native-macos that referenced this pull request Jul 7, 2026
@Saadnajmi
fix(0.83, rctuikit): make SwiftUI platform aliases visible to Swift
457ac69 
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit
Objective-C module via @compatibility_alias. That works for the Obj-C
classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor),
which import into Swift fine, but it silently breaks for the SwiftUI types,
so RCTSwiftUI-macOS fails to compile:

  RCTSwiftUIContainerView.swift:
  error: cannot find type 'RCTPlatformHostingController' in scope
  error: cannot find type 'RCTPlatformViewRepresentable' in scope
  error: cannot find type 'Context' in scope (x2)

UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI
types (a generic class and a protocol). An Objective-C @compatibility_alias
to them is not imported by Swift's Clang importer (and SwiftUI is not even
imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in
Swift. The Context errors are secondary: once RCTPlatformViewRepresentable
conformance is unknown, its associated Context type can't be resolved either.

Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit):
- Add RCTUIKitCompat.swift to the React-RCTUIKit pod, which now compiles Swift
  (SWIFT_VERSION) and links SwiftUI so the types are exported to any module
  that does `import React_RCTUIKit`. It declares:
    - RCTPlatformHostingController: a Swift typealias to UI/NSHostingController.
    - RCTPlatformViewRepresentable: a protocol refining UI/NSViewRepresentable
      that bridges the platform requirements (makeUIView/makeNSView, etc.) to a
      unified makeRCTPlatformView/updateRCTPlatformView. A plain typealias can't
      work here because the two base protocols use different method names, so a
      conformer named makeRCTPlatformView would satisfy neither.
- Remove the two non-functional SwiftUI @compatibility_alias entries from
  RCTUIKitCompat.h (nothing in Objective-C referenced them).
- RCTPlatformViewWrapper now conforms to RCTPlatformViewRepresentable with the
  unified makeRCTPlatformView/updateRCTPlatformView, so the consumer no longer
  needs a per-platform #if.

iOS behavior is unchanged.

Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS
target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed.

Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR
checks on merge branch too"), so the merge-branch Build RNTester / macos job
was not yet running when microsoft#3006 landed, which is why this compile break was
not caught at merge time.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi added a commit to Saadnajmi/react-native-macos that referenced this pull request Jul 7, 2026
@Saadnajmi
fix(0.83, rctuikit): make SwiftUI platform aliases visible to Swift
24a353d 
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit
Objective-C module via @compatibility_alias. That works for the Obj-C
classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor),
which import into Swift fine, but it silently breaks for the SwiftUI types,
so RCTSwiftUI-macOS fails to compile:

  RCTSwiftUIContainerView.swift:
  error: cannot find type 'RCTPlatformHostingController' in scope
  error: cannot find type 'RCTPlatformViewRepresentable' in scope
  error: cannot find type 'Context' in scope (x2)

UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI
types (a generic class and a protocol). An Objective-C @compatibility_alias
to them is not imported by Swift's Clang importer (and SwiftUI is not even
imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in
Swift. The Context errors are secondary: once RCTPlatformViewRepresentable
conformance is unknown, its associated Context type can't be resolved either.

Fix:
- Remove the two non-functional SwiftUI @compatibility_alias entries from
  RCTUIKitCompat.h (nothing in Objective-C referenced them).
- Define RCTPlatformHostingController (a typealias to UI/NSHostingController)
  and RCTPlatformViewRepresentable (a protocol refining UI/NSViewRepresentable
  that bridges the platform requirements to a unified makeRCTPlatformView/
  updateRCTPlatformView) in the RCTSwiftUI module that consumes them. They
  would ideally sit with the other RCTPlatform* aliases in React-RCTUIKit, but
  that module is Objective-C and SwiftPM does not support mixing Objective-C
  and Swift in one target, so they live in the consuming module for now.

iOS behavior is unchanged, and React-RCTUIKit stays Objective-C only so the
SwiftPM prebuild is unaffected.

Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS
target and a full `RNTester-macOS` app build both succeed.

Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR
checks on merge branch too"), so the merge-branch Build RNTester / macos job
was not yet running when microsoft#3006 landed, which is why this compile break was
not caught at merge time.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi added a commit to Saadnajmi/react-native-macos that referenced this pull request Jul 7, 2026
@Saadnajmi
fix(0.83, rctuikit): make SwiftUI platform aliases visible to Swift
80bc426 
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit
Objective-C module via @compatibility_alias. That works for the Obj-C
classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor),
which import into Swift fine, but it silently breaks for the SwiftUI types,
so RCTSwiftUI-macOS fails to compile:

  RCTSwiftUIContainerView.swift:
  error: cannot find type 'RCTPlatformHostingController' in scope
  error: cannot find type 'RCTPlatformViewRepresentable' in scope
  error: cannot find type 'Context' in scope (x2)

UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI
types (a generic class and a protocol). An Objective-C @compatibility_alias
to them is not imported by Swift's Clang importer (and SwiftUI is not even
imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in
Swift. The Context errors are secondary: once RCTPlatformViewRepresentable
conformance is unknown, its associated Context type can't be resolved either.

Fix:
- Remove the two non-functional SwiftUI @compatibility_alias entries from
  RCTUIKitCompat.h (nothing in Objective-C referenced them).
- Define RCTPlatformHostingController (a typealias to UI/NSHostingController)
  and RCTPlatformViewRepresentable (a protocol refining UI/NSViewRepresentable
  that bridges the platform requirements to a unified makeRCTPlatformView/
  updateRCTPlatformView) in the RCTSwiftUI module that consumes them. They
  would ideally sit with the other RCTPlatform* aliases in React-RCTUIKit, but
  that module is Objective-C and SwiftPM does not support mixing Objective-C
  and Swift in one target, so they live in the consuming module for now.

iOS behavior is unchanged, and React-RCTUIKit stays Objective-C only so the
SwiftPM prebuild is unaffected.

Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS
target and a full `RNTester-macOS` app build both succeed.

Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR
checks on merge branch too"), so the merge-branch Build RNTester / macos job
was not yet running when microsoft#3006 landed, which is why this compile break was
not caught at merge time.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi added a commit to Saadnajmi/react-native-macos that referenced this pull request Jul 7, 2026
@Saadnajmi
fix(0.83, rctuikit): make SwiftUI platform aliases visible to Swift
0b17bb6 
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit
Objective-C module via @compatibility_alias. That works for the Obj-C
classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor),
which import into Swift fine, but it silently breaks for the SwiftUI types,
so RCTSwiftUI-macOS fails to compile:

  RCTSwiftUIContainerView.swift:
  error: cannot find type 'RCTPlatformHostingController' in scope
  error: cannot find type 'RCTPlatformViewRepresentable' in scope
  error: cannot find type 'Context' in scope (x2)

UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI
types (a generic class and a protocol). An Objective-C @compatibility_alias
to them is not imported by Swift's Clang importer (and SwiftUI is not even
imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in
Swift. The Context errors are secondary: once RCTPlatformViewRepresentable
conformance is unknown, its associated Context type can't be resolved either.

Fix:
- Remove the two non-functional SwiftUI @compatibility_alias entries from
  RCTUIKitCompat.h (nothing in Objective-C referenced them).
- Define RCTPlatformHostingController (a typealias to UI/NSHostingController)
  and RCTPlatformViewRepresentable (a protocol refining UI/NSViewRepresentable
  that bridges the platform requirements to a unified makeRCTPlatformView/
  updateRCTPlatformView) in the RCTSwiftUI module that consumes them. They
  would ideally sit with the other RCTPlatform* aliases in React-RCTUIKit, but
  that module is Objective-C and SwiftPM does not support mixing Objective-C
  and Swift in one target, so they live in the consuming module for now.
- Package.swift: make the RCTSwiftUI / RCTSwiftUIWrapper SwiftPM targets depend
  on React-RCTUIKit. microsoft#3006 added that pod dependency but did not update
  Package.swift, so `import React_RCTUIKit` failed with "no such module" in the
  SwiftPM prebuild.

iOS behavior is unchanged, and React-RCTUIKit stays Objective-C only so its
SwiftPM target is not turned into an unsupported mixed-language target.

Validated locally with Xcode 26.4.1: clean builds of the RCTSwiftUI-macOS Pods
target and the full RNTester-macOS app, plus the SwiftPM prebuild
(`node scripts/ios-prebuild.js -s`/`-b -p macos`) now compiles React_RCTUIKit,
RCTSwiftUI and RCTSwiftUIWrapper without the "no such module" error.

Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR
checks on merge branch too"), so the merge-branch Build RNTester / macos job
was not yet running when microsoft#3006 landed, which is why this compile break was
not caught at merge time.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@tido64 tido64 tido64 approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Saadnajmi @tido64