macOS *

Скорее всего вы уже в курсе, что Apple объединила три ранее отдельные программы: iOS, Mac и Safari Developer Program в одну, обновленную и расширенную Apple Developer Program.

Я предлагаю всем заинтересованным принять участие в переводе нового Соглашения на translatedby.com: translatedby.com/you/apple-developer-program-license-agreement-with-schedule-2/into-ru/trans

Переводить все с нуля необязательно, можно использовать предыдущий перевод на русский язык iOS Developer Program License Agreement + Schedule 2: drive.google.com/open?id=0B092pX2T-KtiaUNoQWdUSkgxYjg. Лично я действую так: захожу на сайт text-compare.com для нахождения отличий старой и новой версий каждого абзаца соглашений. Далее использую старую версию перевода и вношу в нее необходимые изменения.

Примечание: текст оригинала снабжен markdown-разметкой, которую также необходимо сохранить в переводе.

После 100% готовности перевода он будет опубликован на www.gitbook.com

Сегодня я хочу вам рассказать о том, как однажды познакомился с языком программирования Swift и решил написать на нем приложение для социальной сети ВКонтакте под OSX (которое, к сожалению, до сих пор не закончено). С какими подводными камнями мне пришлось столкнуться при обуздании, на тот момент, нового языка и скрещивании его с VK.API. Поделиться с общественностью результатом того, во что именно все это вылилось и попытаться обосновать, зачем нужно было придумывать очередной велосипед в виде библиотеки для работы с VK.API.
Если кому-то это интересно, то добро пожаловать под кат.

Для участия в семинарах и хакатонах, посвященных технологии Intel RealSense, некоторым разработчикам необходимо установить пакет Intel RealSense SDK на ноутбуки с операционной системой Mac OS. Мы заметили, что иногда это занимает больше времени, чем хотелось бы, поэтому решили опубликовать данное пошаговое руководство, показывающее, как запустить образцы приложений SDK с камерой Intel RealSense на компьютере Mac с помощью Boot Camp.

TL;DR: кроссплатформенный клон WPF. От других попыток сделать нечто с XAML-ом выгодно отличается наличием полностью своей системы отрисовки со сменными бакэндами (сейчас поддерживается Direct2D и Cairo). В наличии инспектор, дизайнер (см. видео). Биндинги сделаны на стероидах под названием ReactiveExtensions (старый стиль тоже можно использовать). Умеет работать с Windows/Linux/MacOS, поддержку мобильных платформ планируется добавить в начале следующего года посредством отрисовки через MonoGame.

Screentendo – это приложение для настольных компьютеров, которое превращает выделенную область экрана в играбельный уровень для игры Super Mario Bros.

Я раньше не делал приложений для Cocoa app и не использовал Sprite Kit, и это стало для меня отличным упражнением. Исходный код доступен по ссылке.

Как это работает?

При запуске приложения появляется полупрозрачное окно, которое можно двигать и изменять его размер. После размещения окошка над какой-то областью экрана клик внутри него приведёт к тому, что приложение создаст уровень на базе контента, находящегося под ним.

У Screentendo есть два основных этапа работы: обработка картинки для определения структуры выбранного района, и создание уровня.

Так сложилось, что большую часть жизни я пользовался Windows и привык воспроизводить аудио файлы с помощью Winamp. Он очень удобно интегрируется с командной строкой — запустил любой аудио файл и готово. После перехода на Linux и OS X (в основном по работе, но Mac использую и дома вместе с виндой) возникла острая необходимость найти альтернативу. Перепробывал большое количестко крафических плееров. Основная их проблема — это отсутствие нормальной интеграции с командной строкой и часто поддержка только одной из платформ: либо Linux, либо OS X. С консольными плеерами ситуация получше: mpg123 и mpg321 практически идеально делают именно то, что надо. Вот только появилось одно большое «но». Они не умеют играть .ogg и трекерную музыку (.it, .mod, .xm, .s3m и прочие), которой тоже накопилось достаточно и расставаться с ней совершенно не хотелось.

