Skip to main content

iOS Data Storage Guidelines


  1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the <Application_Home>/Documents directory and will be automatically backed up by iCloud.
  2. Data that can be downloaded again or regenerated should be stored in the <Application_Home>/Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.
  3. Data that is used only temporarily should be stored in the <Application_Home>/tmp directory. Although these files are not backed up to iCloud, 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.
  4. Use the "do not back up" attribute for specifying files that should remain on device, even in low storage situations. Use this attribute with data that can be recreated but needs to persist even in low storage situations for proper functioning of your app or because customers expect it to be available during offline use. This attribute works on marked files regardless of what directory they are in, including the Documents directory. These files will not be purged and will not be included in the user's iCloud or iTunes backup. Because these files do use on-device storage space, your app is responsible for monitoring and purging these files periodically.

Comments

Popular posts from this blog

Pattern: Riblets vs. VIPER

Engineering the architecture behind Uber's new rider app

Not being held back by our extensive codebase and previous design choices gave us the freedom where we otherwise would have made compromises. The outcome is the sleek new app you see today, which implements a new mobile architecture across both iOS and Android. Read on to learn why we felt the need to create this new architecture pattern, called Riblets, and how it helps us reach our goals.

The platforms share:

Core architectureClass namesInheritance relationships between business logic unitsHow business logic is dividedPlugin points (names, existence, structure, etc.)Reactive programming chainsUnified platform components
Each Riblet is made up of one Router, Interactor, and Builder with its Component (hence the name), and optional Presenters and Views. The Router and Interactor handle the business logic, while the Presenter and View handle the view logic.

Uber

Stetho - A Chrome debug bridge for Android applications

Stetho is a sophisticated debug bridge for Android applications. When enabled, developers have access to the Chrome Developer Tools feature natively part of the Chrome desktop browser. Developers can also choose to enable the optional dumpapp tool which offers a powerful command-line interface to application internals.

Facebook Github

WireMock

WireMock is a flexible library for stubbing and mocking web services. Unlike general purpose mocking tools it works by creating an actual HTTP server that your code under test can connect to as it would a real web service.

It supports HTTP response stubbing, request verification, proxy/intercept, record/playback of stubs and fault injection, and can be used from within a unit test or deployed into a test environment.

Although it’s written in Java, there’s also a JSON API so you can use it with pretty much any language out there.

WireMock.org