Кроссплатформенное нацеливаниеcross-platform targeting

С чего начать?

Сегодня, когда новые материалы по Flutter выходят едва ли не ежедневно, нет никакого дефицита в хороших курсах, помогающих подружиться с данной технологией.

Хороший пример базового курса по Flutter — курс на Udacity. Уроки разбиты на две главы, вдумчивое прохождение каждой из которых займёт 3-4 часа.

Если же курсы не ваш вариант, начните погружение в технологию через изучение исходников уже существующих проектов. Репозиторий awesome-flutter содержит немало таких проектов, а еще может похвастаться очень щедрой подборкой готовых библиотек, решений, сэмплов и прочих материалов для изучения и вдохновения.

Старые целевые платформыOlder targets

.NET поддерживает работу с уже не поддерживаемыми версиями .NET Framework, а также с редко используемыми платформами..NET supports targeting versions of .NET Framework that are long out of support as well as platforms that are no longer commonly used. Поддержка библиотекой максимального числа платформ в некотором смысле оправдана, но реализация решений для отсутствующих API может привести к значительному увеличению размера библиотеки.While there’s value in making your library work on as many targets as possible, having to work around missing APIs can add significant overhead. Мы считаем нецелесообразным обеспечивать поддержку некоторых платформ, учитывая их малую распространенность и ограничения.We believe certain frameworks are no longer worth targeting, considering their reach and limitations.

НЕ️ СЛЕДУЕТ добавлять целевую платформу переносимой библиотеки классов (PCL). DO NOT include a Portable Class Library (PCL) target. Например, .For example, .

НЕ СЛЕДУЕТ добавлять поддержку платформ .NET, которые больше не поддерживаются. DO NOT include targets for .NET platforms that are no longer supported. Например, , .For example, , .

Недостатки Flutter

Как бы Flutter ни был хорош, все же он не лишен недостатков. Уже говорилось, что это довольно молодая технология, и если ваше приложение потребует использования некоторых специфических нативных библиотек, то их Flutter-аналоги могут либо отсутствовать, либо быть слишком сырыми и нестабильными. Да, есть возможность написать нативный код (код на языке, на котором обычно пишут нативные разработчики) и вызывать его из Flutter. Но возникает другая проблема, если обращений к нативному коду будет слишком много, это все же скажется на производительности Flutter-приложения. В таком случае лучше сразу обратиться к нативной разработке.

Быть может, будущие пользователи вашего приложения слишком привыкли к стандартному UI/UX? Тогда им будет сложно пользоваться единым интерфейсом двух платформ. Яркий пример — кнопка «Назад» в навигации между экранами. Если в Android для этого предусмотрена аппаратная кнопка Back, то в iOS используется либо кнопка в левой части навигационной панели, либо движение пальцем от левой части экрана. Без этой кнопки пользователи iOS не смогут вернуться на предыдущий экран, а с кнопкой будет непривычно пользователям Android. Кросс-платформа — это всегда компромисс в дизайне.

Flutter-приложения в среднем получаются объемнее своих нативных аналогов приблизительно на 20%. Это связано с тем, что они содержат в себе собственные виджеты и средство визуализации и не обращаются к системным компонентам. Однако в работают и над этим, оптимизируя размеры итоговых сборок приложений.

Отличия между версиями мультиплатформенных игр

В зависимости от желаний и возможностей разработчиков, а также технических различиях между целевыми платформами, на которых выходит мультиплатформенная игра, версии мультиплатформенной игры для разных платформ могут в той или иной степени отличаться между собой.

Некоторые разработчики стремятся сделать так, чтобы игра для разных платформ выглядела максимально одинаково. Например, разработчики игры BioShock 2, которая вышла на ПК и игровых консолях Xbox 360 и PlayStation 3, стремились сделать игру максимально одинаковой на этих платформах. «Самой главной нашей целью, поставленной на начальной стадии разработки, являлось то, что игра должна была выглядеть практически идентично на всех платформах», — заявил по этому поводу главный дизайнер локаций игры Хогарт Де Ла Плант (англ. Hogarth De La Plante). Он заявил, что это делается для того, чтобы не дать пользователям игры на какой-либо одной платформе преимуществ перед пользователями этой игры на других платформах. Аналогичное стремление показали разработчики из Eidos Montreal при разработке Deus Ex: Human Revolution: продюсер игры Дэвид Анфосси (англ. David Anfossi) заявил, что впечатления от игры и геймплей будут идентичными на всех целевых платформах (ПК, Xbox 360, PlayStation 3).