Очередная встреча CocoaHeads пройдёт 24 июля в 19:00 в офисе компании Rambler&Co, и на ней вы услышите четыре доклада.

Во время разработки iOS/OSX-приложений непременно приходится использовать Interface Builder и Auto Layout. В приложениях со сложными интерфейсом и в приложениях, находящихся в разработке достаточно давно, часто появляется проблема с большим количеством «исключенных констрейнов». Storyboard грузится необоснованно долго, а во время перехода между сценами можно успеть сходить за кофе.

Но, казалось бы, интерфейс всех контроллеров такой же незамысловатый, как и в релизе полгода назад. Что же случилось? Тем, кто использовал Size Classes, сразу понятно, что интерфейс — не такая простая штука, как кажется. Он ведет себя по-разному в разных ориентациях и на разных дисплеях. Делает он это, потому что некоторые constraints применяются только в определенной ситуации.

Это значит, что в остальных ситуациях эти constraints не используются. У Xcode Interface Builder есть особенность, которая помогает при разработке сложных интерфейсов и мешает при разработке простых. Если добавить constraint к какому-то UIView и затем удалить его из Xcode Inspector (а чаще всего это — самый удобный путь), Xcode не удалит его, а лишь сложит в список неиспользуемых на случай, если понадобится для другого дисплея или ориентации.

Иногда, если развернуть все группы constraints, можно ужаснуться происходящему в storyboard-файле:


Не хотите наблюдать подобное? Добро пожаловать под кат!

Сегодня в свет вышел отчет группы специалистов по информационной безопасности, посвященный исследованию атак, основанных на способах коммуникации между собой различных приложений на OS X и iOS — (XARA, от Cross-App Resource Access). Для тех, кому лень читать все 26 страниц оригинальной статьи, я решил подготовить ее небольшой обзор.

Для начала, два коротких тезиса:

• Во-первых, большая часть обнародованных уязвимостей касается OS X. В iOS все намного спокойнее.
• Во-вторых, все на самом деле достаточно печально.

8 июня на проводимом ежегодно WWDC компания Apple анонсировала новую версию языка Swift 2.0



Как написано в блоге Swift и на странице для разработчиков на Swift, новая версия получила более высокую производительность, новое API обработки ошибок, улучшения синтаксиса языка, а также функцию проверки доступности функций Swift для целевых ОС.

На мой взгляд, самое интересное – Apple открывает код Swift. Да, Swift 2.0 — это Open Source язык программирования.

Существует старый и очень известный слоган Apple «There’s an App for that» («для этого есть приложение»), поддерживающий идею, согласно которой люди могут найти и скачать приложение для решения любой проблемы. В App Store уже более 1,2 млн приложений и их количество продолжает расти. Каталог приложений Apple — великолепный пример правильной системы дистрибуции программ и контента. Приложения известных компаний имеют миллионы загрузок в первые же часы после попадания в каталог. Вопрос в том, как пользователи могут найти ваше приложение на бескрайних просторах App Store? В этой публикации мы попытаемся коротко рассказать об основных факторах, которые влияют на выбор пользователя.

Данная статья посвящена вопросу тестирования в рамках Objective-C используя Xcode 6. Рассматриваются стандартная библиотека для тестирования и сторонняя библиотека OCMock. Опытные разработчики, возможно, не найдут здесь слишком полезной информации, тем же, кто недавно встал на этот путь — статья откроет необходимые базовые знания по написанию unit-тестов на языке Objective-C.

Для основы тестирования просьба обратиться сюда.
Для основы unit-тестирования сюда.

А теперь мы начнем изучение unit-тестирования в рамках Objective-C.

Некоторое время назад я написал этот код:

