Divide an app to multiple apps that have different UI design and share logic code

Question

I have an app which I will call it the "base app". The app works with many brands. I need now to separate those brands, and to make a distinct app for every brand. Every app will have a slightly different design (including different images) and here and there maybe some specific-to-a-brand code. All of the apps should also use the same base code from the "base app" that deals with logic.

I have some options I have thought, but I am not sure if any of them suit my needs. Will be happy for clarifying the difference among the options.

The options I have thought are:

1) Creating an app for each one of the brands and just copy-paste the class files from the "base app" as a reference, except the .xib files, which will be copied as a copy. The problem is that then I do not know how and where to write a brand specific code (because it will be shared among others).

2) Creating a workspace that will include the projects for each one of the brand. Not sure how this works and if this is correct, will be glad for help clarifying here.

3) Nest a "base app" project inside every brand's project. Any help clarifying what does it do will be appreciated.

3) Using the base app as a static library which will be linked in every brand's project. Not sure what will happen with the UI (shared, not shared). Will be glad for help clarifying here too.

4) Using a simple way of maintaining each one of the brand's project, including the shared code (which will be a disaster, I guess).

Answer 1

The simple solution in iOS is use targets.

For resources you can use different targets for each brand and then select different resources (images, xibs, etc) for each target.

Also if the changes in code are minimal you can then refactor some part of your code and create different classes with different implementation for each target (you can use some pattern like a Factory). Also you can simply use preprocessor macros.

It's not the better, but this is the simplest and quick approach, but if your code changes a lot it's better to create a core library like the other answers say.

Answer 2

A good approach would be to split your app up into the following components:

• Core Model Library
• Reusable views & view controllers. The views can be designed to support skinning and customization.
• Any other reusable code that can be encapsulated as its own 'identity'.

These core projects should ideally have their own continuous integration (quality control) builds and tests.

And then use CoocaPods

Instead of manually performing all this complex integration, use CocoaPods. CocoaPods will create the Xcode workspace, build the libraries and link them into your project. You then create a custom build just by gluing the pieces together.

In addition to this, CocoaPods also performs tasks such as:

• Resolving transitive dependencies - which just means building and fetching any libraries that your libraries themselves use.
• Managing versions of the libraries being integrated.

Private Spec Repo is possible, or just use GitHub

The main CocoaPods repository is of course public and contains open-source and/or freely available libraries.

You can host your own CocoaPods spec repository, or simply set up a private GitHub account, and include a PodSpec in each project, then resolve as follows:

pod 'MyLibraryName', :git => 'https://github.com/myOrgName/MyLibrary.git'

this will install all of your libraries into your workspace. To update your project to include any changes to the core libraries, simply:

pod update

Advantages of this approach

• You'll have a separate set of quality controls that gets applied to each core project.
• There'll be much less reputation.
• You can use more automation. More automation equals less waste equals more customer value.
• As the team grows, you can split up core product devlopment and solution integration into separate roles/teams. A team working on an integration build, need not pull the latest library features, if that would disrupt them.
• You can have two different customers on different builds of the core library. CocoaPods will manage this seamlessly. So you wouldn't necessarily have to update a build, until you get an enhancement request or scheduled maintenance. (Again reducing waste, thus increasing customer value).

Inspired by Piggly Wiggly (but lean through and through)

This approach is modeled after the production line style approach that was popularized in Japan after World War II. Its called Lean Methodology, and is all about having a fast, small inventory and reducing waste. (Delivering more with less). . Japanese execs got the inspiration for this when they went to America and visited Piggly Wiggly Supermarket stores.

Answer 3

This is often something you encounter creating cheap flash-games or apps.

These have very generic frameworks like: kicking a ball, shooting at the screen, or generating a list with some data downloaded from a specific server etc...

Everytime they want to create a new shootergame, they just load up their shooting framework, add a bunch of graphics and can release a crappy game within a day.

How do they do it?

They often create a framework which contains shared models, handlers, interfaces etc. Put a lot of general utility functions like downloading files etc in a library. And you can also create some default framework views and view-controllers.

When you want to create a similar app, just import the library and re-use the base framework. Containing base-views, base-models etc.

You can find a good example in the demo-examples delivered with the ios SDK or android SDK.

Good luck.