I work now with Flutter full time and love it, but on my way from web Vue.js to mobile development with Flutter, I was researching different app frameworks, and I watched some videos with the main author of BeeWare/Toga, Russell Keith-Magee. The presentations are very engaging and the solution that this project came up is really something.
This is my favorite video by Russel [0], it really is a fascinating project, and he is a great speaker.
With that said, I don't really see it becoming a widely used framework. No matter how creative the solution is, it's hard to compete against real native, Kotlin Multiplatform Mobile, Flutter, React Native, Electron, and more. The most complicated example I saw with BeeWare is a todo list app [1]
But the first big problem has always been delivering an experience that looks and feels right on the target platform. Do you use the native UI or do you use something else? The swing Java UI's of the 00's were so kludgy, and looked unprofessional because they implemented their own UI components.
The other big problem is that how does the code run? Is it transpiled to javascript or does it have to download a python interpreter that can run in the browser/android? It's not a big issue for like a native app for mac/windows, but for the browser it is. https://brython.org takes ~6 seconds to run a simple clock because it's downloading the interpreter. Wasm doesn't necessarily help here, since either you compile the code to directly run on wasm, or you need to bring along the wasm compiled interpreter.
An example of this is Jython. It needed to start the JVM, then run the python code in the python interpreter in the JVM. Very inception like, though I did enjoy writing unit tests this way. Mostly because unit tests didn't need to be compiled against a jar. And broken unit tests didn't need a full recompile.
Not currently. Jetbrains has extended Google's Compose framework with a desktop and and web variant recently. However, IOS is notably not covered by these. Though you might reasonably expect them to be going there as well.
Compose desktop currently target the JVM, which of course is not going to work on IOS. They do use Skia for the UI; which is also what Google is using with Flutter, I think.
Targeting the Kotlin native compiler would be a logical next step. It's currently quite usable for porting libraries between different platforms. However, I'm guessing they would need to do a bit of work on improving the multi platform library ecosystem to be able to have enough of a base platform for developing full applications with it. Targeting IOS would be a logical next goal once they are able to do that.
You are correct. The technical details of the solutions I listed can be different, but in the end they are often competing for the same users (I need an app, which solution should I use).
I haven't looked too deeply into how BeeWare works, but why is it so uncommon to see similar solutions in other languages like Kotlin, Go, Rust etc? Basically the React Native approach but without JS. I would love to write multiplatform native UIs in any of these languages.
I have nothing against Javascript but there are still a lot of weird limitations in RN despite being several years old. Writing smooth animations that support user interaction is difficult because it is still single threaded and you are limited to a declarative animation api where the underlying native runtime does the interpolation.
React-reanimated v2 tries to solve this by spawning JS worklets that can run animation code in another thread but that comes with its own caveats. This would be so much easier to do in a language with built in threading, not to mention all these languages are very ergonomic and loved by developers so I'm curious why something similar hasn't been tried for them yet.
For the languages it boils down to availability of relevant ecosystem and developers in my experience.
Why react-native, well, because it means you have access to one of the largest ecosystems and an awesome tooling catalogue. The same applies for JS as the language of choice for App (UIs). Kotlin was also a great candidate since it could leverage the already mature Java ecosystem for android.
Flutters success is an outlier here that I would guess is due to Google backing. The resources and docs are good and you could rely on financial and developer backing. The decision to go with Dart was most likely to make themselves not dependent on another party for a core utility and to have a steering position on the overall projects course.
If, for example, Microsoft would back a good C# cross-platform framework I would bet on it at least seeing moderate adoption.
Edit: As another commenter pointed out, GO has a cross-platform GUI Framework option - Fyne [https://github.com/fyne-io/fyne]
IMO, Flutter for web only makes sense if you already have a mobile or desktop app done, and you are looking for a quick win: if your app is architected properly, adding web support for a mobile app project is really a matter of hours (or even minutes) which is amazing if you can live with the less-than-perfect UX.
Flutter on the web looks like Flash, everything feels very off, scrolling, keyboard support, text selection, etc everything just feels strange or doesn't work and it provides a poor end user experience.
Apart from the good mobile experience, I'm also excited about Flutter on desktop. It might not be "there" yet (I don't know, I am not using it in production), but it's promising and could be a good alternative to native desktop development and Electron.
Flutter for web is quite rapidly improving in all the areas you mentioned. For right now I think it's already very suitable for highly complex browser applications such as a Figma, Google sheets etc. Load times aren't the best due to a quite hefty WASM download, but for _applications_ that you typically open only a couple of times per day and where you work in for several hours, that initial loading delay really doesn't matter.
Just don't expect to use it for an E-Commerce site or something like that.
Flutter web is not fit for consumer facing products imo, it renders in a canvas so the performance will never match up to html+css+js.
I've used it to make desktop apps but there's still some rough edges but it's getting better. Definitely better than electron though.
Do you love Dart though? Flutter's stateful hot code reload is amazing but, man, for me Dart is just completely hideous. Maybe I've gotten spoiled by Typescript and Scala...
Oh, Dart is my favorite part of Flutter. It's a language that is very easy to learn and use, no surprises, it's performant (performant enough), and you can use it on web, server and as command line apps, too. The language has gotten significantly better and the Dart team focuses on the right issues to solve next.
I’m with you. Dart felt like a step back in time for me.
I was a big fan of some of the early Dart leaders (Lars Bak and Gilda Bracha). I remember when I asked why Dart seemed like a watered down variant of some Lars and Gilads earlier work; I was tiled by a former colleague that had joined the project that “Lars was playing it safer, playing to win” these days.
I don’t know how much either of these people are associated with Dart anymore. Somewhere in Dart’s search of a killer problem to be the solution for, we got fully typed Dart (as opposed to the original annotations are optional mindset).
I did one of the free web courses for it, built like 10 teeny pointless apps. Three things stood out:
- the experience was kind of painful on iOS, the look had an “uncanny” effect
- the tutor tried to explain classes as a “way of organizing code” which undersells what classes are really about (binding behavior to data)
- the language felt like an alter Java (type declarations in the left side still??)
> From its probable beginnings as a simple, practical work-garment, the toga became more voluminous, complex, and costly, increasingly unsuited to anything but formal and ceremonial use. It was and is considered ancient Rome's "national costume"; as such, it had great symbolic value; however even among Romans, it was hard to put on, uncomfortable and challenging to wear correctly, and never truly popular. When circumstances allowed, those otherwise entitled or obliged to wear it opted for more comfortable, casual garments.
> ... the toga's bulk and complex drapery made it entirely impractical for manual work or physically active leisure. The toga was heavy, "unwieldy, excessively hot, easily stained, and hard to launder".[39] It was best suited to stately processions, public debate and oratory, sitting in the theatre or circus, and displaying oneself before one's peers and inferiors while "ostentatiously doing nothing".[
The BeeWare system is incredible and so close to really taking off. What I feel it needs if a proper corporate sponsor, an organisation that will embrace it itself for its own products and invest back into the project. It’s the best chance of Python on mobile we have.
I always thought Kivy was the best chance of python on mobile. I was able to get a python android app working around a decade ago. Nothing special, only installed locally just to see if i could do it. But it was working back then, and it's still under development.
Looks well and cool, but the enterprise "pricing" seems a little... optimistic.
> $5000/month
> An annual meeting with core team
I understand that these are technically "donations" but the incentives offered are very much just a lightweight support agreement for 2-10x the price.
I have no reason to believe that a python based UI solution that finally captures some market share could be a big success, and are that point the pseudo donation model would go out the window. Best of luck to these guys, would be cool to not be forced to use TKinter in school assignments.
That is absolutely insane. What exactly do you get for $60,000 a year?
I could hire a contractor to build out all the UI in whatever framework I want. Plus I avoid paying someone to build it + pay for the framework.
BTW, I've used QT4 in the past with python and it was an absolutely dream to work with. In 2 months part time work, I was able to produce a very high quality app that worked on windows, linux, macos. Highly recommend instead of TK.
Have you used wxPython at all by chance? Curious how it compares in developer experience compared to PyQt/PySide. I like that it uses native widgets, but if Qt is that much easier to deal with I may just go that direction.
I actually looked into wxPython, admittedly only for a day or two to get the general idea behind it. It seemed complicated and not very mature at the time from my experience under linux (circa 2019 I want to say?)
But after spending the same amount of time with QT it definitely won out.
I'd gone down the rabbithole the last few days of whether to use kivy or beeware for a personal powerlifting app I'm building as side project / learning experience. I'd gone as far as settling on Kivy and installing the dependencies (which took an extra few hours until I learned only python <= 3.8 is used), and now this pops up here and I'm reconsidering everything... again. On paper Beeware sounds perfect for my needs, but the limited community support has me timid to try.
I wrote a few small Android apps using Kivy, and I ran into some problems with performance with scrolling lists of buttons. Doing it the most obvious, natural way led to obvious poor performance — a list of more than a dozen or so buttons simply could not be scrolled without accidentally clicking on one. There was a recommended workaround, which I found and used, and its performance was slightly less obviously bad — it showed up with dozens of bad reviews from users of slightly outdated devices. The last I looked, Kivy had not progressed on that issue. I didn't continue to use it, and don't know if it has other similar problems, but it was a discouraging experience for me.
I made a Kivy/KivyMD mobile app as a part of my diploma project like a year ago, and I surely wanted it to be a cool little learning experience, too. It was a disaster!
I mean, the KV language is pretty neat, but the insane amount of tooling involved (that always, always fails) to actually open your app on your phone is disgusting. Disgusting as in using three different versions of Python, setting up mismatching Android tooling, cross-compiling wheels on your virtual machine only for it to fail with some cryptic GCC error disgusting. It's also pretty outdated (e.g. camera doesn't work properly with the last ~5 Android APIs), and of course very slow, even if you pre-optimize your code with pagination and stuff.
Kinda regret using Kivy at all, despite its community being amazing. So, can't recommend. Perhaps, you could consider learning Flutter instead? It will take just about the same time investment, but the whole experience is incomparable. Even better, make a test app in Kivy, and then make one in Flutter. (This is only partly a joke, though. It's really that fun.)
Both BeeWare and Kivy are great projects adressing a space that could surely produce some very interesting applications. Offering seamless integration of the versatile python stack on mobile devices would be a game changer as far as I am concerned, turning the mobile more into a computing device as opposed to merely facilitating the fastest click to the cloud.
They seem under-resourced, though, especially BeeWare. Targeting platforms that do not support python natively feels like a task that would challenge even much larger teams
Does this have support for installing and linking to useful native utilities, like GraphicsMagick? Python is such a good glue. Sometimes I want to make a small GUI that combines great python libraries with great CLI applications.
"On desktop platforms (macOS, Windows, Linux), any pip-installable can be added to your requirements. On mobile platforms, your options are a little more limited - you can only use pure Python packages i.e., packages that do not contain a binary module.
This means that libraries like numpy, scikit-learn, or cryptography can be used in a desktop app, but not a mobile app. This is primarily because mobile apps require binary modules that are compiled for multiple platforms, which is difficult to set up.
It’s possible to build a mobile Python app that uses binary modules, but it’s not easy to set up – well outside the scope of an introductory tutorial like this one."
This was actually a dealbreaker and blocker for me when I last time tried BeeWare. I was hoping I will be able to do some rapid prototyping with numpy + opencv-python directly on my android or iphone. I wish there was at least some tutorial how to make non-pure python modules.
I had the same issue when investigating Kivy and PyQt. It definitely seems possible since you can download Pydroid [1] for android (that supports e.g. pyqt, opencv, tensorflow) or Pyto [2] for iOS (that seems actually is based on BeeWare and support many non-pure modules including opencv)
I've tried using Briefcase before, and I completely gave up. The goal was to get a cross-platform Qt app compiled down to a single executable, but I couldn't even get it to run on the machine it was compiled on, much less a windows machine without Python installed.
Am I an outlier, or is it this difficult to get working at first? I imagine that once you get a working build, it must work quite smoothly!
I've used Python, Qt and BeeWare to develop an interactive tool to analyse compressed video. It's fast enough that I don't know it's not a native app. You can make some very complex applications if you learn to take advantage Qt's features.
I start with a release of WinPython, then use its command line to make a virtual environment, install `briefcase` and go from there.
I haven't used this framework, but this has been my experience with pretty much all UI frameworks and especially with Python ones. Even the demo projects are often a pain to package and starting from scratch means hours of reading docs and changing parameters almost at random to see what happens.
Windows is the absolute worst for packaging Python (unless you give up and package everything in a self-extracting exe, but then antivirus is even more likely to eat it) and Android barely runs native Qt (seriously, the demo project from their website straight up doesn't build), so I can imagine that running something with 4 layers of stuff in between would have even worse odds of working.
At Djangocon 2016 I contributed a bug fix and Russel gave me a Yakshaver coin, I thought that was a neat way to get people involved. I was going to do more, but my boss called and made me leave early.
BeeWare looks great, as always, but my impression is that the documentation/ecosystem isn't very extensive, so I've always been loath to try it. In such an extensive toolkit, I think ecosystem/community is important, as otherwise you'll be hitting walls frequently that will be hard to get past.
Targeting windows is really interesting actually - Microsoft has made such as a hash of the development story on Windows I'm surprised more folks haven't made a run at that market. In my case, I like rich local app -> remote data store.
Does anyone know how well this performs on windows.
If you know how to take advantage of Qt, then you can make real-time video player, a real-time interactive graph or whatever else you can build with Qt's framework, then deploy it to Windows, Mac or Linux as if it were a native app.
I could never figure out what in QT you had to pay for when. That seems to have improved recently, looks like $3,600 per year to develop an app with QT.
Still a bit pricey to just play around with building something I think for someone small? But at least it's simpler, I could see buying something now - before it was impossible.
I never really got into QML (javascript type language). I'm not sure QT creator let's you form build with python? Downloading it is an evaluation thing as I look at it.
Are you suggesting not using BeeWare and using Qt instead? I only want to target Windows and macOS (I'm ignoring mobile.) For web I'm stuck in my ways and just go with Golang + server-side rendering (a bit of JS to make forms nicer.)
BeeWare and Qt are on different levels. It's like comparing a single guy on a scooter, doing a few deliveries on weekends, with FedEx. If you don't care about mobile, and you can deal with the licensing model of Qt and its wrappers, the choice is fairly obvious. Also, a lot of the knowledge around Qt is not really Python-specific, it's transferable to C++ (or the other bindings they have).
I like the guys behind BeeWare and they've done some very good work to address the awful Python story on mobile, but every time I try BeeWare it lacks a lot of functionality one would expect from production-ready toolkits. I'm sure things will improve with time, but I have a feeling someone with deeper pockets will eventually eat their lunch.
It is fair what other commenters have said about Qt being larger and used more production. However it is a pain - from licensing and code/technology point of view.
If you enjoy Go and/or like maintainable GUI code then Fyne is basically designed for you. The team is ambitious and always developing more features, plus there is now commercial support behind the project at https://fynelabs.com.
What if instead of trying to make standalone programs that run everywhere someone took the approach the browser took, but more on the native side?
Make a runtime that can run a bunch of quasi-native code and make it download code from URLs and execute that.
The experience for the user would be to type "myapp.com" on the URL bar and then get a full native app running inside that browser window -- except instead of bloated JavaScript it would be this new language thing with more powerful native-like APIs and without 32 years of bloated history on its back.
3.3.2 An Application may not download or install executable code.
Interpreted code may only be used in an Application if all scripts, code
and interpreters are packaged in the Application and not downloaded
You would have to ship a new copy of it with each application.
There is Pythonista 3 for iOS which allows you to deploy code that is not shipped with the app e.g., it can be used to implement "download audio" button for youtube for iphone (and other supported by youtube-dl video sites)
Apple won't allow that. The only interpreted code is JS and must run on the built-in engine. Plus "dynamically added" code/content must first be approved by Apple or your app can be revoked.
Basically there is no shortcut here. Which is why the OP and others like Fyne (https://fyne.io) are taking the approach of write once, compile for anywhere.
Can people comment here on how powerful they believe Python is vs. something like Javascript/Typescript. The later have their flaws but do really well for UI development. Is there truly an inherent advantage in Python? Are some people inherently keen on the language?
The language specifics are mostly a subjective judgement, but if you can get Python into the same niches as Typescript, then the ecosystem can payoff tenfold.
The number of convoluted JavaScript "data" apps that I've replaced with python and just a dash of Pandas is too high.
Agreed, but this is where Python shines and I don't think it's because of anything to do with Python other than that's where the critical mass of data support lies.
I mean, it's somewhat more suited to data crunching ...
I wonder if the significant increase of Python users lends well to it being also usable as a UI tech with the advantage merely being familiarity, consolidation of tech (i.e. 'we only use Python in house, no need for JS' etc..
Python is a great language. Really nice to work with, if you don’t mind the premise (no static safety etc). It’s not really focused on UI though; packages exist but are kind of niche, I’d say. Not exotic: you have wrappers for Tkinter, Qt, WxWidgets etc. But most people writing serious native GUI apps avoid Python. I’ve always found Python GUIs slow and clunky.
Web is different for many reasons and there Python does well.
Server hardware is generally not user facing (well, everything is "user" facing considering who the "user" is, maybe better to say "end-user facing") and has interfaces, both hardware and software usually, on one or another level.
Yes, anything that sits between a human and the inner-workings of a computer is a user-interface. That power-button on the panel of the server hardware? That's a user-interface.
I'm still a fan of this concept, but I think you have to keep your expectations realistic. You are likely going to have to make some platform specific considerations, just a lot less than without an abstraction technology. Generally, I've found this manageable, but it can be hard to pull off well for sure. Some have succeeded rather well I think (Java comes to mind).
Native GUI frameworks can be more of a challenge. Still, if you want a native L&F your alternative is to code each platform individually, then something like this (or wxWidgets/SWT/etc.) is likely to be a lot less work (but likely to look a bit less native). Trade offs. Good to have choices I think.
It's not worth taking seriously for app development where you gain advantages from the native experience. This rules it out as a primary app development platform for the majority of developers.
It's very strong for the many "good enough" scenarios that range from complete products in domains like pharma where users will tolerate user experience glitches as long as they can be using the same Pandas code behind the scenes on multiple OSes, or utility-level apps that need to run on multiple platforms. These are often tucked away in places that HN readers are averse to exploring from a career perspective.
It never works well because the platforms are not simply the same thing by different companies but they all have their concurrent ideas, conventions and differences.
The toolset for "Write once. Deploy everywhere." that works is HTML + JS + CSS and nothing else. This is because browsers work about the same everywhere.
IMHO if an app is not going to leverage the platform but will simply show some UI to display or collect data, the way to do it is HTML + JS + CSS in the browser.
When you try to support platform specific features, you end up doing much more work but instead of working on the primary App, you spend you time on integration and replication of platform behaviour or functions.
There are two major types of application: one where users play role of "reader" and second type is where user is "writer" - creator of some data, document, etc.
> that works is HTML + JS + CSS and nothing else.
That type of UI mostly works for "reader" applications - when maximum what you do is clicking on buttons and filling couple of <input>s.
For "creator"'s applications, CADs, editors, IDEs, and so on, HTML + JS + CSS is far from being perfect. At least without special means that extend these technologies to acceptable level.
Menu shall be menu but not that position:absolute something, dialog shall be modal window, drawing shall support immediate mode, keyboard interaction shall be there, and so forth.
My App definition was a bit too narrow maybe, games too tend to be multi platform.
I think that’s possible when the App and user interaction model is completely custom - like shooting zombies or drawing 3D shapes.
That's also party why browsers can't replace every app(the browsers have it's own opinion about the UI and interactions), the other reasons are performance and access limitations.
"write once, deploy everywhere [you've got the same kind of hardware or machine available so that the code will work without recompilation and won't look too out of place]" just doesn't have the same ring to it...
I just don't understand why you'd choose something as slow as Python for this. Not sure how it could compete with React Native which seems like the closest equivalent, but in a much faster and better language.
If you want to make a quick shift from writing command line apps to writing GUI apps then you are the target for this. If you need to be writing high value mobile or desktop apps then this is a less of a compelling option as you note.
There are a lot of very high quality libraries like Pandas and SciPy that are not available in the React Native ecosystem. Tools like those provided by BeeWare let you add a GUI quickly. The folks interested in interacting with something running on these data science libraries tolerate imperfect user experiences more than the average consumer.
If we looked at React Native we could level your argument at it as well. Why use RN when you could build real native apps? Surely, that's the most optimal experience over a third-party platform, no matter how good RN is in practice.
Can they go and do it somewhere else? I don’t need another ugly and power draining app in my iphone that I might forced to use. I wish apple forbid to use in store all these inferior interpreted languages with huge over-bloat like csharp, python, java, ruby. They are fine a tool for heating the earth and get corp to purchase even more servers for CRUD, but not to use in a battery powered device.
Python is one of, if not the, easiest languages to learn and use. I feel that's why it took off in science related fields - non CS people can jump in and be productive quickly.
Seeing as this is for GUIs and not say, computing digits of Pi, I think Python is a fantastic choice for this.
I honestly wish Python had taken off as the web language instead of JS, but that's a conversation for another time.
FWIW, I'm not a Python fanatic or anything, I haven't used it in years - but it's hard to argue it's not a great language for beginners.
Yes, Python seems simpler in some aspects, but it does lack the ball-of-clay flexibility of JS, and Python feature-set seem rather conservative speaking in the 2020s (Its standard library data structures abounds in a very mutable api, for example).
Javascript is also average. But Typescript is definitely an above-average language. Much better than Python, especially when you consider the insane performance compared to Python and the fact that it can run in the web.
Typescript tries to fix a lot of the problems JS has, but still inherits a lot of its problems.
> especially when you consider the insane performance compared to Python
In my experience, people who complain about Python’s performance don’t actually have experience with software optimization. Aka, the same people who decide to use C++ “because fast”.
Even if you only look at synthetic benchmarks, there is not a single thing that would make javascript stand out as a good choice for high performance computing, V8 or not. But even if you find yourself in a situation where you’re stuck with javascript and have to optimize a particularly nasty hot path, the types of techniques you’d need to rely on aren’t going to be all that different than what you’d have to do with Python (with similar results).
The difference is that the Python environment can almost always outsource processing to a C library (maybe even hand written assembly). That’s really only possible with typescript if you’re working with Node, but I don’t think that’s what you’re referring to considering the context of this thread.
> and the fact that it can run in the web.
AKA, the only reason to use Javascript pre-Node. Post Node, you get to share code throughout your whole stack, but even then that’s rarely the best objective choice, and the benfits of using a single language tend to be overblown in my experience. For example, an Elixir/Erlang backend would be overwhelmingly more beneficial to any project than the minor conveniences of a single language (and I think Erlang is even slower than Python)
When/if web assmebly becomes more popular, I think JS/TS will finally die because web developers will finally be exposed to good languages, and will not want to go back to the mess that JS is/was.
SixtyFPS (https://sixtyfps.io/) is in progress for Rust, but it is still early days. It also does not technically use a native toolkit (it uses Qt), but I believe that might be on roadmap. For traditional GUI apps, I think the lack of a table or tree widget is the most limiting for the time being. They have stated they intend to remedy that.
I should also add that it is GPL - with all that implies. They also have commercial licenses.
I agree with this, and yet, I love these new languages (esp. Rust) so I'd hate to halt progress.
Instead, what I think we need is a solid cross platform native UI library targeting C (libui would be a candidate - before it lost momentum). It would then be a reasonable amount of work to create multi-language bindings. Instead we have things like wxWidgets/Qt that are a pain to create bindings for since it is written in C++. As proof this would accelerate things, notice how many languages have GTK bindings (C based).
That would be great too. I haven't gotten around to learning any ML-style languages but it looks very nice. I know MAUI is supposedly in the works for .NET but I'm not sure how it will ultimately turn out compared to Flutter or RN. But if it gets close to its ambitious goals I would definitely give it a try.
Trying to use Python on the web or mobile is a lost cause. Use JS/TS or wasm generated from rust, that’s what is was built for. I regret spending time writing backend web frameworks in Python too. Most backends you’d hack together with Python can be built with TS and save you the headache of using PyPI along with npm, as well as rewriting your types, logic, and algorithms in multiple languages.
Plus there are actual companies putting continued investment into V8 and react native, since their revenue depends on it. Python is a liability when it’s used in anything other than developer tooling.
Everything in Python feels like it was made by some passionate oss devevelopers. Cool stuff, but not sustainable or ergonomic. The type system is kludgier than typescript’s and not as strong as rust’s. Python’s async APIs are embarrassing compared to JavaScript’s.
Sadly this feels like one of those projects that should have been abandoned or pivoted before sinking so much energy into it.
I love Python and still use it all the time. But for anything UI related I stay away.
This is my favorite video by Russel [0], it really is a fascinating project, and he is a great speaker.
With that said, I don't really see it becoming a widely used framework. No matter how creative the solution is, it's hard to compete against real native, Kotlin Multiplatform Mobile, Flutter, React Native, Electron, and more. The most complicated example I saw with BeeWare is a todo list app [1]
[0] https://www.youtube.com/watch?v=qaPzlIJ57dk [1] https://www.youtube.com/watch?v=RisCgSIWwLA