With PySide6 adding iOS support alongside existing Python mobile options such as BeeWare and Flet, I'm curious which real-world iOS applications are currently being built with Python and a UI framework. Small calculators and proof-of-concept demos are easy to find, but I'm especially interested in substantial or production applications that have reached users. How do these projects handle App Store approval, application size, startup performance, native iOS APIs, and packaging third-party dependencies? Python becoming officially available for iOS should make deployment easier, but I'd like to hear about practical projects and experiences rather than just framework announcements.
4 Answers
Most Python-based iOS examples I’ve come across are still small utilities, demonstrations, or early-stage projects. The showcase applications from the major frameworks are useful, but there don’t seem to be many widely known, production-scale apps yet. The ecosystem is improving, though, so that may change as the newer iOS support matures.
A desktop Python or Qt application usually can’t just be deployed unchanged to a phone. The interface generally needs to be redesigned for touch, smaller screens, navigation conventions, and platform-specific behavior. Python frameworks can make code sharing easier, but iOS integration and the relatively small user base still mean there are likely to be rough edges compared with Apple’s primary development tools.
I’m working on an iOS app that lets users control layouts through external servers. It includes a large collection of controls and displays, notifications, Dynamic Island support, widgets, Control Center integration, and the ability to send iPhone sensor data back to the servers. It’s currently in TestFlight, but development has been steady. It’s a good example of a Python mobile project being more than a simple demo, even though it isn’t publicly released yet.
The Python runtime itself isn’t necessarily the biggest problem. In Flet’s case, adding Python to the application bundle costs roughly 10–12 MB, while still providing threads and much of the standard library. The harder part is packaging native dependencies such as libraries written in C, C++, or Rust. Packages like NumPy, Pydantic, and Cryptography need compatible iOS wheels, and many projects still have to solve that distribution problem themselves. There are also signing complications when frameworks depend on components such as OpenSSL. Despite that, teams are already getting Python applications through both the iOS and Android store review processes.
That makes sense. It sounds like dependency wheels and signing requirements are more important practical blockers than the size of the interpreter itself, especially for apps that need scientific or security-related packages.
That sounds like a genuinely interesting use case. Supporting widgets, sensors, and the Dynamic Island should provide a useful test of how well the framework handles native iOS features.