SigningHub OEM Distribution & Branding

SigningHub - OEM Distribution & Branding page is intended for Ascertia’s clients who want to update the branding of the mobile apps or want Ascertia to publish the apps for them.

Overview

This page identifies the areas which are brandable in SigningHub Mobile Apps. The following elements are brandable and can be changed according to the theme of the organisation and business:

  1. Colours

  2. Images

  3. Product logos

  4. Product name

  5. Language strings

Any element of the user interface which is not mentioned in this document is not brandable.

For OEM distributions, this page covers the basic requirements of Ascertia that a client needs to fulfil.

Branding

An admin can change the branding of the mobile apps from the SigningHub Admin console. When applications are launched, they pull the branding colour from the SigningHub Admin console. To access the branding configurations:

  • Log in to the SigningHub Admin Console using your enterprise admin credentials.

  • Click "Configurations" in the left menu, and click on "Branding" in the Settings section of "Enterprise Configurations".

The following are the components of the mobile applications that are brandable:

Colours

The “Colour Palette” section enables administrators to define the visual theme of the platform by applying brand-specific colours to various interface elements. You can configure the primary colour, text and icons, error indicators, and document field highlights to create a consistent look and feel across both web and email templates. Built-in accessibility checklists and preview panels are provided for each setting, ensuring that chosen colours meet contrast requirements and enhance readability for all users.

Primary colour

The primary colour setting allows you to define a colour scheme that reflects your brand identity across various UI elements, including web and email templates. This primary colour is applied to elements such as buttons, toggles, and action prompts, helping users recognise your brand consistently. Accessibility is a key consideration here; the primary colour should contrast well against the background to ensure readability without the need for additional background elements. We recommend testing the primary colour on both light and dark backgrounds to confirm it meets accessibility standards and enhances user experience.

Background colour

Text and icons over primary

Preview appearance

Accessibility checklist

Error colour

The error colour settings provide options to set the colour scheme for error notifications, ensuring users quickly recognise issues. This section enables you to choose a distinctive colour, typically red, for error alerts, buttons, and messages, making it easy for users to identify critical errors. Accessibility recommendations suggest selecting a shade that provides strong contrast against the background, so error messages remain prominent. This helps maintain consistency across the application, allowing users to identify and address issues efficiently without confusion.

Primary error colour

Text and icons over primary error

Preview appearance

Sidebar navigation

Sidebar navigation is not available in SigningHub mobile apps; therefore, these colours will be excluded from consideration.

The “Logos” section of the Branding page allows administrators to configure and customise different logos that will be displayed across the SigningHub platform and related communications. From this screen, you can upload and manage the Website Logo, Signature Logo, Email Logo, and Favicon. Each of these logos plays a distinct role in creating a consistent brand identity for your organisation within SigningHub.

To change the logos:

  • Expand the "Logos" tab on the “Branding Page”

  • Browse the images for your “Company Logo”, “Signature Logo”, “Email Logo” and “Favicon” as required. (The set Website logo will appear on the login page, and on the left in the top bar.)

OEM distribution

Ascertia provides mobile application customisation and separate distribution of the customised applications for clients' businesses. Businesses can provide their own branding and other necessary details related to application deployment, allowing Ascertia to compile the application with all customised resources and either submit it to the app stores on behalf of the client or provide the compiled applications to the client for submission. The following customisations are available in SigningHub mobile applications, in addition to branding.

Application default configuration

Certain configurations must be defined before the application can be compiled and submitted to the app stores. Clients are required to provide the following details:

Base URL to APIs

Example: https://api.signinghub.com

Application name

A new application name is required; this name will appear on mobile devices, along with an associated application icon.

Example: SigningHub

Application icon

An application icon is required to compile the application with a new icon. This icon appears on the mobile device’s home screen (springboard) and helps the application stand out from other apps.

Example:

Splash screen

A splash screen appears in mobile applications and remains visible until the necessary resources are loaded in the background, after which the application's first screen is displayed. Typically, the splash screen is an image provided by the client and may include introductory content to engage users while the application loads. Splash screen includes:

Background image

A background image is displayed on various screens, such as the splash screen, login screen, and signup screen.

Sliders

Sliders are the scrollable elements of the splash screen. A maximum of five sliders can be configured, and each slider may contain text, an image, or both.

Example:

