Bloomberg: Apple запланировала объединить приложения для iOS и Mac в 2018 году Статьи редакции
По словам источников, разработчики смогут создавать приложения, которые будут подстраиваться под iPhone, iPad и Mac.
Apple планирует объединить магазины приложений для iOS и Mac в 2018 году. Об этом пишет Bloomberg со ссылкой на собственные источники.
По данным издания, с 2018 года разработчики ПО смогут создавать приложения, которые одинаково хорошо будут взаимодействовать с сенсорными экранами iPhone и iPad и мышью и тачпадом Mac.
Сейчас создатели приложений вынуждены разрабатывать два разных приложения для продукции Apple: одно для iOS, второе — для macOS. Клиенты компании регулярно жалуются на устаревающие приложения для Mac, отмечает Bloomberg. Например, Twitter для iPhone и iPad обновляется регулярно, в отличие от версии для Mac.
Проект по изменению систем iOS и macOS получил название Marzipan. Apple может представить его летом на ежегодной конференции разработчиков, считают источники. Пресс-секретарь Apple отказался от комментариев.
Подобная система работает у Microsoft, которая создала Universal Windows Platform — платформу, которая позволяет создавать приложения для Windows, Windows Phone, Xbox, HoloLens и Surface Hub.
Интересно как это будет реализовано технически. Например, концепция и API для UI у двух систем совершенно разные. Будут ли они унифицированы?
Скорее всего нет, не полностью. Будет что-то общее, а что-то отдельное. У Микрософта именно такой подход.
.... который не очень работает. Когда это Apple слизывала API у MS?
Он работает и еще как работает. Более того, UWP - это второе уже поколение технологии.
Когда это Apple слизывала API у MS?Metal ни что иное как вольная интерпретация DirectX12
Работает в смысле исполняется на процессоре? Это да. А вот в остальных смыслах - нет. Это не удобно.
Metal ни что иное как вольная интерпретация DirectX12Единственное что в них общего это ООП.
Нет. Последний (2-й) Метал даже скопировал те же стадии конвейера, что был в DirectX12 и концепция построения та же самая.
Реализацию DirectX12 ООП назвать можно только условно, там компонентная модель.
Те же самые стадии были и в OpenGL и скопированы в первую очередь от туда. Концепция работы с железом, внезапно, не может сильно отличаться, если нужно минимизировать всю абстракцию. Она определяется не дизайном DirectX или чего либо, а принципами работы железа.
Но опять-таки это схожесть концепций, а не API.
Реализацию DirectX12 ООП назвать можно только условно, там компонентная модель.Компонентная модель это COM? Как он противоречит ООП? COM построен как раз вокруг ООП.
Это ошибочное суждение. Я сравнивал все графические API в динамике развития. OpenGL давно отстал и догоняет DirectX и стадии там далеко не одинаковые.
Концепция работы с железом, внезапно, не может сильно отличаться, если нужно минимизировать всю абстракцию. Она определяется не дизайном DirectX или чего либо, а принципами работы железа.Это тоже ошибочное суждение.
Иначе бы не было "Совместимых с DirectX9" видеокарт, например.
Что именно ошибочное? Да, OpenGL отставал из-за того, что сам API давно устарел, с этим я вроде не спорю.
Иначе бы не было "Совместимых с DirectX9" видеокарт, например.Этот пример не опровергает, а подтверждает то, что я написал. Архитектура железа меняется, а с ним и концепция работы с ним. Есть карты, которые в поддерживают старые подходы архитектурно и на них может работать DirectX9.
"Этот пример не опровергает, а подтверждает то, что я написал. Архитектура железа меняется, а с ним и концепция работы с ним. "
Нет, посмотрите что появилось вперед API или железо.
И почему железо GPU стало именно таким (почитайте про совместную работу Микрософта с вендорами и т.п.)
Это не противоречит. API может появляться до железа, потому что от разработки прототипа до массового выпуска готовой железки проходит больше времени чем на реализацию API.
почитайте про совместную работу Микрософта с вендорамиВы думаете вендоры железа подстраивались под прихоти программистов API? Даже банальная логика говорит об обратном.