How to handle deployment of white-labeled platform mobile apps?

Question

I'm working on a product that will be deployed to many different organizations (ideal scenario, dozens). Each deployment of the system (composed of native apps for iOS and Android) will involve the following:

• Branding specific to the organization (i.e. a new skin)
• Integration with the organization's authentication system and user database
• Some custom features depending on the organization's needs

In other words, the core functionality will remain the same across all deployments, but each instance will look different, hook into a different authentication systems, and have certain features enabled/disabled.

My Question: What would be the best strategy for managing our 2 mobile codebases (iOS & Android) in order to minimize duplication and simplify the deployment process?

The three solutions we're debating are:

1. Create a core library that is shared across all instances (as a sub-project/library project, or a git submodule), and add a thin layer on top with the branding and any configuration details.

2. Maintain a Git branch with the core functionality, and create a new branch for each deployment that contains the additional code.

3. Do something totally different that some smarter person on stackoverflow suggests.

Which sounds best to you? Thanks in advance for any feedback!!

Answer 1

An approach I would consider is dependency injection.

On Android, if you use a dependency injection tool such as Square's Dagger you can simply create a @Module class which provides and injects components into your application. This way, you could maintain each white-label client's logic as separate components, and at compile time, a specific component would be selected via the reference in the @Module class.

This is also a great way to test your applications and it can avoid a lot of boilerplate code.

There's great info in the following talks also given by Square:

Dagger: A Fast Dependency Injector for Android and Java

Engineering Elegance: The Secrets of Square's Stack

iOS has similar frameworks, one being Objection.

Outside the box options:

Is it a requirement that the mobile client has to speak directly to the white-label's servers? If not, you may want to consider using your own servers as a proxy to the white-label's servers. This would move all of the business logic up to your server, supporting all of your clients.

I don't have any experience with this but a seemingly promising option is J2ObjC which is in development at Google.

J2ObjC is an open-source command-line tool from Google that translates
Java code to Objective-C for the iOS (iPhone/iPad) platform. This tool
enables Java code to be part of an iOS application's build, as no editing
of the generated files is necessary. The goal is to write an app's non-UI
code (such as data access, or application logic) in Java, which is then
shared by web apps (using GWT), Android apps, and iOS apps.

Answer 2

We're in a similar situation (we've got a platform of whitelabel apps with both an Android and iOS codebase) and we'll be transferring our native codebases to a C# implementation. We'll be making use of MonoTouch / Mono for Android. I actually just started working on this since last week (I've been asking some questions on SO to figure some Mono basics out).

This is effectively your option 1, but every platform will be build on C# code (with optionally the ability to interact with a "native" codebase if required).

Mono should make it possible for us to share somewhere between 30-50% of the code between platforms (currently iOS & Android, in the future perhaps Windows Phone). From the little experience I've had, it seems performance is good (remember: lots of people also use MonoGame to create high-performance games and I think Unity also makes use of Mono for 3D games). For me personally this is added value as well. I'd still love to make games someday and some basic experience with the Mono framework for "serious" apps will lower the barrier to use the MonoGame framework for gaming apps.

The nice thing about this setup is that you can keep all code (Android, iOS, Windows Phone) in 1 solution. Create a core "library" project (models, service calls, etc...) and create another project for each platform. The specific platform projects will each have appropriate UIs with a real native experience.

For an impression on how to create multiplatform apps with Mono, read a small introduction here.

Answer 3

If you not depend on native GUI use Unity3d, make your own Unity Package with all main functionality (and develop it as single app for all platforms), for any deployment app you will have to make new Unity project and import this Package to it, customise it (might be by replace resources and edit configs). (if you need to upgrade core functionality, you will need to simple import new version of core Package again to delivered project).

Or use your option 1:

1. C++ core library
2. Resource package which is can be individual for all applications (might be autorizations & modules configs also be here)
3. Native UI realisation for all platforms Android-Java, iOs-Objective-C