Я думал о создании приложения для Mac App Store, но мне было интересно, будут ли они принимать только программы, созданные на Objective-C с использованием XCode.
Я думал о том, чтобы сделать программу мультиплатформенной с помощью Qt, чтобы я мог выпускать версии для Windows и Mac.
Учитывая, что я не представляю Apple и пока не видел примеров, когда этот спор разыгрывался в пользу той или иной стороны, сложно дать вам однозначный ответ на этот вопрос. Вместо этого я опубликую то, что выглядит как соответствующие разделы Руководства по обзору Mac App Store, и позволю вам решить для себя.
Сначала идет Раздел 2 «Функциональность». Это довольно широкая тематическая область, и мне кажется, что есть много потенциальных нарушений с использованием сторонней библиотеки графического интерфейса. Конечно, я также думаю, что все это можно обойти, если вы достаточно заинтересованы.
2.5 Приложения, использующие закрытые API, будут отклонены.
. . .
2.14 Приложения должны быть упакованы и отправлены с использованием технологий упаковки Apple, включенных в Xcode — сторонние установщики не допускаются.
2.15 Приложения должны быть автономными, отдельными установочными пакетами приложений и не могут устанавливать код или ресурсы в общих папках.
2.16 Приложения, загружающие или устанавливающие дополнительный код или ресурсы для добавления функциональности или изменения своей основной цели, будут отклонены.
. . .
2.24 Приложения, в которых используются устаревшие или необязательные технологии (например, Java, Rosetta), будут отклонены.
. . .
2.29 Приложения, которые не используют соответствующие API Mac OS X для изменения пользовательских данных, хранящихся в других приложениях (например, закладок, адресной книги или записей календаря), будут отклонены.
Раздел 6 о «Пользовательском интерфейсе» также стоит рассмотреть для приложения, использующего Qt. Я отказываюсь использовать библиотеку в Windows, потому что она не использует стандартные элементы графического интерфейса платформы. Я могу только предположить, что то же самое происходит и на Mac, и еще неизвестно, как Apple отреагирует на это. (Я подозреваю, что альтернативные кроссплатформенные библиотеки графического интерфейса, которые ведут себя правильно и используют собственные виджеты, здесь бесплатны и понятны.)
6.1 Приложения должны соответствовать всем положениям и условиям, изложенным в Руководстве по интерфейсу пользователя Apple Macintosh.
. . .
6.3 Приложения, которые не используют предоставленные системой элементы, такие как кнопки и значки, правильно и как описано в Руководстве по пользовательскому интерфейсу Apple Macintosh, будут отклонены.
. . .
6.5 Приложения, изменяющие собственные элементы пользовательского интерфейса или поведение Mac OS X, будут отклонены.
Чтобы уточнить, как требования к графическому интерфейсу, опубликованные Коди Греем, усложнят принятие нетривиального приложения Qt, рассмотрим некоторые особенности Mac, которые необходимо будет реализовать или, по крайней мере, проверить на правильность для случая простой текстовый редактор:
По мере продвижения вниз по этому списку вероятность того, что функцию можно будет легко реализовать с помощью кроссплатформенного инструментария, уменьшается. По моему опыту, все эти функции были исключены по крайней мере из одного приложения Qt Mac. Некоторые из этих функций, вероятно, можно было бы легко добавить в Qt только с помощью непубличных API. Тем не менее, большинство этих функций бесплатны или почти тривиальны для реализации в проекте Cocoa, поэтому они почти вездесущи в нативных приложениях, и Apple будет права, если отклонит ваше приложение за то, что они их испортили.
Если ваше приложение не является тривиальным и не является полноэкранной игрой OpenGL, то вам, вероятно, лучше написать собственный графический интерфейс с кросс-платформенной серверной частью. Альтернативой является код, который полон #ifdef, но все равно никогда не выполняет свою работу правильно.
