From my understanding, this trick is necessary due to a circular dependency between the accessibility bridge and the delegate. The drawback is that it's now possible for the accessibility bridge to be in an invalid state. Would it be possible to avoid this circular dependency to avoid this drawback?

For example, perhaps the accessibility bridge could provide its instance when it calls the delegate's methods?

You're absolutely correct about the drawback.

There's another approach: The bridge is initialized with the viewId, fetches the view controller from the engine on demand, and passes this ID to the delegate and the nodes. However I'm really hoping to limit the knowledge of the view IDs, and instead let the bridge talk directly with assigned objects.

Another approach is to let AccessibilityBridge to be able to host multiple AXTrees, and I think that is what chromium does, too. The AXTreeData can set the id for different AXTree, and you can also derive axtree id from a AXNode. You can let the FlutterEngine to create a wrapper delegate that wires up action and event to different ViewController and view.

We can, but is it making a big difference? In the current approach, the engine will manage a map of view controllers and bridges. In your approach, the engine will manage a map of view controllers and one bridge, and the bridge will manage a map of delegates and trees (which is likely another class). So you're basically moving what's in the engine into the bridge singleton, which isn't much code (just map addition and map removal).

Actually I'm wondering, why can't we merge the delegate and the bridge? We'll still use virtual methods to allow platform-specific code, and reassign views when the view is being swapped. The engine will hold a map of bridges, and there will be no circular reference.

My original thought about the multiple AXTree in one bridge vs Multiple bridges was on how easy to use the bridge in different platforms. I am not sure how the embedding code will be like, so I will leave the decision to you.

Another approach is to let AccessibilityBridge to be able to host multiple AXTrees, and I think that is what chromium does, too.

We can, but is it making a big difference?

I think that doing the same thing that chromium does will help us in the short term. We will definitely encounter mistakes in the short term as we add this new functionality. The more help we can get, the better.

For the circular dependency part, I think I kinda prefer the other way around, let the delegate aware of the bridge later. If one of them has to be an unusable state during initializing, let the delegate be unusable would probably be better. The bridge is a public class that will be shared between embedding, it is better for it to be more stable

My initial thought was also the 2nd option, but I gave up because it's still very hard to initialize the bridge. There are two ways:

If the outside code assign the bridge to the delegate manually, it'd be hard to get the delegate since it's been moved in, and has to use a dangerous raw pointer:

void productionCode() {
  auto delegate = new FlutterPlatformNodeDelegateMac();
  // The delegate will be moved away before it can be assigned a bridge.
  auto bridge = new AccessibilityBridge(std::unique_ptr<FlutterPlatformNodeDelegateMac>(delegate));
  delegate->SetBridge(bridge);
}

Or the bridge can also assign the delegate automatically, but then the bridge needs to access its own weak_ptr in constructor, which somehow crashes (it seems that there's some restriction with shared_from_this and weak_from_this, which I'm not sure.)

AccessibilityBridge::AccessibilityBridge(std::unique_ptr<AccessibilityBridgeDelegate> delegate) {
  delegate_ = std::move(delegate);
  delegate_->SetBridge(weak_from_this()); // crashes
}

I think that doing the same thing that chromium does will help us in the short term. We will definitely encounter mistakes in the short term as we add this new functionality. The more help we can get, the better.

What kind of help and from whom are we expecting? The code is going to evolve and who other than the Flutter contributors will read our code?

I think the best kind of help is that we choose the best structure that suits us with the best maintainability and cleanest flow, instead of trying to fit our feet in others' shoes.

Or the bridge can also assign the delegate automatically, but then the bridge needs to access its own weak_ptr in constructor, which somehow crashes (it seems that there's some restriction with shared_from_this and weak_from_this, which I'm not sure.)

shared_from_this and weak_from_this requires the AccessibilityBridge to be created with shared_pointer. It should not crash though since the flutterengine in macos already holds it as shared_ptr, and it has already used shared_from_this in UpdateDelegate. Anyway, I don't think this is the right way though, not every platform's delegate needs the reference to bridge.

If the outside code assign the bridge to the delegate manually, it'd be hard to get the delegate since it's been moved in, and has to use a dangerous raw pointer

I am not sure what moved away means, can you use shared_ptr + weak_ptr? the unqiue ptr doesn't really make sense in this ownership model if multiple objects want references from it. it would also be good to draw out the ownership model, right now there seems to be a lot of moving parts, engine, bridge, delegate, viewcontroller.