Mac Radar Лайфхакер ЖКХакер Ловим Robotor

Мак для независимого разработчика

Комментарии: 7

За последние пару месяцев ко мне уже неоднократно обращались разработчики программ под Windows с просьбой дать совет относительно того, стоит ли ввязываться в разработку под Mac. Как оказалось, у многих из них уже сформировался набор стереотипов уровня «разработчики платят Apple за то, что она разрешает писать программы под Mac», «Objective-C — старый язык, на котором ничего невозможно написать», «для Mac нет инструментов разработки» и т.д. и т.п. Так как повторяться мне уже порядком надоело, попробую оформить свои ответы в формате небольшой статьи, к которой в дальнейшем и буду отсылать.

Итак…

Рынок shareware приложений под Mac забит не так сильно, как под Windows. Свободных областей навалом: можно писать теггеры/конвертеры мультимедиа файлов, игры, productivity утилиты (впрочем, не стоит делать очередной GTD). Игр под Mac, кстати, относительно немного и шанс быть замеченным гораздо выше, чем в случае написания проекта под Windows. Например, разработчик игры Lugaru пишет, что половину денег с продаж дает именно Mac-версия.

Зарабатывать 3-4 тысячи вечнозеленых рублей в месяц с одного проекта вполне реально. Это не потолок. Авторы Pixelmator за первый день продаж заработали 60 тысяч долларов, Delicious Library за месяц принес своим разработчикам четверть миллиона. Оба продукта создавались небольшими командами, а вовсе не штатом по 30+ человек.

Макинтошники очень трепетно относятся к качеству интерфейса. Если вам хочется разрабатывать удобные приложения, использующие передовые решения, то Mac — идеальная платформа. Не Windows с традиционно низкой культурой разработки интерфейсов и уж точно не Linux с полным отсутствием таковой. Посмотрите на Disco, Things, Times, Fontcase и сравните их с тем мусором, которым забиты до отказов помойки вроде Tucows. Почитайте блоги вроде Beautiful Pixels или многостраничные обсуждения на тему нового вида  iTunes. Пользователи Mac в состоянии по виду отличить XUL от QT и каждую из них от Cocoa, они замечают разницу между разными типами антиалиасинга и вряд ли будут терпеть надранные из разных приложений иконки, натыканные на тулбаре приложения как попало.

Касается это не только интерфейса. Продавать халтуру под Mac не так-то просто, так что не следует надеяться на головокружительный успех еще одного «cd-ejector’а».

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

Основные средства разработки доступны бесплатно. Ладно, за доступ к iPhone/iPad SDK и некоторым другим радостям жизни все же придется заплатить… Зато с каждым макинтошем вы уже получаете Xcode (аналог Visual Studio). Хочется большего? Качайте и ставьте мак-порты соответствующих утилит или сторонние инструменты вроде SVN лиента Versions.

Потратив немного времени на поиски можно найти кучу готовых компонентов, позволяющих упростить написание приложения. Хотите удобное автообновление? Ставьте Sparkle. Красивые полупрозрачные окошки? BWToolkit. Примеров полно. Что радует, большинство подобных компонентов распространяется на условиях более чем либеральных лицензий BSD/MIT, а не «вирусной» GPL. Разумеется, FFmpeg, LAME и куча других открытых кроссплатформенных проектов также в наличии.

Отказываться от старых привычек все же придется. Например, интерфейсы надо будет собирать в Interface Builder, а вместо изобретения велосипеда на C++ использовать связку Objective-C/Cocoa (первое время работать будет непривычно). Книги по Objective-C сейчас неложно заказать, да и в Сети немало обучающих материалов, форумов и примеров кода. Если вдруг решитесь писать игры под Mac или же портировать существующие с Windows, сразу закладывайтесь на отсутствие здесь DirectX, работать придется с OpenGL.

Советую отдельно потратить время на изучение возможностей современных OS X. Использование Core Animation, «родной» поддержки 64 бит или Grand Central Dispatch могут здорово облегчить жизнь разработчика.

Заинтересовал? Отлично. Попробуйте для начала выпросить на пару дней Mac у знакомых или взять в аренду. Покупка б/у «миника» — практически беспроигрышный вариант. Даже если вы передумаете, его всегда можно задействовать в качестве тихой и удобной Windows машины.

