Поскольку операционная система Apple OS-X является производной от UNIX (BSD), а базовая архитектура (Intel) Mac одинакова, почему не так просто запустить приложения для Apple, работающие в Linux?
15
OS X на самом деле (в основном) проприетарная графическая оболочка поверх BSD. Чтобы создать приложение OS X GUI, нужно следовать API, выставленному Apple, и, следовательно, это не кроссплатформенный и не легко переносимый.
Вот почему большинство библиотек являются легко портированы ( на самом деле большинство из них разработаны на Linux) для Linux , но не их графических оболочек.
На заметку: существуют фреймворки, с помощью которых вы можете создавать кроссплатформенные приложения с графическим интерфейсом. Qt приходит на ум. Но тот факт, что эти платформы являются кроссплатформенными, также делает приложения, созданные с их помощью, менее удобными для пользователя на конкретной платформе, чем «родное» приложение с графическим интерфейсом. Эти фреймворки, как правило, заставляют все выглядеть универсально на разных платформах, что в случае с Apple плохо, потому что Apple создала очень специфический пользовательский интерфейс, который не просто «вписывается» в другие платформы.
Редактировать (чтобы включить комментарии в ответ - спасибо @Nick, @kbisset и @John):
Решением было бы перенести всю графическую оболочку OS X (библиотеки Cocoa / Core с закрытым исходным кодом - что делает OS X действительно уникальной ) в Linux. И технически Apple может сделать это довольно легко, но у них нет причин для этого, поскольку вся их бизнес-модель является уникальностью всей их платформы - аппаратного и программного обеспечения.
Можно предположить, что кто-то может попытаться клонировать библиотеки, но на это уйдут человеческие десятилетия, и, вероятно, он никогда не будет прав из-за всех недокументированных вызовов, которые необходимо будет повторить.
Под приложениями для Apple вы подразумеваете приложения с графическим интерфейсом? Когда вы перемещаетесь над командной строкой, появляются специальные API-интерфейсы Apple для всего (графика, звук и т. Д.), Которые не поддерживаются в Linux, поэтому вы не можете легко портировать приложения.
источник
Графический слой совсем не тот. 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 года)
источник
Поскольку большинство приложений зависят от гораздо большего, чем процессор и базовая архитектура компьютера, на котором они работают. Они также зависят от наборов инструментов пользовательского интерфейса и других специфичных для платформы библиотек.
источник