Deploying your Python application to Android
Python can be used to create native applications for Android. However, although Python is the most popular programming language, it is not the first choice to create an Android application. This talk gives an overview of developing Android application with Python by comparing the 3 popular frameworks for GUI development with Python that support Android as a platform – PySide6, Kivy and Flet. This comparison is demonstrated with a simple Contact List application with the ability to add, edit and delete contacts.
The overall structure of the talk will be almost the following:
- Why is Android a relevant platform for Python application developers? (6 minutes)
In this section, we establish why Android is the most popular OS being sued currently. Although Python has had the support to run applications natively in Android, even dating back to 2011, the development of Android applications with Python is not so popular. We will further highlight one of the major concerns of using Python for Android develpoment and how PEP 738 can help simplify this.
- Current status of Android app development with Python (2 minutes)
In this section, we give a brief introduction to some of the Python based toolkits that support Android as a platform – Kivy, Flet, PySide6, Beeware etc.
- Contact List application with Kivy (3 minutes)
In this section, we look at how the applicatiion looks with Kivy and KivyMD, followed by the ease of development and some pros and cons of the framework.
- Contact List application with PySide6 (5 minutes)
The deployment of PySide6 application to Android uses the same build tool as Kivy, called python-for-android. python-for-android now also supports a Qt backend along with SDL2 that Kivy uses thus enabling the deployment of PySide6 application. In this section, we look at how the applicatiion looks with PySide6, followed by the ease of development and some pros and cons of the framework.
- Contact List application with Flet (3 minutes)
In this section, we look at how the applicatiion looks with Flet, followed by the ease of development and some pros and cons of the framework.
- Python packages support (6 minutes)
We see the various Python packages supported by each framework.
- Conclusion and Questions (5 minutes)
Questions from the audience.
This session took place in track Programming & Software Engineering and was classified suitable for intermediate domain / intermediate python by the speaker.
Transcript (auto)
Auto-generated from the recording utilizing Open-Source AI. Speaker labels (Speaker 1, Speaker 2) reflect diarization, not identity. Timestamps refer to the recording.
Speaker 1 [00:06]
So welcome to my presentation as I take you on an exciting journey across Android Almond with Python. In this talk, I'm going to give you a general overview of the current status of Android support in Python. Furthermore, we'll be looking at three of the very popular Python GUI framework that support Android. We'll be creating a contact manager application in all these three frameworks, and we'll see how the UI differs, and we'll also look at some of the pros and cons of each of these frameworks. Hopefully at the end of this talk, you'll have a better understanding of some of these Python GUI framework that support Android. And also you have a better idea on what Python GUI framework to choose for your next Android project. So a little bit about myself. My name is Shyam. I work for the Qt company in this project called PySide. PySide is another popular GUI framework. And full disclosure, although I've been working with PySide for almost two years now, I've never really developed a GUI application with Python, for example. So all these comparisons that you see in the next set of slides is basically from the perspective of a beginner, so it's more takes into account of how each of these frameworks were actually easy for a beginner to get started with. And I have to say that although I work for the QT company, this talk is going to be completely unbiased. start with the bigger question here. So why is Android an important platform? The graph that you see here basically shows the OS usage statistics as of February 2024, and it clearly depicts that Android with a market share of 43.72% of users is actually the most popular operating system. And since many years now, Python has been consistently the most popularly used programming language. So what is the support of the most popularly used operating system with the most popularly used programming language. Is Python a good alternative for native languages like Java or Kotlin for Android development? The quick answer to that is actually no. But why is that? What are some of the challenges that Python has when it comes to supporting Android? There are a couple of challenges. To highlight some of the few, there is no official support for Android in CPython. That actually means that Python doesn't give you official Android binaries for each of the different Android targets. There are four different Android targets. So what that actually means is that if you need to produce Python binaries for each of these Android targets, you'll have to cross-compile them yourselves. Second point, there is no native support for Python with Android SDK. As I mentioned earlier, the native languages for Android development are Java and Kotlin. Android Android basically works around JVM. Python is not one of the native languages, so you basically need a way to interface between Python and Java or Kotlin. And the third important point is that the app should bundle the Python binaries. So your Python app that gets deployed to Android basically should bundle all these Python binaries that you basically cross-compiled in step one. What that actually means is that this actually contributes to the size of your application, making your application kind of large. But some of these issues or some of these challenges have already been solved or are in the process of getting solved. If you look at the first point, there is no official support for Android in CPython. PEP 738, adding Android as a supported platform, was proposed by Malcolm Smith. It's actually a PEP that is accepted already. What that actually proposes is to have official releases for Python binaries for all the four Android platforms. The second point, non-native support for Python with Android SDK, this is also something that has been solved since many years now. All of these Python GUI frameworks basically work exactly because of this working. There are Python packages like PyJN-IUS and Chakupai project that actually enable you to interface between Python and Java or Kotlin. But the third important point, the app should bundle Python binaries, currently there is no solution for this, your Python application that is deployed to Android should still bundle all these Python binaries, but hopefully we'll actually find a solution for this soon enough. Coming on to the GUI frameworks with Android support, there are many GUI frameworks with Android support, to highlight the most popular among them there is QV which is kind of synonymous with Python and mobile. There is Flet, which is actually the new client in the block, which is pretty popular these days. And then there is PySide, which is the official bindings for that of the Qt project. And then there's PyQtSense, which is the unofficial bindings for Qt. Then there is Toga from VWare, which is also pretty popular. One thing that I have to mention about all these frameworks is that they're all cross-platform. It doesn't really make sense making a Python application for Android unless you're targeting cross-platform. If you're just targeting Android, I would just say always go for the native languages, just Java or Kotlin. Another thing to mention here is that all of these frameworks, except for Toga, basically work around a theme that pretty much resembles that of the native Android toolkit, except for Toga. Toga actually found a way to directly interface with the native Android toolkit. As I mentioned earlier, we'll be comparing a few of these tools, and for the purpose of the comparison, we'll only take three because of obvious time constraints And also, the reason why I chose these three frameworks among the others is basically because of their popularity, how big their community was, and ease of learning of each of these frameworks. And as I mentioned earlier, we'll be creating a contact manager application. What I mean by a contact manager application is basically a simple contact manager that enables you to list different contacts. At the end of each contact row, there should be a delete button, which when I click, it should delete that particular contact. When I click on a contact, it should give me more details about the contact, like the address and the phone number of the contact, and there should be a floating plus button at the end of the screen, which when you click, it will open up a dialogue, which enables you to add a new contact. Although this app kind of looks pretty simple, there are a lot of things happening in this app. There are a lot of kinds of user interactions, a lot of event handling. This app explores a lot of navigation patterns and different kinds of layout, making it an an ideal app to compare GUI frameworks, at least according to me. Coming on to our very first framework in the list, FLUT. As I mentioned, FLUT is actually in the new kit in the block, and ever since it's released, it's actually pretty popular these days. The very first release was actually last year, in 2023. FLUT is actually the Python interface to Flutter, which is a server-driven UI framework. I'm pretty sure most of you know what Flutter is. Flutter actually, although it has a minimal API, it's fully in Python. On top of it being cross-platform, it also supports WebAssembly, so it enables you to actually deploy your app as a web app on the browser or even as a progressive web app. And in this last one year, it has gained like 8.8k stars in GitHub stats itself. Coming on to our app itself, as you can see here from the screenshots of the app, I was actually able to do everything that I actually wanted to do with the contact manager application I was able to list out the different contacts I have delete button at the end of the screen at the end of each contact when I click on a contact it shows me more details about the contact there is a floating button at the end which when I click opens up a opens up a dialogue that enables me to add the contact into the list and you when you click on the text field in each one of the text field in that of the dialogue it actually opens up the keyboard and the dialog moves are making the app itself pretty responsive. As you see from the UI itself, it's actually pretty modern itself. Coming on to some of the pros and cons of FLUT as I was developing it. FLUT being based on Flutter definitely has a very modern UI. It was super easy to get started with from a perspective of a beginner. I absolutely loved the documentation. The documentation was easy to navigate. The entire code for this contact manager application was just under 250 lines of code including the formatting. It was fully in Python. There was, although it's like a minimal API, all these functions were like super customizable, supports cross-platform of WebAssembly, and it has a very active and responsive community. Some of the cons that I felt were like, it's still very new. I mean, it was only released last year, as such that the resources are pretty limited when it comes to Flirt. If you look at Stack Overflow, you will actually see only like 83 questions for Flirt, and the number of examples that comes with Flutter is also pretty limited. One of the major drawbacks that I see about Flutter is that it doesn't come with a visual designer yet. By a visual designer what I actually mean is IDE where you can actually drag and drop each of the widgets and then with a click of a button it should output you the, give you the Python code for the interface. There was no modules for hardware access. It is not as mature as PySide and Kiwi which has been existing for decades right now. For example, PySide has modules like for 3D and networking, which doesn't really exist in Flutter. There was no localization support also in Flutter. Coming on to our second framework, Kiwi. Like I said, Kiwi is kind of synonymous with Python and mobile, so it has been existing since many years now. More than a decade, the very first release was in 2012. Kiwi proposes two ways to create your GUI. Either you can actually do it fully in Python, just like that of Flutter, Or Kiwi also proposes to use their own language called Kiwi language. Kiwi language is like a mock-up language. It's almost like similar to XML. And I actually found it super easy to use. In less than probably an hour or two, I was actually able to get a gist of the Kiwi language. And the reason why they recommend Kiwi language is to actually separate the interface design from the application logic so that you can have the interface design in Kiwi language and your application logic again in Python. What I felt about Kiwi was that Kiwi was more suitable for games than traditional applications. The thing about Kiwi is that when you develop an application, the UI pretty much looks the same in desktop platform and also in mobile. That is, it doesn't come with material design components. But there is another project called KiwiMD, where MD stands for material design, that actually builds material design components on top of Kiwi that actually enables you to use these material design components. Coming on to our contact manager application, You actually, I mean, although the UI looks great, UI has materials and components, but then if you look closer, you would see some of the discrepancies here. Like, most importantly, I was not able to have the delete button at the end of the contact. Instead, the delete button basically comes inside the expansion view. I honestly had no idea how to put the delete button there. I checked across many forums, Stack Overflow. I even asked GitHub Copilot to give me the code. It wasn't able to give me the code. Another thing that you see in the image 3 here is that when you click on the text field, although it opens the keyboard, the keyboard kind of hides the dialogue there. That is, it wasn't too responsive. Again, I was not really able to find it. I'm sure there is a solution for this, but then the solution was not really hard to find. Although I had some of the issues, again, the app looked pretty fine with Kiwi. Coming on to some of the pros and cons of Kiwi, the biggest pro is that it does come with a visual designer where you can actually drag and drop different widgets to create your app, and with the click of a button, it'll give you the Kiwi language code, which you can easily plug into the Python code. Kiwi language, as I mentioned, was pretty much easy to learn. It was pretty much like a no-brainer where you can actually easily create the interface pretty easily. Both PySide and Flood uses Bulldozer. Okay, Bulldozer is actually a project that is maintained by Kiwi that enables you to package all these Python packages or Python modules that you use along with your application to finally create an APK. And we'll be exploring more into that a little later. Kiwi does come with more modules than Flut. It has been around for more than a decade. It has a super active community again. Some of the cons, again, were that even though Kiwi language was super easy to learn, you still have to learn a new language. Kiwi was not as modern as Flut, even with KiwiMD. It is not as mature as Qt. Qt has been existing for more than 30 years now. Kiwi was not ideal for desktop GUI applications. Again, the UI doesn't look pretty modern when it comes to desktop. It does have limited resources as compared to PySide. And incomplete API. So if you go to the API documentation of Kiwi, you actually see that there are some discrepancies there. Like when you go to certain functions, I was more interested in knowing the data types of certain functions, which I was not really able to find in the API reference itself. Some of the widget names in Kivy I actually found to be confusing. For example, there was something called an accordion. Accordion is basically an expansion view, which I actually wanted for the contact manager application, but then the name was actually pretty confusing to me. It was just me. I mean, not sure about you guys. Coming on to PySide, PySide is the official bindings for the Qt framework. Qt framework has been existing since 1995, and PySide has been existing since more than a decade right now. Again, PySide proposes two ways to create your GUI application. Either you can do completely in Python or C++, and this is called Qt Widgets. And then there is Qt Quick, which gives you the material design components, which actually is used for Android, where you actually use a language called QML with Python and C++ together. QML is a language just like that of Quby's own language. The purpose of QML was to separate... Initial purpose of QML was at least to separate the interface design from that of application logic so that you can have the interface design in QML and the application logic in that of Python or C++. QML is actually more powerful than that of QV's language. You can actually have JavaScript constructs directly in the QML code itself, but then what I noticed is that QML was actually harder for me to learn rather than QV's language because it had a lot of things going on. Qt, as general, had a steep learning curve in general. Coming on to the visual, It does come with two different kinds of visual designer. For Qt Widgets, there is something called Qt Designer, which when you drag, it's an IDE where you can actually drag and drop each of these widgets, and then it'll output you the Python or C++ code. And then there is Qt Quick. For Qt Quick, we have Qt Design Studio, where you can actually plug in all these components together, and it'll output you the QML code, which you can then plug into your Python code. coming to the application again I was able to do everything that I wanted to achieve with the contact manager application I was able to list all the items when I click on an item it will actually give me more details about the contact there was a delete button at the end okay one thing to mention here is that Flutter and Kiwi did come with pre-bundled icons for most of the common icons that you would actually use for PySide I actually had to use a custom icon I was able to get the dialog running. The dialog itself was super responsive. When I click on the touch field, it actually opens the keyboard, and then the dialog moves up. But the responsive part, to make it responsive, I actually had to add separate code, which I didn't really have to have for Flutter. And the coolest factor here is that I was actually able to use GitHub Copilot to write that code. So with Kiwi and PySide being existing for many years now, you can actually use any of these LLMs to actually write code, and it actually gives you a pretty decent code, I have to say. Some of the pros and cons of PySide are that PySide does, the process that PySide does have more features and modules than Kube and Flutter. I mean, Kube has been existing for many years now. It does come with a lot of resources, a lot of examples, a lot of questions on Stack Overflow. To put into perspective, like I said, PySide had around 3,000 some hundred answered questions in Stack Overflow, as opposed to 83 for Flutter, and I don't remember the exact number for QA, but then it was more than flood. PySAT has a big and active community. Once you have most of your code in QML, you can easily switch to, at least for the Python components, you can actually switch to C++ for higher performance. Along with the visual designer, it does come with a lot of other tools that actually make your development experience much more easier. Some of the biggest cons with PySAT is that, first of all, you have to learn a new language. QML was actually harder to learn from the perspective of a beginner as compared to QV's language. It does come with a steep learning curve. For 30 years of legacy, it comes with a lot of baggage. So you have to learn a lot of cute nomenclature, like signal slots to actually make your app running. And third point is that you need to manually create Android wheels for PySAT at the moment. We do not really officially release Android binaries at the moment. You have to cross-compile PySide yourself to make the binaries. This is something that will go away in the next month or so once we release official binaries. There is no iOS and WebAssembly support. And for the deployment tool to work, you basically need a Unix host right now. This is also something that goes away once we have official wheels. But then one thing to mention here is that it does come with a steep learning curve. So another important question is, What about the Python packages support? Pure Python packages are platform independent. So as long as your Python binaries are compatible with the Android architecture, Pure Python packages are pretty much like a no-brainer. But what about the native Python packages? Native Python packages are Python packages like NumPy or Pyrandic that has compiled components, where you basically need to cross-compile these components against to the Android architecture that you're actually targeting. The coolest thing is that all these three frameworks, FLUT, PySide, and Kiwi, actually uses Bulldozer for native Python packages. Bulldozer internally uses another project called Python for Android. Both of these projects are actually maintained by Kiwi. So FLUT only uses Bulldozer to a limited extent. For pure Python packages, it doesn't use them. It only uses them for native Python packages. For PySide, on the other hand, uses it to a full extent, where it uses it for both pure Python as well as native Python packages. Some of the other concerns that you might have with packaging your application, what if the Python version of that gets packaged with your application? It's 3.11 for all these three GUI frameworks, at least according to the latest release. The Android NDK version that is compatible is actually slightly older for Flood, but then PySide and KV actually uses the newer versions. When it comes to licensing, You notice that Flutter and Kiwi having Apache and MIT has a more permissive licensing as compared to PySide, which is still open source, but then it's less permissive as compared to Apache and MIT. Coming on to the app size, you notice that Flutter is around 43 MB for the same contact manager application. Kiwi was super impressive with around 20.5 MB. PySide was slightly larger with around 80 MB. And the reason for this is that into your application, it packages all your PySide modules. all of those modules that weren't required were also packaged into your application making the application pretty large this is again something that can be optimized away and this is something that can be optimized away pretty soon and again with the next release I'm sure that we can fix that coming on to the conclusion I hope I was able to give you just some of the Python frameworks that support Android and which one to choose I would say that Flood was actually amazing from a beginner's perspective when you really want to develop a smaller application with not too complicated features. Flood was pretty much very easy. It was fully in Python. It took me probably less than two hours to get it just onto the entire framework itself. Kiwi was more suitable for games and also with KiwiMD also for traditional mid-size applications. Kiwi has a robust support for 2D animations that actually makes it more ideal for game development. And coming on to PySide, PySide is more suitable for bigger projects, I would say. It does come with a steep learning curve, but when you get used to it, bigger projects actually becomes much more easier to do. It comes with a huge amount of support. There's a very big community across Qt that actually, when you're stuck somewhere, there are always people to help you around. And again, KB and PySide does have LLM support, so you can always use GitHub Copilot to actually make your code work. That's all in my presentation today. I hope I was able to give you some idea into some of these Python GUI frameworks and general support of Python, Android support in Python. Thank you so much. I'll be more than happy to take any questions right now.
Speaker 2 [21:28]
Thank you, Sean, for the great talk and the great comparison between the frameworks. We have several questions. I will put two of them together. One question was how to actually deploy your Python app to people's phones and how an APK is created. Are they alternatives to the Play Store?
Speaker 1 [21:50]
So, Android has two formats. There is APK for packaging format, and there is AAB for the format that you actually publish to the Play Store, which still encompasses an APK. All of these deployment tools for all of these frameworks that I mentioned, they actually provide you with two different options that actually enable you to either create an AAB or an APK, which you can take it to Play Store or directly take it to your devices, copy to your devices and install so
Speaker 2 [22:21]
Thank you. Next question. How do these frameworks differ in terms of licenses as a
Speaker 1 [22:26]
As I mentioned across the licenses, Flutter has Apache 2.0, Kiwi has MIT license, and PySide has commercial as well as LGPL licenses. As I mentioned, Flutter and Kiwi are more permissive. All of them are open source, but then more permissive are Flutter and Kiwi.
Speaker 2 [22:45]
Next question is, what's the big pain points using Python instead of the most known hybrid native frameworks like React Native?
Speaker 1 [22:52]
Of course, as I mentioned, you literally have to bundle all of these libpython binaries that you cross-compile for the Android target. That actually makes your application pretty large. And again, when you have an Android application in Python, you kind of have a slow startup time as compared to native frameworks like Java or Kotlin or React Native, for example.
Speaker 2 [23:15]
So would you recommend using these path and frameworks if you have if you
Speaker 1 [23:18]
If you're targeting cross-platform, definitely, because you just need to maintain one code. But if you're just targeting just Android, I would say always go for one of these native frameworks.
Speaker 2 [23:27]
Last question is, does cross-platform mean iOS and Android?
Speaker 1 [23:31]
Cross platform means desktop platforms and all the mobile platforms and even WebAssembly if you look at it
Speaker 2 [23:37]
So that was the final question. Thank you, Sean. Thank you so much. And give him a warm applause.