Версии одной игры для разных платформ могут выходить в разное время, причём это время может исчисляться годами. Например, игра Ballistics (англ.) для ПК вышла в 2001 году, а для аркадных автоматов — в 2002-м.

Иногда версии одной мультиплатформенной игры имеют больше различий, чем общих признаков. Например, игра «Tom Clancy’s Ghost Recon Advanced Warfighter» была разработана разными компаниями для разных платформ на разных игровых движках, версии для которых были выпущены в разное время. Эта игра вышла для платформ Xbox 360, Xbox, PlayStation 2 и ПК (Microsoft Windows), причём эти версии выходили на протяжении всей весны 2006 года. Версия для Windows разрабатывалась компанией GRIN на игровом движке Diesel. Версия для Xbox разрабатывалась компанией Ubisoft Shanghai, а версия для PlayStation 2 — Ubisoft Paris. Эти две версии (для Xbox и PlayStation 2) использовали игровой движок Unreal Engine 2. Версия для Xbox 360 разрабатывалась на игровом движке YETI engine двумя компаниями — Ubisoft Paris делала однопользовательский режим игры, а Red Storm Entertainment — многопользовательский. Среди общих элементов этих версий были лишь концепция и общий сюжет. Геймплей, сценарий, миссии и уровни, особенности вооружения и оснащения протагонистов для каждой версии были индивидуальными. Это привело к тому, что некоторые обозреватели, как, например, GameTech, написали отдельные рецензии для версий этой игры под разные платформы.

Многие агрегаторы оценок компьютерных игр разделяют оценки для каждой платформы. Например, онлайновый агрегатор GameStats для каждой из семи платформ, на которых вышла игры James Cameron’s Avatar: The Game, скомпоновал отдельный профиль с отдельной оценкой.

Smite

Кроссплей: РС, Xbox One, PS4, Nintendo Switch

Smite – одна из немногих кроссплатформенных MOBA-игр, еще и с довольно необычным сеттингом. Ведь сражаются тут не просто герои, но настоящие боги, к тому же позаимствованные у разных исторических культур.

Всего в игре есть больше сотни богов, относящихся к греческому, египетскому, римскому, индийскому, китайскому, японскому, скандинавскому, индейскому и кельтскому пантеонам

Важное отличие игры от множества других «убийц Доты» – камера здесь не висит над ареной, а привязана к игровому персонажу. Это дает больший эффект присутствия и повышает челлендж, ведь о ситуации на других участках поля можно судить только по мини-карте

Поиграть в эту оригинальную игру можно как на консолях PS4 и Xbox One, так и на ПК с виндой.

Платформы

Платформа может относиться к типу процессора (ЦП) или другому оборудованию, на котором работает данная операционная система или приложение , типу операционной системы на компьютере или комбинации типа оборудования и типа операционной системы, работающей на нем. Пример распространенной платформы — Microsoft Windows, работающая на архитектуре x86 . Другие хорошо известные платформы настольных компьютеров включают Linux / Unix и macOS, обе из которых сами по себе являются кроссплатформенными. Однако существует множество устройств, таких как смартфоны , которые также фактически являются компьютерными платформами, но о них меньше думают. Прикладное программное обеспечение может быть написано в зависимости от функций конкретной платформы — оборудования, операционной системы или виртуальной машины, на которой оно работает. Платформа Java — это платформа виртуальных машин, которая работает во многих операционных системах и типах оборудования, и является общей платформой для написания программного обеспечения.

Аппаратные платформы

Аппаратная платформа может относиться к архитектуре набора команд . Например: архитектура x86 и ее варианты, такие как IA-32 и x86-64 . На этих машинах часто работает одна версия Microsoft Windows, хотя они могут работать и с другими операционными системами, включая Linux, OpenBSD , NetBSD , macOS и FreeBSD .

