feature: Official Native Mobile Extensions Before Flet v1

[fazi-gondal]

Duplicate Check

• I have searched the opened issues and there are no duplicates

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:

• feature: Support Native Media Gallery Indexing / scanFile API on Android (Serious Python) #6648 — Native Media Gallery Indexing / scanFile API on Android
  feature: 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:

• 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.

[fazi-gondal]

Hi @FeodorFitsner @ndonkoHenri — just a gentle follow-up on this one.

Since I opened this issue I’ve continued working on the media side of the gap. I now have a production-ready community extension that covers the first item on the list (flet-media-library / MediaStore):

• PyPI: https://pypi.org/project/flet-media-scanner/
• GitHub: https://github.com/fazi-gondal/flet-media-scanner
• Real-world usage: https://github.com/fazi-gondal/Vidsaver

It does silent MediaStore inserts (videos → Movies/<Album>), list, and delete by content URI, without broad storage permissions. It has been running in production for a while.

Related concrete issues:

• feature: Support Native Media Gallery Indexing / scanFile API on Android (Serious Python) #6648 — Native Media Gallery / MediaStore on Android
• feature: Share Intent Extension for Receiving Shared Content on Android & iOS #6671 — Share Intent

I’m happy to keep maintaining the package as a community extension, but I still believe the broader point of this issue stands: the most important mobile capabilities (media library, contacts, calendar, biometrics, printing, etc.) would be much more reliable for production apps if they lived under official or semi-official Flet maintenance.

No pressure at all — just wanted to leave an update and keep the conversation open in case the team has any thoughts on prioritising a small set of official mobile extensions.

Happy to adjust the existing media package (API, packaging, ownership) if that would ever help.

[fazi-gondal]

I wanted to share a follow-up to the earlier discussion around media-library support in Flet.

Since the previous issue, I have continued working on this area and have now built a reusable community package:

flet-media-library

It is a Flet service extension for Android and iOS that provides access to the device media library from Python.

The package currently supports:

• Photos, videos, and Android audio
• Per-media-type permissions
• Android 6–12 and Android 13+ permission models
• Android 14+ selected/limited visual media access
• iOS PhotoKit full/limited access
• Albums and media buckets
• Pagination, filtering, sorting, and date-range queries
• Media metadata
• Fast thumbnails
• Filesystem thumbnail paths to avoid unnecessary Base64 transfer
• Saving images and videos to the public gallery
• Saving audio to the Android Music directory
• Rename and move operations where supported
• Single and batch deletion
• Copy support where the platform allows it
• Live media-library change notifications
• Platform capability detection
• Typed exceptions for permission, platform, argument, and asset errors

The implementation uses photo_manager for the cross-platform media-library functionality, with a custom Android Kotlin implementation for functionality such as audio saving and Android-specific MediaStore operations.

The package also includes a working demo application demonstrating gallery browsing, thumbnails, media playback, camera preview, audio recording, gallery saving, moving, renaming, deletion, and other APIs.

Package/repository:
https://github.com/fazi-gondal/Flet-media-library

I think this is a useful example of how Flet extensions can provide deeper native platform functionality while keeping the application API Python-friendly.

I am sharing it here as a follow-up to the earlier discussion so people interested in media access, gallery integration, downloads, media applications, or native Flet extensions can see the current implementation and try it.

Feedback, suggestions, and use cases are welcome.