feat: Add support for AppDocuments, AppLibrary and AppTemp (#12276) #14598
Conversation
…2276) Previously, there was no access to 3 specific paths used by iOS. We have added support for these directories, and added documentation explaining how these different methods are meant to be used. This also required the creation of a Swift plugin to allow us to access these iOS APIs. In this process, we have added a page to the sample views to immediately see the output of the different path methods. This required some visual fixes of the examples/api app for the menu button to be usable on modern Android devices to work with insets.)feat: Add support for AppLibrary, AppTemp, and AppCache (tauri-apps#12276) Previously, there was no access to 3 specific paths used by iOS. We have added support for these directories, and added documentation explaining how these different methods are meant to be used. This also required the creation of a Swift plugin to allow us to access these iOS APIs. In this process, we have added a page to the sample views to immediately see the output of the different path methods. This required some visual fixes of the examples/api app for the menu button to be usable on modern Android devices to work with insets.)
|
|
||
| /// Returns the path to the app's documents directory. | ||
| pub fn app_documents_dir(&self) -> Result<PathBuf> { | ||
| self.call_resolve("getFilesDir") |
There was a problem hiding this comment.
Both of these methods call getFilesDir and return the same path. What about external files directory on Android? Would this be a better fit for app_documents_dir? How is this pattern handled in other platforms like Expo, MAUI etc?
There was a problem hiding this comment.
I have mixed thoughts on where the entry point for getExternalFilesDir should exist.
I lean strongly toward it being a completely separate method because it simply doesn't exist on the other platforms, and I don't know how much we are expecting devs to fully read the docs to understand the mapping from API method to the actual implementation.
However, if this all should be handled in Tauri V3, perhaps this new method can point to getExternalFilesDir, and we can add comments at the Rust and TS layers describing the behavior on Android.
Does that make sense @velocitysystems ?
Cross-platform comparison (brought to you by Claude 😄 )
Expo (React / Expo FileSystem)
Exposes only app-scoped directories (documentDirectory, cacheDirectory).
On Android these map to internal app storage (effectively Context.getFilesDir() / getCacheDir()).
There is no API surface for getExternalFilesDir(); user-visible files are handled via sharing or pickers.
Rationale: maintain strict iOS parity and hide Android-specific storage topology.
.NET MAUI
Exposes AppDataDirectory and CacheDirectory, which on Android map to internal app storage (getFilesDir(), getCacheDir()).
MAUI does not expose external app storage in the cross-platform API.
Access to getExternalFilesDir() requires platform-specific Android code, intentionally outside the portable abstraction.
Capacitor (used with web stacks, often compared to Electron on mobile)
Exposes a Directory enum (Data, Cache, Documents, External, ExternalStorage, etc.).
On Android, the native plugin explicitly maps:
Data→getFilesDir()(internal storage)Cache→getCacheDir()(internal storage)Documents→getExternalFilesDir(Environment.DIRECTORY_DOCUMENTS)(app-specific external storage)External→getExternalFilesDir(null)(app-specific external storage root)ExternalStorage→ primary shared/external storage (separate fromgetExternalFilesDir(); requires special permissions on Android 10+)
This is the only examined cross-platform stack that intentionally exposes Android external app storage as a first-class concept.
Electron (desktop)
Not applicable to Android; uses OS-level concepts (userData, documents, downloads).
There is no internal/external distinction analogous to Android; mobile behavior depends on wrappers (e.g., Capacitor).
Summary
Most cross-platform frameworks (Expo, MAUI) collapse Android internal vs external app storage into a single "app data" abstraction to preserve iOS parity. Capacitor is the notable exception, explicitly modeling getExternalFilesDir() in its cross-platform API, with the caveat that ExternalStorage access requires additional permissions on Android 10+ due to scoped storage restrictions.
feat: Add support for AppLibrary, AppTemp, and AppCache (#12276)
Previously, there was no access to 3 specific paths used by iOS.
We have added support for these directories, and added documentation
explaining how these different methods are meant to be used.
This also required the creation of a Swift plugin to allow us to access
these iOS APIs.
There was a thought that we would be able to add access to these directories
by setting a feature flag in the plugin and having conditional retrieval of
the needed directories.
However, this proved to be much more complex than needed, since in reality we are able to
make this a purely additive change, with the only changed output being for the
appCacheDirmethod on iOS. In the related issue #12276 , it was stated this could be acceptable.Comparisons of the returned values before and after these changes for both Android and iOS are
attached here.
Android comparison:
PostChangeResults-Android.csv
iOS comparison:
PostChangeResults-iOS.csv
In this process, we have added a page to the sample views to immediately
see the output of the different path methods.
This required some visual fixes of the examples/api app for the menu button
to be usable on modern Android devices to work with insets.)