If you create a document (e.g. with Apple’s Keynote) or receive one via E-Mail you possibly want to further work with it in another app. In Apple’s filesystem this is not possible by default.Interactions of an iOS app are limited mostly to the folders associated with it. This limitation is labeled Sandbox-Mode and was designed to increase the security of the filesystem. Unfortunately it also decreases the usability in many cases.
One exception to this rule occurs when an app uses public system interfaces to access things such as the user’s contacts or music. In those cases, the system frameworks handle any file-related operations needed to read from or modify the appropriate data stores.
Although usability is decreased Apple continues it’s file system implementation in iOS 7.
During installation of a new app, the installer code creates a home directory for the app, places the app in that directory ( /AppName .app) and creates several other key directories. These directories constitute the app’s primary view of the file system and represents the universe for that app and contains everything the app can access directly.
Further directories in the iOS file system …
Developers should use this directory to store critical user documents and app data files. Critical data is any data that cannot be recreated by your app, such as user-generated content.
The contents of this directory can be made available to the user through file sharing. The contents of this directory are backed up by iTunes.
Developers should use this directory to access files that your app was asked to open by outside entities. Specifically, the Mail program places email attachments associated with your app in this directory; document interaction controllers may also place files in it.
Your app can read and delete files in this directory but cannot create new files or write to existing files. If the user tries to edit a file in this directory, your app must silently move it out of the directory before making any changes.
The contents of this directory are backed up by iTunes.
This directory is the top-level directory for files that are not user data files. You typically put files in one of several standard subdirectories but you can also create custom subdirectories for files you want backed up but not exposed to the user. You should not use this directory for user data files.
The contents of this directory (with the exception of the Caches subdirectory) are backed up by iTunes.
Developers should use this directory to write temporary files that do not need to persist between launches of your app. Your app should remove files from this directory when it determines they are no longer needed. (The system may also purge lingering files from this directory when your app is not running.) In iOS 2.1 and later, the contents of this directory are not backed up by iTunes.
See the folder structure of an iOS device revealed with the app iExplorer.
So … Every app is an
But don’t worry. There is a functionality which will reassure you.
It’s called ‘Open in…‘ and looks like this
The example shows a website opened in Safari which was converted into a PDF file by using a small piece of code entered in the address bar of Safari.
Another (well-known) application is tapping on an attachment within an E-Mail (e. g. a PDF-Document). The ‘Open in…’-Dialog comes up and you can select an appropriate app for further viewing or editing e.g. Documents by Readdle.
Every app is an
‘Open in…’ forwards your document to Adobe-Island without deleting it on E-Mail-Island. So now you have two redundant copies of the PDF file.
What You have to do is:
Take care of your devices memory.
Locking up an app in it’s app specific folder and limiting it’s access to it’s folder and subfolders brings security to iOS devices. This is called the Sandbox Mode.
So security of an iOS device is given by design.
Additionally Apple screens all apps offered in their App Store whether the code contains procedures compromising the device’s security. The security can be affected by the services the app has permission to. The actual versions of iOS asks for permissions to access location services, contacts, camera roll, etc. for every app which is installed on the device and opened for the first time.
This stats published by MyAppleNews Blogspot shows the consequences of Apple’s design concept for it’s operating system.
Pros and cons …
From a technical point of view, there are a number of benefits that come up with this approach.
Apple’s file system doesn’t reflect the way people work on projects.
Useful information you want to combine in an article on your website might be spread over many app specific folders of your device.
To collect them all and further keep them together can escalate to a troublesome even annoying procedure.
Usually there are lots of apps installed on an iOS device because of all the flaws coming up with one app and compensated by an additionally installed app.
Creating projects cannot be done by thinking on islands. For presenting comprehensive information you need a boat and have to visit all the other islands of interest.
My suggestion for iOS 7 was to allow apps saving some file types in a PUBLIC folder with access from other apps. The limitation to solely access the photo library is insufficient. Sad to say that Apple didn’t go this way in iOS 7.
Related links …
Out of memory
I reworked this article on August 22, 2013.
Thanks for visiting http://iNotes4You.com.