App and user data

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

There are a number of places for Windows Runtime apps to store app data and user data. The right place to store data depends on the scenario and the language you choose to create your app. We outline the full range of storage mediums and highlight scenarios where each medium works best.

Types of app data

There are two kinds of data that apps frequently manage or interact with:

• App data

  Data that the app itself creates and manages. It is mutable data specific to the internal functions or configuration of a particular app. It includes runtime state, user preferences, reference content (such as the dictionary definitions in a dictionary app), and other settings. App data is tied to the existence of the app and is only meaningful to that app.

• User data

  Data that the user creates and manages when using an app. It includes document or media files, email or communication transcripts, or database records holding content created by the user. Note that user-selected preferences or app configuration options are considered app data, not user data. User data may be useful or meaningful to more than one app. Often this is data that the user wants to manipulate or transmit as an entity independent of the app itself, such as a document.

Store your Windows Runtime apps app data in data stores that the system provides for that purpose, which are specific to that app and user. The system can then manage these data stores and keep them isolated from other apps and other users. The system preserves these data stores when the user installs an update to the app. The system also removes the contents of these data stores completely and cleanly when the user uninstalls the app. Don't store app data in storage locations intended for user data to circumvent these characteristics.

Because the lifetime of app data stores are tied to the lifetime of the app, don't store user data such as documents or media in data stores intended for app data. Use the user's libraries and Microsoft OneDrive to store this sort of info.

The tables summarize the various data locations available to your app, their limitations, and their recommended uses. Access to some data locations is limited within Windows Runtime apps using JavaScript, depending on the context of the document. All storage size limitations are also constrained by the overall size of the storage medium.

User data

Data location	Available to	Features and limitations	Recommended use
Libraries accessed by the Windows Runtime StorageFile and file pickers	Windows Runtime apps using JavaScript (local context) Windows Store apps using C++, C#, or Visual Basic Windows Store apps using DirectX with C++	Load and save files to the user’s libraries Asynchronous API No size limitation File and folder pickers: Use file and folder pickers to let the user to control the selection or creation of the file. Programmatic access: Requires a capability in the package manifest for each library, with the exception of downloads where an app is allowed to write or read what it wrote. Requires an extension of the desired file type in the package manifest for files that can be opened for Documents or removable storage locations.	Use for user data that is intended to survive the lifetime of the app or is managed independently by the user.
OneDrive	Windows Runtime apps using JavaScript Windows Store apps using C++, C#, or Visual Basic Windows Store apps using DirectX	Supports storage of user data in the cloud and is available to multiple device platforms A REST- and JavaScript Object Notation (JSON)-based API Restricted to a well-defined list of supported file formats Allows accessing content shared by other users Size quota is based on user account	Use for user data that the user wants to access from multiple devices, platforms, or apps.
HTML5 File API	Windows Runtime apps using JavaScript (web context and local context) Windows Store apps using C++, C#, or Visual Basic Windows Store apps using DirectX	Web standard	Preferred only for scenarios involving upload and download of files. For transfers that continue while the app is not active, use the Windows Runtime BackgroundTransfer from the local context.

 

In addition to storage options described in this table, you can also use third-party database and cloud storage solutions.

App data