Product icon

A product icon with a transparent background may be required on the home page, similar to the one displayed in the SigningHub app.

Example:

Checklist

The following table provides a checklist and the required information for both platforms (Android and iOS).

Checklist and Required Information

Requirements
Remarks

Application Name

Example: SigningHub. The name should be up to 50 characters in length.

Subtitle/Short Description

Example: Premier Signing Solution. The length should be up to 30 characters.

API URL

Example: https://api.signinghub.com

Dropbox Account Credentials

Required only if the business wants to enable Dropbox-related features in the application.

Google Account Credentials

Required for configuring push notifications through Firebase services and managing crash reports via Crashlytics.

Customers can either:

  • Grant Ascertia temporary Admin rights on the Firebase Console to create and configure the required project, or

  • Share their existing Firebase project credentials with Ascertia. If neither option is preferred, please follow the process outlined in the "Push Notification (by Client)" section below.

Microsoft Account

Required only if Azure or OneDrive features are to be used.

Apple Developer Account Credentials

Required to create development and production certificates for submitting the application to the Apple App Store.

Play Store Developer Account Credentials

Required to create development and distribution environments on the Google Play Store.

Application Description

An example screenshot is provided below:

Privacy Policy URL

Required so that users can review the privacy policy before downloading the application. Apple will redirect users to this link from the store page.

Splash Screen Slider Data

Specify how many sliders should be shown and the data (text/images) for each slider.

iOS-Specific Requirements

Requirements
Remarks

Application Icon

Size: 512 px × 512 px (PNG format).

Splash Screen Background Image

Apple guidelines recommend providing multiple images for different orientations and resolutions.

Product Icon

Size: 567 px × 190 px (PNG format).

App Store Icon

Size: 1024 px × 1024 px (PNG format).

Support URL

Apple displays this link on the store page for users to submit queries related to the application.

Marketing URL (Website)

If users want to know more about the application, they can follow this link.

Contact Information

Provide the name, email address, and phone number of a contact person.

General Information

An example screenshot is provided below:

App Review Information

Apple requires one set of test account credentials for the provided API URL. This account is used by Apple to verify the application. A screenshot from the store is shown below:

Android-Specific Requirements

Requirements
Remarks

Application Icon

Must be provided in two layers:

  • Background (Non-Transparent): 432 px × 432 px

  • Foreground (Transparent with Logo): 432 px × 432 px

  • Maximum drawable area: 288 px × 288 px.

For more details, see Google’s Adaptive Icon guidelines.

Legacy Icons

Must be provided in the following size with sharp corners: 192 px × 192 px.

Splash Screen Background Image

Size: 1280 px × 1920 px.

Product Icon

SVG format, in either white or black, with a transparent background.

Play Store App Icon

Size: 512 px × 512 px, shape: full square.

For more details, see Google Play’s App Icon guidelines.

Play Store Feature Graphic

Size: 1024 px × 500 px.

Account Deletion URL

Google Play requires a public link explaining the process users must follow to request account and data deletion. The customer must host this guide on their server and share the link with Ascertia (similar to the privacy policy link).

Push notification (Configured by client)

If the client chooses to manage Firebase independently, they must create their own Firebase project and connector, then provide the following files to Ascertia:

  • google-services.json (for Android)

  • GoogleService-Info.plist (for iOS)

These files will be integrated into the brandable apps before upload.

Accounts

This section explains the account invitation requirements for app release on the Google Play Store and Apple App Store. It also includes information regarding the Firebase account needed to enable features such as push notifications.

Apps submitted by clients

If the client submits the applications to the stores themselves, the "Checklist" section is not applicable. However, additional information is required to create a signed build for both iOS and Android platforms.

  • iOS

    • Bundle ID (e.g., com.company.appid)

    • Production Certificate (.p12 file)

    • Provisional Profile

    • Firebase Plist file (GoogleService-Info.plist)

  • Android

    • Application ID (e.g., com.example.app)

    • google-services.json file from Firebase

    • Keystore (.jks file) and credentials (storePassword, keyPassword, keyAlias) to sign the app

      1. This is required only if the client wants Ascertia to sign the app with their own .jks file. Otherwise, Ascertia will create a new one to sign the app.

PreviousInstallation via domainNextGo>Sign OEM Distribution & Branding

Last updated

Was this helpful?