RSS Feed

The Joel on Software Discussion Group (CLOSED)

I often noticed that many programmers consider developing cross-platform applications extremely important. I don't understand this.

Why is cross-platform support so important? Who are the customers who require this?

In my mind, if I write a desktop application, then it must be for Windows, because Windows has over 90% of the market for desktops.

If I write a server application, then it must be for Linux.

I have worked for lots of clients and the requirement of writing a cross-platform app appeared very rarely.

Also, many times when writing a cross platform desktop app, no matter what toolkit I use, the resulting application doesn't have the right look-and-feel on any supported system. There are always subtle and not so subtle differences when comparing to how a native app should look.

So in my opinion cross platform development is:

- extremely rarely needed

- a poison, because it produces apps which don't have the right look and feel on any system

If your business is producing the same product but for different target markets with different operating systems and different kinds of platforms then you don't want to have umpteen different versions.

That would mean upteen source trees, delays in getting releases out across all platforms and OS's etc.

There's bound to be some platform specific code but you keep that as small and as well abstracted as possible.

One of the reasons:
* Because the technologies are more progressive.

Sometimes the platform-specific tools are like COBOL -- kind of obsolete, but still work.

If you consider that Windows is the only major OS that tries to avoid the Unix code bases, you will understand why cross-platform is even an issue at all.

The problem is that the new generations don't really mind jumping on the Unix-like bandwagon, hence as long as it's supplied with fresh blood, it's going to grow.

It's not that Windows is not attractive, it's just that it's not the only game in town, despite its monopoly. One needs to understand that the folks responsible for Windows have been trying to avoid its total commoditization. If they had embraced the commoditization of Windows, then they wouldn't spend energy fighting it and fighting the competition.

Also, while Windows is developed mainly in the US, also mainly by English speaking folks, the world is much more than that. I think Windows should have opened its development to the world, with centers of development spread throughout the world, like Japan, China, India, Brazil, Europe in general, etc. That is, the money that's generated in those countries should have financed the development of Windows in those countries, at least partially.

I know it's not simple, due to the differences in laws, politics, etc. But this gives the opportunity to the Unix-like OSs of flourishing in those countries, with the help of the competition of Microsoft in the US, of course. Thanks to IBM, Sun, Novell, etc, the Unix-like OSs get a great deal of support in the Windows' backyard.

Thus, the simplicity is pretty much in the eye of the beholder. :-)

Simple answer for us - we have roughly 50% windows users and 50% OSX users - because of the niche market we target.

The advantage of a cross-platform solution is that you do not dictate to your potential customers what platform they should use, therefore you do not turn potential customers away.

I develop web applications in PHP, which means that it will work on every platform which supports PHP. For example, I do all my development on Windows, but the same code runs under linux, unix, whatever.

My applications are also database independent, which means I don't have to say "MySQL only" or "PostgreSQL only". I leave the choice to the customer.

If your desktop app has a server portion, then I would say it was fairly important for it to support Linux.

We didn't initially have support for Linux, but an increasing number of our clients wanted to be able to run the server on it.

Luckily we used Delphi and it was relatively easy for us to port the non-UI stuff over to Linux (using Kylix) without much in the way of code changes.

If we had had to maintain two separate code-bases, it would be extremely difficult to manage.

Some programmers are in love with cross-platform, just because... sort of a technical challenge

However, some product types, fewer than most programmers probably think, genuinely may sell better cross platform.

For example, if somebody sells an enterprise app, the enterprise customer may want to know that your software works with the mix of platforms/hardware/databases/etc., that they have now... and that they may have in future.

I write all of my code to be cross platform so that when someone asks if the application will run on their platform, the answer is "if you want" and not "no go away you loon, why do you want a <insert OS here> version."

I always thought Cobol was a mess precisely because it was *supposed to be* cross platform.  Then to get anything done practically every compiler ever produced for it added machine and OS specific extensions.

If you look at the Cobol market today (for "small" platforms anyway) it's all about portability.  How do they achieve it?  Mostly through sandboxed interpreters.

I find the vendors very defensive about this strategy when questioned.  The questions typically arise when you move to one of these portable Cobols and (a.) your performance takes an enormous hit or (b.) your code no longer can use native DLLs, middleware, and OS facilities.

My niche is the Mac, but I develop using a cross-platform toolkit for marketing purposes: the X11 version of my application is free and the Aqua version requires a paid download. Same functionality, but a lot of users don't want to use the free "Unixy" version, and pay for the Aqua version.

Doing this is simpler than figuring out how to a) cripple the application's free version or b) enforce a time limit on the free version. I only need to set a few general variables on startup, which are then invoked depending on which runtime of the toolkit I've shipped (X11 or Aqua).

This strategy wouldn't be possible using a platform-specific toolkit.

Portable code isn't simply about delivering your application to multiple platforms today, but also about delivering the application to same platform a year from now, or to the same users on a different platform a year from now.

Technologies change. Portable software insulates you from those changes whether they come from the manufacturer or from your clients. In either case, you don't want to be screwed when your platform goes through a major upgrade, or when your largest client decides they want to switch platforms for their own inscrutible (but, from their point of view, perfectly valid) reasons. Occasionally, you may even need to port to a new platform (e.g. because the manufacturer abandons your platform, loses their lead position or simple goes out of business).

