In my app I'm doing background sync of contacts, and when the device is locked the app crashes:
Terminating app due to uncaught exception 'RLMException', reason:
'/var/mobile/Containers/Data/Application/FF77C6DA-970E-4FDD-AB69-C10C20607243/Documents/MyApp/default.realm.lock:
Unable to open a realm at path
'/var/mobile/Containers/Data/Application/FF77C6DA-970E-4FDD-AB69-C10C20607243/Documents/MyApp/default.realm.lock':
open() failed: Operation not permitted.'
I tried:
Creating a new folder:
NSError *error;
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0]; // Get documents folder
NSString *dataPath = [documentsDirectory stringByAppendingPathComponent:#"/MyApp"];
if (![[NSFileManager defaultManager] fileExistsAtPath:dataPath])
[[NSFileManager defaultManager] createDirectoryAtPath:dataPath withIntermediateDirectories:YES attributes:nil error:&error]; //Create folder
and then create the .realm file in this folder, and set the file protection to None. along with NSFilePosixPermissions
[[NSFileManager defaultManager] setAttributes:#{NSFileProtectionKey: NSFileProtectionNone,
NSFilePosixPermissions : [NSNumber numberWithShort:0777]
}
ofItemAtPath:[[[RLMRealm defaultRealm]configuration]fileURL].URLByDeletingLastPathComponent.path error:nil];
Still the app crashes when device is locked while syncing.
Any ideas on how to fix this ?
Having data protection on intentionally interferes with access in certain conditions (like when the device is locked).
The default level of protection is complete protection, in which files are encrypted and inaccessible when the device is locked. You can programmatically set the level of protection for files created by your app, as described in Protecting Data Using On-Disk Encryption in App Programming Guide for iOS. For files stored in shared containers (described in Configuring App Groups), set the level of protection programmatically.
(from https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGuide/AddingCapabilities/AddingCapabilities.html)
This link also shows where Data Protection is enabled in your Xcode project (specifically, the entitlements for a target), in the event that you're not sure if it's been enabled or not.
If your app needs the benefits of Data Protection but at a more granular level than all-or-nothing, you'll need to dig into the "Protecting Data Using On-Disk Encryption" section referenced in the copy from Apple's docs.
Related
With Swift or with Obj-C, I have done an app, and I store sensitive data in a specific folder in the app. Now, I would like the user not be able to see that folder and not able to copy it on his computer, or the best, to hide it with software like iMazing for example.
I tried to add a ".", this is not a solution at all: How to hide folder in NSDocumentsDirectory and disallow backup via iTunes & iCloud
I tried to store it in the Library folder, this is not a solution too, as it is accessible in iMazing: How to hide folders created in Document Directory in ios?
I don't want to use the Application supports iTunes file sharing because I need to access to the documents folder from the app with iMazing.
Does exist an intelligent and subtil solution that allows to store some files in the iPad not accessible with iMazing and not carried to the extreme as the "all or nothing" Application supports iTunes file sharing option?
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES);
NSString *libraryDirectory = [paths objectAtIndex:0];
BOOL isDir = NO;
NSError *error;
if (! [[NSFileManager defaultManager] fileExistsAtPath:libraryDirectory isDirectory:&isDir] && isDir == NO) {
[[NSFileManager defaultManager] createDirectoryAtPath:libraryDirectory withIntermediateDirectories:NO attributes:nil error:&error];
}
NSString *pathLibToCreate = [libraryDirectory stringByAppendingPathComponent:#"testDoc"];
NSString *pathDocToCreate = [[self documentsDirectory] stringByAppendingPathComponent:#"testDoc"];
if (![[NSFileManager defaultManager] fileExistsAtPath:pathLibToCreate]) {
[[NSFileManager defaultManager] createDirectoryAtPath:pathLibToCreate withIntermediateDirectories:NO attributes:nil error:&error];
}
if ([[NSFileManager defaultManager] fileExistsAtPath:pathDocToCreate]) {
[[NSFileManager defaultManager] removeItemAtPath:pathDocToCreate error:nil];
}
NSError *copyError = nil;
if (![[NSFileManager defaultManager] copyItemAtPath:pathLibToCreate toPath:pathDocToCreate error:©Error]) {
NSLog(#"Error copying files: %#", [copyError localizedDescription]);
}
Thanks in advance.
If you use "File Sharing" permission to NO and if you use a distribution profile, you won't be able to view your files in Amazing.
I guess that it is because you use a developer profile for your app and then you're able to view these files.
I think this is not possible, at least if an user has a jailbroken device where he has access to all files on the system.
To prevent the user from having access to the content of a file, one option could be to encrypt the content of the file. Using the CommonCryptor framework that should be an easy task.
For encrypted databases you could use SQLCipher.
I'm one of the devs of iMazing. Indeed, the accepted answer is correct: iMazing and other similar tools will give access to the app's sandbox when in development. But there are 3 more cases to be aware of:
Jailbroken devices
iMazing will display all files, read/write access.
Devices running a version of iOS prior to iOS 8.3
Same here - before iOS 8.3, we could have access to app sandboxes, read/write too.
Access via iTunes backup
iMazing and similar tools have backup browsers which will let users see app sandboxes. Library and Documents folders, not Caches or tmp. If you really want to be safe, you'll need to explicitly exclude files from the backup. Of course, this has substantial drawbacks...
I am trying to copy a zip file in "appname/Documents/" folder in iCloud. I copied the file using NSFileManager.
NSURL *ubiq = [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil];
NSString *ubiqPath = [ubiq path];
NSError *error;
[[NSFileManager defaultManager] copyItemAtPath:[DocumentsDirectory stringByAppendingString:#"/Documents.zip"] toPath:[ubiqPath stringByAppendingString:#"/Documents/Documents.zip"] error:&error];
The problem is, the zip file isn't synchronizing across the devices. fileExistsAtPath: returns YES for first device and NO for the second device. I tried with an iPhone and an iPad.
Another important thing is, I used iExplorer to browse both devices and found that the zip file is in both device's "iCloud/appname/Documents/" path. It's getting really confusing for me.
I have a core data app, I am sending the sqlite files to Dropbox.
//Upload files
NSString *filePath = [[NSHomeDirectory() stringByAppendingPathComponent:#"Documents"] stringByAppendingPathComponent:#"myApp.sqlite"];
NSString *filePath1 = [[NSHomeDirectory() stringByAppendingPathComponent:#"Documents"] stringByAppendingPathComponent:#"myApp.sqlite-shm"];
NSString *filePath2 = [[NSHomeDirectory() stringByAppendingPathComponent:#"Documents"] stringByAppendingPathComponent:#"myApp.sqlite-wal"];
[restClient uploadFile:#"myApp.sqlite" toPath:#"/Data" withParentRev:nil fromPath:filePath];
[restClient uploadFile:#"myApp.sqlite-shm" toPath:#"/Data" withParentRev:nil fromPath:filePath1];
[restClient uploadFile:#"myApp.sqlite-wal" toPath:#"/Data" withParentRev:nil fromPath:filePath2];
Problem is with this method is the -WAL file lags behind and sometimes doesn't arrive. Ive tried to making a zip folder with ZipArchive but when it arrives it can never be opened. The sqlite, wal and shm are the only files in the documents directory so ive tried creating a folder to upload in one go but couldn't get this to upload correctly to Dropbox. I could just stop journal mode and have the single sqlite file, any pitfalls of doing this with an app that currently using journal mode? On testing, stopping journal mode on the update didn't cause any problems with lost data but not sure if something wouldnt come out the woodwork later on a s this app is live on the appstore with journal mode on.
I got a real strange problem with an iOS app I'm currently working at. The effect only exists if I test the app using ad hoc distribution. After updating the app (it has to be installed before) it wasn't working correctly. I could track the error down and it is caused by following line of code:
[fileManager createDirectoryAtPath:folder withIntermediateDirectories:YES attributes:nil error:&error];
Now you could say, of course: Don't ever write to the app bundle itself, but the base path is the Documents folder via:
dirPaths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
docsDir = [dirPaths objectAtIndex:0];
imgDir = [docsDir stringByAppendingPathComponent:#"images"];
folder = [imgDir stringByAppendingPathComponent:md5]; // md5-Hash is created before
The complete error message (logged to iphone system log) is:
Error Domain=NSCocoaErrorDomain Code=513 "The operation couldn’t be completed. (Cocoa error 513.)" UserInfo=0x14d44f30 {NSFilePath=/var/mobile/Applications/280C6D36-3667-4589-A74F-42F3F17ABA71/Documents/images/39b6cd45a05a2276ef065b2ecf33b1eb, NSUnderlyingError=0x14d4e340 "The operation couldn’t be completed. Operation not permitted"}
The interesting thing is, as I noted, if I delete the app before installing via ad hoc distribution (Testflight to a iPhone 5 with iOS 7.0.4) the folder is created and the App works as expected. The only references I could find were developers not using stringByAppendingPathComponent or writing directly to the app bundle. Maybe anybody else got the problem or has an idea?
I finally found the reason why the folder could not be created. Afterwards it seems pretty simple and stupid, but if you could take a look at the complete source code you would unterstand how this could happen. In my defense I have to say that I came to this project for further development because the original developer left the project. For your better understanding I simplified the code a lot.
dirPaths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
docsDir = [dirPaths objectAtIndex:0];
imgDir = [docsDir stringByAppendingPathComponent:#"images"];
The imgDir was actually saved in userPreferences and a proxy class always returned the saved path, which is a really bad idea. During the update process the app gets a new guid which reflects in the apps documents path. So trying to create a folder in the previous version documents folder had to fail as it doesn't exist anymore. I corrected the code to never save the path and always return the current one with the code above.
I've met a problem with core data.
The simple app is to create documents, and the first view controller will show all the documents I've created, which is store in a core data database.
When I was running the program on the iOS simulator, it works fine. And when I run the app on iOS device when connecting the iPad with mac, it works fine, too.
But when I disconnect the iPad from the Mac, or stop running the program in xCode, the app still can run on my iPad. But all the documents created before are not loaded. I can still create documents and they appears on the view controller correctly. But when I stop the app and launch it again, the bookshelf is still empty... Those documents are not loaded from the core data database.
Can you help me with this?
Thanks!
If your app is deployed to iOS 5.1 or newer, then you should be using the "Documents/Application Support" folder, and also marking the documents if you do not want them backed up to iCloud. I am finding I need to create "Application Support" if its not there. This is the code I use:
NSFileManager *manager = [NSFileManager defaultManager];
NSString *appSupportDir = [self applicationAppSupportDirectory];
if(![manager fileExistsAtPath:appSupportDir]) {
__autoreleasing NSError *error;
BOOL ret = [manager createDirectoryAtPath:appSupportDir withIntermediateDirectories:NO attributes:nil error:&error];
if(!ret) {
NSLog(#"ERROR app support: %#", error);
exit(0);
}
}
- (NSString *)applicationAppSupportDirectory
{
return [NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSUserDomainMask, YES) lastObject];
}