Всем привет!
Нет, это не очередной пост в стиле «встречайте Swift и его возможности», а скорее краткий экскурс по практическому применению и тонкостях, где протоколо-ориентированность нового языка от Apple позволяет делать симпатичные и удобные вещи.

Язык Swift был представлен сообществу чуть больше года назад, что вызвало достаточно большой резонанс в среде разработчиков, при том не только iOS и OS X.

Но еще больший резонанс вызвал тот факт, что Apple пообещала открыть код компилятора и анонсировала возможность поддержки языка для операционных систем на базе linux.

Предистория

Под впечатлением статей про Sprite Kit и про GestureRecognizer возникла идея портировать простенькое приложение себе на телефон. А так как там достаточно часто используются структуры CGPoint, то озадачился изучением перегрузки операторов в Swift и подсмотрел тут.

Мы обратили внимание на активную работу по приложениям для watchOS выпускника нашего Акселератора, решили не отставать и поспособствовать активному использованию новой платформы.

Ниже представлен список фреймворков, библиотек и примеров приложений для watchOS.

С выходом iPhone 6s и iPhone 6s Plus компания Apple представила нам совершенно новый способ взаимодействия с нашими телефонами: жест сильного нажатия. Как вы знаете, эта функция уже доступна на Apple Watch и MacBook и в MacBook Pro под названием Force Touch. Это — буквально — добавило новое понятие к пользовательскому интерфейсу.

Если вы задаетесь вопросом, почему Force Touch было переименовано на 3D Touch для iPhone, тогда вы не одни такой. Вскоре после того, как Крейг Федериги (Craig Federighi), который также был явно озадачен названием, представил эту новую возможность, возникло много догадок. Чем не устроило название Force Touch? Слишком много шуток из Звездных войн?

Но есть разница! Очевидно, что Force Touch может распознать только сильное нажатие, тогда как функция 3D Touch более чувствительная и может выделить несколько уровней нажатий на основе того, как сильно вы нажимаете.

Как self и _cmd оказываются в методе? Как работает dispatch table и категории? Что такое мета-класс? Сколько на самом деле методов у ваших классов в ARC и в MRC? Как работает swizzling?
Интересно? Добро пожаловать под кат!

ВНИМАНИЕ!

Эта статья не рассчитана на начинающих разработчиков… Приношу свои извинения за то, что не рассматриваю многие моменты, которые должен знать Objective-C разработчик.

iOS разработчики это — фантастическое сообщество, которое предлагает широкий спектр доступных сторонних библиотек.

Если вы разрабатывали для этой платформы, тогда, скорее всего пользовались хотя бы одной из этих библиотек. Будь это AFNetworking, SDWebImage, SSKeychain или CocoaLumberjack, и уже должны понимать важность использования чужого кода, если вы не любите «изобретать свой велосипед».

Есть CocoaPods. Если по какой-то причине вы не знакомы с этим прекрасным инструментом, так это самый популярный менеджер зависимостей, который упрощает процесс интеграции такого рода библиотек в ваш проект.

CocoaPods широко используется в iOS сообществе, и даже Google использует его для распространения различных iOS SDK.

Хоть CocoaPods и потрясающее средство для управления зависимостями, есть и другие варианты. Carthage является одним из таких вариантов; это безжалостно простой менеджер зависимостей для Mac и iOS, созданный группой разработчиков из Github.

Это был первый менеджер зависимостей для работы с Swift; фактически, сам Carthage написан на Swift'e! Он использует исключительно динамические фреймворки вместо статических библиотек – это только способ распространения двоичных файлов Swift, которые поддерживаются в iOS 8 и выше.

Однажды я почти полностью отказался от мышки для навигации по Xcode и вполне этому рад. Следующий шаг — это отказ от визуальных средств управления отладчиком. Зачем? — Увеличиваем возможности, уменьшаем время дебага, тратим меньше калорий для перемещения тяжеленькой ручишки (нам калории нужны, чтобы головой работать) и тем самым провоцируем меньше туннельного синдрома.

Привет, Хабр!

Давно мы не публиковали новостей про AppCode, пора это исправить. К тому же у нас есть отличный повод — 2 ноября вышла новая версия нашей IDE для iOS/OS X.



Если в AppCode 3.2 мы упорно работали над “умными” возможностями для Swift (и многое успели реализовать), то в версии 3.3 все силы были брошены на поддержку новых языковых конструкций Swift 2.0 и Objective-C, анонсированных Apple в июне.

