Поскольку операционная система Apple OS-X является производной от UNIX (BSD), а базовая архитектура (Intel) Mac одинакова, почему не так просто запустить приложения для Apple, работающие в Linux?
4 ответа
23
OS X на самом деле (в основном) проприетарная графическая оболочка поверх BSD. Чтобы создать приложение OS X GUI, нужно следовать API, выставленному Apple, и, следовательно, оно не является кроссплатформенным и не легко переносимым.
Именно поэтому большинство библиотек легко портированы ( на самом деле большинство из них разработаны на Linux) для Linux , но не их графических оболочек.
На заметку: существуют платформы, с помощью которых вы можете создавать кроссплатформенные приложения с графическим интерфейсом. Qt приходит на ум. Но тот факт, что эти платформы являются кроссплатформенными, также делает приложения, созданные с их помощью, менее удобными для пользователя на конкретной платформе, чем "родное" приложение с графическим интерфейсом. Эти фреймворки, как правило, заставляют все выглядеть универсально на разных платформах, что в случае с Apple плохо, потому что Apple создала очень специфический пользовательский интерфейс, который нелегко "вписывается" в другие платформы.
Изменить (чтобы включить комментарии в ответ - спасибо @Nick, @kbisset и @John):
Решением было бы перенести всю графическую оболочку OS X (библиотеки Cocoa/Core с закрытым исходным кодом - что делает OS X по-настоящему уникальной) на Linux. И технически Apple может сделать это довольно легко, но у них нет причин для этого, поскольку вся их бизнес-модель является уникальностью всей их платформы - аппаратного и программного обеспечения.
Можно предположить, что кто-то может попытаться клонировать библиотеки, но на это уйдут человеческие десятилетия, и, вероятно, он никогда не будет прав из-за всех недокументированных вызовов, которые нужно будет повторить.
2
Под приложениями для Apple вы подразумеваете приложения с графическим интерфейсом? После перемещения над командной строкой появляются специальные API-интерфейсы Apple для всего (графика, звук и т.д.), Которые не поддерживаются в Linux, поэтому вы не можете легко портировать приложения.
1
Графический слой совсем не тот. OS X использует проприетарную графическую структуру, Linux использует X (X11/X.org)
Почти все нативные приложения OS X используют такие инфраструктуры, как Cocoa, CoreAnimation и т.д., Которые доступны только в OS X.
Например, скажем, у вас есть приложение, которое хранит пароль для пользователя - в OS X это будет использовать его систему Keychain и соответствующие API. Если бы вы перенесли это на Linux, прямого эквивалента не было бы, поэтому вам пришлось бы повторно реализовать всю эту функцию. Это крошечная функция, которая потребует большой переписывания.
Если вы пишете свое приложение, используя кросс-платформенную библиотеку GUI, такую как GTK, Qt или wxWidgets, и перенос будет намного проще (или "возможен"), но операционные системы по-прежнему сильно отличаются с точки зрения пользовательского интерфейса (например, ОС X использует отдельную строку меню, в то время как у Linux, как правило, есть строка меню для каждого окна)
Одним из лучших кроссплатформенных портов, которые я когда-либо видел, является Transmission, который реализует свою основную функциональность в виде библиотеки (которая содержит как можно меньше кода для конкретной платформы), а затем создает собственные графические интерфейсы для каждой платформы отдельно. Это означает, что каждый порт имеет много общего кода, но у всех есть хорошие, собственные интерфейсы (а не один интерфейс, который прекрасно подходит для Linux, но неуместен в OS X, или наоборот)
Существует проект под названием Cocotron, который "нацелен на реализацию кроссплатформенного API Objective-C, подобного тому, который описан в документации Apple Inc. по какао", который потенциально может значительно упростить портирование, но в последнее время активность, по-видимому, очень мала (последнее сообщение в блоге было в декабре 2008 года)
1
Потому что большинство приложений зависят от гораздо большего, чем процессор и базовая архитектура компьютера, на котором они работают. Они также зависят от наборов инструментов пользовательского интерфейса и других библиотек, специфичных для платформы.