As a software developer until now, I've mostly worked on projects that were quite "monolithic" with hardly any dependencies on other projects, without building automation (no Make, Ant, Maven, etc.) and kept on a simple version control system (mostly Subversion) with just a few easily managed version branches.

Now together with some friends I'm planning a project that is intended to run on multiple platforms (mostly mobile: Android, iOS, Kindle, Windows, etc.), thus written in several languages and on different development platforms.

This will lead to many dependencies: All projects sharing the same resources (e.g. images) or projects dependent on each other (e.g. a core Java library project used by the Android and other Java based implementations).

So what I need is some basic information on how to answer questions such as: How would the VCS be structured? Would a client-base or a decentralized VCS be better? How to decide building automation system(s) to use?

Since this quite an open question I guess for now it would be great if you could point me to any books or web resources that you can recommend for this topic.

1 Answer 1


This doesn't answer your actual question, but may be of help.

Consider cross platform tools

There are layers such as PhoneGap, that would allow you develop apps accross multiple platforms in one language.
Also, a cross platform language, such as haXe might be of interest (you can use the C++ backend for native apps, and the JS backend for web and mobile apps (through the aforementioned PhoneGap)).

You can drastically reduce the amount of code you need to write, if you can reuse it on multiple platforms. Having less code in the first place, solves many problems before they even occur.

Focus on a single platform to start with

If you try to write the app for many different platforms at once, the results may become mediocre. Instead, you should rather try to pick a single platform, to focus on. Test the concepts of your app on that platform and then port it to other platforms and adapt it accordingly.

For example, you may realize, that you don't actually want the different ports to share graphics, to better fit with the graphical needs. For example on the iPhone 4, you have a very high resolution, so you might need extra icons for that. Also, the users may have different expectancies.

Porting a working concept to a new platform is relatively straight forward (although sometimes work-intense), in comparison to really developing it in the first place. If you try to do that on multiple platforms at they same time, you may overburden yourself.

So pick a platform, that is sufficiently widely spread and that you feel comfortable with, to get up and running quickly. A user base is a valuable source of feedback, that you'll hardly get anywhere else.

Do not think too big. Start small and grow.

This applies not only to your initial choice of platforms, but also to your projects setup. Adapt your toolchain according to your needs instead of investing time on building up a giant all-purpose environment, that is actually putting a lot of overhead on your development process.

You want to tackle a non-monolithic problem. As a consequence, I think a behemothish, monolithic workflow is maybe not the best thing to do.

  • Thanks for the tips. These are certainly ideas I'll keep in mind. I'm actually looking into PhoneGap, but while it does cut down on duplicate coding, it still requires you to create native projects, which each include the shared code plus a library, so it still not trivial to organize.
    – RoToRa
    Commented Jan 9, 2011 at 17:30
  • 2
    +1: Start small and grow. Brilliant. Choose one platform to start. Migrate after you have something working.
    – S.Lott
    Commented Jan 9, 2011 at 18:50
  • You are correct. The question is still unanswered.
    – zkent
    Commented Apr 19, 2016 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.