В конце мая 2014 года я писал подробную статью как тестировать приложения на iOS7 и Xcode 5.1.1, но не далее как два месяца назад миру был представлен iPhone 6 и iPhone 6 Plus с новой операционной системой iOS 8 и Apple изменила что-то в коде и старый «твик» более не работает. Знаю, что некоторым интересно попробовать написать приложение для iOS, чисто в познавательных целях, но 99USD платить Apple за «любознательность» не хочется. Не отчаивайтесь, не все так страшно, более того, теперь всё гораздо проще — больше не нужно создавать сертификаты и компилировать ldid для отладки.

Трудно отыскать iOS-разработчика, никогда не пользовавшегося для тестирования своих приложений сервисом TestFlight, или хотя бы не слышавшего о нем. Его популярность в феврале этого года подтвердила сама Apple, купив компанию Burstly, благодаря которой в свое время появился TestFlight.



Как известно, Apple не из тех, кто бросает деньги на ветер — 9 сентября Apple представила TestFlight в App Store уже под своим брендом.

Вслед за публичным релизом iOS 8.1 в понедельник, 20 октября, Apple представила ряд других новшеств, среди которых есть и то, что напрямую касается разработчиков мобильных приложений под iOS.



В частности, компания изменила требования к выпускаемым приложениям, о чем вчера оповестила разработчиков через уведомления от Developer Center.

Как вы знаете, в Xcode 6 и iOS 8 SDK Apple добавила возможность рендеринга кастомных компонентов и редактирования их свойств прямо в стандартном Interface Builder (здесь должно быть едкое упоминание о том, что это было еще в Delphi древних версий).

Основы

Для начала нам понадобится какой-то самодельный наследник UIView, чтобы заставить Xcode рендерить его в Interface Builder. Для этого его нужно пометить атрибутом IB_DESIGNABLE (технически в Objective-C это макрос, ну раз Apple называет это атрибутом, и в Swift это атрибут, так тому и быть):

IB_DESIGNABLE
@interface XXXStaticPriceView : UIView

@property (nonatomic, copy) IBInspectable NSNumber *price;
@property (nonatomic) IBInspectable NSUInteger amount;
@property (nonatomic) IBInspectable NSNumberFormatterRoundingMode roundingMode;

@property (nonatomic, getter = isHighlighted) IBInspectable BOOL highlighted;

@property (nonatomic, copy) IBInspectable UIColor *textColor;
@property (nonatomic, copy) IBInspectable UIColor *outlineColor;

@end

Теперь можно создать storyboard (или xib) и разместить там наш view, и Xcode должен будет его успешно отобразить (предварительно собрав проект):

Привет всем! Сегодня хотелось бы сделать небольшое введение в такую штуку, как Size Classes. Она появилась недавно вместе с Xcode 6, документации по ней от самой Apple совсем немного.

Итак, для чего же предназначена Size Classes? Все мы знаем, что на подходе уже iPhone 6 двумя (как минимум) разными размерами дисплея (4,7 и 5,5), после чего разработчикам еще больше придется заморачиваться с версткой UI для них + само собой расширения iPad«ов. В итоге количество всех поддерживаемых экранов будет около 7 (маленький привет Android). Герой сегодняшнего дня — Size Classes — как раз и предназначен для того, что бы помочь решить данную проблему.

Как многие читали в книгах, в языке Objective-C изначально есть два корневых класса — NSObject и NSProxy. И если на первом основано практически все и с ним невозможно не столкнуться, то вторым пользуются значительно реже. В этой небольшой статье я опишу те применения этого класса, которые приходилось использовать мне.

Предисловие

Недавно Apple представила общественности достаточно важное изменение в разработке iOS приложений, анонсировав новый язык программирования Swift. Я принял решение: изучая этот язык пошагово, я буду в своих статьях рассказывать обо всём, что мне удалось найти. Это лишь первый пост из многих на эту тему, но я надеюсь, что вы решите изучать язык вместе со мной!

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

Итак, я собираюсь начать с довольно простого приложения. Также я буду объяснять, как работает код. Готовы? Поехали…

Возьмём за основу статью Знакомьтесь, Swift!, где показано как сделать простое приложение на Swift, и добавим туда такие известные и полезные штуки как pull to refresh и infinite scrolling используя встроенные возможности языка. Чтобы было еще интереснее, добавим немного асинхронности, иначе приложение будет каждый раз замирать на время обновления.

Меня зовут Митя Куркин, я руковожу разработкой iOS мессенджеров Mail.Ru Group. Сегодня я расскажу о нашем опыте ускорения приложений на iOS. Высокая скорость работы очень важна для 99% приложений. Особенно это актуально на мобильных платформах, где вычислительные мощности и, соответственно, заряд аккумулятора весьма ограничены. Поэтому каждый уважающий себя разработчик стремится оптимизировать работу своего приложения с целью устранения различных задержек, из которых складывается общее время реакции.