Эти 32-разрядные архитектуры ARM (и более новые 64-разрядные версии) является общим на смартфоны и планшетные компьютеры , которые работают Android , IOS , и других мобильных операционных систем .

Программные платформы

Программные платформы могут быть либо операционной системой, либо средой программирования , хотя чаще это комбинация того и другого. Заметным исключением из этого правила является Java , которая использует независимую от операционной системы виртуальную машину для своего скомпилированного кода, известного в мире Java как байт-код . Примеры программных платформ:

• BlackBerry
• Android для смартфонов и планшетных компьютеров (x86, ARM)
• iOS ( ARM )
• Microsoft Windows (x86, ARM

  Интерфейс командной строки , также известный под именами реализации .NET Framework (от Microsoft) и кроссплатформенным вариантом Mono (ранее Novell, а теперь Xamarin )

  )

• Ява
• Веб-браузеры — более или менее совместимы друг с другом, работают с веб-приложениями на JavaScript.
• Linux (x86, PowerPC, ARM и другие архитектуры)
• macOS (x86, PowerPC (на 10.5 и ниже))
• Mendix
• Solaris (SPARC, x86)
• SymbianOS
• SPARC
• PlayStation 4 (x86), PlayStation 3 (на базе PowerPC) и PlayStation Vita (ARM)
• Unix

Незначительный / исторический

• AmigaOS (m68k), AmigaOS 4 (PowerPC), AROS (x86, PowerPC, m68k), MorphOS (PowerPC)
• Atari TOS , MiNT
• BSD (многие платформы; см., Например, NetBSDnet)
• Системы типа DOS на x86: MS-DOS , IBM PC DOS , DR-DOS , FreeDOS
  
• OS / 2 , eComStation

Платформа Java

Как отмечалось ранее, платформа Java является исключением из общего правила, согласно которому операционная система является программной платформой. Язык Java обычно компилируется в виртуальную машину: виртуальный ЦП, на котором выполняется весь код, написанный для языка. Это позволяет запускать один и тот же исполняемый двоичный файл во всех системах, реализующих виртуальную машину Java (JVM). Программы Java могут выполняться изначально с использованием процессора Java . Это нечасто и в основном используется для встроенных систем.

Код Java, работающий в JVM, имеет доступ к службам, связанным с ОС, таким как дисковый ввод-вывод и доступ к сети, если предоставлены соответствующие привилегии. JVM делает системные вызовы от имени приложения Java. Эта настройка позволяет пользователям выбирать соответствующий уровень защиты в зависимости от ACL . Например, дисковый и сетевой доступ обычно разрешен для настольных приложений, но не для апплетов на основе браузера . JNI также можно использовать для обеспечения доступа к специфическим функциям операционной системы.

В настоящее время программы Java Standard Edition могут работать в Microsoft Windows, macOS, нескольких Unix-подобных операционных системах и еще нескольких не-UNIX-подобных операционных системах, таких как встроенные системы. Для мобильных приложений используются плагины браузера для устройств на базе Windows и Mac, а Android имеет встроенную поддержку Java. Также существуют подмножества Java, такие как Java Card или Java Platform, Micro Edition , предназначенные для устройств с ограниченными ресурсами.

Требования Opera 8.5x/Presto 1.0 (2005~2011)

Да-да, некоторые производители, например Motorola, поставляли телефоны с браузером Opera Mobile 8.54 вплоть до 2011 года.

Системные требования для Opera 8.5x на движке Presto 1.0 составляли:

• 32-битный процессор
• 8 MБ оперативной памяти, доступной для использования Оперой
• C++-подобный компилятор для платформы

Остальные возможности платформы, даже устройства ввода и вывода, сеть и файловая система, являлись, строго говоря, необязательными. Например, Presto успешно обходилось без устройств ввода-вывода на серверах Opera Mini.

В списке не случайно упомянут “C++-подобный” компилятор. Opera могла быть собрана практически любым компилятором, даже самым капризным.

