5 ms·

Sandboxing and App Stores do not prevent powerful software tools being developed. You can have first-class video editors, painting and photo manipulation, and c

Sandboxing and App Stores do not prevent powerful software tools being developed. You can have first-class video editors, painting and photo manipulation, and coding environments. You might not be able to do absolutely everything you could with unfettered access, but that hardly leads to "mostly toys." The nature of mobile apps stems far more from the use case of the devices (user attention measured in seconds, rather than minutes) than limitations of the software development platforms.

karmelapple 11y ago
The sandboxing of mobile apps - at least on iOS - was always sold as a feature that respected this handheld computer was also a phone, and needed the voice chat reliability of a pre-smartphone. If you have any suspicion that installing an app will cause your phone call with your grandmother to be interrupted, you will really scrutinize what you install. Early Android devices tended to have more problems than iOS devices when it came to phone calls getting interrupted, so whether this was marketing making an excuse for something Apple wanted on s technical level, it seems sandboxing was with the use case of "keep the phone working" firmly in mind.
userbinator 11y ago
Sandboxing and App Stores do not prevent powerful software tools being developed. You can have first-class video editors, painting and photo manipulation, and coding environments I don't doubt that - but the problem is that everything you do with one app must almost always stay within that one. It's only when you want to exchange data between apps that all the power of the traditional full-access model really shines, and the reason why people have resorted to some horribly inefficient workarounds (e.g. upload to some server on the Internet from one app, then download the data in another) to do this.
- interpol_p 11y ago
  That's not an insurmountable problem though, and sandboxed environments are getting better in this regard. E.g., it is now possible in iOS to launch one application from another which edits the source document directly — not a copy. That said, the notion of a file system isn't inherently incompatible with sandboxing. If you allow the user to grant permission on a per-app basis whether those apps can read/write to a common data store, you essentially have the benefits of a local file system in a way that does not break sandboxing. You only want to sandbox apps to keep them from touching the OS and other private app data. If it is user-permitted for them to touch a common data store then that means data does not always have to stay within the app in which it was created.
  - TeMPOraL 11y ago
    Fair, but I also want to grant sandbox apps to touch the OS and other private app data. The way how on desktop I can use Emacs to edit /etc/hosts, or MS Paint to change some other program's splash screen.
    - interpol_p 11y ago
      Well that defeats the purpose of a sandbox. A sandbox is specifically to disallow apps from touching OS or private data. But there's no reason such apps can't live side-by-side. I use Emacs to edit my hosts file, it's pretty convenient. A sandboxed Emacs would not be. But I don't mind if the painting app I download is sandboxed because I'm going to be dragging-and-dropping my artwork into that program and I don't want it having access to my disk or network outside its sandbox.
    - geofft 11y ago
      There are methods for solving that, like powerboxes: http://plash.beasts.org/powerbox.html http://plash.beasts.org/powerbox.html I believe that Apple's desktop sandbox does use powerboxes, in that the Open dialog is privileged code and hands the app an open file handle. But it means that you can't tell Emacs to edit an entire source code directory. BBEdit had exactly this complaint about the sandbox.

karmelapple 11y ago

The sandboxing of mobile apps - at least on iOS - was always sold as a feature that respected this handheld computer was also a phone, and needed the voice chat reliability of a pre-smartphone. If you have any suspicion that installing an app will cause your phone call with your grandmother to be interrupted, you will really scrutinize what you install. Early Android devices tended to have more problems than iOS devices when it came to phone calls getting interrupted, so whether this was marketing making an excuse for something Apple wanted on s technical level, it seems sandboxing was with the use case of "keep the phone working" firmly in mind.

userbinator 11y ago

Sandboxing and App Stores do not prevent powerful software tools being developed. You can have first-class video editors, painting and photo manipulation, and coding environments I don't doubt that - but the problem is that everything you do with one app must almost always stay within that one. It's only when you want to exchange data between apps that all the power of the traditional full-access model really shines, and the reason why people have resorted to some horribly inefficient workarounds (e.g. upload to some server on the Internet from one app, then download the data in another) to do this.

interpol_p 11y ago
That's not an insurmountable problem though, and sandboxed environments are getting better in this regard. E.g., it is now possible in iOS to launch one application from another which edits the source document directly — not a copy. That said, the notion of a file system isn't inherently incompatible with sandboxing. If you allow the user to grant permission on a per-app basis whether those apps can read/write to a common data store, you essentially have the benefits of a local file system in a way that does not break sandboxing. You only want to sandbox apps to keep them from touching the OS and other private app data. If it is user-permitted for them to touch a common data store then that means data does not always have to stay within the app in which it was created.
- TeMPOraL 11y ago
  Fair, but I also want to grant sandbox apps to touch the OS and other private app data. The way how on desktop I can use Emacs to edit /etc/hosts, or MS Paint to change some other program's splash screen.
  - interpol_p 11y ago
    Well that defeats the purpose of a sandbox. A sandbox is specifically to disallow apps from touching OS or private data. But there's no reason such apps can't live side-by-side. I use Emacs to edit my hosts file, it's pretty convenient. A sandboxed Emacs would not be. But I don't mind if the painting app I download is sandboxed because I'm going to be dragging-and-dropping my artwork into that program and I don't want it having access to my disk or network outside its sandbox.
  - geofft 11y ago
    There are methods for solving that, like powerboxes: http://plash.beasts.org/powerbox.html http://plash.beasts.org/powerbox.html I believe that Apple's desktop sandbox does use powerboxes, in that the Open dialog is privileged code and hands the app an open file handle. But it means that you can't tell Emacs to edit an entire source code directory. BBEdit had exactly this complaint about the sandbox.