Всего сколько лет назад о кроссплатформенном ПО большинство разработчиков не задумывалось вовсе, а те кто сталкивался с подобной задачей в основном занимались разработкой решений которые работали на Windows и UNIX. Это были (и есть) крупные серверные системы, системные библиотеки, редакторы, и прочее узкоспециализированное ПО.
Но, все течет, все меняется, Windows и Linux (с Гномом или КДЕ) уже не единственные платформы с которыми работает “обычный пользователь”. В последнее время появилось большое количество платформ для обычного пользователя и это никак нельзя игнорировать.
К сожалению, даже сейчас, большая удача если ПО работает на чем-то кроме Windows. А уж если такое приложение еще и выглядит прилично… Но это уже совсем редкость.
Собственно, к чему я все это пишу. Меня всегда интересовало кроссплатформенное ПО, но, обычно, это было серверное ПО не обладавшее вообще никаким GUI. А тут меня озадачил вопрос, как написать приложение для конечного пользователя которое можно при минимальном количестве усилий заставить работать на как можно большем количестве платформ. При этом, приложение везде должно выглядеть “как родное”. Да, говоря о приложении для конечного пользователя, я имею ввиду не очень сложное приложении типа графического просмотрщика, планировщика задач и т.п. Приложение обладающее относительно не сложной бизнес логикой, в тоже время не являющиеся приложением класса свистелко-перделка у которого есть только GUI.
Исходя из сказанного ранее, я думаю что список поддерживаемых платформ можно ограничить следующими ОС: Windows, Linux, Mac OS X, iOS, Android, Symbian^3 и Windows Phone 7. А в качестве языков для разработки приложений C++, Java, Objective-C, C#.
Как известно, при наличии желания обеспечить поддержку большого количества платформ, необходимо довольно тщательно подходить к вопросу построения архитектуры приложения. Как минимум стоит продумать разбиение приложения по слоям GUI, бизнес логики и, при необходимости, базы данных.
Если внимательно посмотреть на список платформ, то сразу становится очевидно то, что, как минимум, общего GUI создать не удастся, хотя, это не такая уж большая проблема. Для начала я подготовил небольшой, и совершенно не претендующий на “единственный и окончательный” список библиотек, поддерживаемых каждой из платформ. В список я старался включать наиболее распространенные, либо переносимые библиотеки (именно поэтому в нем нет WTL и других похожих решений).
Windows. Наверное, это наиболее богатая в плане выбора доступных библиотек платформа. GUI для Windows приложений отлично разрабатываются с использованием C++ (Qt), Java, C#. В принципе, можно использовать даже Objective-C из состава GCC в связке с GNUStep, разве что перед тем как на это решиться, я бы очень советовал посмотреть на вот этот скриншот.
Linux. Как ни странно, но тут практически нет никаких отличий от Windows, разве что Mono поддерживает C# версий 1.0, 2.0 и 3.0, версия языка 4.0 в разработке.
Mac OS X. Выбор доступных библиотек для Мака существенно более ограниченный. Полагаю, это вызвано тем, что основная масса пользователей не любит отличный от Cocoa интерфейс и как следствие все стараются выпустить приложения с “родным” внешним видом. Недавно (Mac OS X 10.6.3), руку к этому приложила и компания Apple объявив Java “устаревшей”. Написанные на Java приложения и раньше отличались некой внешней убогостью и неповоротливостью (Stanza, Code Collaborator), но поддержка со стороны Apple гарантировала стабильность платформы. Теперь этого нет и использование Java уже не кажется на столько привлекательным решением как раньше.
Еще существует Qt, который хоть и не позволяет добиться 100% нативного внешнего вида, но все же не плох (Perforce Client).
Поклонников C# обрадует тот факт, что Mono работает на Mac OS X, но вот то как Mono приложение будет выглядеть на Маке заставит вздрогнуть даже не притязательного пользователя. Дело в том, что Mono использует библиотеку GTK, которая работает на Mac OS X только через X-сервер и отличается на редкость уродливым внешним видом (лично я это могу простит только Wireshark).
iOS. Обычно, GUI для iOS приложений пишут с использованием Objective-C и Cocoa Touch (несколько урезанная версия Cocoa “большого брата” с поддержкой тачскрина). Но никто не мешает купить тот-же MonoTouch по вполне разумной цене и создавать GUI на C#. Да, судя по видеороликам, на iOS можно затащить не только Qt, но и QML. Удастся ли разместить такое приложение в AppStore я не знаю.
Android. Тут все довольно просто, GUI пишется на Java с использованием Android SDK. Так же на платформу портируется Qt в рамках проекта android-lighthouse который на данный момент доступен в довольно куцем виде. Не менее куцым, выглядит и проект MonoDroid.
Symbian^3. Nokia рекомендует использовать для разработки приложений Qt либо Java. А на просторах интернета мне попадались линки о возможности использования .Net Compact Framework для Symbian, но я не смог найти какой-либо актуальной информации на этот счет.
Windows Phone 7. Для разработки доступен только C#. Ну что за гады?!

В итоге получаем следующую интересную табличку для GUI приложения:

“+” – идеально подходит;
“-” – использование не возможно в принципе, либо крайне не рекомендуется;
“+/-” – подходит, но по тем или иным причинам лучше не использовать.

Теперь можно сказать что с GUI разобрались. Одно можно сказать точно – использовать Qt придется.

Теперь к слою с логикой. Тут вопросов однозначно меньше, а альтернатив больше, ведь для написания бизнес логики нужно не так уж и много: контейнеры да алгоритмы и, в идеале, возможность так или иначе распаралелить вычисления. Так что таблица с инструментарием для написания уровня бизнес логики выйдет схожей с таблицей посвященной GUI, разве что с небольшим но очень важным уточнением. Для платформ iOS и Android (в случае с Android придется дополнительно использовать NDK) бизнес логика может быть написана на C++.
При этом, использование STL на Symbian потребует использования uSTL который был портирован Penrillian. Насколько это оправданное решение сказать сложно.

Выводы получаются довольно неожиданные. Java не является лучшим решением ни для написания кроссплатформенной логики, ни для написания кроссплатформенного GUI. Оптимальным вариантом оказывается логика написанная на C++ с использованием абстракции над контейнерами и алгоритмами.
GUI придется писать как минимум с использованием Qt (Windows/Linux и Symbian), Cocoa (Mac OS X и iOS) и Android SDK. А вот поддержку для Windows Phone 7 я бы стал делать только в крайнем случае. Создание приложения для этой платформы потребует отдельной реализации как логики, так и GUI которая нигде больше не пригодится.