Компания «Deque Systems» представила бета-версию WorldSpace Xcode Plugin, который интегрируется в Xcode и автоматически анализирует исходный код проекта на предмет правильного указания всех атрибутов доступности. Плагин также предоставляет контекстную справку по методам решения тех или иных проблем accessibility в iOS. Кроме того, он может быть встроен в Continuous Integration.

С помощью этого инструмента можно легко включить поддержку VoiceOver в процесс разработки на постоянной основе, так как он позволяет нажатием пары кнопок отловить базовые проблемы невизуальной доступности интерфейса. Плагин использует растущий набор правил, основанных на базе критериев стандарта WCAG 2.0.

Статья является своеобразным продолжением статьи «Знакомьтесь, Swift!» за авторством Helecta, а также вольным переводом статьи Developing iOS Apps Using Swift Tutorial Part 2.



Итак, в первой статье мы написали простое Single View приложение, включающее таблицу с несколькими ячейками.
На этот раз мы немного углубимся и сделаем несколько более амбициозных вещей. Мы будем обращаться к API поиска iTunes, парсить ответ, полученный в JSON и отображать результаты в Table View.
На первый взгляд может показаться, что все это довольно сложно и предстоит много работы, но на самом деле это не так. Все описанное выше является достаточно простым функционалом для iOS приложений и каждый уважающий себя iOS разработчик должен это уметь.

Зачесались у меня тут руки узнать, что это за зверь такой Swift и с чем его собственно едят. Как и ожидалось проблем и подводных камней пока оказалось много, ну либо я совсем не умею этот Swift готовить. Самая большая проблема ожидала меня при попытке подружить этот самый Swift с CoreData — штука принципиально отказывалась работать. Обильное гугление не приводило к хоть каким-либо хорошим результатам — информация была либо крайне обрывочной, либо попахивала костылями. Посему в первый вечер терзаний я капитулировал и решил использовать самое тупое решение в работе с CoreData по-старинке — хранить весь код в старом добром Objective-C и уже к нему обращаться из Swift (например в интерфейсах). Однако, перфекционизм в душе не давал покоя и требовалось реализовать чистое одноязычное решение, что я собственно и смог сделать, хотя признаться и не без костылей тоже. Кому интересен процесс прошу под кат. Также попутно предлагаю собирать баги и не самые на мой взгляд удобные вещи, которые пришли вместе с новым языком. Возможно, что-то я сделал криво — буду благодарен комментариям и поправкам, а также обсуждению лучших практик.

2 июня на конференции WWDC 2014 Apple представила новый объектно-ориентированный язык программирования — Swift. Я думаю, многие уже успели посмотреть, что из себя представляет этот язык (Swift — нововведения), поэтому я не буду останавливаться на нововведениях. Я предлагаю создать простенький проект на языке Swift, чтобы понять на деле основные отличия от привычного Obj-C.

Мне было интересно попробовать написать приложение для iOS, чисто в познавательных целях, но 99USD платить Apple за «любознательность» не очень то и хотелось. Не отчаивайтесь, для таких как мы есть способы и запустить приложение и отладить его на целевом устройстве.

Я хотел научиться работать с oracle из xcode, так как не обнаружил готового фреймворка от apple для работы с базой данных oracle напрямую.
Для начала, я попробовал создать тестовый проект и подключить к нему instantclient от oracle. Также я использовал тестовый пример от Oracle ( cdemo81.c ), включил его код в проект на xcode и протестировал работу. Да, все работает, хотя пришлось немножко побить в шаманский бубен от google. Тем не менее, использовать напрямую oci библиотеку тяжело, так как нужно реализовать интерфейс, а это похоже на изобретение велосипеда.
Тогда я решил попробовать использовать кросс-платформенную библиотеку ocilib ( http://orclib.sourceforge.net )
Далее в тексте пошаговая инструкция о том, как сделать тестовый проект на cocoa и использовать эту библиотеку. Цель тестового проекта — подключив библиотеку получить данные с сервера oracle.

Данный туториал описывает создание плагина для Clang и покрывает следующие шаги:

• настройка окружения
• создание базового плагина
• создание Xcode-проекта для разработки плагина
• генерирование предупреждений
• генерирование ошибок
• интеграция плагина в Xcode
• интерактивные подсказки по устранению предупреждений и ошибок

TL;DR

Готовый плагин можно найти здесь

Основную идею данной заметки в принципе можно уместить в одном предложении: «раз уж вы пишете тесты, то неплохо было бы прогонять их на всех возможных конфигурациях, а не на одной единственной». Но поскольку формат однострочных статей на хабре не принят, а информация усваивается пропорционально логарифму количества слов в объяснении, то раскрою мысль подробнее.

Quick Help научился брать документацию из комментариев: