Channels

Managing channels

First, let’s take a look at the channels page. You can access it by clicking on your app and then clicking on the channels tab.

Creating a channel

As you can see, there exists a plus button in the lower right corner. (1 in the image) Clicking on it will open a modal where you can create a new channel.

Then after you click on Add a new channel should appear in the list.

What does misconfigured mean?

Sometimes the configuration of a channel is not valid. In that case, you will get a big warning and the Misconfigured column will say Yes for one or more of the channels. You can learn more about it here

Deleting a channel

Deleting a channel is straight forward. Just click on the trash icon and confirm the deletion. (2 in the image)

Managing a channel

Clicking on the channel name will open a modal where you can manage the channel. (3 in the image) This page should look something like this:

Let’s go through the different sections.

First the Bundle number (1 in the image). This is the current version for that channel. When asked to serve an update this channel will always attempt to respond with that version.* ¹ Clicking on it should take you to the bundle page.

Second the Shared to (2 in the image) page. I recommend against ever using this. A new and better system is in the works.

Now the forced devices (3 in the image). This is a list of devices that will always get updates from this channel. This is useful for testing purposes. You can add force a device to a channel from the devices page.

Lastly the settings (4 in the image). This is where you can manage how the channels behave. After you click on it you should see something like this:

The list of settings is long, but I will do my best to explain them all.

---

First the Default channel THIS IS PROPABLY THE MOST IMPORTANT ONE.
If a channel is marked as default, then it will be used as the default channel for all new devices.
In different terms: If you have a new user capgo will try to serve him the latest version of this default channel. Only 1 channel can be set to default at a time. If you try to break this rule you will be asked to confirm your action.

After you confirm the old default channel will be unmarked as default and the new one will be marked as default.

---

Second the IOS setting. This is relatively simple. If this is false then IOS devices will not be allowed to download updates from this channel.

Third is the Android setting. This is similar to IOS. If this is false then Android devices will not be allowed to download updates from this channel.

Fourth is the Disable auto downgrade under native setting. If this is true then it will be impossible to downgrade from a native version. This means that if you have uploaded a 1.2.0 version to the app store or play store and try to set the channel version to 1.1.0 then the update (downgrade) will fail.

Fifth is the Disable auto update. This setting is quite complex, and you can learn more about it here

As for Allow develoment build. If this is true then development builds will be allowed to download updates from this channel. If not then any update request that has the prod set to false will be rejected. This is mostly useful for testing purposes.

Seventh is the Allow Emulators. If this is false then cagpo will disallow any update request that comes from an emulator. This is mostly useful for testing purposes.

Eight is the Allow devices to self associate. If this is true then the setChannel method will be available. If this is set to false and you try to call the setChannel method with this channel then the call will fail.

---

Next is the AB testing. This is a VERY complex setting. Let’s start at the beginning. After enabling this setting you should see 2 versions instead of 1.

The idea is that after you upload the bundle to capgo cloud you will be able to select which version you want to serve to which percentage of users. For example, you could say that you want only 30% of your users to receive the new update. In that case, you would set the A version to the old version and the B version to the new version (the one thay you only want 30% of users to receive) Next, you would set the Percentage of users recving secondary version to 30%.

Danger

⚠️ Sending a new version from the CLI into the production channel will set version A to it. If you want to change it you will have to do it manually from the webapp.

---

The last setting is the Enable progressive deploy. This is similar to AB testing, however, the Percentage of users recving secondary version will be increased every 10 minutes by 10% until it reaches 100%. Progressive deploy is exclusive to AB testing. You can’t have both enabled at the same time.

First, do not worry about the Progressive deploy status failed message. It is just a warning that will go away once you deploy the first version.

To start a new progressive deploy go to the specific bundle page and click on Channel. Then click on the channel that has progressive deploy enabled. You should see something like this:

If you skip progressive deploy it should look like this:

If you do not skip progressive deploy it should look like this:

After the progressive deploy finishes you should see something like this:

Footnotes:

Footnotes

1. *: There are A LOT of exceptions to this but regardless that is the main version for the channel. ↩