[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.
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.
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.
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.
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.
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.
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)