cuts version 28 of the docs

fbshipit-source-id: b7b4374

Author: jimmylee

package.json

@@ -1,6 +1,6 @@
 {
   "name": "expo-docs",
-  "version": "27.0.0",
+  "version": "28.0.0",
   "private": true,
   "scripts": {
     "dev": "concurrently -k 'yarn run mdjs' 'node server.js'",

versions/v28.0.0/distribution/advanced-release-channels.md

@@ -0,0 +1,120 @@
+---
+title: Advanced Release Channels
+---
+
+> **WARNING:** Channel features are in beta, run `npm install -g exp` to get the most up to date features.
+
+## Introduction
+
+For a quick introduction to release channels, read [this](https://docs.expo.io/versions/latest/guides/release-channels.html).
+
+When you publish your app by running `exp publish --release-channel staging`, it creates:
+
+- a release, identified by a `publicationId` for Android and iOS platforms. A release refers to your bundled source code and assets at the time of publication.
+- a link to the release in the `staging` channel, identified by a `channelId`. This is like a commit on a git branch.
+
+For simplicity, the rest of this article will refer to just the `ios` releases, but you could swap out ios for android at any point and everything would still be true.
+
+## See past publishes
+You can see everything that you’ve published with `exp publish:history`.
+
+#### Example command and output
+`exp publish:history --platform ios`
+
+| publishedTime  | appVersion  | sdkVersion  | platform  | channel  | channelId  | publicationId  |
+|---|---|---|---|---|---|---|
+| 2018-01-05T23:55:04.603Z  |  1.0.0 | 24.0.0 |  ios | staging  | 9133d577  | d9bd6b80  |
+
+To see more details about this particular release, you can run `exp publish:details`
+
+#### Example command and output
+`exp publish:details --publish-id d9bd6b80`
+
+[![Publish Details](./release-channels-pub-details-1.png)](/_images/release-channels-pub-details-1.png)
+
+
+## What version of the app will my users get?
+
+Your users will get the most recent compatible release that was pushed to a channel. Factors that affect compatibility:
+
+- sdkVersion
+- platform
+
+The following flowchart shows how we determine which release to return to a user:
+
+[![Serving Flowchart](./release-channels-flowchart.png)](/_images/release-channels-flowchart.png)
+
+## Promoting a release to a new channel
+
+Example use case: you previously published a release to `staging` and everything went well in your testing. Now you want this release to be active in another channel (ie) production
+
+We run `exp publish:set` to push our release to the `production` channel.
+`exp publish:set --publish-id d9bd6b80 --release-channel production`
+
+Continuing from the previous section, we can see that our release is available in both the `staging` and the `production` channels.
+
+`exp publish:history --platform ios`
+
+| publishedTime  | appVersion  | sdkVersion  | platform  | channel  | channelId  | publicationId  |
+|---|---|---|---|---|---|---|
+| 2018-01-05T23:55:04.603Z  |  1.0.0 | 24.0.0 |  ios | staging  | 9133d577  | d9bd6b80  |
+| 2018-01-05T23:55:04.603Z  |  1.0.0 | 24.0.0 |  ios | production  | 6e406223  | d9bd6b80  |
+
+## Rollback a channel entry
+
+Example use case: you published a release to your `production` channel, only to realize that it includes a major regression for some of your users, so you want to revert back to the previous version.
+
+Continuing from the previous section, we rollback our `production` channel entry with `exp publish:rollback`.
+
+`exp publish:rollback --channel-id 6e406223`
+
+Now we can see that our release is no longer available in the production channel.
+
+`exp publish:history --platform ios`
+
+| publishedTime  | appVersion  | sdkVersion  | platform  | channel  | channelId  | publicationId  |
+|---|---|---|---|---|---|---|
+| 2018-01-05T23:55:04.603Z  |  1.0.0 | 24.0.0 |  ios | staging  | 9133d577  | d9bd6b80  |
+
+## Release channels CLI tools
+### Publish history
+
+```
+  Usage: exp publish:history [--release-channel <channel-name>] [--count <number-of-logs>]
+
+  View a log of your published releases.
+
+  Options:
+    -c, --release-channel <channel-name>  Filter by release channel. If this flag is not included, the most recent publications will be shown.
+    -count, --count <number-of-logs>      Number of logs to view, maximum 100, default 5.
+```
+
+### Publish details
+```
+  Usage: exp publish:details --publish-id <publish-id>
+  View the details of a published release.
+
+  Options:
+    --publish-id <publish-id>  Publication id. (Required)
+```
+
+### Publish rollback
+```
+Usage: exp publish:rollback --channel-id <channel-id>
+
+  Rollback an update to a channel.
+
+  Options:
+    --channel-id <channel-id>  The channel id to rollback in the channel. (Required)
+```
+
+### Publish set
+```
+ Usage: exp publish:set --release-channel <channel-name> --publish-id <publish-id>
+
+  Set a published release to be served from a specified channel.
+
+  Options:
+    -c, --release-channel <channel-name>  The channel to set the published release. (Required)
+    -p, --publish-id <publish-id>         The id of the published release to serve from the channel. (Required)
+```

versions/v28.0.0/distribution/app-stores.md

@@ -0,0 +1,76 @@
+---
+title: Deploying to App Stores
+---
+
+This guide offers best practices around submitting your Expo app to the Apple iTunes Store and Google Play Store. To learn how to generate native binaries for submission, see [Building Standalone Apps](./building-standalone-apps.html).
+
+Although you can share your published project through the Expo Client and on your [expo.io](https://expo.io) profile, submitting a standalone app to the Apple and Google stores is necessary to have a dedicated piece of real estate on your users' devices. Submitting to these stores carries stronger requirements and quality standards than sharing a toy project with a few friends, because it makes your app available through a much wider distribution platform.
+
+**Disclaimer:** Especially in the case of Apple, review guidelines and rules change all the time, and Apple's enforcement of various rules tends to be finicky and inconsistent. We can't guarantee that your particular project will be accepted by either platform, and you are ultimately responsible for your app's behavior. However, Expo apps are native apps and behave just like any other apps, so if you've created something awesome, you should have nothing to worry about!
+
+## Make sure your app works on many form factors
+
+It's a good idea to test your app on a device or simulator with a small screen (e.g. an iPhone SE) as well as a large screen (e.g. an iPhone X). Ensure your components render the way you expect, no buttons are blocked, and all text fields are accessible.
+
+Try your app on tablets in addition to handsets. Even if you have `ios.supportsTablet: false` configured, your app will still render at phone resolution on iPads and must be usable.
+
+## Make app loading seamless
+
+- Add a [splash screen](./splash-screens.html), the very first thing your users see after they select your app.
+- Use [AppLoading](../sdk/app-loading.html) to ensure your interface is ready before the user sees it.
+- [Preload and cache your assets](./offline-support.html) so your app loads quickly, even with a poor internet connection.
+
+## Play nicely with the system UI
+
+- Configure the [status bar](./configuring-statusbar.html) so it doesn't clash with your interface.
+- Use [native gestures](../sdk/gesture-handler.html) whenever possible.
+- Use interface elements that make sense on the device. For example, see the [iOS Human Interface Guidelines](https://developer.apple.com/ios/human-interface-guidelines/overview/themes/).
+
+## Tailor your app metadata
+
+- Add a great [icon](./app-icons.html). Icon requirements between iOS and Android differ and are fairly strict, so be sure and familiarize yourself with that guide.
+- Customize your [primaryColor](../guides/configuration.html#primarycolor).
+- Make sure your app has a valid iOS [Bundle Identifier](./configuration.html#bundleidentifier) and [Android Package](./configuration.html#package). Take care in choosing these, as you will not be able to change them later.
+- Use [versionCode](configuration.html#versioncode) and [buildNumber](configuration.html#buildnumber) to distinguish different binaries of your app.
+
+## iOS-specific guidelines
+
+- All apps in the iTunes Store must abide by the [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/).
+- Apple will ask you whether your app uses the IDFA. Because Expo depends on Segment Analytics, the answer is yes, and you'll need to check a couple boxes on the Apple submission form. See [Segment's Guide](https://segment.com/docs/sources/mobile/ios/quickstart/#step-5-submitting-to-the-app-store) for which specific boxes to fill in.
+
+## Common App Rejections
+
+- It's helpful to glance over [Common App Rejections](https://developer.apple.com/app-store/review/rejections/).
+- Binaries can get rejected for having poorly formatted icons, so double check the [App Icon guide](./app-icons.html).
+- Apple can reject your app if elements don't render properly on an iPad, even if your app doesn't target the iPad form factor. Be sure and test your app on an iPad (or iPad simulator).
+- Occasionally people get a message from Apple which mentions an IPv6 network. Typically this is just Apple's way of informing you what kind of network they tested on, and the actual "IPv6" detail is a red herring. All of Expo's iOS code uses `NSURLSession`, which is IPv6-compatible. [More info](https://forums.expo.io/t/ios-standalone-rejected-at-review-because-of-ipv6/7062).
+
+## System permissions dialogs on iOS
+
+If your app asks for [system permissions](../sdk/permissions.html) from the user, e.g. to use the device's camera, or access photos, Apple requires an explanation for how your app makes use of that data. Expo will automatically provide a boilerplate reason for you, such as "Allow cool-app to access the camera." If you would like to provide more information, you can override these values using the [ios.infoPlist](../workflow/configuration) key in `app.json`, for example:
+
+```
+"infoPlist": {
+  "NSCameraUsageDescription": "This app uses the camera to scan barcodes on event tickets."
+},
+```
+
+The full list of keys Expo provides by default can be seen [here](https://github.com/expo/expo/blob/master/exponent-view-template/ios/exponent-view-template/Supporting/Info.plist#L28-L41). You can provide any overrides you want in the `infoPlist` configuration. Because these strings are configured at the native level, they will only be published when you build a new binary with `exp build`.
+
+## Localizing system dialogs on iOS
+
+If your app uses a language besides English, you can optionally provide [localized](../sdk/localization.html) strings for the system dialogs. For example, in `app.json`, you can provide
+
+```
+"locales": {
+  "ru": "./languages/russian.json"
+}
+```
+
+...where `russian.json` looks like:
+
+```
+{
+  "NSContactsUsageDescription": "Hello Russian words"
+}
+```