Jump to content
  • Advertisement

How does a dev typically manage multiple platforms?

Recommended Posts

Say (hypothetically) a company is looking to deploy an app on Steam VR, Google VR, and any other VR app. Do software devs and companies typically manage the differences in the way the game or app is coded and launched to different platforms? 

Do you make the changes to the main part of the game then tweak them for each platform?

Just curious. Thanks!

Share this post

Link to post
Share on other sites

I can't answer the VR-specific portion, but I can give you some examples of what I work on.

I work on Android and iOS games developed in Unity.  Our process works like this:

The vast majority of our game is written in C# and works on both platforms without modifications.  Unity and Mono provide most of the low-level platform-specific stuff for us.  For example, if we write code that says: 'File.ReadAllBytes(Path.Combine(Application.persistentDataPath, "savegame.bin"))':

Application.persistentDataPath gets the appropriate folder on the device where we can load/save data.  It's different on Android, iOS, Windows, etc.

Path.Combine will use / on OSX, Linux, Android, and iOS, and \ on Windows.

File.ReadAllBytes will eventually call the OS-appropriate file I/O functions.

The majority of the C# APIs which need to call OS methods work similarly.


Unity also gives you a way to write OS-specific methods yourself.  For example if you want to implement push notifications on Android and iOS, you have to write your own Java (for Android) or Objective-C (for iOS) code, which you can then call from your C# game code.

Unity provides preprocessor defines you can use to enable/disable specific C# code for each platform as well (this is mainly used to call the unique native plugin):

public static void RegisterForPushNotifications()
    // Push notifications not applicable to the editor


When we want to build and publish the game, we use scripts which automate the following process:

Launch Unity with the activeBuildTarget set to the desired platform we want to build (Android or iOS).

Run the BuildAssetBundles command to build our free DLC.

Run BuildPlayer to build the APK (on Android) or XCode project (on iOS)

On Android:  Run zipalign and jarsigner as postprocessing steps on the APK.

On iOS: Invoke XCode to compile the XCode project into the final IPA.

This entire process is fully automated by our continuous integration build farm (a set of computers on the network dedicated to this).


After we create the APK/IPA, we give those builds to QA for testing.  This process repeats until we're satisfied that all major features are working correctly and bugs have been fixed.


To actually let real players download the APK and IPA, we have a separate team who will use the Google or Apple store interfaces to upload the files, fill in a bunch of publishing details (app name and store page details, markets to release in, etc) and then hit the publish button(s).

Share this post

Link to post
Share on other sites

1) Object not draw themselvs

2) SOLOD/TDD/GRASP principles

3) Entity Component System

4) At most, you need only low level explicit modules and system level API abstractions

Compile time polymorphism = #define/templates

Build time polymorphism = list of files in build system


Share this post

Link to post
Share on other sites

I'm developing native for different platforms. We have our build pipeline targeting for different platforms via command parameter when starting the build and also use compiler switches inside the code. There is a platform header for each system we want to support and a general header that is included by the API code. The runtime works in the same way but defines unified functions for platform dependent API calls so our code can use for example

uint64 GetHighPrecisionTimestamp()

without the need to know anything about the implementation below.

For code that just uses different available APIs on the same platform like Occulus or similar VR SDKs, you have to possible options:

  • Building with compiler switch to target exactly one SDK (bad flexibility)
  • Building using some small bootstrapping code that binds the correct library and provides runtime function mapping (LoadLibrary/dlopen and GetProcAddress/dlsym) and hide this behind a unified API (good flexibility)

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!