# Real cross-platform linking Flutter UI with JUCE as a fastest OpenGL renderer. Does anyone have an experienced in it? **URL:** \ **Category:** Development\ **Created:** [November 26, 2025, 10:55am UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683 "2025-11-26T10:55:05Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![ave](https://avatars.discourse-cdn.com/v4/letter/a/e47c2d/32.png) [@ave](https://forum.juce.com/u/ave)\ **Post date:** [November 26, 2025, 10:55am UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683/1 "2025-11-26T10:55:05Z")
Greetings to the JUCE community. Does anyone have experience in linking Flutter as an UI layer and JUCE framework as a cross-platform OpenGL renderer? Real cross-platform is interesting, both mobile development and desktop implementations for various OS platforms. I will be glad to receive any links to projects, examples or articles, or any feedback. With best wishes. ---
**Author:** ![ave](https://avatars.discourse-cdn.com/v4/letter/a/e47c2d/32.png) [@ave](https://forum.juce.com/u/ave)\ **Post date:** [November 27, 2025, 11:42am UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683/2 "2025-11-27T11:42:31Z")
**I apologize to the community for my amateurish question.** If someone knows the reasons why it is not possible to do this now, please tell me what the pitfalls are. ---
**Author:** ![JeffMcClintock](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jeffmcclintock/32/21430_2.png) [@JeffMcClintock](https://forum.juce.com/u/JeffMcClintock)\ **Post date:** [November 28, 2025, 4:10am UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683/3 "2025-11-28T04:10:46Z")
it’s a reasonable question. But the answer is not so great. ”The thing being requested here—being able to load an arbitrary number of _different_ copies of Flutter into an iOS or macOS application—is fundamentally unworkable” > > > \## Use case > > I'm exploring using Flutter in a DAW plugin, VST and AudioUnit. A… Host like Ableton Live running a plugin is a different environment than a standalone desktop application. In this context, two plugins both using Flutter collide. The first App.framework to be linked is the one that plugin instance will load. This means that loading Plugin B, will actually launch the flutter application for Plugin A. > > I'm currently using JUCE, which is a convenient way to build a plugin. The JUCE window creates an NSView, and I add the FlutterViewController to it, embedding the App.framework and the FlutterMacOS.framework into the plugin bundle. I've attached an example with two flutter Hello Word apps embedded into a JUCE plugin. One uses the standard blue theme while the other uses red. > > \### Example Videos > Two plugins colliding: > > https://user-images.githubusercontent.com/246982/169207486-35296119-6d3b-490b-a7c9-c86a81a9ea56.mov > > One red plugin loads correctly: > > https://user-images.githubusercontent.com/246982/169207735-291979b8-b0ba-48ab-85d5-51dc2e7290e3.mov > > \### Example Source Code > JUCE/Flutter example projects with included README: > > https://www.dropbox.com/s/juib7oqnsyzu2qd/FlutterDAWPluginExample.zip?dl=0 > > \## Proposal > > I believe the above issue could be resolved if we could optionally add a naming prefix to all of the generated frameworks including plugin packages. > > App.framework and FlutterMacOS.framework would become MySpecialNameApp.framework and MySpecialNameFlutterMacOS.framework. Flutter would have to be told to link these frameworks instead. > > Not just the framework packages would have to be renamed, but all the files needed to keep the symbols from colliding. > > If we only do this for App.framework to solve the described issue, there would still be collisions with mismatched versions of the FlutterMacOS.framework as well as commonly used flutter plugin packages. That's why I believe it should be done for all the embedded frameworks. > > I'm very open to alternative solutions that may solve this issue. > > Thank you for your consideration, > Hayden Bursk ---
**Author:** ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)\ **Post date:** [November 28, 2025, 10:57am UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683/4 "2025-11-28T10:57:59Z")
OOI, why do you need to use JUCE for OpenGL? Couldn’t you just use the OpenGL API directly? It’s already inherently cross-platform. ---
**Author:** ![ave](https://avatars.discourse-cdn.com/v4/letter/a/e47c2d/32.png) [@ave](https://forum.juce.com/u/ave)\ **Post date:** [November 28, 2025, 2:25pm UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683/5 "2025-11-28T14:25:16Z")
Thank you for your reply. I have carefully studied the specified forum thread [#104144](https://github.com/flutter/flutter/issues/104144). My task is a bit different. Development for Windows, Linux and Android platforms. The intended usage pattern of Flutter User Interface + JUCE OpenGL backend. The user interface, including menus and buttons on Flutter, and on JUCE C/C++ and OpenGL, all background rendering, multithreading, interaction with various interfaces, and receiving commands from the Flutter UI. ---
**Author:** ![ave](https://avatars.discourse-cdn.com/v4/letter/a/e47c2d/32.png) [@ave](https://forum.juce.com/u/ave)\ **Post date:** [November 28, 2025, 2:34pm UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683/6 "2025-11-28T14:34:09Z")
> [@ImJimmi](#): > > OOI, why do you need to use JUCE for OpenGL? Couldn’t you just use the OpenGL API directly? It’s already inherently cross-platform. The functionality of the backend of the application being developed is far from limited to the use of OpenGL. Implementing and maintaining all cross-platform functionality in the future will become an overwhelming distraction from the development of useful functionality and application development. Therefore, it was decided to search for a cross-platform framework written in C++, preferably open source, and a bunch of other search options. JUCE doesn’t have many competitors here, and JUCE is perfect for most parameters. ---
**Author:** ![ave](https://avatars.discourse-cdn.com/v4/letter/a/e47c2d/32.png) [@ave](https://forum.juce.com/u/ave)\ **Post date:** [November 28, 2025, 2:42pm UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683/7 "2025-11-28T14:42:45Z")
My starting point is a project that I managed to build for one of the target platforms, Android. I’m working on this project to try to put together my own example [github/flutter\_jucer](https://github.com/andresbrocco/flutter_jucer). In parallel, I’m reading Flutter/Flutter Embedder/Flutter Linux Embedder. If anyone has seen similar projects where Flutter is used as a User Interface for the target Linux platform, please share the information. ---
**Author:** ![lucianoiam](https://avatars.discourse-cdn.com/v4/letter/l/aeb1de/32.png) [@lucianoiam](https://forum.juce.com/u/lucianoiam)\ **Post date:** [November 29, 2025, 9:48am UTC](https://forum.juce.com/t/real-cross-platform-linking-flutter-ui-with-juce-as-a-fastest-opengl-renderer-does-anyone-have-an-experienced-in-it/67683/8 "2025-11-29T09:48:45Z")
An ideal solution could be a generic JUCE module enabling cross-process embedding of a native view. The plugin process (A) would forward all input to the child process (B), which would render onto a shared GPU surface displayed in A. This is technically possible (Chromium?), but a substantial engineering effort. Such an approach would make it possible to embed Flutter, or actually any UI toolkit not originally designed for plugin environments. This is a simplified analysis, and there are likely additional complexities to solve. However, it potentially scales beyond a single toolkit and therefore involve multiple contributors. Finally, there would need to be RPC for the application logic itself, which is comparatively straightforward and likely similar to what I expect the JUCE web view component implements (I haven’t used it yet).