Помогу немного

В этом случае, Вы сравнивали одинаковость указателей.

 (c.priceCriterion == [NSNumber numberWithInteger:EDEvaluatePriceHundredPoint])

Правильно сравнивать объекты по значению нужно так

[c.priceCriterion isEqual:[NSNumber numberWithInteger:EDEvaluatePriceHundredPoint]]

Еще можно использовать сахар @(EDEvaluatePriceHundredPoint)
и сравнивать сразу методом для NSNumber (если уверены, что оба объекта этого класса)

[c.priceCriterion isEqualToNumber:@(EDEvaluatePriceHundredPoint)]

Что касается этого " Проблема оказалась в представленных в xcode 6 constraint to margin"
Не скажу, нужно смотреть экраны. Может ваш девайс был на iOS7, а айфон 6 на iOS8?

Одного меня смутило?

О её наличии можно судить лишь по эффекту гравитационного линзирования, который искажает идущий к нам от далёких галактик свет

В самом деле, эти скопления находятся как раз в местах, где сформировались галактики и целые галактические кластеры

Такое чувство, что они просто «увидели» темную энергию только в местах скопления галактик. Но это же не значит…

Печально, но наверное нужно уточнить, что не для рессуров, а для asset catalog'a

Насчет UILabel
в awakeFromNib лучше вызвать super
Или переопределить -initWithCoder (по аналогии с initWithFrame)
Еще, как вариант, можно использовать appearance (собственно для этого он и предназначался), а стиль устанавливать для всех label в отдельном методе аля

[[CustomLabelClass appearance] setFont:[UIFont customFont]];

Ну или в самом классе CustomLabelClass в методе

+ (void)load;

Я с удовольствием прочитал. Но формат больше geektimes'овский, да

Интеграция с SDK тоже достаточно простая, но конечно же далека от идеала, которым, по-моему, на данный момент является решение, используемое Fabric (Crashlytics) — о нём мы поговорим в заключительной — четвёртой — части обзора.

Хм, странно, но я совсем недавно интегрировал HockeyApp и там все аналогично Fabric — отдельный Мастер настройки, по сути все то же. Но в отличии от Fabric, Hockey предложил установку через Cocoa pods (как альтернативу Framework интеграции)

Ох и странно это выглядит. Пишешь то на JS, но синтаксис Objective-C всё равно знать нужно. По сути это и есть синтаксис Objective-C. Получается какая-то каша.

Блин, у меня такое же чувство возникает, когда при написании кода на Swift я сталкиваюсь с UIKit'ом

Ходят слухи, что это сделано специально для того, что бы дать возможно запускать на айпадах по несколько приложений одновременно в двухоконном режиме. в таком случае, привязка к ориентации выглядит действительно глупо. Но опять же, слухи… за что купил, за то и продал

В интернете подсказывают два решения проблемы
1) ориентироваться на viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:
2) проверять в viewDidLayoutSubviews и обновлять layout

Вы все же меня не понимаете. Система дает на откуп приложению обработку ввода пароля (внутреннего пароля приложения, я еще раз подчеркну, внутреннего пароля именно приложения, а не устройства). Откуда система может знать что там за метод идентификации пользователя у приложения: 4 цифры, или там квадратик нужно нарисовать.

С этим полем не все так просто. При его нажатии диалог для ввода пароля не появится, как вы могли подумать, а вместо этого вызовется блок reply с ошибкой. Код ошибки задокументирован:
LAErrorUserFallback
Authentication was canceled because the user tapped the fallback button (Enter Password).
То есть так и было задумано. Честно говоря, эту логику я так и не понял;

Все очень просто, это позволяет приложению выполнить проверку пользователя другим (старым дедовским, ага) способом, будь-то ввод пина или логин@пароль. Рассмотрим на примере Dropbox'a или любого другого защищенного хранилища, аля privatefolder. Там при запуске запрашивают 4 значный пароль, не общий системный, а приложения. Вот это на тот случай, когда пользователь не хочет пальцем тыкать, а хочет просто вбить пин. Лично я так часто делаю, так как биометрический датчик не всегда срабатывает с первого раза и быстрее натапать четыре цифры.

ну судя по описанию, это банальное полуавтоматическое командное наведение, как у комплексов птрка. у пули есть трасер сзади, который отслеживает оптическая система наведения на «винтовке». при отклонении трасера от прицельной марки подается команда пуле «довернуть» таким образом, что бы стать в центр прицельной марки. т.е. пуля дура и ничего не знает о своем положении. в конце ролика даже заметно, как она виляет, но мало ли, может и другое наведение

Хм, а я еще удивлялся, почему некоторые спрайты в некоторых играх при запуске на эмуляторе мерцают. хотя на телевизоре в детстве я таких проблем не замечал

ох, извините, я не указал. этот код работает для xib. в сторибоардах же, apple побеспокоилась и за нас (спасибо ей) и под капотом сделала часть кода, который мы раньше писали.
метод dequeueReusableCellWithIdentifier сам создает ячейку, если ее нет в кэше.
финальный вариант

       var tableViewCell = tableView.dequeueReusableCellWithIdentifier(CellReuseId) as? UITableViewCell;
         tableViewCell!.detailTextLabel.textColor = UIColor.purpleColor()
        tableViewCell!.text = "\(text) \(indexPath.row)"
        tableViewCell!.detailTextLabel.text = "Hi, \(indexPath.row)"
        return tableViewCell;

и все там должно перезагружаться, если нет — то Вы что-то напутали. залейте в гит проект, посмотрим :)

блин, не верно.
там где идет обращение к свойствам tableViewCell нужно добавить!
т.е.
tableViewCell!.text =

вот ничерта не читаем этот свифт…

Привожу корректный код:

       var tableViewCell = tableView.dequeueReusableCellWithIdentifier(CellReuseId) as? UITableViewCell;
        if  (!tableViewCell){
            tableViewCell = UITableViewCell(style: UITableViewCellStyle.Default, reuseIdentifier: CellReuseId);
            tableViewCell.detailTextLabel.textColor = UIColor.purpleColor()
        }
        tableViewCell.text = "\(text) \(indexPath.row)"
        tableViewCell.detailTextLabel.text = "Hi, \(indexPath.row)"
        return tableViewCell;

Где CellReuseId некая строка идентификатор

let CellReuseId = "Row";

Если я все правильно понял, то у Вас вот здесь ошибка

let cell: UITableViewCell = UITableViewCell(style: UITableViewCellStyle.Subtitle, reuseIdentifier: "MyTestSwiftCell")
        
        cell.text = "\(text) \(indexPath.row)"
        cell.detailTextLabel.text = "Hi, \(indexPath.row)"
        cell.detailTextLabel.textColor = UIColor.purpleColor()
        
        return cell

Вы каждый раз создаете ячейку для таблицы, игнорируя механизм переиспользования ячеек UITableView. Из-за этого скролл talbeView может заметно подтормаживать, лучше поправить, а то наверняка новички, изучающие Swift, наткнутся на эту статью и потащут это к себе в проект.

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

Кстати, насчет немутабельных массивов и возможности их изменений все как-то странно, ведь в документации написано что это таки фича, а не баг

«Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array. This enables Swift’s Array type to provide optimal performance for array operations when the size of an array is fixed.»

Отрывок из книги: Inc, Apple. «The Swift Programming Language.» Apple Inc., 2014-05-27T07:00:00Z. iBooks.
Этот материал может быть защищен авторским правом.

Посмотрите эту книгу в iBooks Store: itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=881256329

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