Поддержка Xcode

В конце августа мы пообещали, что постараемся как можно скорее реализовать поддержку Xcode 7 в AppCode. Часть необходимых изменений мы внесли в первой же EAP-версии, и продолжали работать над этой задачей в течение всей программы раннего доступа. Новый AppCode 3.3 официально совместим с Xcode 7/7.1, а вот поддержку Xcode 6.x на OS X 10.11 нам пришлось прекратить (почему — можно прочитать здесь).

Подходит к концу разработка моего первого приложения под Apple TV, и я решил поделиться собранной информацией об этой платформе.

tvOS поддерживает два типа приложений: TVML и традиционные.

Традиционные приложения — практически то же самое, что и приложения под iOS (UIKit, Storyboard);
TVML — фреймворк для создания клиент-серверных приложений. Вся логика, дизайн и данные находятся на удаленном сервере.

От переводчика: C пятницей, дорогие хабровчане! Хочу поделиться сегодня с вами переводом статьи из небольшого блога об опыте работы с языком Swift. Вряд ли она претендует на лавры серьезного и скрупулезного анализа, но, думаю, будет интересна всем, кто задумывался: «а не пора ли отправить на свалку истории этот Objective-C?».

Когда Apple представила нам Swift — это было круто! Наконец-то мы получили next-gen (т. е. модный-скриптоподобный) язык для разработки под яблочные девайсы (но без поддержки приватных членов класса, хм....). Теперь этот [языкДинозавр квадратноскобочный] может отправиться в музей, а мы начнем тыкать эти новые блестящие фичи языка. Безусловно, наивно предполагать, что язык, которому менее года, будет без тараканов. Очевидно, некоторое время нужно дать ему на избавление от детских болячек. Именно поэтому я не бросился переписывать все мои проекты на Swift сразу после анонса.


Заметили, что птица падает вниз?

Почти каждый из нас испытывал дискомфорт, когда при нажатии на кнопку или при вводе текста в iOS или Mac приложениях, как внезапно пользовательский интерфейс переставал отвечать, приложение будто замирало и переставало реагировать на ваши действия.

На Mac, пользователи видит песочные часы или вращающийся радужный курсор, пока снова не возобновится взаимодействие с пользовательским интерфейсом. Многие пользователи ошибочно предполагают, что приложения сразу же заработает при прикосновению к экрану. Такие приложение дают ощущение низкой производительности и кажутся медленными, и, как правило, получает плохие отзывы в AppStore.

Но обеспечить постоянную отзывчивость пользовательского интерфейса не так уж просто. Как только приложение выполняет множество задач, оно начинает подтормаживать. Не так уж много времени выделяется для выполнения большого количества задач в главном потоке и для обеспечения отзывчивости интерфейса.

Что же должен делать «несчастный» разработчик? Решение есть, оно состоит в том, чтобы отделить основной поток через параллелизм. Параллелизм, это свойство приложения выполнять задачи в несколько потоков одновременно – и при этом пользовательский интерфейс остается отзывчивым, поскольку Вы выполняете свою работу в разных потоках.

Одним из методов для одновременного выполнения операций в iOS являются использование классов NSOperation и NSOperationQueue. В этой статье вы узнаете, как их использовать! Вы будете работать с приложением, которое совсем не использует многопоточность, таким образом, оно будет очень медленным, и будет «тормозить». Когда вы измените приложение, чтобы можно было добавлять параллельные операций и — надеюсь – это обеспечит более отзывчивый интерфейс для пользователя!

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

Недавно, читая пост про SwiftyVK, нашел там ссылку на статью про OptJSON, позволяющую сильно упростить работу с JSON в Swift. И хотя подход, описанный в статье, действительно интересен, меня не покидало ощущение, что это все-равно слишком сложно.

Я попробовал еще немного упростить библиотеку OptJSON, и вот что получилось:

let obj = json?["workplan"]?["presets"]?[1]?["id"] as? Int

В первой части мы рассмотрели лишь часть новых возможностей Swift 2:

• фундаментальные конструкции языка, такие, как enums, scoping (область действия), синтаксис аргументов и т.д.
• сопоставление с образцом (pattern matching)
• управление ошибками (error handling)

Во второй части мы рассмотрим оставшиеся:

• расширения (extensions) протокола
• проверка доступности (availability checking)
• взаимодействие с Objective-C и С

