DOC v2.0 — Verification/Authentication, Configuration, Release
Note: This document contains a list of artifacts required to configure, build, test, and publish an Android, iOS, Mac, Chrome, and Windows apps on the Play Store, App Store, Mac Store, Chrome Store, and Microsoft Store respectively using the Cloud Softphone white-label softphone program.
For every platform, there are three required steps:
- Verification/Authentication
- Configuration
- Release
Verification/Authentication: This describes methods of Platform Operator (Google, Apple, Microsoft) to verify and/or authenticate user access to the development portal/console. It starts with account creation on the desired platform and then ends with verifying the account owner to have access to the platform.
Configuration: This refers to a list of the required artifacts to configure and build the app. Before publishing or releasing the app, configuration needs to be added. Usually, a manifest or XML file is added to the app directory, while sometimes the configuration is done on the platform website.
Release: This is a list of required artifacts to publish an app in the store. It usually includes things like an app icon, splash screen, background image, screenshots, etc.
If you have been following the tech of Acrobits, then you know that it supports Cloud Softphone white-label application development with little to no coding. With just a few clicks, you can create fully-fledged white-label applications of the Cloud Softphone SIP client.
On the portal/console, you need to choose white-label feature-set, which will allow you to configure all the white-label features, such as the app icon, UI design and theme, as well as the overall look of the app. The goal is to configure and publish the app, so that the final app looks like it was created by you.
Acrobits supports virtually every platform on the market. Regardless of the platform, you can create white-label apps that will run on all the supported platforms, with the same look and feel.
You don’t need to do any extra coding either. However, before you can use the app, you need to set it at “Live” mode (which can be done by submitting the app to Acrobits for the review process) and publish the app to the different app stores.
Let’s see how this can be done for Android, iOS and rest of the supported platforms.
ANDROID VERIFICATION
Google uses four verification methods to verify user access to the developer console. The verification is device/location specific. This usually involves a hash calculated from the MAC/IP address. Access from a different location will require new user verification, and so will access from a different device. Access won’t require verification again from the same device and location from which access was verified previously.
These four verification methods are mentioned below:
Verification Email: This is the email address defined for the account by the account owner.
Verification Phone: This is the phone number defined for the account by the account owner.
G-code: This is a six-digit number that Google sends to the account owner’s registered phone number. The code is valid for a limited amount of time, typically a few minutes, and will expire afterwards. It’s only available for a limited login session. For any new login attempts, a new G-code will be sent and must be entered.
Remote: This is the number on the account owner’s phone, which is used to verify user access remotely. Remote verification works as follows:
- The account owner enters their credentials and logs into the account.
- Once the account owner is logged in, it will show them a remote verification number and send a verification prompt to account owner’s defined phone number.
- The Account owner must enter the verification number from (2) on their phone to remotely verify access.
- Access is now verified, and the account owner can proceed to the next step.
ANDROID CONFIGURATION
The following are the artifacts required to configure, build, and test an Android app using the Cloud Softphone white-label program:
- App Name
Data type: text.
Example: SoftPhone
- App Id
Data type: text.
This is the reverse domain. “.android” is added automatically by Cloud Softphone at the end. It cannot use dashes or underscores.
Example: com.softphone.android
- App Version
Data type: text/number.
Example: 1.0.0
- Legacy GCM Sender ID
Data type: text/number.
Legacy GCM Sender ID is created on Google Firebase Console.
- Legacy GCM Server Key
Data type: text.
Legacy GCM Server Key is created on Google Firebase Console.
- Firebase Settings Json
Data type: file/json.
Firebase Settings Json is created on Google Firebase Console.
- Firebase Server Key
Data type: text. Firebase Server Key is created on Google Firebase Console.
- Google Developer Account
Data type: text.
Account must be a Developer account.
A one-time $25 Google fee applies
https://support.google.com/googleplay/android-developer/answer/6112435
To build a production version of the app, additional graphic files must be provided. The following images are the minimum requirements:
- Splash Screen / Background Image
Data type: file/image.
Required resolution: 1440×2560
- Splash Screen / Splash Image
Data type: file/image.
Required resolution: 1080×1200
- Initial Screen / Background Image
Data type: file/image.
Required resolution: 1440×2560
- Initial Screen / Logo Image
Data type: file/image.
Required resolution: 1152×245
- App Icons
Data type: file/image.
Required resolution: 48, 72, 96, 144, 192
ANDROID RELEASE
The following are the artifacts required to release an Android app on Google Play:
- Build
Data type: file/APK.
- Title
Data type: text (50).
- Short Description
Data type: text (80).
- Full Description
Data type: text (4000).
Description must meet the Google Metadata Policy (https://play.google.com/about/storelisting-promotional/metadata/) Please review the above link to see common violations related to app metadata.
We also recommend you understand all program policies relevant to your app before you submit it.
(https://play.google.com/about/developer-content-policy/)
- Screenshots
Data type: file/image.
JPEG or 24-bit PNG (no alpha).
Min length for any side: 320.
Max length for any side: 3840px.
Max aspect ratio: 1:2.
At least 2 screenshots are required.
- Hi-Res Icon
Data type: file/image.
32-bit PNG (with alpha).
Required resolution: 512×512.
- Feature Graphic
Data type: file/image.
JPEG or 24-bit PNG (no alpha).
Required resolution: 1024×500.
- Privacy Policy
Data type: URL.
The URL must be valid and contain privacy policy text/content. Failing to provide a valid URL may result in app termination by Google.
iOS AUTHENTICATION
From March 2019, Apple started using Two-Factor Authentication (2FA) to authenticate user access to the development portal and to the App Store Connect. The authentication is device/location specific and involves a hash calculation of a MAC/IP address.
Access from a different location will require new user authentication and so will access from a different device. Access won’t require authentication again from the same device and location from which the access was authenticated previously.
Apple 2FA works by sending a six-digit authentication code to the account owner’s phone number. One or more phone numbers can be defined. You can request for a code to be sent using SMS or through voice.
Important: From the time the code was requested, the code must be entered within 60 (sixty) seconds, otherwise the code will expire.
A new code can be requested at any time.
iOS CONFIGURATION
The following are the artifacts required to configure, build, and test an iOS app using the Cloud Softphone white-label program:
- App Name
Data type: text.
Example: Softphone
- App ID
Data type: text.
This is the reverse domain and .ios is added automatically by Cloud Softphone. It cannot use dashes or underscores.
Example: com.softphone.ios
- App Version
Data type: text/number.
Example: 1.0.0
- UDID
Data type: text/number.
Example: d549829d83fe170f9b28936a477a57f669fc3041 (pre-X) or 00008020-001634E01A04002E (X and newer).
There are two types of Ios test build (IPA) distribution, A/H (Ad Hoc), and T/F (Test Flight). The default Cloud Softphone distribution method is A/H. In A/H, UDID is required. T/F distribution doesn’t require UDID.
- Provisioning Profile
Data type: file/.mobileprovision.
The provisioning profile is created on the Apple Developer Portal and has an embedded distribution certificate (.cer), either an A/H type, or T/F (App Store type). The provisioning profile is valid for one year and then must be recreated.
- Push Certificate
Data type: file/.cer.
The push certificate (VoIP services type) is created on the Apple Developer Portal and is valid for one year and then must be recreated.
- Apple Developer Account
Data type: text.
The account must be a Developer account. A one-year $99 Apple fee applies to standard Developer account and $299 for Enterprise Developer account. See below:
https://developer.apple.com/programs/enroll/
To build a production version of the app, additional graphic files must be provided. The following images are the minimum requirements:
- Splash Screen / Splash Image
Data type: file/image.
Required resolution: 1242×2208
- Initial Screen / Background Image
Data type: file/image.
Required resolution: 1242×2208
- Initial Screen / Logo Image
Data type: file/image.
Required resolution: 1165×350
- App Icons
Data type: file/image.
Required resolution: 167, 180
- Notification Icon
Data type: file/image.
Required resolution: 87
- Marketing Icon
Data type: file/image.
Required resolution: 1024
iOS RELEASE
The following are the artifacts required to release an iOS app on the App Store:
- Build
Data type: file/IPA.
- Privacy Policy
Data type: URL.
The URL must be valid and contain privacy policy text/content. Failing to provide a valid URL may result in app rejection by Apple.
- Support URL
Data type: URL.
The URL must be valid and contain some sort of support content. For instance, a contact us page, help or documentation pages, and a FAQ page are acceptable examples of a support URL.
- Key Words
Data type: text.
- Description
Data type: text (4000).
The description must not contain any contact information like phone, email, or URLs, and must not mention any direct competitors like Android or Windows.
- Copyright
Data type: text.
- Contact Information
Data type: text.
The first and last name, phone number, and email address.
- Test Accounts
Data type: text.
The username/password, or phone number/PIN required for logging into the app.
- Notes
Data type: text.
Any additional information/instruction on how to login and test calls.
- Screenshots
Data type: file/image.
JPG or PNG (RGB color space).
Required resolution: 1242×2208.
We recommend you use at least three screenshots. These screenshots should demonstrate the app in use. Graphics of the splash screen are not considered a valid screenshot. Typical examples are quick dial/favorites, keypad, call screen, settings, about, or history.
MAC AUTHENTICATION
Like iOS, an Apple ID developer account is required for publishing Mac apps. The 2FA must be enabled to authenticate user access to the development portal and the App Store Connect.
Note: When creating an Apple ID, a $99 USD or $299 USD yearly fee will need to be paid depending on the service you require.
Like iOS, accessing the App Store account from a different location will require new user authentication and access from a different device. Access won’t require authentication again from the same device and location from which the access was authenticated previously.
Apple 2FA works by sending a six-digit authentication code to the account owner’s phone number. One or more phone numbers can be defined. You can request to send a code by SMS or through a voice call. This applies for both iOS and Mac apps.
Important: From the time the code was requested, the code must be entered within 60 (sixty) seconds, otherwise the code will expire.
The new code can be requested at any time. All available apps can be seen in the “My Apps” section of the App Store Connect. New apps can be created by clicking on “+” sign just below “App Store Connect” title.
MAC CONFIGURATION
The following are the artifacts required to configure, build, and test a Mac app using the Cloud Softphone white-label program:
- App Name
Data type: text.
Example: Softphone
- App ID
Data type: text.
This is the reverse domain and .mac is added automatically by Cloud Softphone. It cannot use dashes or underscores.
Example: com.softphone.mac
- App Version
Data type: text/number.
Example: 1.0.0
- Push Certificate
Data type: file/.cer.
The push certificate (VoIP services type) is created on the Apple Developer Portal and is valid for one year and must be recreated afterwards.
- Apple Developer Account
Data type: text.
The account must be a developer account. A yearly $99 USD or $299 USD fee will need to be paid depending on the services you require.
https://developer.apple.com/programs/enroll/
To build a production version of the app, additional graphic files must be provided. The following images are the minimum requirements:
- Splash Screen / Splash Image
Data type: file/image.
Required resolution: 1242×2208
- Initial Screen / Background Image
Data type: file/image.
Required resolution: 1242×2208
- Initial Screen / Logo Image
Data type: file/image.
Required resolution: 1165×350
- App Icons
Data type: file/image.
Required resolution: 167, 180
- Notification Icon
Data type: file/image.
Required resolution: 87
- Marketing Icon
Data type: file/image.
Required resolution: 1024
MAC RELEASE
The following are the artifacts required to release a Mac app on the App Store:
- Build
Data type: file/IPA.
- Privacy Policy
Data type: URL.
The URL must be valid and contain relevant privacy policy text/content. Failing to provide a valid URL may result in app rejection by Apple.
- Support URL
Data type: URL.
The URL must be valid and contain some sort of support content. For instance, a contact us page, help or documentation page, or FAQ page are acceptable examples of support URLs.
- Key Words
Data type: text.
- Description
Data type: text (4000).
The description must not contain any contact information like your phone, email, or URL, and must not mention any direct competitors like Android or Windows.
- Copyright
Data type: text.
- Contact Information
Data type: text.
The first and last name, phone number, and email address.
- Test Accounts
Data type: text.
The Username/password or phone number/PIN required for logging into the app.
- Notes
Data type: text.
Any additional information/instruction on how how to login and test calls.
- Screenshots
Data type: file/image.
JPG or PNG (RGB color space).
Required resolution: 1242×2208.
We recommend you use at least three screenshots. These screenshots should demonstrate the app in use. Graphics of the splash screen are not considered a valid screenshot. Typical examples are quick dial/favorites, keypad, call screen, settings, about, or history.
CHROME AUTHENTICATION
A valid and verified Google account is required in order to upload white-Label apps to the Chrome extension store. Google recommends using a new account instead of a preexisting account for uploading the apps. The uploaded apps will be associated with this account.
Extensions rely on manifest JSON files, which contain all the configuration (including app name, version, etc.) and features of the extension app. Before uploading the white-label app, every configuration detail must be included in your manifest file.
Once the app is uploaded to the store, the account owner will receive the confirmation message, which once approved, will authenticate user access to the Chrome developer tools and apps developed by the user.
CHROME CONFIGURATION
The following are the artifacts required to configure, build, and test a Chrome extension using the Cloud Softphone white-label program:
- App Name
Data type: text.
Example: Softphone
- App/Extension Id
Data type: text.
This is a 32 character long unique Id in the URL contained in “id=” that can be found when viewing the details of the extension on Chrome. This is required, especially if you want to use Licensing API.
Example: alsdbwqsyqwasdmskwsglkswfqfhmnpoj
In the URL: “https://chrome.google.com/extensions/detail/alsdbwqsyqwasdmskwsglkswfqfhmnpoj?hl=en
The app ID “alsdbwqsyqwasdmskwsglkswfqfhmnpoj.”
- Version Number
Data type: text/number.
Example: 1.0.0
- Manifest File
Data type: text/json.
Example: {
“manifest_version”: 2,
“name”: Chrome Ext Test,
“description”: “Cool app!”,
“version”: “1.0.0”,
}
- Google Account
Data type: text.
You can use any Google Account. There are no fees.
- OAuth Token
Data type: text.
Required if you want to use Chrome Web Store Payments.
- Description
Data type: text.
- Category
Data type: text.
To build a production version of the app, additional graphic files must be provided. The following images are the minimum requirements:
1. Icon
Data type: file/image.
Required resolution: 128×128
2. Initial Screen / Background Image
Data type: file/image.
Required resolution: 1242×2208
3. Screenshot
Data type: file/image.
Required resolution: 1280×800 or 640×400
4. Small title icon
Data type: file/image.
Required resolution: 440×280
5. YouTube video
Data type: file/video.
This is required to show off what your app does.
Please read https://developer.chrome.com/webstore/publish to see the updated requirement of assets.
CHROME RELEASE
The following are the artifacts required to release a Chrome extension app on Google’s App Store:
- Build
Data type: file/IPA.
- Privacy Policy
Data type: URL.
The URL must be valid and contain privacy policy text/content. Failing to provide a valid URL may result in app rejection by Google.
- Support URL
Data type: URL.
The URL must be valid and contain some sort of support content. For instance, a contact us page, help or documentation pages, or a FAQ page are acceptable examples of support URLs.
- Key Words
Data type: text.
- Detailed Description
Data type: text (4000).
The description must not contain any contact information like your phone, email, or URL, and must not mention the name of any direct competitors.
- Copyright
Data type: text.
- Contact Information
Data type: text.
The first and last name, phone number, and email address.
- Test Accounts
Data type: text.
The username/password or phone number/PIN required for logging into the app.
- Notes
Data type: text.
Any additional information/instruction for how to login and test calls.
- Screenshots
Data type: file/image.
JPG or PNG (RGB color space).
Required resolution: 1242×2208.
We recommend you use at least three screenshots. These screenshots should demonstrate the app in use. Graphics of the splash screen are not considered a valid screenshot. Typical examples are quick dial/favorites, keypad, call screen, settings, about, or history.
WINDOWS AUTHENTICATION
Submitting Windows applications to the Microsoft Store requires a valid and registered Microsoft account. A pre existing Microsoft account can be used to upload, manage, and update your app. There’s no need to create a new Microsoft account.
Windows also uses an optional two-step verification system to improve account security. It requires a password and a contact method (security info).
There are plenty of contact methods to authenticate user access to the account. Some of these are listed below:
- Verification using phone number
If two-step verification is enabled, the user will get notified on their mobile device whenever someone is trying to sign-in. The PIN code is typically received via message and must be manually entered to confirm an individual’s identity. You can also enable push notifications on mobile to access an account.
2) Microsoft Authenticator
The Microsoft Authenticator mobile application allows you to verify the identity of an individual. You can also use it to sign-in to the Microsoft account without any password. It generates a code in the app that is valid for a few seconds.
3) SSO (single sign-on)
If the user has already signed into Microsoft services that are configured with SSO associated with the Microsoft account, then the user will be automatically logged-in.
WINDOWS CONFIGURATION
The following are the artifacts required to configure, build, and test a Windows app using the Cloud Softphone white-label program:
- App Name
Data type: text.
Example: Softphone
- App Id
Data type: text.
This is the reverse domain and .windows is added automatically by Cloud Softphone. It cannot use dashes or underscores.
Example: com.softphone.windows
- App Version
Data type: text/number.
Example: 1.0.0
- Windows Developer Account
Data type: text.
A free Windows Developer account is required.
To build a production version of the app, additional graphic files must be provided. The following images are the minimum requirements:
1. Icon
Data type: file/image.
Required resolution: 128×128
2. Initial Screen / Background Image
Data type: file/image.
Required resolution: 1242×2208
3. Initial Screen / Logo Image
Data type: file/image.
Required resolution: 1165×350
4. App Icons
Data type: file/image.
Required resolution: 167, 180
5. Notification Icon
Data type: file/image.
Required resolution: 87
6. Marketing Icon
Data type: file/image.
Required resolution: 1024
WINDOWS RELEASE
The Following are the artifacts required to release a Windows app on the Microsoft Store:
- Base price
Data type: text.
- Category and subcategory
Data type: file/IPA.
- Privacy Policy URL
Data type: URL.
The URL must be valid and contain privacy policy text/content.
- Website (optional)
Data type: URL.
The URL must be valid and must contain some sort of support content. For instance, Contact Us page, Help page or Q/A page is acceptable example of Support URL.
- Support Contact Info
Data type: text.
- Display Mode (optional)
Data type: text (4000).
The description must not contain any contact information like your phone, email, or URL, and must not mention the name of any direct competitors like Android or iOS.
- Product Declarations
Data type: text.
- System Requirements (optional)
Data type: text.
- Age Ratings
Data type: text.
- Package Upload Control
Data type: text.
- Description
Data type: text.
- Screenshots
Data type: file/image.
JPG or PNG (RGB color space).
Required resolution: 1242×2208.
We recommend you use at least three screenshots. These screenshots should demonstrate the app in use. Graphics of the splash screen are not considered a valid screenshot. Typical examples are quick dial/favorites, keypad, call screen, settings, about, or history.
https://docs.microsoft.com/en-us/windows/uwp/publish/app-submissions
