How to Access App Specific Folder and Use It to Backup or Some App Specific Data? in Swift

How to access app specific folder and use it to backup or some app specific data? In swift

You need to setup scope for google drive configuration,

GIDSignIn.sharedInstance().scopes = [kGTLRAuthScopeDriveAppData]

Reference
Drive scope

User specific Documents directory on iOS device

From Apple Documentation

Where You Should Put Your App’s Files

Put user data in Documents/. User data generally includes any files you might want to expose to the user—anything you might want the user to create, import, delete or edit. For a drawing app, user data includes any graphic files the user might create. For a text editor, it includes the text files. Video and audio apps may even include files that the user has downloaded to watch or listen to later.

Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. This directory can also include data files, configuration files, templates and modified versions of resources loaded from the app bundle.

Remember that files in Documents/ and Application Support/ are backed up by default. You can exclude files from the backup by calling -[NSURL setResourceValue:forKey:error:] using the NSURLIsExcludedFromBackupKey key. Any file that can be re-created or downloaded must be excluded from the backup. This is particularly important for large media files. If your application downloads video or audio files, make sure they are not included in the backup.

Put temporary data in the tmp/ directory. Temporary data comprises any data that you do not need to persist for an extended period of time. Remember to delete those files when you are done with them so that they do not continue to consume space on the user’s device. The system will periodically purge these files when your app is not running; therefore, you cannot rely on these files persisting after your app terminates.

Put data cache files in the Library/Caches/ directory. Cache data can be used for any data that needs to persist longer than temporary data, but not as long as a support file. Generally speaking, the application does not require cache data to operate properly, but it can use cache data to improve performance. Examples of cache data include (but are not limited to) database cache files and transient, downloadable content. Note that the system may delete the Caches/ directory to free up disk space, so your app must be able to re-create or download these files as needed.

What is correct way to store/retrieve user data (read/write files) in iPhone (iOS) dev via Swift?

See iOS Storage Best Practices video and the File System Basics document. That should get you going.

In short, app data is generally stored in “application support directory”, documents exposed to the user (e.g. the Files app) are stored in “documents” folder, downloads that can be easily re-retrieved are stored in “caches” folder. Technically you could use UserDefaults for storing of this sort of application data, but it really is not intended for this purpose.

Re opening a file for “read/write”, when dealing with JSON, you don’t generally do that. You read the file into a Data and deserialize the JSON into your model objects.

do {
    let fileURL = try FileManager.default
        .url(for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
        .appendingPathComponent("appdata.json")

    let data = try Data(contentsOf: fileURL)
    let appData = try JSONDecoder().decode(AppData.self, from: data)
    // do something with appData
} catch { 
    print(error)
}

When you want to update, you serialize the model objects into a Data containing your JSON and then write it to the file, replacing the file.

do {
    let fileURL = try FileManager.default
        .url(for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
        .appendingPathComponent("appdata.json")

    let data = try JSONEncoder().encode(appData)
    try data.write(to: fileURL)
} catch { 
    print(error)
}

Obviously, this assumes that the AppData type (or whatever you call it) conforms to Codable, but you said you were familiar with serialization of JSON. See Encoding and Decoding Custom Types for more information.

iOS: When I open my app from iMazing, how to hide and protect from read and protect from copy on the mac a specific folder?

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.

Backup core data locally, and restore from backup - Swift

I've never needed to do this but if I did this is what I'd do.

To make backups

At any time, use the following steps:

1. Create a new, second Core Data stack. Use either NSPersistentContainer or the older (but still supported) method of creating an NSPersistentStoreCoordinator.
2. Use NSPersistentStoreCoordinator's function migratePersistentStore(_:to:options:withType:) to create the backup. Make the destination URL include something unique, using a UUID or a timestamp. Put the backups in the documents folder.
3. Keep a list of backups by date. You could put this in UserDefaults or create a new property list file to save backup info.

Step #2 will remove the original store from the Core Data stack-- which is why you create a second stack in step #1. This way you can use the second stack to make the backup without affecting the one your app is using.

If you're using NSPersistentContainer, use its persistentStoreCoordinator property to carry out step #2.

To restore from backups

This is a little bit tricky because your app may be using its persistent store, but now you want to replace that with an older version. Before restoring from a backup, make sure you're not currently using any managed objects from the persistent store. Deallocate your NSPersistentContainer. Unload any UI that makes use of managed objects. Get your app into a state where all it can do is either restore from a backup or go back to using the current data, but where it's not showing any data except the backup list.

Now that you've done that,

1. Display the backup list and let the user select one.
2. Create an NSPersistentStoreCoordinator using your data model.
3. Use the replacePersistentStore(at:destinationOptions:withPersistentStoreFrom:sourceOptions:ofType:) method to copy the backup data to the normal app location. The starting location is the backup location, the destination is where the app normally saves its data.
4. (optional) Use NSPersistentStoreCoordinator's function destroyPersistentStore(at:ofType:options:) to delete the backup.
5. Load an NSPersistentContainer as usual and reload the regular app UI.

Don't use direct file-related APIs like FileManager for any of this. The Core Data methods will cover all of the Core Data-related files and do other nice things like avoid causing data corruption and respecting file locks.

Update: I later wrote a blog post that covers this in more detail, with sample code: https://atomicbird.com/blog/core-data-back-up-store/

Does iTunes backup core data?

This depends on where you save your core data database.

In general the Library and the Documents directory are backed up by iTunes (and by iCloud), tmp and Caches are not backed up.

See: Apple Documentation - iOS Standard Directories: Where Files Reside

AppName.app
This is the app’s bundle. This directory contains the app and all of its resources.
You cannot write to this directory. To prevent tampering, the bundle directory is signed at installation time. Writing to this directory changes the signature and prevents your app from launching. You can, however, gain read-only access to any resources stored in the apps bundle. For more information, see the Resource Programming Guide

The contents of this directory are not backed up by iTunes. However, iTunes does perform an initial sync of any apps purchased from the App Store.

Documents/
Use this directory to store user-generated content. The contents of this directory can be made available to the user through file sharing; therefore, his directory should only contain files that you may wish to expose to the user.

The contents of this directory are backed up by iTunes.

Documents/Inbox
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.

Library/
This is the top-level directory for any files that are not user data files. You typically put files in one of several standard subdirectories. iOS apps commonly use the Application Support and Caches subdirectories; however, you can create custom subdirectories.
Use the Library subdirectories for any files you don’t want exposed to the user. Your app should not use these directories for user data files.

The contents of the Library directory (with the exception of the Caches subdirectory) are backed up by iTunes.
For additional information about the Library directory and its commonly used subdirectories, see The Library Directory Stores App-Specific Files.

tmp/
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 they are no longer needed; however, the system may purge this directory when your app is not running.

The contents of this directory are not backed up by iTunes.

---

Related Topics