Я буду рассматривать новые возможности Swift 2, сопровождая их примерами, код которых находится на Github.

Уильяму Генри Гейтсу III 60 лет. Да-да, так его зовут полностью. Хотите проникнуться духом того времени — прочтите «Сотворение Microsoft». Сердечно поздравляем и желаем долгих лет и новых рабочих свершений. Тем временем в App Store появляется категория Shopping. Разработчики получили соответствующее письмо.

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

Swift 2 сфокусировался на улучшении самого языка, взаимодействия с Objective-C и повышении производительности компилируемых приложений. Новые возможности Swift 2 представлены в 6 различных областях:

• фундаментальные конструкции языка, такие, как enum , scoping (область действия), синтаксис аргументов и т.д.
• сопоставление с образцом (pattern matching)
• проверка доступности (availability checking)
• расширения (extensions) протокола
• управление ошибками (error handling)
• взаимодействие с Objective-C

Я буду рассматривать новые возможности Swift 2, сопровождая их примерами, код которых находится на Github.

Совсем недавно, в сентябре, Apple выпустила ожидаемый многими апдейт, вторую версию операционной системы watchOS. По написанию программ для нее статей на Хабре вроде еще не было, попробуем исправить этот момент.

Что нового

Все знают, что ключевым недостатком всех «умных часов» является малое время работы от батарей. Инженеры Apple решили исправить этот момент весьма простым способом — максимально разгрузить процессор часов. Для этого было придумано оригинальное решение — на часах хранились лишь ресурсы программы, а все вычисления делались на процессоре телефона. Программа для часов состояла из 2х компонентов: Watch App (то что хранится на часах) и WatchKit Extention (хранится на телефоне). Т.е. по сути, это было неким вариантом «удаленного рабочего стола» для смартфона — без наличия рядом телефона приложение работать не могло. В качестве канала связи скорее всего, использовался не отличающийся быстротой Bluetooth LE. Пользователи в итоге часто жаловались на «заторможенность» интерфейса, что было следствием этого принципа. В общем, несмотря на оригинальность, концепция «не взлетела». Так вот, основное отличие OS2 — теперь приложение хранится на часах полностью. Однако абсолютно независимым оно все равно не является — хотя приложение на часах работает автономно, должна быть «основная» программа для iPhone, вместе с которой это приложение ставится. Все это сильно похоже на «костыль», и в следующей версии такого ограничения наверно не будет. Впрочем, посмотрим.

Если говорить о железе, то программисту доступны 2 варианта часов для отладки:

— экран 38mm, разрешение 272x340,
— экран 42мм, разрешение 312x390.

Остальных характеристик (память, процессор и пр), на сайте Apple их найти не удалось. Впрочем, для нашего проекта это не столь важно. Перейдем к проекту (осторожно, траффик).

Надеюсь, все успешно обновились до 9.0.2 и El Capitan. Уже успело подзабыться с презентации, что же там такого нового. Тем приятнее находить изменения. Сегодня вечером встреча Cocoa Heads Moscow. Большая программа. Не забывайте.
Кстати, 29 октября планируется ежегодная встреча разработчиков LLVM. Возможно там будет что-нибудь сказано про Swift и то, когда он станет Open-Source.

Кому нужны модульные тесты? Не Вам — Ваш код идеален. Но все же, Вам просто нужно прочитать эту статью, которая должна больше рассказать о написании модульных тестов на Swift’е. Вдруг это Вам в дальнейшем пригодиться.

Модульное тестирование являются отличным способом для написания безупречного кода; тестирование поможет Вам найти большинство ошибок на ранней стадии написания проекта. Как показывает опыт: если у Вас возникают трудности при тестировании кода, тогда у Вас возникнут сложности с его поддержкой или отладкой.

Модульное тестирование работает с изолированными “микрокомпонентами”. Зачастую Вам нужно «мокировать» классы – то есть обеспечить фейк функциональной реализацией, чтобы изолировать специфический микрокомпонент, таким образом, он сможет быть протестирован. В Objective-C существует несколько сторонних фреймворков, которые помогают это реализовать. Но они еще не доступны в Swift’е.

В этом руководстве Вы научитесь, писать свои собственные mock-обьекты, fakes и stub'ы, чтобы покрыть тестами давольно простое приложение, которое поможет вам запомнить дни рождения ваших друзей.