Как же Опере удавались эти чудеса? Секрет в хорошем проектировании программы.

React Native

Инструмент от Facebook. Его цель — сделать кроссплатформенные приложения такими же производительными, как нативные.

Кто использует

React Native достаточно популярен, поскольку его уже применяют технологические гиганты. Среди них Instagram, Facebook, Walmart, Tesla, Pinterest, UberEats и другие.

IDE и написание кода

С момента запуска React Native прошло около 5 лет, поэтому его поддерживают почти все ведущие IDE. Изучать React Native и писать код на нём довольно просто благодаря использованию JavaScript (разумеется, если вы знаете JavaScript).

Архитектура и исполнение кода

«Learn once, write anywhere», что можно трактовать как «научись один раз, используй везде» — главный принцип React Native, который подразумевает применение одного и того же кода для разных платформ. Также в Native есть функция Hot Reloading, позволяющая добавлять новый код и вносить правки прямо во время выполнения — это очень полезно, когда вы настраиваете пользовательский интерфейс. Среда поставляется с большим набором готовых компонентов, однако они не всегда адаптируются под разные платформы, что требует дополнительных корректировок в коде. Благодаря обширной поддержке сообщества также есть богатый выбор сторонних библиотек.

Производительность

Так как React Native нацелен на результат, сопоставимый с нативной разработкой, в погоне за производительностью чаще всего отдают предпочтение именно этому фреймворку. Native также позволяет разработчикам использовать кастомные модули на языках для нативной разработки, но их придётся писать отдельно для каждой платформы.

***

Так что выбрать?

• Если вы знаете Dart и хотите получить высокую производительность, выбирайте Flutter.
• Используйте React Native, если вам важна поддержка зрелого сообщества, разработка на JavaScript и проверенное временем решение.
• Выбирайте Ionic, когда вам требуется ускорить цикл разработки и тестирования приложения за счёт полной кроссплатформенной адаптации.
• Xamarin подойдёт тем, кто хочет писать на C#, получить хорошую производительность и преимущества нативных инструментов.
• Для создания небольших и простых приложений с помощью веб-технологий применяйте PhoneGap.

Помните, что каждый инструмент имеет свои особенности, и делать выбор следует исходя из конкретной задачи. Всегда стоит обсуждать проект с опытной командой разработчиков, которая рассмотрит различные подходы и предложит наилучший вариант.

Собственный UI, общий код

Этим подходом пользуются почти все игровые движки, но они находятся за рамками данной статьи.

Принцип данного подхода — приложение использует собственный код и собственную отрисовку пользовательского интерфейса.

Основные плюсы

Высокая производительность интерфейсов

По сути, приложение, самостоятельно рисующее свой интерфейс, выполняет те же операции, что ОС в нативном интерфейсе. В теории оно может быть даже быстрее, т.к. нет переключения между процессом и ядром, но на практике другие факторы влияют на скорость отрисовки конкретного интерфейса, играют намного большую роль.

“Дизайнерские интерфейсы”

Нативные приложения пользуются готовыми компонентами интерфейса и имеют некоторые ограничения в том, что с ними можно сделать. В свою очередь, приложения, сами рисующие свой интерфейс, не имеют таких ограничений и могут свободно смешивать готовые элементы с индивидуальной отрисовкой.

Основные минусы

Данные минусы актуальны только для приложений, имитирующих стандартный интерфейс ОС. Как уже говорилось, для дизайнерских интерфейсов и игр данный подход является оптимальным.

Размер приложения

Приложения с таким подходом вынуждены нести с собой код для отрисовки всех элементов интерфейса, включая условно стандартные. Это сказывается как на размере приложения при установке, так и на оперативной памяти при работе.

Если первую проблему можно минимизировать эффективным Tree Shaking (как это делают последние версии Flutter), то по оперативной памяти эти приложения стабильно проигрывают нативным. Впрочем, эта проблема характерна и для других кросс-платформенных фреймворков.

Ненативный интерфейс

По умолчанию, приложение выглядит одинаково на всех платформах, что может создавать дискомфорт для пользователей. Для решения этих проблем используются темы, но создать ощущение полностью нативного приложения они не могут.

