Re:Surface Go 2, Surface Book 3, Surface Headphones 2 and Su...
by derefr on Wednesday May 06, 2020 @02:06PM
(#23094323)
> had a real filesystem and I could easily load comics and movies on
Apps might not expose the iPadOS filesystem well (since they've gradually accreted a UX paradigm over the last 10 filesystem-less years), but it actually does work perfectly well to open files from your iPadOS home directory [the thing the Files app exposes] in any app that can handle that file type. You can open video files from Files into VLC; you can open CBRs/CBZs into https://chunkyreader.com/ ; etc.
For getting the files in/out of the iPad, Files can access external disks just fine (I've been using a Samsung USB-C T5 SSD); and Safari (don't know about other browsers) now allows you to save arbitrary files, putting your downloads in a regular Downloads folder within the Files-visible homedir. I'm sure there are other methods as well (e.g. copying files to the iPad's local storage from a storage provider, e.g. iCloud Drive, or Dropbox, or an SFTP/S3 client's host profile; or using a BitTorrent client to download whatever.)
Of course, apps can't access your homedir arbitrarily if they don't have the relevant capability, but that's just good sandboxing—if an app only works with particular files, it should only be receiving capabilities on individual files (through e.g. the Share/Open With action), not capabilities on your filesystem as a whole. The only reason desktop OSes aren't already mostly this way is the inertia of legacy apps.
(There's also nothing stopping a local POSIX terminal emulator app from creating a shared container that other apps like IDEs can write into, if you're wondering. Nobody's bothered yet, but that's because everyone wants to own your eyeballs with fully-integrated single-app solutions, not because it's not technically possible. You could totally build the equivalent of Termux for iPadOS. The only limitation would be that the package ecosystem would have to use the App Store as its package manager, with packages containing executables being distributed as Apple-signed extension "apps." Sort of like how iMessage's sticker-pack "apps" work, or how Photos.app's filter-pack "apps" work; or how Safari's content-blocker "apps" work. Or, come to think of it, exactly like how XCode.app attaches its POSIX tooling into the [read-only] macOS rootfs.)
Apps might not expose the iPadOS filesystem well (since they've gradually accreted a UX paradigm over the last 10 filesystem-less years), but it actually does work perfectly well to open files from your iPadOS home directory [the thing the Files app exposes] in any app that can handle that file type. You can open video files from Files into VLC; you can open CBRs/CBZs into https://chunkyreader.com/ ; etc.
For getting the files in/out of the iPad, Files can access external disks just fine (I've been using a Samsung USB-C T5 SSD); and Safari (don't know about other browsers) now allows you to save arbitrary files, putting your downloads in a regular Downloads folder within the Files-visible homedir. I'm sure there are other methods as well (e.g. copying files to the iPad's local storage from a storage provider, e.g. iCloud Drive, or Dropbox, or an SFTP/S3 client's host profile; or using a BitTorrent client to download whatever.)
Of course, apps can't access your homedir arbitrarily if they don't have the relevant capability, but that's just good sandboxing—if an app only works with particular files, it should only be receiving capabilities on individual files (through e.g. the Share/Open With action), not capabilities on your filesystem as a whole. The only reason desktop OSes aren't already mostly this way is the inertia of legacy apps.
(There's also nothing stopping a local POSIX terminal emulator app from creating a shared container that other apps like IDEs can write into, if you're wondering. Nobody's bothered yet, but that's because everyone wants to own your eyeballs with fully-integrated single-app solutions, not because it's not technically possible. You could totally build the equivalent of Termux for iPadOS. The only limitation would be that the package ecosystem would have to use the App Store as its package manager, with packages containing executables being distributed as Apple-signed extension "apps." Sort of like how iMessage's sticker-pack "apps" work, or how Photos.app's filter-pack "apps" work; or how Safari's content-blocker "apps" work. Or, come to think of it, exactly like how XCode.app attaches its POSIX tooling into the [read-only] macOS rootfs.)