Data location	Available to	Features and limitations	Recommended use
Application Data APIs for the Windows Runtime	Windows Runtime app using JavaScript (local context) Windows Store app using C++, C#, or Visual Basic Windows Store app using DirectX	Provides a local data store and roaming data store Also provides a temporary data store that is subject to disk cleanup by the system Supports highly structured content (settings) Supports composite types (a set of settings that are managed as an atomic unit) Supports unstructured data (files) Settings use a synchronous API Files use an asynchronous API Settings are limited to 8K per setting or 64K per composite setting; there is no limit on number of settings, we recommend storing less than 1MB of data Files have no size limit Roaming files and settings are limited per package in overall size, as defined in the ApplicationData.RoamingStorageQuota or roaming won't occur The system manages when roaming occurs, to preserve bandwidth and battery life. The HighPriority setting roams with higher frequency than other settings. No size limit on temporary data	Use for settings and unstructured data files.
IndexedDB	Windows Runtime app using JavaScript (web context and local context)	ISAM storage technology Indexed or sequential cursor navigation Storage is limited to 250MB per app For drives less than 30GB, storage is limited to 375MB among all installed apps For drives that are 30GB and larger, storage is limited to 4% of the drive size or 20GB, whichever is smaller, among all installed apps Web-based web context pages can only use IndexedDB if the page's URL is in the ApplicationContentUriRules portion of the app’s package manifest, unless the you set the ms-enable-external-database-usage meta tag on the app’s start page	Use for structured and indexed data storage for use solely by JavaScript. It is principally intended for caching scenarios.
Extensible Storage Engine (ESE)	Any app, but a developer must wrap the calls in a Windows Runtime object before it can be used by non-C/C++ callers	ISAM storage technology Indexed or sequential cursor navigation Transactional data Robust data consistency even in the event of system crashes Cached data for fast retrieval Scalable to large sizes, commonly over 50 GB Stored in a flat binary file, placed on disk via other means, such as the Windows RuntimeApplicationData APIs Only C/C++ APIs are provided	Use for structured and indexed data storage for use by C/C++ or wrapped in a developer-authored Windows Runtime object.
HTML5 Web Storage	Windows Runtime app using JavaScript (web context and local context) Windows Store app using C++, C#, or Visual Basic (using the WebView control)	Uses string key-value pairs Web standard Isolated from browser cache on a per-user and per-app basis Synchronous API Has a 10MB size limit	Use localStorage when you need lightweight storage in a web context and the Windows Runtime is not available. Don't use sessionStorage because it only exists in memory and will not survive app termination. Use it only for momentary storage that is unlikely to be interrupted by the user switching away from the app.
WinJS.Application.sessionState	Windows Runtime app using JavaScript (local context)	JavaScript object with app-defined properties Automatically saved by Windows Library for JavaScript on suspend to the local ApplicationData No size limitations.	Preferred only as a place to store transitory app state when the app suspends and is terminated, in order to resume in the same state.
WinJS.Application.local state storage	Windows Runtime app using JavaScript (web context and local context)	Convenience wrapper for ApplicationData Falls back to an in-memory implementation when in a web context	Use for JavaScript that must run in both a web context and local context.
WinJS.Application.roaming state storage	Windows Runtime app using JavaScript (web context and local context)	Convenience wrapper for ApplicationData Falls back to an in-memory implementation when in a web context	Use for JavaScript that must run in both a web context and local context.

 

In addition to storage options described in this table, you can also use third-party database and cloud storage solutions.

Server

When your app interacts with web sites and web services, it can use some other data storage locations:

Data location	Available to	Features and limitations	Recommended use
HTML5 Application Cache	Windows Runtime app using JavaScript (web context and local context) Windows Runtime app using JavaScript (using a web-based Application Cache manifest)	Web standard Allows pre-fetching of web-based app markup, scripts, style sheets, and resources to facilitate offline usage Local context pages can only use a web-based Application Cache to fetch resources that don't contain code. For example, you can use it to fetch images, audio, video, or xml for offline usage. Can't be written via script For a page in the web context to access the Application Cache, the page's URL must be added to ApplicationContentUriRules portion of the app's package manifest. Pages in the local context don't have this requirement.	Use when content is read-only, delivered from a web server, and needs to be accessible while the device is offline. While the HTML5 Application Cache can be used to deliver individualized content, it is primarily intended as a caching strategy for offline access to data.
Cookies	Windows Runtime app using JavaScript (web context and local context) Windows Store app using C++, C#, or Visual Basic (using the WebView) Apps using IXMLHTTPRequest2	Web standard Isolated from browser cache on a per-user and per-app basis 4K size limit per cookie; number of cookies is unlimited Cookies to and from a page in the local context to the web via XHR are subject to normal web cross-domain cookie sharing rules	Use for data that must be shared with each request to a web server.
Cloud Services, OpenData Services, and Cloud Databases	Any app	Allows full cloud database solution Enables server side triggered or periodic processing Features depend upon cloud service adopting	Preferred when working with content that is voluminous, generated by a third party source, or is also displayed on a website as well as in the app.