Мы обновим его до свифт 3 на этих выходных =) Пока что есть девелопмент версия в бранче swift3, она почти готова к релизу, осталось отполировать использование Alamofire 4.0 до нормального вида.

А вот еще =)

https://github.com/MLSDev/TRON

Его легко можно сделать lazily loaded — все глобальные переменные в свифте lazy loaded, можно дополнительно сделать конструктор вот такого вида

private let _sharedInstance: Singleton  = {
    let singleton = Singleton()
    singleton.property = ...
    return singleton
}()

class Singleton {
    class var sharedInstance : Singleton {
        return _sharedInstance
    }
}

Третий пункт про синглетоны не верен. class var уже давно работает, кажется с релиза XCode 6.1. Сейчас самый логичный способ создать синглетон на свифте вот такой:

private let _sharedInstance = Singleton()

class Singleton {
    class var sharedInstance : Singleton {
        return _sharedInstance
    }
}

Хочу обратить внимание на то, что автор кода по ссылке и автор Reactive Cocoa это одно и то же лицо, Justin Spahr-Summers.

Ну вообщем думаю, дальнейший спор бесполезен =) Обе стороны не переубедить.

С моей точки зрения, у UIViewController как раз есть интерфейс. Все примеры, которые вы приводите, прекрасно можно обработать в prepareForInterfaceBuilder().

Я и не говорил, что UIViewController должен отвечать за отображение. Это может быть иерархическая структура.

Делаем IBDesignable UIViewController, в нем IBDesignable UIView и так далее. Каждый из этих классов имплементит prepareForInterfaceBuilder. И мы сразу видим результат в preview. Прекрасно же было бы.

В вашем же случае, вам доступна только вторая часть с UIView, что режет полезность функционала в два раза.

Не согласен с вами. Кастомную вьюху имеет смысл делать, когда у нее есть функционал, которого нет в стандартной. Например — у меня в проекте есть UIButton, который через IBInspectable поддерживает borderColor, borderRadius, и так далее. Для использования достаточно подкинуть, и выставить значения в IB.

А что будет делать вьюха контроллера, если вы сделаете ее кастомной? Все равно за весь контент отвечает контроллер, а не UIView.

Любую UIView, которую можно реюзнуть, разумеется стоит делать кастомной, но вьюха UIViewController имхо не тот случай.

Для 99% UIViewController используется стандартный UIView, заменять его на кастомный ради рендеринга — костыль. И как раз UIViewController очень даже нормально выглядит, и показывается в live preview на разных разрешениях экрана. В данный момент удобно открывать превью с 3.5, 4, 4.7, и 5.5 inch, чтобы сразу видеть, правильно ли настроены те же autolayout constraints.

И за исключением IBDesignable части, все статические элементы прекрасно видно. Если они допилят IBDesignable — будет потрясающе, необходимость запускать симулятор практически отпадет.

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

В данный момент сториборды могут рендерить вьюхи, но не могут рендерить UIViewController. Хотя метод prepareForInterfaceBuilder находится в категории на NSObject, что намекает на то, что рендерить можно не только UIView.

IBInspectable + IBDesignable вместе со свифтом просто божественны, без фреймворков позволяют сразу видеть, как вьюха будет выглядеть на любом размере экрана.

Немного не хватает поддержки UIViewController для IBDesignable, надеюсь Apple допилят, все-таки prepareForInterfaceBuilder обьявлена в категории на NSObject, а не на UIView.

Очень надеюсь, что популярность ReactiveCocoa будет падать, ибо пока что этот фреймворк приносит только вред, а не пользу. Вместо loose coupling получаем на выходе бешеную колбасу из блоков и коллбэков, которая в определенный момент становится совершенно нечитабельной

Пример

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

У нас была идея, которая могла показаться странной на первый взгляд — встроить персонального помощника в телефон

Действительно, где вы ее взяли? Здесь кто-то сказал «Siri»? Не, не слышал.

В данном случае не использую, но иногда мокнуть проще, чем инжектить. Все зависит от ситуации, и от языка. В тех же рубях например сделать мок намного проще, чем в objective-c, rspec позволяет прямо чудеса творить.

Не обязательно инжектить класс. Можно инжектить то, что он возвращает. Например у меня в iOS проекте есть синглетон, который держит токен для работы с API. Я мог мокнуть этот синглетон, но вместо этого я просто вынес получение токена в отдельный метод, и банально наследуюсь от тестируемого класса, переопределяя данный метод. И без всяких моков и инжектов класса получаю возможность менять токен на лету.

Естественно, это конкретика, но странно говорить, что TDD мертв и не обращаться к конкретным примерам. TDD жив!

Да, действительно) Даже не знал об этой настройке. В настройках апп-кода сам черт ногу сломит)

Спасибо =) Справедливости ради надо сказать, что это довольно субъективная вещь, больше половины людей в нашем iOS отделе полностью перешли на AppCode, и не жалуются на такие вещи) Видимо дело привычки.

Да, тоже. Не думаю, что дело в конкретной машине, на работе на хакинтоше то же самое. Снэпшот как-то непросто у вас делается =) Поведение, о котором я говорю, воспроизводится довольно просто. Live templates AppCode против XCode templates.

Конкретно у меня автогенерация проперти повешена на такие сочетания:
www — @property (nonatomic,weak) x * y;
sss — strong
и так далее.

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