Unless you don't plan to support your own product for more than a few years, it is simply a matter of enlightened self-interest to write code in a portable manner. I'm not saying you need to go whole hog and make sure your code can work on three entirely different platforms at once, but you should reduce your dependance on vendor specific technologies and separate your presentation code from the business logic, in order to minimize the impact of vendor-induced change.

This means segregating database access from the rest of the application (so that DBMS-specific SQL can be easily replaced when you need to switch from Oracle to Transact SQL or vice versa), segregating the GUI layer so that the GUI can be redone in the API-du-jour, using mature, non-proprietary languages such as C or C++ for the business logic and making sure that the business logic compiles without warnings on two entirely different compilers (e.g. MS VC++ and GNU gcc). You won't be able to entirely eliminate the effect of a major port, but you'll greatly reduce the pain involved.

The investment is not all that huge and most of the changes are just good design and coding practices. Compiling against multiple compilers (or, if you can swing it, multiple platforms) may even uncover a few, otherwise hard-to-find, bugs in your business logic. When the time comes, however, that MS pulls the rug out from under you, or when your largest client comes and tells you that they are migrating to Solaris or OpenVMS or z/OS, you will be mighty happy you put a little effort in up front.

Cross-platform is pretty important in the world of version control tools.  If a team has 30 developers and 3 of them are non-Windows platforms, they're going to choose a version control product which is cross-platform.

The OP has obviously never done graphics or sound applications.

>>>>>
The advantage of a cross-platform solution is that you do not dictate to your potential customers what platform they should use, therefore you do not turn potential customers away.
>>>>>

What if the costs exceed the expected revenue from the less dominant OS?

>>>>>
My applications are also database independent, which means I don't have to say "MySQL only" or "PostgreSQL only". I leave the choice to the customer.
>>>>>

I think, this is more dificult than you make it sound.  Or, I suppose it depends what your app is doing.  If you are processing large amounts of data (think tera-bytes as my company does), it's not as simple as setting up generic installations.

Because it is what a lot of clients want.

In the early 90s I worked for a small consulting shop. It happened more then once that we would put together a proposal for a business, only to have them return a week later and tell us "We forgot to tell you that Bob and Jane in our Art department work on Macs, so we absolutely have to have a Mac version too. That won't cost extra will it?"

Isn't basically any of the modern languages portable?  I mean:  Java, C#, Ruby, Python, Perl are all portable.  Why is it such a big thing to be cross platform, they all appear to be cross platform. 

Sure, the devil is in the details, but that's going to be true in any case.  Cross platform apps do tend to not look like a native app, and they also tend to be slow (which I think is worse than not looking native) but it doesn't seem as though it is so hard to make something that is cross platform now.

" "We forgot to tell you that Bob and Jane in our Art department work on Macs, so we absolutely have to have a Mac version too. That won't cost extra will it?" "

And I'd tell them what I tell our other customers:

I can have a Mac version for you for 20x the price* (about $4,000) or you can use Virtual PC for $160 or you can buy them an extra pc for $400 (with 17" monitor).

We give away Virtual PC these days with orders over $400.00.  About 1 taker a year on that.

* I'd love to have a Mac version but there are 20 PC users for every Mac user  (Macs have a 4% to 5% penetration vs. Windows at about 93%. Commodore 64 makes up the rest <g>)

We distribute a product that used to be x-platform, but just the cost of the Quicktime licenses and the hassle therein (having to update it every year per contract with Apple) drove them to make it Windows only.  (I wish they hadn't. We sell about 2 or 3 copies to Mac users a year. It's nice to have SOMETHING for the Mac users who are outraged that you'd make a rational business decision and disregard the fact that the earth orbits around the Mac b/c it's the *best*.

"just the cost of the Quicktime licenses "

What cost? Did you have to distribute Quicktime Pro with it? Otherwise there's no cost.

"Quicktime Pro."

Is that the version that doesn't nag you to buy Quicktime Pro constantly?

>>>>>
My applications are also database independent, which means I don't have to say "MySQL only" or "PostgreSQL only". I leave the choice to the customer.
>>>>>

>>I think, this is more dificult than you make it sound.<<

No it's not actually. As Jeff Dutkey said "The investment is not all that huge and most of the changes are just good design and coding practices."

My framework is built around the 3 Tier Architecture with separate components for the presentation, business and data access layers. This gives me a clear separation of responsibilities. When a business object wants any database access it calls an appropriate method on the data access object which then constructs and issues the necessary SQL query. The trick is that I have a separate DAO class for each DBMS, and I instantiate the DAO object using whatever DAO class is appropriate to that installation. I have a global switch which defines the default DBMS for the entire installation, but individual tables can be accessed through a different DAO if required.

It's not rocket science, just structured programming (which I learned in my COBOL days) taken to a higher level.

"Isn't basically any of the modern languages portable?"

Yes and no. The language may be portable (especially if it is interpreted) but there are many subtle cross-platform perculiarities. The <CR>/<CR><LF> end-of-line difference between *nix and Windows is one. There are also low-level differences, such as little-endian vs. big-endian. Then you have much larger differences. I remember developing a UI in Java for a cross-platform project in grad school (Windows and Solaris). For the most part everything worked, but there were subtle differences in behavior that made things look and feel "not-quite-right" (as another poster pointed out).