Cross-Platform Development

This topic covers information regarding the build framework of your app project, including build environments, using a cross-platform build system, and how to deal with assets (images, fonts) to limit the size of your final product.

Typical Build Environments

Setting up to execute a build using the You.i Engine C++ requires selecting one or more IDEs to use as your build environment. The You.i Engine C++ currently supports and uses XCode, Visual Studio and Android Studio: these are the three most commonly used IDEs, and are typically chosen according to the platform being targeted. Depending on which platform you’re building on, your set up will also require other components to be installed.

For a complete list of the components you will need to install for different platforms, see Environment Setup.

A notable exception to this is Tizen. Tizen Studio is required for any deployment testing for Tizen apps, but does not work for development or debugging of apps. There are currently no IDEs that support development or debugging of Tizen apps; a developer needs to create the code in a text editor and use a build system to compile the code.

Using a Cross-Platform Build Framework: Benefits and Perils

You.i TV uses CMake as its build system. CMake is cross-platform, meaning that developers can select the preferred build environment of their choice, whether Mac (XCode), Linux (as per user’s choice) or Windows (Visual Studio).

CMake will compile for any target environment, and this is not dependent on the host environment that CMake is compiling from, making it a cross-compiler. You.i TV does not currently use CMake in this way, but the capabilities exist to add this functionality to CMake.

When CMake has lacked support for certain platform builds, You.i TV has adapted it to create this functionality.

CMake is easily adaptable when new features are added that need to be supported, and it works with both C++ and JavaScript programming languages: the You.i Engine is compatible with both. CMake can handle the multiple libraries—both static and dynamic—required by apps and is able to compile libraries with additional code for packaging into an application.

Using CMake allows for a streamlined, simplified build process; it can be used whatever platform your app is targeting.

For more information on CMake, see this link: https://cmake.org/overview/

Specific Platform Configurations

While the You.i Engine C++ allows you to develop for any platform and form factor, there are still certain requirements pertinent to the choices you will make on which platform you are using to build. A notable requirement is for certificates with provisioning profiles, which include security settings and permissions (including features like push notifications) for your app. Vendors rightly prioritize the security and verification of apps for their users.

Some app stores require that you include certificates or keys within the build itself—in the case of tvOS and iOS, your build will fail without those elements. For other platforms, you can build and test your app without the certificates, but you will need to incorporate them prior to submitting your app to the requisite store, as approval won’t occur without them.

Certain platforms require that you specify and set sign-in identities manually; there are sometimes environment variables that you can set to automate this process.

Each platform has its own way of approaching security and may also have other features that require integration at the build stage. Consult with each vendor to determine these requirements for each of the platforms you are targeting.

In the case of Sony, as they support different versions of their own SDK, when building for PS4, you need to ensure that you are using the same version of the SDK that the You.i Engine was built against. Older versions won’t work, and will tend to be deprecated by Sony as newer ones are released.

Fighting Packaging Bloat

Developing an app means being aware of the way the package (meaning all of the assets bundled with the code) is assembled. This necessitates an open dialogue between your design and development teams regarding the management of assets for different architectures, which encompasses both the form factors and platforms being targeted.

Packaging bloat has implications for the user’s experience of the app on their device and for the performance of the device. Bloat occurs when assets for multiple form factors and target platforms are bundled into a single app, irrespective of the actual device or platform that the app is intended for. Some devices have memory limits that can be severely taxed by apps that are overloaded with assets that won’t ever be required for the app to function.

Architectures

When building your app, you will need to specify the architectures being targeted. If you neglect to do this, your build may capture any and all architectures regardless of the actual architectures your app is going to support.

Optimizing Assets

Optimizing assets means ensuring that no assets are larger than they need to be for the form factor they’re destined for. For example, if you have an image that will appear in both a 10-foot and mobile version of your app, you will need to create two versions: one that is as large as needed for the 10-foot platform, and another that is smaller for the mobile version. Using one format of image for both means that the image assets contained in the package assembled for your mobile app will be larger than they need to be, unnecessarily inflating the final size of your app. Certain kinds of image assets, such as background gradients, can be created in ways that decrease their size which has implications for the final package size.

Assets by Platform

A big way to reduce bloat is to ensure that you include in your package only the assets your app will need to support the platform and form factor being targeted. Adding assets for form factors or platforms that your app won’t support only takes up space, and increases package sizes unnecessarily. You.i TV supports a structure that allows developers to organize assets into separate folders based on the platform (Android, iOS, tvOS, and so on), and a “common” folder for any assets easily shared across platforms. The build system will only gather those assets required for the target platform it is building against.

Splitting Assets From the Package

Occasionally, a platform will allow you to ship the assets of an app (images, video, audio, and so on) separately from the packages that contain the libraries and executables of the program itself. This is a strategy developers will want to employ when the app package size exceeds the limits allowed by the vendor’s app store. Android is one platform that allows this.