Developing for different platforms individually, does anyone recommend it?

Question

I know it is easy to recommend several cross platform libraries.

However, are there benefits to treating each platform individually for your product?

Yes there will be some base libraries used in all platforms, but UI and some other things would be different on each platform.

I have no restriction that the product must be 100% alike on each platform.

Mac, Linux, and Windows are the target platforms.

Heavy win32 API, MFC is already used for the Windows version.

The reason I'm not fully for cross platform libraries is because I feel that the end product will suffer a little in trying to generalize it for all platforms.

Answer 1

I can't deny that this is attractive, but it certainly raises the question of a middle ground. Obviously, you'll share some backend code, but how much can you share and what will you share in the UI side in both terms of design and code?

I think this is an individual case issue. Usually, it probably isn't worth it, but some specific applications on some specific platforms should be targeted to the particulars of that operating system.

Answer 2

Yes, cross-platform UI libraries are always going to make your program look and/or act a little "weird" on at least one platform.

If you have good separation between the UI code and the internals, it isn't very hard to re-use the non-UI code, and create an optimized user interface for each platform. A lot of high-budget cross-platform applications are made just this way.

Answer 3

I see the benefits as

• being able to get a totally native behavior in all your platforms which is a good thing for end users

The risks being that

• You may end up coding three apps instead of one with a few differences (ie, it's easier to fall in the let's do X differently as well!)
• You'll create slight incompatibilities between the different OS versions without noticing it.
• The maintenance cost will suffer proportionally to the amount of different code you have

So, by taking the risks in consideration, you can develop nice native behaving apps, with the largest common core possible (resisting the temptation of risk 1), a great set of integrated tests for all the platforms (minimizing risk 2) and designing to reduce the amount of code needed to get the native behavior (taking care of risk 3)

Answer 4

It also depends just how different your platforms are, and whether all the functionality on one platform is available on another. I develop tools that have versions available for Win32 platforms, Windows CE and mobile, and various embedded platforms. Some aspects of the product simply aren't pertinent to platforms that don't have the matching hardware. For example, I'm currently working on [link text]a field based land survey product[1] that works with a variety of measurement devices, such as GPS and Total stations, using a variety of communications media, such as bluetooth, RS232, and radio modems, on a wide range of platforms. The specific version I'm currently working on will be hosted onboard on a measurement device with a relatively small screen and keyboard, and very limited memory and storage. There is no point including the functionality relating to other devices, and it is highly beneficial to the user to keep the interface as simple and streamlined as possible.

Streamlined user interfaces, small executables, and a zero tolerence to bloatware are still of paramount importance in some domains. Plenty of common source for sure, but also plenty of target specific source and conditional compilation.

Answer 5

For client programs (i.e. not web server programs) it's pretty hard to find to find good Mac and Linux developers, and not really easy to find good Windows developers.

The more platform independent code you have, the easier and faster it will be to complete to your project on all three platforms.

It's going to be expensive and risky to maintain three codebases. Your competitor who uses cross platform tools is going to beat you to the market every time.