NSMutableArray *environments = [NSMutableArray new];
for (NSString *key in [dictionary allKeys]) {
    XCCEnvironment *environment = [[XCCEnvironment alloc] initWithName:key
                                                            parameters:dictionary[key]];
    [environments addObject:environments];
}
return environments;

Заметили проблему? Я — нет.

Под катом спрятано видео, на котором один из пользователей нашего проекта демонстрирует работу приложений для MacOS внутри ReactOS при помощи Mini vMac.

Заинтересовавшись публикацией «Пишем свой Xcode plugin» решил написать простой тайм-трекер для Xcode. Процесс, через который я прошел — суть данной статьи. В ней мы с вами разберём несколько плагинов, которые помогут писать другие плагины быстрее и эффективнее.

Основная идея любого плагина с интерфейсом состоит в том, что он интегрируется в UI Xcode'a и выглядит максимально родным для него. Но как только мы смотрим на окно Xcode, сразу же встает вопрос: «Как понять где какой объект и как нам интегрироваться в нужный нам?» Так на нашем пути появляется первый плагин. Мы напишем простой плагин, который будет загружаться в Xcode и говорить, где какой объект расположен.

Вот так теперь выглядит игра Laser Squad, которую я увидел очень давно. Тогда она была во всех смыслах проще и выглядела так:



При этом принципиально игра не изменилась. Просто стала сложнее: куча типов ресурсов, множество вариантов их применения плюс «инфляция»: каждая следующая мастерская, лаборатория или спутниковый канал стоят больше, чем предыдущие. С одной стороны, это все дает возможность играть разными стратегиями развития, но иногда так хочется поиграть просто в Laser Squad! Поэтому…

Сегодня мы “подружим” или настроим макбук и RAD Studio XE8 (или Delphi, или C++ Builder, или Appmethod).

В результате мы сможем запускать свои приложения не только в среде Windows, но и на макбуке и iOS-симуляторе из одного и того же исходного кода. Эти действия являются основой для настройки и подключения реального iOS-устройств (тема отдельного поста).

План действий:
— настройка макбука (xCode + PAServer);
— настройка RAD Studio XE8 (Profile + SDK);
— запуск своего приложения на макбуке и iOS-симуляторе.

Разработка программных продуктов — очень интересный процесс, который нам всем очень-очень нравится, но есть некоторые вещи, которые слишком монотонны. Сегодня я бы хотел рассказать про то, как я упростил свой рабочий процесс в Xcode с помощью различных сторонних плагинов.



Заинтересованных прошу под кат

Привет всем хаброюзерам. Хотел бы поделиться опытом создания нативных расширений для OS X.

AIR — просто потрясающая в своей кроссплатформенности среда. Пока дело не доходит до использования каких-то уникальных для платформы фишек. Именно с этой проблемой я столкнулся, когда передо мной была поставлена задача превратить браузерную flash-игру в десктопную для OS X. Всё это с использованием среды AIR мной было сделано за несколько часов и я не буду описывать этот процесс, так как в гугле на эту тему полно информации. Самое интересное началось тогда, когда появилась необходимость подключить к игре различные сервисы Apple, такие как GameCenter, In-App-Purchase и т.д. И здесь я столкнулся с трудностями. Дело в том, что есть куча готовых ANE, в том числе и бесплатных. Но вся беда в том, что все эти решения работают только для iOS. Для OS X же нет ни то, что готовых библиотек, но даже информацию по созданию этих библиотек приходилось собирать по крупицам с пары-тройки интернет ресурсов многолетней давности, постоянно натыкаясь на какие-то подводные камни или даже айсберги.

Сейчас же я хочу собрать все накопленные знания и опыт в одном месте и поделиться с вами, чтобы хоть немного уменьшить ту боль, через которую вам придётся пройти, если всё таки вы тоже решитесь на создание нативных библиотек для мака. Хотя после четырёх разработанных расширений для OS X они не кажутся такими уж сложными и мудрёными.