What is Preprocessing of Manual Builds and how to use it
As a White Label Publisher you are able to manually manage all the applications requests (build requests) from your users.
As you might know, all the build requests from a White Label website come by default directly to our system were we manually process them in 1-2 business days. Once you enable the "Preprocessing of Manual Builds"option from Publisher Dashboard > Account Settings > Website Settings, all the publication requests will come to this page click here .
1) Status. You may sort all the build requests by status.
a) Any - this will show all the builds, including completed, failed, etc
b) Review - the current and unprocessed build requests. Only the manual builds requests will be shown.
A manual build means a build request that requires our input. These are all the build types from the submission process except "Instant Builds" and "Instant Ad Hoc Builds"
c) Prepared - The Manual Builds that you have already completed.
d) Failed - The builds that failed. The failed builds can be Instant Builds that failed from different causes. You may check why a build has failed in the Logs.
2. Platform. You may see that platform of the builds requested. The platform can be iPhone, iPad, Android or Kindle
3. User. You may check the users. You can login as a user by clicking on it. Use your Admin SeattleCloud's credentials to login as an user.
4. App. Here you may see details about the app requested.
a). This is a unique identifier for the application. It contains the White Label brand name (that you have set once you signed up) , User ID and Application ID.
b) Click "View" to preview the app.
c) Proprieties. You may see here the "App Store Proprieties" for the app. It includes the Application Name, Description keywords and icon.
d) Code Sign Files. Here you may upload a Distribution Certificate and a Mobile Provisioning Profile for an iOS app.
e) Builds. Here you may see the history of the build requests for the current app.
5. Type. Once a user submits an app, he will choose the type of build from the submission process:
Build_Only - means the user requested "Build & Review" during the submission process on the website.
mydev_account - the user requested "Build & Publish under my account".
qbiki_account - the user requested publication on Publisher's account.
auto_build - the user requested an Instant Build .
6. Status.
The status of an application can be either "Review" or "Completed".
Review - means that the app was not yet processed.
Completed - the app was processed. Once the app is processed, it will not appear on this page.
7. Actions.
Once you receive a build request form a customer, you have the following options:
Delegate to SC - this means the build request will be forwarded to us. We will process it.
Request Binary - this option will request an Instant Build. Note that in order to request an Instant Build for an iOS app - you need to create the necessary certificates (step 4, d)
Needs Improvement - you may reject the app and send a message to the user
Completed - this action will automatically take place once one of the above mentioned options are done.
What is Preprocessing of Manual Builds and how to use it
As a White Label Publisher you are able to manually manage all the applications requests (build requests) from your users.
On this page http://seattleclouds.com/publisherbuildsreview.aspx , you will see all the application builds request from your users.
1) Status. You may sort all the build requests by status.
a) Any - this will show all the builds, including completed, failed, etc
b) Review - the current and unprocessed build requests. Only the manual builds requests will be shown.
A manual build means a build request that requires our input. These are all the build types from the submission process except "Instant Builds" and "Instant Ad Hoc Builds"
c) Prepared - The Manual Builds that you have already completed.
d) Failed - The builds that failed. The failed builds can be Instant Builds that failed from different causes. You may check why a build has failed in the Logs.
2. Platform. You may see that platform of the builds requested. The platform can be iPhone, iPad, Android or Kindle
3. User. You may check the users. You can login as a user by clicking on it. Use your Admin SeattleCloud's credentials to login as an user.
4. App. Here you may see details about the app requested.
a). This is a unique identifier for the application. It contains the White Label brand name (that you have set once you signed up) , User ID and Application ID.
b) Click "View" to preview the app.
c) Proprieties. You may see here the "App Store Proprieties" for the app. It includes the Application Name, Description keywords and icon.
d) Code Sign Files. Here you may upload a Distribution Certificate and a Mobile Provisioning Profile for an iOS app.
e) Builds. Here you may see the history of the build requests for the current app.
5. Type. Once a user submits an app, he will choose the type of build from the submission process:
mydev_account - the user requested "Build & Publish under my account".
qbiki_account - the user requested publication on Publisher's account.
auto_build - the user requested an Instant Build .
6. Status.
The status of an application can be either "Review" or "Completed".
Review - means that the app was not yet processed.
Completed - the app was processed. Once the app is processed, it will not appear on this page.
7. Actions.
Once you receive a build request form a customer, you have the following options:
Delegate to SC - this means the build request will be forwarded to us. We will process it.
Request Binary - this option will request an Instant Build. Note that in order to request an Instant Build for an iOS app - you need to create the necessary certificates (step 4, d)
Needs Improvement - you may reject the app and send a message to the user
Completed - this action will automatically take place once one of the above mentioned options are done.