Но есть и более крупный минус — с таким подходом сложнее всего использовать сторонние элементы интерфейса, созданные для нативных приложений (включая упомянутые ранее Native Ads).

Основные фреймворки

Flutter

Flutter продвигается компанией Google как основной фреймворк кросс-платформенной разработки и основа интерфейса их будущей ОС Fuscia. Пока фреймворк очень молод (в стадии Release Preview) и не очень распространён, но быстро набирает популярность. Использует язык Dart (с компиляцией в нативный код).

Имеет все плюсы и минусы молодости — продуманную архитектуру с учётом ошибок предшественников, но достаточно ограниченную экосистему.

QT Mobile

Пользуется популярностью у разработчиков десктопного QT. При разработке может использоваться JavaScript. Без поддержки крупных компаний не пользуется особой популярностью.

Kivy

Ещё один не очень популярный фреймворк, который интересен, в первую очередь тем, что это единственный фреймворк в списке, который использует язык Python. Для разработчиков, знакомых только с этим языком (а таких много в некоторых областях информационных технологий), это может иметь решающее значение.

По работе памяти в Xamarin и похожих фреймворковСравнение производительности нативных приложений, Flutter и React Native

Почему нужно поверить во Flutter?

Отличный тулинг для быстрой разработки

Вам не придётся вылезать из привычной Android Studio. При помощи плагина она отлично приспосабливается под разработку Flutter-приложений.

Hot Reload — киллер-фича, позволяющая моментально переносить все изменения из кода на запущенный эмулятор или подключенное устройство.

Простота и выразительность вёрстки

Если вы когда-либо разрабатывали приложения под Android, уверен, вёрстка — это не то, от чего вы получали удовольствие.

С Flutter всё иначе. Во-первых, никаких XML-файлов с вёрсткой — виджеты создаются и настраиваются прямо в коде (чем-то напоминает Anko Layouts). Вместо View используются Widget.

Так выглядит код Flutter-проекта. Поначалу огромное количество скобок пугает, но такие “деревья” довольно наглядны. Flutter пропагандирует композицию: из готовых виджетов можно составить новый, как из конструктора. Почти у любого компонента есть свойство child или children, которое принимает другой элемент или массив элементов соответственно. Все просто и понятно. Сделать красивый пользовательский интерфейс можно достаточно быстро.

Во-вторых, прямо со старта создатели платформы предлагают разработчикам каталог готовых виджетов. Он содержит два набора элементов, Material Components и Cupertino, которые выглядят нативно для каждой из платформ. Кроме того, доступны кроссплатформенные виджеты. Их внешний вид и поведение идентичны на iOS и на Android-устройствах.

Реактивный фреймворк

Создать красивый и приятный UI в сжатые сроки можно не только благодаря большому количеству готовых виджетов, но и языку, на котором вам придётся писать. Dart отдалённо напоминает Java, JavaScript, C#. Он выразителен и отлично заточен под нужды фреймворка, хотя, после Kotlin некоторые художественные излишества синтаксиса могут ввести в легкий ступор.

Flutter компилируется в нативный код под каждую из платформ. “Под капотом” он использует Skia в качестве графического движка.

Ключевой особенностью архитектуры системы является то, что все виджеты, а также компоненты, ответственные за отрисовку виджетов на канве, являются частью приложения, а не платформы. Именно отсутствие необходимости в переключении контекста и использования «мостов» даёт прирост производительности, который, способствует достижению заветного показателя в 60 FPS при отрисовке UI.

Вся мощь платформы по-прежнему в ваших руках

Зачем отказываться от тонны полезного кода, который целое десятилетие создается в сообществе мобильных разработчиков? Все библиотеки, доступные в нативных приложениях SDK и платформенные API могут быть использованы для Flutter-приложений.

Чем Flutter лучше

Однако кросс-платформенных решений в наше время довольно много

Почему же стоит обратить внимание именно на Flutter?. В статье на сайте «Типичного программиста» можно увидеть обзор наиболее популярных на сегодняшний день инструментов для написания кросс-платформенных приложений

