Duplicate Check
Describe the requested feature
Hi @FeodorFitsner @ndonkoHenri Flet already provides a strong cross-platform foundation, including Services such as Clipboard, FilePicker, Battery, Connectivity, Geolocator, sensors, Share, SecureStorage and others. It also has official extensions for capabilities such as Camera, Audio, Video, Maps and WebView.
However, there is still a gap in the mobile-native ecosystem.
Some of the remaining functionality can be implemented through community extensions or custom native code, but community extensions are not always maintained alongside Flet releases. This can make them difficult to rely on for production applications, especially when Flet's extension APIs or Flutter dependencies change.
For Flet to become a stronger choice for building production Android and iOS applications, I believe a set of officially maintained native extensions should be considered before Flet v1.
Suggest a solution
The goal is not to create one package for every possible API, but to cover the most important missing mobile capabilities:
| Extension |
Purpose |
flet-media-library |
Photos, videos, albums and device media |
flet-image-picker |
Pick photos/videos |
flet-image-manipulator |
Crop, resize, rotate and transform images |
flet-contacts |
Device contacts |
flet-calendar |
Device calendars/events |
flet-print |
Native printing/PDF printing |
flet-sqlite |
SQLite database |
flet-local-authentication |
Face ID, Touch ID and fingerprint |
flet-background-task |
Background execution |
flet-task-manager |
Background task registration |
flet-speech |
Native speech capabilities |
flet-screen-capture |
Screen capture/security APIs |
flet-screen-orientation |
Device orientation control |
flet-device |
Device/platform information |
flet-application |
Application metadata and native app APIs |
flet-store-review |
Native App Store/Play Store review |
Some of these could be added to existing Services rather than implemented as separate packages. The important part is having a stable, documented and officially maintained API.
Existing issues that demonstrate the need
There are already concrete examples of native mobile functionality requiring additional support:
These are not isolated problems. They are examples of the broader challenge of exposing platform-native functionality to Python/Flet applications without requiring developers to maintain their own Kotlin/Swift implementations.
Why official support matters
Flutter already has mature packages for many of these capabilities. Flet's extension architecture provides a good foundation for wrapping them and exposing a Python-first API.
The important difference between an official extension and a community extension is long-term compatibility and maintenance.
Official extensions could be:
- Tested against supported Flet versions
- Updated together with Flet releases
- Maintained when Flutter/Android/iOS APIs change
- Documented in the official Flet documentation
- Covered by Flet's CI/testing process
- Designed with consistent Flet APIs
This would make these APIs much safer to use in production.
Screenshots
No response
Additional details
Flet v1 is an important opportunity to establish the foundation of its mobile API.
If developers have to leave Flet and write Kotlin/Swift whenever they need common capabilities such as media libraries, contacts, calendars, printing or biometric authentication, Flet becomes much less attractive for building complete mobile applications.
I believe Flet should aim for:
Python / Flet
↓
Official Flet Extension
↓
Flutter Package / Native API
↓
Android + iOS
rather than requiring application developers to maintain platform-specific implementations themselves.
This doesn't mean Flet needs to copy Expo's API one-to-one. The goal is simply to provide the most important native capabilities through officially maintained Flet APIs.
Suggested goal
Consider making an Official Mobile Extensions initiative part of the Flet v1 roadmap, starting with the highest-impact capabilities such as:
Media Library → Image Picker → Image Manipulation → Contacts → Calendar → Print → SQLite → Local Authentication
and then expanding based on developer demand.
Flet already has the extension infrastructure and a large Flutter ecosystem available to build on. I believe investing in these official extensions before v1 would significantly strengthen Flet as a production-ready Python framework for Android and iOS.
Duplicate Check
Describe the requested feature
Hi @FeodorFitsner @ndonkoHenri Flet already provides a strong cross-platform foundation, including Services such as Clipboard, FilePicker, Battery, Connectivity, Geolocator, sensors, Share, SecureStorage and others. It also has official extensions for capabilities such as Camera, Audio, Video, Maps and WebView.
However, there is still a gap in the mobile-native ecosystem.
Some of the remaining functionality can be implemented through community extensions or custom native code, but community extensions are not always maintained alongside Flet releases. This can make them difficult to rely on for production applications, especially when Flet's extension APIs or Flutter dependencies change.
For Flet to become a stronger choice for building production Android and iOS applications, I believe a set of officially maintained native extensions should be considered before Flet v1.
Suggest a solution
The goal is not to create one package for every possible API, but to cover the most important missing mobile capabilities:
flet-media-libraryflet-image-pickerflet-image-manipulatorflet-contactsflet-calendarflet-printflet-sqliteflet-local-authenticationflet-background-taskflet-task-managerflet-speechflet-screen-captureflet-screen-orientationflet-deviceflet-applicationflet-store-reviewSome of these could be added to existing Services rather than implemented as separate packages. The important part is having a stable, documented and officially maintained API.
Existing issues that demonstrate the need
There are already concrete examples of native mobile functionality requiring additional support:
feature: Support Native Media Gallery Indexing / scanFile API on Android (Serious Python) #6648 — Native Media Gallery Indexing /
scanFileAPI on Androidfeature: Support Native Media Gallery Indexing / scanFile API on Android (Serious Python) #6648
feature: Share Intent Extension for Receiving Shared Content on Android & iOS #6671 — Share Intent Extension
feature: Share Intent Extension for Receiving Shared Content on Android & iOS #6671
These are not isolated problems. They are examples of the broader challenge of exposing platform-native functionality to Python/Flet applications without requiring developers to maintain their own Kotlin/Swift implementations.
Why official support matters
Flutter already has mature packages for many of these capabilities. Flet's extension architecture provides a good foundation for wrapping them and exposing a Python-first API.
The important difference between an official extension and a community extension is long-term compatibility and maintenance.
Official extensions could be:
This would make these APIs much safer to use in production.
Screenshots
No response
Additional details
Flet v1 is an important opportunity to establish the foundation of its mobile API.
If developers have to leave Flet and write Kotlin/Swift whenever they need common capabilities such as media libraries, contacts, calendars, printing or biometric authentication, Flet becomes much less attractive for building complete mobile applications.
I believe Flet should aim for:
rather than requiring application developers to maintain platform-specific implementations themselves.
This doesn't mean Flet needs to copy Expo's API one-to-one. The goal is simply to provide the most important native capabilities through officially maintained Flet APIs.
Suggested goal
Consider making an Official Mobile Extensions initiative part of the Flet v1 roadmap, starting with the highest-impact capabilities such as:
Media Library → Image Picker → Image Manipulation → Contacts → Calendar → Print → SQLite → Local Authentication
and then expanding based on developer demand.
Flet already has the extension infrastructure and a large Flutter ecosystem available to build on. I believe investing in these official extensions before v1 would significantly strengthen Flet as a production-ready Python framework for Android and iOS.