I am starting to investigate iOS 8 extensions, and I see that App Groups are the mechanism provided to pass data between the host app and the extension. This data sharing can be done with NSUserDefaults, flat files, and core data. When you setup an app group, a new directory is created on the device/simulator that is outside the application sandbox. That directory can be accessed from the host app and the extension, and it would appear that other apps from the same account/team can also access this directory.
Given all of this, I would like to know what the lifecycle of the shared App Group directory and its contents are. I have been unable to find any Apple documentation explaining this. Some empirical testing on the simulator has shown that when more than one application is installed that is accessing the app group, the directory is removed when the last application that has that App Group entitlement is removed. This is what I expected to see. I'd like some confirmation that this is the case. Also, is there any potential for the system purging this location under low disc conditions?
I'm trying to determine if it is "safe" to store my app's primary core data database in this App Group location, or if I should be making copies of data there instead. I don't want my main database to get wiped out from underneath me unexpectedly by the system.
Also, what is the intent for App Group directories? Should they be used for sharing data with extensions only, or are they intended as a general data sharing mechanism between apps from the same developer account/team?
I also posted this on the Apple Dev forums, and got an answer back from someone in Apple developer relations. Here is what they said:
Is there any potential for the system purging this location under low disc conditions?
That won't happen.
I'm trying to determine if it is "safe" to store my app's primary core data database in this App Group location, or if I should be making copies of data there instead.
Placing your core data store in an App Group directory is perfectly reasonable.
Also, what is the intent for App Group directories?
They are there so that suites of apps can shared data. I think the clearest expression of this comes from the Mac documentation. The "App Sandbox Design Guide" says:
[...] an application can use the com.apple.security.application-groups entitlement to request access to a shared container that is common to multiple applications produced by the same development team. This container is intended for content that is not user-facing, such as shared caches or databases.
Documentation
Related
My understanding is that because of sandboxing, it isn't possible to view any text file (ie config file) associated with an iOS app using another app. Something quite simple with Android. Am I mistaken?
I am trying to implement a text config file with a Unity iOS app that gets loaded and parsed once when the application boots.
This config file would also be able to be edited and saved manually on that actual iOS device.
(addendum)
In Unity there is PersistentDataPath which resolves to /var/mobile/Container/Data/Application/foo/Documents
Is there an iOS supported file explorer app that will allow me view and edit files in this location (without jailbreaking)?
Use can check iOS App Groups. It allows multiple apps access to shared containers and allow interprocess communication. There is no so much documentation about this, but maybe that's what you're looking for. At least you can share NSUserDefaults between the apps.
NSUserDefaults it's a most simple way to save any (not big) configurations for your app. For manual editing: if your app on the device signed with developer certificate, you can connect through any iOS supported file explorer app and edit it. But after release, from App Store, your app installed in restricted/private path, so it's not possible, if only you don't have a jailbreak.
Initial configuration you can put into your app bundle, and at the first run just copy them to NSUserDefaults.
Short answer: There are utilities such as iExplorer - https://macroplant.com - that allow "file manager" type access. However...
Long answer: If your app requires users to buy (or get) other software to modify configuration files, the chances of Apple approving it are slim to none.
The appropriate thing to do is to provide a User Interface in your own app which allows the user to modify / update the settings.
We have created a new project with the same app ID, but this is designated a different folder in isolated storage. Why is this?
file:///Users/houman/Library/Developer/CoreSimulator/Devices/FBFFFF1E-B5C8-4541-AB4B-ED1657D43EB9/data/Containers/Data/Application/EB3A549F-1604-4E5C-8FBE-3076A3D581E5/Documents/
file:///Users/houman/Library/Developer/CoreSimulator/Devices/FBFFFF1E-B5C8-4541-AB4B-ED1657D43EB9/data/Containers/Data/Application/22E1E792-1F4F-4F05-B7D9-F61AD3624EE9/Documents/
Even though the apps share the same ID.
Since they don’t share the same location, no core data migration can take place.
Any advice please?
Update:
We have two apps in the AppStore and would like to combine the functionality. Hence the idea is to use the appID of the other app to push a new release from a separate project. We have the appID and right certificates, but the isolated storage seems to depend on something else than just appid. Without that a migration of existing data to the new system won't be possible. Alternatively we could copy and paste all files into the other project and go through lots of pain. That might make it possible.
I have seen this on my end - I believe (and could be wrong) that each simulator you run in gets its own folder on the disk. If you switch for iPhone 5 to iPhone 6s for example you may end up with a different folder.
I always actually (when running in the simulator) print out the on-disk location so that I can take a look at the sqlite file if i need to and recently (as of xcode7) i've noticed this directory change between runs - however in my case i tracked it down to changing simulator versions.
Mainly for security reasons. Every iOS application is placed in an application sandbox.
This not only refer to an application's sandbox directory in the file system, granting security by limiting the access to user data stored on the device, system services, and hardware.
I want to keep an apps documents directory that contains sqlite using core data files in sync across users' devices. The sqlite files are the only files in the apps documents directory and simply need to be common to all users' devices
I've tried zipping up the sqlite files to send by email, which works with iTunes file sharing but is not suitable for my needs as it can expose the files to other users' devices.
I've tried using app groups to keep the directory common across devices http://blog.sam-oakley.co.uk/post/92323630293/sharing-core-data-between-app-and-extension-in-ios,
and
Accessing Core Data SQL Database in iOS 8 Extension (Sharing Data Between App and Widget Extension) but that simply did not share the directory across devices for me.
I've sent the file to parse, but pulling them down and reconfiguring the data was the problem there.
I've tried using iCloud and even the Apple engineer gave up on that one.
What I'm after is the simplicity of file sharing through iTunes (being able to replace the sqlite files) with a bit more finesse and without the need to plug in the device.
Some considerations
The whole model can be synced in one go
Data does not need constant syncing facilities, a manual sync option would suffice.
I am familiar with iCloud syncing, but I am new to app groups. There may be a simple answer to this question, but I haven't found it yet. Basically, I have an app in which I have iCloud integration, and now I want to try to add a today extension. I am currently using Core Data as a backend and would like to continue to do so. However, from what I have read, I need to move my data store to a shared location by defining an "App Group". (http://blog.sam-oakley.co.uk/post/92323630293/sharing-core-data-between-app-and-extension-in-ios-8 and Accessing Core Data SQL Database in iOS 8 Extension (Sharing Data Between App and Widget Extension)) I haven't been able to find out if this location is synced using iCloud or not. Or, because I"m using iCloud, do I need an App Group at all? I appreciate any and all help/suggestions.
If you're already using iCloud, you don't need to use app groups, because your extension can access the same iCloud container as your app does. As long as your entitlements and provisioning are configured correctly, you can literally just use the same Core Data stack setup in the extension as in the app.
Apple's Lister demo project does this, but there's nothing special about it. Just use iCloud as usual.
App groups are usually necessary to share data between apps and extensions. But a big exception is when the data is already stored external to the app-- as with iCloud.
How do I keep the users data when they get an update.
I use the Marmalade SDK to develop an app and I saved the user data to bin files and text files, I used the ram:// prefix when saving the files.
If I delete the app and get it from the app store again with the could symbol It had lost all its user data. I would like to release an update that doesn't delete the users data. The app does not come with any user data files, the app creates them as you use it.
Edit: Marmalade is cross platform but my question is for iOS only and the app has been publish, I am asking with respect to an existing app.
Deleting the app from the device, also removes it's sandbox. So any user data stored locally is deleted. This is expected behaviour.
If the user data comes from the web, then you just need to download it again.
Have you read the tutorial for dealing with files?
I have never used that sdk but:
rom for the read-only portion of your apps data area and is read only.
ram for the writable portion of your apps data area. This drive is the only drive that is guaranteed to exist across platforms
rst for a removable memory card on the phone or tablet
raw for paths that will be passed directly to the underlying operating system without modification. (not supported on all platforms)
tmp for a system temp folder, outside of the s3e data area. (system temporary folder and currently only available on iOS)
So maybe you could try rst:// and get the expected result?