Обратите внимание, что если вы хотите, чтобы скорость работы приложения была максимально близка к нативной, то у вас всего два варианта — React Native и Flutter. Эти технологии сейчас являются наиболее продвинутыми во многих отношениях. Почему же стоит выбрать Flutter, несмотря на то, что есть React Native, который несколько старше, уже зарекомендовал себя и имеет довольно крупное сообщество разработчиков?

В статье на сайте «Типичного программиста» можно увидеть обзор наиболее популярных на сегодняшний день инструментов для написания кросс-платформенных приложений

Обратите внимание, что если вы хотите, чтобы скорость работы приложения была максимально близка к нативной, то у вас всего два варианта — React Native и Flutter. Эти технологии сейчас являются наиболее продвинутыми во многих отношениях

Почему же стоит выбрать Flutter, несмотря на то, что есть React Native, который несколько старше, уже зарекомендовал себя и имеет довольно крупное сообщество разработчиков?

Flutter ближе всего по производительности к нативным приложениям. Как правило, другие решения, основывающиеся на веб-технологиях, всегда имеют JavaScript-прослойку, которая преобразовывает JavaScript-код в нативные вызовы, и React Native не исключение. Flutter же не использует JavaScript и вообще не нуждается в промежуточных преобразованиях кода. Он основывается на языке Dart, который компилируется сразу в нативный код, а для отрисовки визуальной части приложения использует графический движок Skia, написанный на C++. Поэтому его производительность значительно выше.

Элементы интерфейса, которые рисует Flutter, не зависят от версии операционной системы (ОС), на которой запущено приложение. В отличие от того же React Native, который всегда обращается именно к нативным компонентам, используемым ОС. Поэтому на разных версиях ОС внешний вид приложения может немного отличаться. Для Flutter такой проблемы не стоит — приложение будет корректно отображаться и функционировать как на старых устройствах, так и на новых. Кстати, о новых устройствах. Не так давно разработчики столкнулись с тем, что не все приложения адекватно поддерживали темную тему в iOS-13, когда она только появилась. Вследствие того, что Flutter не использует компоненты системного интерфейса, его эта проблема не затронула.

Flutter гораздо меньше зависит от сторонних библиотек, необходимых для написания интерфейса приложения. Скажем, React Native обращается через API к нативным компонентам ОС и полагается на специальные плагины. Такие компоненты могут не вовремя обновиться и «сломать» внешний вид приложения. Тогда как во Flutter уже есть встроенные библиотеки для обеих платформ с довольно богатым выбором UI-компонентов, предоставляющих разработчику полную свободу действий. Риск внезапно получить «сломанный» интерфейс здесь гораздо ниже.

Те, кто интересуется более подробным анализом, с точки зрения мобильных разработчиков, могут ознакомиться со статьей из блога компании The Droids On Roids. Статья интересна тем, что авторы имеют опыт как в нативной разработке, так и в кросс-платформенной, поэтому оценивают фреймворки с разных сторон.

Нужна ли мне кросс-платформенная разработка

Почему вообще стоит выбирать кросс-платформенные решения? Начнём с того, что они позволяют сэкономить бюджет и сроки проекта за счет сокращения рабочих часов, поскольку работа над двумя платформами ведётся одновременно и с использованием одной технологии. Единожды написанный и отлаженный код потенциально содержит гораздо меньше ошибок и расхождений в своей работе, чем если бы приложение разрабатывалось отдельно под каждую платформу разными командами. Поддержка продукта (добавление функциональности в приложение, исправление ошибок на обе платформы сразу, выпуск обновленной версии сразу в два магазина) будет обходиться дешевле по тем же самым причинам.

Также рекомендуем выбирать кросс-платформенное приложение в следующих ситуациях:

• Когда нужно, чтобы приложение выглядело одинаково на разных платформах. Навигация между экранами, поле поиска, системный календарь на iOS и Android выглядят по-разному, но кросс-платформенные решения позволяют вам взять лучшее от обеих ОС и реализовать единый вариант дизайна.
• Когда разрабатываемое приложение для своей работы не требует задействования всех вычислительных ресурсов устройства. В целом, кросс-платформенные технологии позволяют реализовывать практически любые виды приложений, однако есть исключения. Например, игры или приложения с дополненной реальностью, которые сильно загружают процессор и оперативную память (иначе говоря — «требовательны к производительности»).
• Когда приложение ориентировано на «card material design», который сегодня довольно популярен. То, что на Android является тривиальной задачей, для iOS-разработчиков становится настоящей головной болью. Они тратят значительно больше времени на разработку интерфейса. С кросс-платформенными технологиями (в частности, с Flutter) разработчики «из коробки» (то есть им не нужно дополнительно устанавливать библиотеки и что-то настраивать) имеют доступ ко всем нативным UI-компонентам обеих платформ, благодаря чему работа ускоряется в разы.

Как добиваются кроссплатформенности

Swing выглядит одинаково на всех ОС.

Mozilla Firefox, использующий XUL, оформляет окна в стиле ОС (в данном случае — Linux).

Кроссплатформенные языки программирования

Кроссплатформенными можно назвать большинство современных высокоуровневых языков программирования. Например, C, С++, Free Pascal, FreeBASIC, PureBasic — кроссплатформенные языки на уровне компиляции, то есть для этих языков есть компиляторы под различные платформы. Это позволяет — при надлежащем качестве кода — не переписывать основной движок программы, меняются только особые системозависимые части.

Не менее важны для кроссплатформенности стандартизованные библиотеки среды выполнения. В частности, стандартом стала библиотека языка Си (см. POSIX). Из крупных кроссплатформенных библиотек — Qt, GTK+, FLTK, STL, Boost, OpenGL, SDL, OpenAL, OpenCL.

Кроссплатформенные среды исполнения

Ещё на заре ПК компания IBM сделала свой персональный компьютер совместимым с CP/M. Это позволило запускать на нём уже имеющиеся программы.

PHP, Perl, Python, Tcl и Ruby — кроссплатформенные интерпретируемые языки, их интерпретаторы существуют для многих платформ.

Среды исполнения ActionScript Virtual Machine, Java Virtual Machine и .NET также кроссплатформенны, однако на их вход подаётся не исходный текст, а промежуточный код. Поэтому программы, написанные на ActionScript, Java и C#, можно запускать под разными ОС без предварительной перекомпиляции.

Кроссплатформенный пользовательский интерфейс

На разных ОС — независимо от того, как технически достигнута работа в них — стандартные элементы интерфейса имеют разные размеры. Поэтому простое жёсткое позиционирование элементов интерфейса невозможно — под другой ОС они могут налезать друг на друга. Существует несколько подходов.

1. Единый стиль, общий для всех ОС. Программы выглядят одинаково под всеми ОС. Так работают интерфейсные библиотеки Java наподобие Swing.
   • Плюс: можно жёстко расставлять элементы управления на манер Delphi; оригинальный стиль.
   • Минус: системе приходится иметь свои экранные шрифты; стиль отличается от стиля ОС.
2. Самоадаптирующийся интерфейс, подстраивающий сетку под реальные размеры элементов управления. Типичные примеры — Qt, wxWidgets, XUL.
   • Плюс: стандартный стиль ОС, очень быстрый и «скинующийся» под Windows XP, Vista и ; некоторая автоматизация локализации.
   • Минус: чтобы собрать самоадаптирующуюся сетку, требуется квалифицированный программист; затруднена плотная компоновка.
3. Гибридный подход реализован в GTK+.
   • Плюс: шрифты можно брать из системы, а не «тащить» свои; некоторая автоматизация локализации.
   • Минус: берёт все недостатки от первых двух подходов. Стиль отличается от стиля ОС; затруднена плотная компоновка.

В любом случае, под другими ОС требуется хотя бы минимальное тестирование, так как возможны ошибки компоновки.

Условная компиляция

Даже несмотря на широкую, в общем, стандартизацию аппаратного и программного обеспечения, программисту часто приходится налаживать ветви под разные ОС, включая ту или другую с помощью условной компиляции.

Браузер Mozilla Firefox имеет разные комплекты иконок под разные ОС.