Удачи!

  • alex

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

  • Денис

    В Qt давно есть много разных элементов, изменяющихся «под платформу». Например, QDialogButtons перестраивают порядок кнопок «ОК», «Отмена» и т.д. в соотвествтии с принятым под Win / MacOS / Linux. Единственная, но легко решаемая сложность под Qt — разное поведение приложения при нажатии на крестик на заголовке окна: под MacOS надо сворачиваться в Dock, а закрываться только, если приложение уже «свёрнуто». Но это пять строк кода…

    В остальном Qt даёт хоть и менее «нативные» приложения под Mac, но экономит 60-70% времени при разработке одновременно под три платформы…

    Правда, формально есть один нюанс: LGPL версия Qt не позволяет создавать приложения с закрытым кодом, и «для юридической чистоты» нужно покупать версию коммерческую. Впрочем, Nokia, ныне владеющая Qt, смотрит сквозь пальцы на выход первой версии приложения несколько раньше покупки лицензии, похоже, прекрасно понимая, что независимый разработчик должен вначале как-то заработать те 2-3K вечнозелёных президентов, что придётся отдать за полную коммерческую лицензию.

  • Гость

    С кросс-платформенными приложениями есть куча нюансов, которые за пять минут не опишешь.
    Приложение, написанное на QT пусть и будет смотреться лучше использующего XUL или подобную мерзость, только вот использование одного и того же интерфейса для Windows и Mac — моветон. Хотя бы по той простой причине, что Windows UXG и Mac HIG заметно различаются. Не зря для мак-портов многие выбирают Cocoa. Да, в качестве quick and dirty решения это вполне может подойти, но лично я рекомендую по возможности держаться от подобных библиотек подальше.

  • alex

    еще можно смешивать С++ и Objective-C в одном исходном файле, это бывает удобным. Особенно если пишешь кроссплатформенное приложение, бизнес-логика на плюсах, а интерфейс на Objective-C.

    по XCode можно поподробнее рассказать, о том что это довольно удобная и современная среда ничуть не хуже Visual Studio…

    На счет Qt не согласен. Это наверное единственная библиотека где GUI выглядит достаточно нативно под всеми платформами. Для многих разработчиков это вполне хороший вариант.

  • http://macosxhints.ru/ Rodion Baskakov

    Вы невнимательно читаете написанное.

    Итак, вот фраза из текста «за доступ к iPhone/iPad SDK и некоторым другим радостям жизни все же придется заплатить», которая не соответствует действительности, поскольку зарегистрировавшись тут: http://developer.apple.com/programs/register/ можно получить доступ к iPhone/iPad SDK совершенно бесплатно.

    Фразы «Отказываться от старых привычек все же придется. Например, интерфейсы надо будет собирать в Interface Builder» однозначно дают понять, что если вашей старой привычкой является динамическая сборка интерфейсов и расстановка контролов из кода (как-то раз даже писали фронт-енд для админки сайта, где все контролы выставлялись на форме в соответствии с инструкциями, возвращаемыми в виде XML с сайта), то вам придётся эту привычку изменить, что не соответствует действительности.

    Я совершенно согласен, что Objective-C для этих задач удобнее и лучше, я лишь сказал, что если человек всю жизнь писал на C++, то переучиваться ему практически не потребуется.

  • Гость

    >Почему за доступ к ним нужно платить?
    http://developer.apple.com/programs/which-program

    >в XCode есть поддержка работы с SVN
    Можно и из консоли работать, никто ж не заставляет. Некоторые товарищи пишут HTML разметку в Xcode и не жалуются. Что ж теперь, авторам Coda удавиться?

    >Если кому-то привычнее собирать интерфейсы из кода — никто не запрещает :)
    Никто не запрещает и штаны через голову надевать. Тем не менее большинство надевает их традиционным способом ;)

    >На C++ тоже можно писать (и на куче других языков) — есть соответствующие фрэймворки и библиотеки.
    Можно. Хоть на Ruby. Но лучше Objective-C :)

  • http://macosxhints.ru/ Rodion Baskakov

    > за доступ к iPhone/iPad SDK и некоторым другим радостям жизни все же придется заплатить

    Почему за доступ к ним нужно платить?

    > инструменты вроде SVN лиента Versions

    в XCode есть поддержка работы с SVN

    > интерфейсы надо будет собирать в Interface Builder

    Если кому-то привычнее собирать интерфейсы из кода — никто не запрещает :)

    > а вместо изобретения велосипеда на C++ использовать связку Objective-C/Cocoa

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