4 ms·

Apple’s implementation of enabling access to files is entirely different. I actually much prefer it because it sidesteps the self-dealing permissions bomb that

Apple’s implementation of enabling access to files is entirely different. I actually much prefer it because it sidesteps the self-dealing permissions bomb that Google just set off. In iOS, applications can use the File Provider API to present themselves in the Files app. You can move/copy/delete data there using the normal human interface constructs native to iOS, including mouse support and keyboard shortcuts on iPadOS. Apps can also present the same directory internally (inside the app). Cloud-backed applications can then do useful things like materialization, eviction, and dataless file presence. It doesn’t allow standing access to the entire filesystem, though. iOS only has support for applications reading outside their sandbox if the apps are from the same developer, and then they can call a pooled storage location for all apps that share the same “Team ID” (e.g., top level developer account/organization). It’s actually far easier (functionally) to grant access to your entire photo library, so for example you can have an app query and backup your photo library. “True” filesystem-wide backup requires hooking into the iOS backup/MobileFile hooks. Apple isn’t as hostile to third parties doing that as Google is to anyone accessing their own device data. But the process is more cumbersome by far.

nolist_policy 1y ago
> In iOS, applications can use the File Provider API to present themselves in the Files app. You can move/copy/delete data there using the normal human interface constructs native to iOS, including mouse support and keyboard shortcuts on iPadOS. > Apps can also present the same directory internally (inside the app). Cloud-backed applications can then do useful things like materialization, eviction, and dataless file presence. In Android apps can do all this with the SAF API. More importantly, on Android the user can give multiple apps access to the same directory, allowing apps to work together with files. iOS doesn't allow this AFAIK.
- apitman 1y ago
  SAF doesn't work with native code, which really sucks if you're trying to make a cross-platform app.
  - nolist_policy 1y ago
    Native code can work with files inside the app data folder. Then you can expose that folder with SAF in a separate Activity. Termux does this and it works really well.
  - pjmlp 1y ago
    Yes it does, nothing forbids someone to write a bit of Java, invoked via Android IPC, no need to be allergic. Too many folks keep pretending Android is GNU/Linux
radlad 1y ago
This is basically exactly how Android MediaStore API works too: https://developer.android.com/training/data-storage/shared/media https://developer.android.com/training/data-storage/shared/m... The difference is that Android also has APIs (which require user permission and are, at this point, mostly deprecated or heavily discouraged through Play Store policy, hence what happened to NextCloud) which offer filesystem-level access to files created by other apps. This has historically allowed for apps like NextCloud and SyncThing to offer automatic backup or syncing. SyncThing ran into similar problems recently: https://news.ycombinator.com/item?id=41895718 https://news.ycombinator.com/item?id=41895718
antman 1y ago
Cloud applications can do nil, because the api for the background transfers is only working for iCloud, Nextcloud and other apps in the background get a couple of kb/s effectively pushing you to pay apple. Great Dark pattern from Apple that has been going on for years.
- TheNewsIsHere 1y ago
  I’ve heard this admonishment from the developer community, but I haven’t run into this issue myself. I expect there is some kind of dynamic at play rather than a strict hard and fast rule in the OS. I’ve got multiple independent apps that do background sync to various destinations and I’ve never had any problems. Depending on how much data and processing is needed for a sync, sometimes they do get stopped by the OS, especially when on battery power, but they resume when the app is opened. This hasn’t been a big issue for me. Almost all of the problems I’ve had with this kind of workload have been specific to the OneDrive app, and it doesn’t seem to matter whether it’s a SPO/business or MSA/personal account, or whether via the Files app or native app UI.

nolist_policy 1y ago

> In iOS, applications can use the File Provider API to present themselves in the Files app. You can move/copy/delete data there using the normal human interface constructs native to iOS, including mouse support and keyboard shortcuts on iPadOS. > Apps can also present the same directory internally (inside the app). Cloud-backed applications can then do useful things like materialization, eviction, and dataless file presence. In Android apps can do all this with the SAF API. More importantly, on Android the user can give multiple apps access to the same directory, allowing apps to work together with files. iOS doesn't allow this AFAIK.

apitman 1y ago
SAF doesn't work with native code, which really sucks if you're trying to make a cross-platform app.
- nolist_policy 1y ago
  Native code can work with files inside the app data folder. Then you can expose that folder with SAF in a separate Activity. Termux does this and it works really well.
- pjmlp 1y ago
  Yes it does, nothing forbids someone to write a bit of Java, invoked via Android IPC, no need to be allergic. Too many folks keep pretending Android is GNU/Linux

radlad 1y ago

This is basically exactly how Android MediaStore API works too: https://developer.android.com/training/data-storage/shared/media https://developer.android.com/training/data-storage/shared/m... The difference is that Android also has APIs (which require user permission and are, at this point, mostly deprecated or heavily discouraged through Play Store policy, hence what happened to NextCloud) which offer filesystem-level access to files created by other apps. This has historically allowed for apps like NextCloud and SyncThing to offer automatic backup or syncing. SyncThing ran into similar problems recently: https://news.ycombinator.com/item?id=41895718 https://news.ycombinator.com/item?id=41895718

antman 1y ago

Cloud applications can do nil, because the api for the background transfers is only working for iCloud, Nextcloud and other apps in the background get a couple of kb/s effectively pushing you to pay apple. Great Dark pattern from Apple that has been going on for years.

TheNewsIsHere 1y ago
I’ve heard this admonishment from the developer community, but I haven’t run into this issue myself. I expect there is some kind of dynamic at play rather than a strict hard and fast rule in the OS. I’ve got multiple independent apps that do background sync to various destinations and I’ve never had any problems. Depending on how much data and processing is needed for a sync, sometimes they do get stopped by the OS, especially when on battery power, but they resume when the app is opened. This hasn’t been a big issue for me. Almost all of the problems I’ve had with this kind of workload have been specific to the OneDrive app, and it doesn’t seem to matter whether it’s a SPO/business or MSA/personal account, or whether via the Files app or native app UI.