As Python developers, we're incredibly lucky to have over half a million packages that we can choose to build our applications from over at PyPI. However, when it comes to choosing a UI framework, the options get narrowed down very quickly. Intersect those choices with the ones that work on mobile, and you have a very short list. Flutter is a UI framework for building desktop and mobile applications, and is in fact the one that we use to build the Talk Python courses app, which you'll find at talkpython.fm/apps. That's why I'm so excited about Flet. Flet is a Python UI framework that is distributed and executed on the Flutter framework, making it possible to build mobile apps and desktop apps with Python. We have Fedor Fitzner back on the show after he launched his project a couple of years ago to give us an update on how close they are to a full featured mobile app framework in Python. This is Talk Python to Me, Episode 491 recorded December 17th, 2024.
- Are you ready for your host, please?
- You're listening to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
- Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython, both accounts over at fosstodon.org.
And keep up with the show and listen to over nine years of episodes at talkpython.fm.
If you want to be part of our live episodes, you can find the live streams over on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming shows.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/posit.
P-O-S-I-T.
And it's also brought to you by us over at Talk Python Training.
Did you know that we have over 250 hours of Python courses?
Yeah, that's right.
Check them out at talkpython.fm/courses.
Flash courses.
Peter, welcome back to Talk Python to Me.
Awesome to have you here.
>> I'm Michael, fellow Python developers.
>> Yeah, it's real good to have you here.
I know that there was a lot of excitement about Flutter.
In fact, I got a message just a couple of weeks ago from somebody saying, "Is Flutter what you use to write your mobile apps?" And I'm like, "No, because that was a while ago." And I kind of wish that was an option, but it wasn't an option for us at the time.
Anyway, I think Flutter is going strong.
I think there's a lot of excitement around it.
And certainly there's an excitement for building mobile applications in Python.
Yeah.
Flutter is getting stronger and stronger.
You know, like recently I saw there was an attempt to fork Flutter, you know, because like it was a feeling in the community that it's not moving anywhere.
You know, but I don't believe that even that guy mentioned that there are like 50 developers working on Flutter right now at Google.
So yeah, Flutter is getting better and better and their release cycle is pretty awesome, you know?
Sometimes it's really hard to catch up, but still, yeah.
- That can actually be a problem.
I just updated Flutter on my Mac mini.
I had out of date CocoaPods and Ruby and there's a whole tool chain that people need to know about.
Maybe we can talk a little bit about the tool chain, but yeah, you're constantly chasing versions and releases and updates.
You've got Android Studio versions.
You've got Xcode.
There's a lot there.
We recently started using Flutter version manager FBM and it's pretty good.
Yeah, because the updating is so fast, you know, it's really hard to catch up.
This portion of Talk Python to Me is brought to you by the folks at Posit.
Posit has made a huge investment in the Python community lately.
Known originally for RStudio, they've been building out a suite of tools and services for team Python.
Today, I want to focus on hosting your Python-based data science workloads.
This includes dashboards, reports, plots, interactive web apps, all the way to custom Flask and Django apps.
Their service is Posit Connect.
Posit Connect makes it easy for data scientists to share work built with Python code.
If you have a Streamlit app, Dash, dashboard, Plotly, interactive plot, a FastAPI service, or even a Quarto report, just give Posit Connect the code it needs to maintain the asset and Connect automatically does the rest.
Connect will manage your APIs and serve your interactive apps for you.
And if you want, you can update your reports and dashboards on a scheduled basis.
That's right, no need to explain to the stakeholders why that dashboard or plot stopped updating last week.
You get to focus on your data science and leveraging your skillset while Connect makes you look good, keeping your code running and private.
With Connect, you get a private URL on your Connect server, ensuring that your asset is continuously available to your shareholders.
And you can control which users have access to the asset.
Let Posit Connect handle the delivery and DevOps involved in sharing your work.
You focus on what you do best.
So if you work on a data science team, you owe it to you and your org to check out Posit Connect.
Visit talkpython.fm/connect today and get a three-month free trial to see if it's a good fit.
That's talkpython.fm/connect.
The link is in your podcast player show notes.
Thank you to Posit for supporting Talk Python to me.
Maybe a quick introduction.
It has been, you know, we, I guess it's worth giving a shout out back in summer 2022, you were on the show when Flutter first came out to tell everyone about, sorry, when Flutter first came out to tell everyone about Flut and how it's basically Flutter plus Python for UI, but it's been a while.
So, you know, tell people quickly who you are and we can get into the project.
My name is Peter Fitzner.
I'm the founder and developer of a flat framework, like Flutter for Python, for Flutter, yeah, it's been two and a half years since we released the first version. It's not like the first release of web and since that time we gained really great traction. To my mind like we got 12,000 stars on github, 72 contributors, 5k members on discord channel and I found the statistics for PyPy. It's like almost 3 million downloads from PyPy of web package. So It's a great community, great people, a lot of feedback, a lot of issues.
So it's pretty nice.
That's awesome.
And it definitely seems like it's going strong.
I do think maybe it's worth actually talking a bit about what Flutter is before we dive into Python for Flutter with Flut, right?
Give people a quick sense of what is this Flutter thing that we're talking about?
Flutter is a cross-platform framework.
It works for web, iOS, Android, and all desktop platforms.
It allows you to write nice apps, really nice apps with great UI in Dart language.
So you have to learn a new language.
And Flutter is a framework.
So it's like, it's not just UI, it's application framework.
It has all the things to build the app.
There's the, the language, which is Dart, not Flutter, but then Flutter has all the UI widgets and the mechanisms, but it also is a whole series of build tools that will take that and create things that you can upload to the mobile app stores like app, Apple's app store or Google play or other places, right?
Like desktop apps.
So there's a bunch of layers to what Flutter really is.
I think Also, the interesting part about Flutter is that it has a painted UI.
So it started from the Skia engine and now they have their own engine in Palo Alto.
So the UI is basically painted on the canvas.
So it looks similar everywhere on every device.
Like some frameworks, like for example React Native, they use native controls.
But Flutter, it looks similar on every device.
It's cool that it runs everywhere, but sometimes that can fall short.
The biggest example of this for me is Java applications.
When they have their own file browsing dialogue, you're like, Oh, this is clearly not a native sort of thing going on here.
You know, on a, on a desktop situation, they don't look like windows dialogues.
They don't look like macOS dialogues.
They just look like Java dialogues.
But so that can be a problem or limitation.
But Flutter tries to look like the native controls.
There's the, what do they call them?
The Cupertino widgets and the material design widgets that, so it tries to adapt to the platforms it's on.
That's why it's called Adaptive.
Yeah.
It's like this material design is built in, there is Cupertino controls.
It also, I thought there are, think body packages for micro-OS and Windows like Fluent Design.
By the way about dialogue, you know, if like this it's called file picker and it looks different for all platforms.
So it's not always drawn like the UI.
You can write like a native package, like using the underlying operating system API.
So the, the dialogue looks pretty standard on macOS or windows.
So yeah, it's not always so bad.
It is for building apps all over the place, Flutter, but I would say it's real seems to be in the mobile app space, right?
What do you think?
Primarily iOS and Android?
- Some recently asked me about like, why not React Native?
So why you chose, and I went to Google, like, you know, like typing like Flutter, yes, React Native.
And the interesting, it became more popular this year, 2024.
So it's a little bit ahead of React Native, Flutter, in this year.
So, yeah, so it's, it's according to stick with floor questionnaire, something like that.
So it's gaining popularity.
And I would say that yes, Flutter is more a mobile fast framework, despite they have awesome support for desktop platforms or web, it's still mobile first.
And when we talked about Flutter, we should probably talk first about mobile devices and these benefits it brings to mobile development.
That's right.
It's a pretty interesting.
I just looked on Stack Overflow trends.
Let's see if I can find it.
Yeah, look at that.
The flutter is quite a bit higher than React Native.
More than I expected.
I'll put a link to that in the show notes for the Stack Overflow trends graph.
What are the reasons behind that?
Maybe it's ecosystem, maybe because it's pretty easy to find an extension to find some nice package on pub.dev.
Maybe it's because it looks nice on both iOS and Android, and it looks similar, maybe.
Maybe because Dart itself, I know people tend to criticize Dart, but I have some experience writing in JavaScript, TypeScript, and I can say that it was really nice learning Dart.
It's a great language.
And honestly, I know it's unpopular, but I feel it's kind of like better than JavaScript.
It's just my opinion.
So once you learn it, you can do everything.
It's pretty nice.
Maybe because of that.
- Perhaps.
And before we move off Flutter, just real quick, I wanna give a quick shout out to Lauren, the developer I worked with.
He and I built the Talk Python courses apps in Flutter, which is why I have more than just like reading the docs experience in it.
And those apps are going strong today.
They're really great.
Although I'm about to release a new version because you never stop releasing new versions, even if you think you're done and something changes behind the scenes with iOS or Android this time it's Android.
Yeah.
They go that all the time, that package that used to do this thing.
It doesn't do it anymore.
Like, Oh no.
Okay.
So that's the foundation that's Flutter.
Flet.
Tell us about Flet.
I mean, you talked about the downloads, but like, where does it fit in this Flutter ecosystem?
Flet is a native framework.
As you can think, it's not just translated from Python to Dart.
It's not just bindings for Flutter widgets, like PyQt, PySite, for example, but it's a standalone framework that uses Flutter for each UI.
So Flet is an application framework.
It's not just UI, and it uses Flutter to build each UI.
I see. So people should think of it more as an independent UI and application framework for Python, not so much as a extension of Flutter into the Python world. Is that maybe the way to think of it?
Right. We're still trying to go away from this label, you know, it's kind of, but it works really nice, like, right. Flutter, Epson, Python, it works pretty good, like in terms of a CEO, for example, but, but it's not true. Like It's a framework that uses, we could, I mean, potentially we could replace it with something else like this backend, you know, with like Compose or, you know, React Native, but no, it's Flutter.
And it's really great.
We, we, we have our own controls and it's not always one-to-one maybe, maybe, but it's like maybe of Flutter controls, they are built out of like multiple Flutter widgets.
So we combine multiple Flutter widgets into controls.
Because sometimes if you have some Flutter experience, sometimes you can notice that it's getting really...
the UI getting really complex or, like, you know, later, like a lot of controls, like, wrapped into other widgets.
Like, for example, if you want to center something, There is a center widget if you want to limit the size, the resize box.
So Flag combines many widgets into more like controls and those are properties.
So it's like it's cluttered in serve to Python developers in Pythonic way, I would say.
On your, if people want to browse these controls, widgets, what do you want to call them?
There's a whole controls section in your docs and I'll link to the docs, but the left it says controls and you go there, there's layout controls, navigation controls, you know, app bar type things that you might expect from standard mobile apps.
And of course, like I sort of pointed out, you got the Cupertino versions and you've got the non Cupertino material design versions.
So people can have a look at that and just get a sense for all the controls, but there are many, how many controls do you know off the top of your head?
Oh, it's like a hundred plus I would say.
And some really nice ones, right?
Like you've got a web view, you've got maps, animations, charts.
Yeah.
Web view is, is not available for like all platforms at the moment.
It's mostly for mobile and for my class, if I'm not mistaken.
So yeah, it's kind of like there is a flat rule limitation right now that, for windows that doesn't allow to have a proper web view on windows platform.
Oh yes.
I remember that.
That's yeah.
What a hassle.
There is work going on.
You know, you were on the show before to talk about Flet and those were pretty early days then, right?
To over two years ago.
A lot.
You've been, you're going strong.
Like you said, you talked about the downloads and the contributors and stars and all that.
That's awesome.
So you, what have you all been up to?
Where's this effort gone?
Like what, what progress have you made?
We started from a simple design.
it was pre-built executable for every platform, mostly like for desktop platform, which is able to display all controls we have. And that executable was an ease part of a wheel, flat wheel you install. So if you do heap install flat, you install this executable with the Python API itself. But then we started getting more and more requests like asking Like, how would I put all this beautiful stuff to a mobile device?
Or how do I do a standalone app?
And, well, the answer is we should generate executable and Python should be part of it.
Python, your program, set by the libraries you use for your program, all this stuff should be part of this executable.
It's been a lot of work to produce a standalone package for desktop, for web, and for mobile.
So Flutter is a good start for that.
So the question was Python itself and third-party packages.
So we decided that, like, okay, Python for desktop platform is really straightforward.
You just take regular, basically regular Python and bundle it into your executable or application bundle and that's it.
So it's pretty straightforward. For mobile devices, there is a challenge and we know that multiple projects when are working on this problem, like the most popular Kybee and Beware, Those guys started back, started solving this problem back in 2010, maybe 2012 if I'm not mistaken.
And they did really great job and they're still doing great, you know.
Yeah, I know Beware's got a lot of recent support as well through the Anaconda team, which is really great.
We started from Kavi. I don't know, at that point, like two years ago, I thought that I saw maybe that Kavi is more popular And I decided to explore this way, whether Kyde could be used as a foundation for planning or we can grab portions of Kyde and make something different, you know.
And it was good for the start, obviously.
We managed to use Kyde tooling, like Python for Android, Python for iOS, and their command line and their libraries and their recipes to compile runtime, Python runtime and third party modules and use them in quantification.
So, I mean, there was Kyvee.
But you guys ended up moving off of it, right?
Recipes was a great, and it's still a great idea, but there were limitations, you know, like first of all, Kyvee recipes, some of those recipes, they're outdated. So I tried building a few recipes. So I fought tidy and tried building new recipes by myself. And it wasn't easy task, you know, it's kind of so recipes, it's basically Python code. And there are a lot of historic stuff, you know, it's you should know about like a lot of debugging, I was really struggling trying to build new recipes and update existing recipes for Kairi.
And also the biggest issue with Kairi's approach was you have to build all the Python runtime and all the modules like packages by yourself all the time.
If you're a user, it's kind of pain. So you should enjoy SDK installed and all environment wearables in place you know like and I mean it could be a real struggle to build and it takes time sometimes like if you add NumPy pandas to your app as a dependencies it could take like like half an hour to build all the packages and fingers crossed you know like whether it finishes okay you know or you get some weird pre-prepare yeah it wasn't nice it wasn't nice. I mean, it worked, this approach worked for simple things, you know, with the way your app requires fewer Python packages. But if it's not something trivial, it's either no recipe or outdated recipe, or you have to build your own recipe, etc, etc.
And a recipe is basically saying how to build some particular library or Python itself for Android or for iOS or something, is that right?
We can dig into that.
Yeah.
But it's kind of basically like settings.
It's a bunch of settings for compiler for linker and how to move resulting files.
You know, and basically that's it.
Yeah.
That doesn't sound that easy.
Yeah, absolutely.
Yeah.
It's it's C, C++.
Yeah.
I can talk about this later, you know, it's.
It's probably, probably people get enough of a, an idea from it.
Is this, so I know that you are using or you publish serious Python.
Is this sort of your answer to that?
As we do open source and Kylie and other projects are open source, I thought maybe it's a good idea to contribute something to open source, right?
We can do this as a part of our application templates, for example, and not dealing with this plugin, you know, but I thought maybe someone would be interested in using Python with your Clutter app.
So C++ Python is a pretty low-level package that allows you to embed Python engine into your Clutter application.
So, and I'm not sure if it's even popular, you know, but maybe someone can use it for some purposes.
Do you do anything with Python build standalone?
You know, UV has started making it really easy to install Python, all the different platforms of it by leveraging Python build standalone that was previously run by Greg now by Astral.
Yes.
Or do you do something else?
Yeah.
Like where you build, you build it for platforms.
So you're talking about this GitHub project, building every version of Python for all platforms, right?
Yeah.
We use this repository for desktop as a, as a starting point and we don't want pre-built Python from that repo and we actually repackaged it.
For mobile, now we use a different approach and I can talk about this.
For web we use Pylodyte.
Yeah.
Well, let's maybe talk for a little bit about the runtime side of things and we could talk about packaging after that.
Flutter goes into all different places, more than most platforms.
You can build desktop apps.
You can build mobile apps.
You can also build web apps, kind of a competitor to Angular or something like that.
Right.
And if you're going to have Python run times in these different locations, and that's kind of why I was asking about Python build standalone is, you know, there's all these variations of places that could be, which is quite tricky.
Right.
So the web version is WASM WebAssembly based, right?
Web could be deployed in two like moments in two states, like client side and the server side.
So if it's deployed as a server side app, obviously the Flutter part runs in the browser and Python runs on the server and it's standard Python with any module, you can use anything.
And client part, client side, talks to server by web sockets.
So all UI changes are streamed via web sockets to the client and all events go back to server side.
So this is one mode, it's called server side.
And another mode is client side or static web side.
You can build, you can publish web app as a static website and put it on CloudFlare or GitHub pages or whatever you like.
Yeah, you just put the WebAssembly files there and it just picks it up and goes, right?
It's Flutter itself and Python, PyDyn, which is WebAssembly, which is Python and WebAssembly.
So we don't compile Flutter part into WebAssembly yet because we have a lot of dependencies and not all of them support Wasm.
But it's definitely on our roadmap and we'll have a branch trying to produce fastening builds.
So it would be really nice because the size would be much smaller.
The size of Flutter web would be much slower.
It's probably right now it's 10 megabytes maybe.
And it's going to be like two megabytes something.
So it's going to be really nice when we do that.
And with the right amount of caching, the right style of caching, it's not big of a deal, right?
PyGuide is a pretty strong project.
It has the biggest number of packages supported.
So it's great.
I mean, like it got really great support.
I believe that the Python core devs are also working on getting Python itself to be a sort of officially built for WebAssembly.
I know Brett Cannon's done a ton of work for this as well.
Does that help you guys in any way?
use built-in, this built-in Python support.
So we migrated from Kylie to this approach.
And it's thanks to the way guys, Russell and Malcolm.
So Russell is iOS, Malcolm is Android.
So they did a great, a really great job putting like this iOS and Android support into Python project itself.
And now they, they like actually, they, they implemented the support for Python 3.13 and they ported to lower versions.
Oh, nice.
When I first, first saw the proposal, you know, for iOS, first of all, I really liked it.
It's really great.
I mean, like the way producing binary libraries, you know, like for, and packaging them, it's really good because we can use dynamic libraries versus static libraries entirely. Like entirely everything, like all these third-party modules you can file on your machine every time they produce static libraries. Basically like.a files for iOS. And finally, and they like the entire code base is like single executable at the end, you know, like everything like NumPy, like all this stuff is a single file.
I mean, you cannot reuse some of those libraries, you know, like when you package them into iOS app, I really love the approach and I understood, you know, that it's probably the way going forward, you know, and you see it's kind of like it's getting like a standard now and it allows this approach allows you to have binary wheels that are prebuilt and put somewhere on not on PyPy.org yet.
They don't support this model yet, but you can publish them on a custom feed, you know, and use and all users, all your users, they can download them from that location.
Now that's it.
Yeah, it's great.
It's standard.
And in the future, we can use pre-built wheels by like project maintainers, you know, like if NumPy, for example, decide releasing those wheels, we can, we can use them because we follow these standards, you know, like, so we use like standard runtime.
Excellent.
But NumPy folks, for example, as you said, they could use their expertise to get NumPy, this NumPy C code and Python code to build for WebAssembly and just put that in as automation and GitHub and everyone else in the world doesn't have to solve it over and over.
Right?
The Python 3.13 Python itself is, is pretty fresh.
You know, it's many packages are still on, like don't support it.
Right.
So I believe like in at some point those projects will start doing their will start producing their own iOS and Android wheels and publishing them to PiPi once it's supported.
So yeah, and of course, they can reuse our expertise.
Yeah, you're making me dream, dream big, you know, like wheels for iOS and wheels for Android.
Could you, could you imagine a day where it's as easy to just get libraries for the mobile platforms as it is for Mac or Linux or whatever?
It's still not many people working in this area.
And what I can tell you, it's like modern processors, modern CPUs in the Android and iOS, like Apple devices.
They're pretty powerful, you know?
And I remember there were a lot of like those times, like 2012, 2010, when Kylie and VWare started, there were a lot of issues trying to squeeze this desktop C code into a mobile processor.
Now it's much easier. Most of those packages could be compiled as is without any tweaks, without any pictures, you know, so it's pretty, it's pretty nice.
Maybe yeah, in the future we will have this as a standard thing, you know.
Yeah.
Last PyCon with the, maybe the Python before started, I think it was salt lake anyway, it doesn't really matter.
Recently, Carol Willing at the PyCon US keynote talked about how mobile is such an important platform.
And you know, there's people like you and Russell Keith McGee and the B-Ware team working on it.
But I think it feels a little chicken and an egg to me, you know, if it was a little easier, there would be a huge bunch of people that jump into it, but there's, it takes projects like Flet and the Beware one to just kind of unlock it.
And then I think once it gets unlocked, people are going to realize and just go for it, you know, Kevin Python on the mobile devices is, is, is pretty awesome.
You know, it's like for, for Android, for example, it's, it adds maybe like 8 megabytes of size to your app.
So it's not so large.
And it makes sense.
Python is a great language.
It's great for beginners, you know, for scientists.
So it's really, I don't know, like addictive, you know, like to write apps for everything in Python.
I've become like, I've been using Python for three years already, and I still love it, you know.
Like I write most of my, like, even like sweets, you know, like in Python, like, so I'm looking back and all.
Yeah.
I've worked in a lot of programming languages, myself, static and dynamic ones.
And yeah, it's Python.
It's comfortable.
It's nice.
Yeah.
All right.
I want to talk about packaging and I know that's the area that you've been working on a lot as well.
And as a segue, let's take a question from the audience.
Alan out there asks, I'm someone taking a careful look at Flet.
My question is what is the process of getting finished app reviewed by Apple or Google?
I think, let me rephrase that into slightly different part because the reviewed by Apple or Google, there's like a voodoo doll and you stick it with a few pins and then you like rub it with an oil and then they, they approve your app, right?
Like that seems to be the process.
It's been so hard, but I think the thing is how do you get it built in a way that you can submit it to the app store?
And then it's just down to, right?
So what's the process?
This is one of those rough questions, you know, it's, and you should have a list of rough questions.
You're ready to answer.
So right now you can build your APK for AAB for Android.
You can sign it, but you have to upload the file manually right now into.
I see.
So you have to sideload it basically at the moment.
YOLT command allows you to build the AAB file, which is basically APK for multiple platforms.
sign it, and then you upload it by yourself through the web interface of Google Play.
Oh, let me go back then. That's not side loading it. That's just not having it auto upload.
Yeah.
That's encouraging.
So we have own Flag app in both Google Play and App Store. It's for testing apps on mobile devices. Basically, like the same flag client that connects to app through web sockets and the app itself is running on your machine.
So yeah, and honestly, right now we publish it with Fastlane.
So there is a CI job that publishes both iOS and Android versions with Fastlane.
I'm not sure, maybe we will do the instructions how to use Fastlane because it's a great tool and it's pretty easy to synchronize certificates you know, for App Store and publish your app and make that information for app.
So, yeah, but right now you can, you can build IP, you can build AAB, but you have to upload them manually.
I think that's fine.
Yeah.
And then the review process starts.
That's the voodoo doll part where you get the voodoo doll out and you hit it with the needles.
People usually concerned about like, whether is it allowed to have Python or like the like stuff like that in your app and would it be approved by Apple, by Google?
And I can tell you it works pretty well.
We dogfood our own stuff.
So we build Klet app using Klet.
So the way it's packaged inside, it's getting approved.
There are some issues.
I can tell you there are some issues.
For example, disabled, we used to disable x86 devices right away.
And because they're like Google Play, usual machines, they show just like a black screen, you know, like, like the market share for those devices is pretty small right now.
So we disabled that.
So two plus is the review, but it works.
It works.
talk through the, the publishing workflow that you all have with the new CLI tools you got, but let's just dive into one more thing real quick.
So when I have my Python code running, let's just say iOS, I have my Python code running on an iPhone.
What is the runtime look like?
Is that regular CPython?
Can I add a standard package as a wheel?
Like, could I use HTTPX?
Like what is the story around the execution environment and the external packages and so on?
It's CPython.
As I said, right now we use, or this serious Python package, it uses Python.
There is, by those scripts, which are part of Python 3.13.
So like, theoretically, if you go there to Python repository and look into those, folders you will see instructions you can you can follow those instructions and build runtime like build CPython for both iOS and Android but yes this is it's not blossom it's CPython compiled into native iOS or Android code like platform for platform not like code assemble and binary packages yes you have to repackage, you have to build binary packages targeting those platforms as well. And for that purposes we use MobileForge project by DeWare.
It's pretty nice, it's an awesome project, it's a brainchild of Malcolm and Russell.
And yeah, in its turn it uses cross-env package, which is basically the way to simulate, like it allows you to create a virtual environment and Python thinks that it's being run on a mobile device, you know. So it's like basically MobileForge is like you do people install something and it feels like for Python it feels like it's being run this command on a mobile device and you it uses like if it's binary package and there is setup.py or pyproject.toml It uses mobile compilers, cross compilers to build.so file and produce a build.
So if a pip install action requires a local build of something, it will use the mobile compilers with the target platform being like iPhone or whatever.
The whole package like this cross-env, it tweaks Python into thinking it's kind of like running on a mobile device, you know, like it has these compilers, this archiver, this linker, you know, it's so nice. So like, and it's, it's pretty, it's pretty smart thing, you know, like in most cases, so you should do a recipe. But this time recipe is, is basically YAML file, it's like meta.yaml.
And in most cases, if it's standard C, if it's simple package, you don't have to do anything.
It works right away.
You can build it for Android.
You can build it for iOS.
It takes literally minutes to produce a binary wheel for both platforms.
I'll definitely link that in the show notes.
All right, back to wherever I put it, the publishing side of things.
So maybe we could talk through a little bit about the CLI and the process.
Tell us, tell us how we go through this to get something built here.
The first release, the first releases of web were using the like so-called web, like offering flat path command and using PyInstaller to produce executable.
But it worked for desktop platforms as well only.
And to produce the package, like the bundle for mobile platform, it's you need to do more. It's still possible as those guys are basically zip files inside, you know, you can build the AAB, you can build the APK, you can build the IPA by yourself or using Xcode tools. And it's like, it's the approach BWAM takes, for example. So the briefcase it builds like packages basically from scratch you know but for Flutter we use we require to use Flutter SDK so there is a new command let build which uses Flutter SDK and it's basically like a wrapper around the Flutter build command which allows you to build the app for desktop for web for mobile. So inside we take template, we take template and we create a new Flutter app and we build this Flutter app.
Right. And just for people listening, the template looks something like here's a folder with a bunch of images and here's a main.py and a pyproject.toml, stuff that Python people would be familiar with.
This is template for the app and template for Flutter app, it's something internal.
You don't have to look into that.
You know, it's like...
It gets kind of complicated for the different platforms and linking them together and stuff.
The problem with this, with Flutter is like the difference because we want to, we want to support extensions.
We want to allow people using those nice extensions packages on pub.dev.
So we cannot have the same process every time we, we should really run Flutter build to like, for example, include a media kit for video control or audio players package for audio control.
It's not the same.
It's always.
So it should be built from dark to this code Flutter produces.
That's a lot of what Flutter is.
It's like orchestrating all the pieces to build into the right stuff to go into the mobile apps.
Yeah, exactly.
So we've got this pyproject.toml and you even have a create CLI command, like flit create my app or whatever.
And it will go and get that all out there.
Right.
Recent stuff and still pretty rough.
Yeah.
And here you have flat build and then target platform and where a target platform is APK that is Android, AAB, IPA, which is iOS, web, macOS, windows, and Linux, that's a pretty impressive list of package destinations for building an executable.
So if I build, let's suppose this.
If I build a, let's say windows.
I say target equals Windows, what files or file or executable or what do I get when I run that?
Do I get just a.exe? Do I get a.exe with DLLs or a whole bunch of other stuff?
Yeah, unfortunately it's not a single.exe, but it's.exe and a bunch of DLLs. Yes. It's, if you look inside the folder, you'll see like this executable, then Python itself, Python in runtime, which is a bunch of lead files, you know, and DLLs, Python files themselves, then your app coming as a zip file, also different kinds of DLLs from, from plugins, from extension packages, Flutter packages, like for video, for example, it's going to be like four more DLLs, something.
So yeah, it's, it's, it's a bunch of things.
Yeah.
But, but it's something I could put into an installer or copy to a Windows And then you create a shortcut to the.exe and it, it looks like an app to the user.
You can make self-extracting archive for MSI.
Okay.
And for macOS?
For macOS, it's a bundle.
Is that a.app bundle?
Yeah.
But it's a standard bundle that looks like a file, but it's a folder.
Works like a charm, you know, like having the right structure.
Again, the app inside is a part of the Flutter asset, which is like, it's called like car file.
It's not like even the zip, it's car file and which has all the assets.
Nice.
It's a work in progress, you know, like to.
Are you ready for the hard question now?
Those are all awesome answers, but here's the one that has been driving me crazy.
Is so many of these platforms by that, I mean, windows and Mac have anti malware, anti phishing protections, which is good, but that means if you build a dot app file and just try to run it.
It'll say this is from an untrusted developer.
We'll probably, you want to move it to the trash.
You know what I mean?
Like the lack of notarization or on windows, if it's not digitally signed with a trusted cert certificate, it gets treated with like a yellow warning.
Is there a way to digitally sign these or notarize them through Apple?
Yeah, I know flutter can do it.
So maybe you could show up, maybe it shells down to the flutter side of how that works.
But still, it looks pretty complicated, you know, like, even from my perspective, like, it looks pretty creepy.
But I have this item on my desk right now to start from my class.
Because there was a complaint from one user recently, like two days ago, and I still had this issue.
So I'm gonna work on that, and I'm gonna provide, like, a definitive answer.
It's not like I'm not going to say like it's do whatever you like.
Like, no, I'm going to go through all this stuff because right now we honestly, we use it.
We don't even use sandbox mode in produce.app file.
You know, it's so we start from there and there was an issue with the loading Python binaries, like package binaries.
I'm going to, I'm going to solve that problem as well.
So yeah, definitely. It's our next step. Yeah. We, as you see, we're getting closer and closer to building real apps and we're getting more and more developers building real apps and they want to publish them. It's not just experimental, you know, anymore, like they want to publish them.
And we are working on that right now, like publishing. And it's actually, it's our number number one priority for the next year.
I'll tell you, if you had that, that dialed, I mean, that means that that opens up desktop apps completely.
Absolutely.
Yeah.
So we will, I will start from micro-ends because I have probably more, a little bit more experience with micro-ends right now.
And then I want to continue with the Windows Store.
I never published anything to Windows Store before.
So it's going to be an interesting journey, you know, but yeah, Windows Store as well.
Well, yeah, even if you just digitally signed it so that if you download it off someone else's website, it wouldn't go, Oh my gosh, this is an executable.
That's untrusted runaway.
You know, we actually sign our MSIs right now for, for other products.
And it's kind of like conspiracy, you know, like, so you have to use a really expensive certificate to pass through what was like screen, Windows screen, something like, so it's not just even like code signing and not even easy code sign is something else.
Yeah.
On MacOS it's gatekeeper and these sorts of things.
Yeah.
I remember it's like $600 per year, something like that.
At least if you want to pass this windows 11 screen.
Yeah.
Otherwise it's always a warning.
Always.
Where's the let's encrypt for desktop apps.
Come on people, somebody help us out.
Where's the cert bot for let's for desktop apps.
But yeah, I, you know, like it's, it's there for a reason because people kept getting wrecked by ransomware and all sorts of stuff, but it does make building desktop apps challenging.
Well, yeah, but we'll get there.
No worries.
I love it.
All right.
What else should we say about, about this here?
I guess controls.
I know there was a question.
See a video.
There was a question out in the audience also from Allen's is about camera controls.
Is this a thing that you guys support yet?
We started working on that, but it's not like it was kind of like testing the waters, you know, like it's kind of like at this moment we are trying to harmonize API, flat API and as I see it right now, we, we're going to split all controls into like visual controls and so-called services.
So camera is going to be service because yeah, right now it's sometimes it's, it's messy, you know, like to use non-visual controls, you have to add them like to overlay or something.
And like if you jump to a different page, it like audio could stop, you know, like, so we're going to re-implement that. And camera is true. Camera is the number one parameter right now. That's why there is a draft pull request and we're not closing it. So we keep it in mind The reason I even brought that up right now is because part of this packaging process, you have to state things like your permissions that you're requesting, like access to location.
And you also have to include which optional controls you want to build like audio recorder or geolocation or maps and things like that.
Right?
This is something we're going to change by the next release as well.
We will make this process more streamlined, easier to add new controls or services and include them into the build process.
Well, even having them under a subsection of your pyproject.toml is pretty nice, actually.
It looks standard, you know?
Yeah.
It looks like it belongs, which is really nice.
Right.
And obviously you've got icons and splash screens and all of those types of things that you have to include in order to build, especially mobile apps, but even icon for a dot app or dot exe.
Yeah.
I guess one more thing we got time for one more thing to call out here about this packaging side of things, or maybe, maybe two, but this one's pretty interesting is by default, flat will flat build.
We'll just pile your Python app together and assume that it must be fine, but you have a --compile app option that will compile your Python files.
Now people listening might think, well, but there's no Python compiler.
There is a Python compiler.
You just don't do anything with it.
It's in the interpreter, right?
So when Python loads your Python files, it converts it to a byte code and then interprets it.
Right.
But you can have it compile that to PYC files, which will detect problems.
Right.
That's kind of cool.
Yeah.
Tell people about that a bit.
One of the reasons we introduced those options is that if you always compile and there are some issues inside user code, the entire process fails, you know, Like even at least one single syntax error somewhere in your app leads to like a failed build process.
And also you can disable compilation so it could be easy to debug your app.
People asking like, is it like, can I see what's going on?
Like if I am like downloaded your app and looked inside, like, can I see what's going on inside my app?
Like can users see?
Well, it's not the way to properly protect your app from someone looking at the logic.
It's not 100% protection.
So maybe you should use obfuscators.
And we have some ideas to build obfuscating into Pipeline.
I was thinking obfuscators were kind of like a separate thing.
Imagine if it doesn't work.
I mean, it's good if it works, like if you obfuscate it and it works, but Python is pretty complex thing because it's, it operates by text files, you know, like, so you can break some paths, you know, like module names, you know.
Exactly.
If it obfuscates the import statement or it's an import request, like that's not going to work anymore, you know, cause that's how Python works.
It needs to see it.
Yeah.
I want to play with it.
If I compile my Python files, my PY files, does that omit them from the project and only include the PYC files or how does that work?
We remove the PY.
Yeah.
That's already pretty, pretty good levels of obfuscation.
There are disassemblers and decompilers for C code for, especially for.NET and Java, you can get those back to almost source level decompilation and sort of things.
So yeah, that's, that's kind of close to at least close to, I would say it puts on par with.NET level of obvious cases.
>> It's the star.
>> Yeah.
All right.
The last thing I guess we should talk about real quick is just permissions.
So if you live in this mobile world, this is androidmanifest.xml or info.plist or.entitlements and all these things.
And so you support these platform specific deals pretty much because Flutter supports them, right?
>> It's not like pre-camped permissions.
You can put anything you like.
It's basically, it's whatever you put here into PyProject.toml or common line arguments, it goes directly to this build template.
So it's, in fact, it's a big template, it's a cookie cutter template, and there are a bunch of for each statements, you know, like going through all these arrays.
So whatever you put here, it goes to those entitlements, PLLs and manifest file.
So it's pretty, it's pretty flexible.
Yeah.
But sure.
We have like some predefined.
When you say it's a cookie cutter thing, it's not just like a template.
It literally uses the Python cookie cutter library, right?
It's in a separate repository.
So every flat build command downloads that template and provides the data.
combined template and data and produces this Flutter app.
And then it goes to Flutter build.
>> It looks great.
And it also looks like a lot of work.
So congratulations on making it this far.
>> Thank you.
Yeah, it's still a lot of work.
>> Yeah.
Yeah.
Let's see.
I wanted to just have you real quickly close out.
I don't know where I stuck it somewhere in here, the roadmap for, for where you're going.
So maybe tell us what's in the future.
What's what's in the near term that people can count on and then we'll wrap up.
Yeah, maybe this roadmap is already outdated, but yeah, first of all, we want to have this 1.0 because it's maybe it's a psychological thing, you know, it's like people, developers feel stability and all that.
When there is 1.0, it says that the framework is ready for for SilverSaps.
It's a commitment to sustainability.
Like we think we're ready.
It's commitment for sustainability and it's commitment for proper release schedule.
So we'll keep this release after releasing it and we'll be providing patches to this 1.0, etc.
So you can start doing real apps using 1.0.
So it's 1.0 and we were doing a lot of work trying to harmonize API, trying to remove outdated stuff, trying to like have consistent naming conventions across different controls, you know, it's like property names, method names, remove different duplicates.
So it's a lot of work and we're almost there.
So definitely like another thing is improving developer experience, right?
So improving developer experience, further improving developer experience, Like for example, we will be pre-installing all dependencies to make flood build command work really smooth on your computer.
Like right now you have to install Flutter by itself, but we'll be installing correct version of Flutter on your behalf and Android is, yeah, Java, Java could be a pain, real pain.
Like sending this Java home.
If you're a people who have not been through Flutter projects, they don't They don't know all the little tools and the version mismatches.
And I've got this version of Android Studio, but the Android SDK version wasn't checked correctly.
And so now I can't, you know, like that, what you're saying is there's a lot of stuff that you could help out with and make that smoother, but it's challenging.
Yeah. And still, it's still, you need Android Studio or Xcode or Visual Studio.
Yeah. You can spend a lot of time configuring those things.
You know what, maybe next year we're going to, we're going to work, start working on on the service, you know, like I call it packaging and publishing service.
So you could somehow link a GitHub branch, like a production branch or something.
If you push that, you guys grab it and you'll build all the assets.
Yeah.
Nice.
You can push your, just, you know, your code in this directory to this service and get artifact back, you know, like MSI file or ATP file.
That's it.
That'd be awesome.
Actually.
That's very cool.
You don't need to deal with all these dependencies, like all this stuff, you know, it's you just do your part, your like Python code and that's it.
And the rest will be done inside the, yeah, in the cloud.
So that's the idea.
That's the plan.
Very promising.
I love it.
And I love all this work, all this progress you guys have made.
So thanks for coming back on and sharing with everyone.
Let's close it out.
Final call to action.
People are interested in Flet.
What do you tell them?
Go ahead.
Download the latest version.
Try doing your app and join our discord channel.
Let us know what you think.
Awesome.
All right.
Thanks a bunch.
See you later.
Yeah.
Thank you guys.
Bye.
This has been another episode of talk Python to me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/posit, P-O-S-I-T.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the Direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.