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()
{
#if UNITY_EDITOR
    // Push notifications not applicable to the editor
#elif UNITY_ANDROID
    AndroidRegisterPushNotifications();
#elif UNITY_IOS
    IosRegisterPushNotifications();
#endif
}

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).

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

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)