так в Великобритании привито почти 50% (2 дозы 46%, 1 доза 17%), а динамика заболеваемости примерно как у нас. Опять непонятно.

Не скажу про динамику заболеваемости, а вот смертность у них практически на нуле, в отличие от нас, и не растет.

Флагов -F у нас немного (порядка десятков), так как при сборке мы не используем фреймворки, за исключением бинарных. Подавляющее количество флагов — -Xcc -fmodule-map-file=... — их около тысячи.

Я правильно понял, что чем больше либ на objc содержит твой podfile, тем хорошо если квадратично больше время запуска дебаггера?

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

Тем не менее, это не делает ваше наблюдение неправильным, ведь у cocoapods своя атмосфера. Вот пара фактов:

1. Даже если под написан только на Swift без примесей ObjC, поды добавляют к нему сгенерированные заголовок и m-файл.
2. Каждому поду в header search paths записываются пути поиска до всех остальных подов, вне зависимости от того, от чего он на самом деле зависит (простите за каламбур).

Вследствие этих фактов получаем такую картину: допустим, у нас были поды A, B, C, все на Swift. Поды сгенерируют проект таким образом, что, в числе прочих, у Swift-модулей будут такие флажки:

A: -Ipath/to/B -Ipath/to/C
B: -Ipath/to/A -Ipath/to/C
C: -Ipath/to/A -Ipath/to/B

Теперь мы хотим добавить еще один под D, и картина будет выглядеть уже таким образом:

A: -Ipath/to/B -Ipath/to/C -Ipath/to/D
B: -Ipath/to/A -Ipath/to/C -Ipath/to/D
C: -Ipath/to/A -Ipath/to/B -Ipath/to/D
D: -Ipath/to/A -Ipath/to/B -Ipath/to/C

И, таким образом, количество флажков возросло с 6 до 12 (в асимптотике тут будет квадратичный рост: всего их будет N * (N - 1)). Напомню, что, как мы уже выяснили в статье, все эти флажки склеятся, несмотря на то, что они дублируют друг друга.

Давайте добавим еще один под E, но уже на ObjC. Для него не будет Swift-модуля, пагубным образом влияющего на дебаггер, поэтому картина будет такая:

A: -Ipath/to/B -Ipath/to/C -Ipath/to/D -Ipath/to/E
B: -Ipath/to/A -Ipath/to/C -Ipath/to/D -Ipath/to/E
C: -Ipath/to/A -Ipath/to/B -Ipath/to/D -Ipath/to/E
D: -Ipath/to/A -Ipath/to/B -Ipath/to/C -Ipath/to/E

Количество флажков возросло с 12 до 16, но, если бы модуль E содержал Swift (или был бы полностью на нем, это уже никакой роли не играет), то мы бы увидели не 16, а целых 20 флажков (т.к. добавилась бы еще такая же строчка для E).

tl;dr: количество флажков при использовании подов растет как M * N, где M — количество подов, использующих Swift (неважно при этом содержат ли они ObjC), а N — общее количество подов (причем во всем этом учитываются не только те поды, которые вы используете непосредственно в вашем приложении, но и их зависимости, которые вы, возможно, напрямую не используете). Таким образом, как ни парадоксально, чем больше доля подов на чистом ObjC, тем меньше взрыв флажков при сборке контекста дебаггера.

Меня мучает такой вопрос: какие преимущества у лазерной коррекции перед ИОЛ? Вроде как замена хрусталика — операция, которая отработана на огромном количестве пациентов с катарактой, риск осложнений минимален, и, насколько я знаю, ее можно делать повторно без особых ограничений. С другой стороны, лазерная коррекция — это необратимые изменения, и докоррекция там довольно нетривиальна, плюс травмируется Боуменова мембрана.

Лично у меня бы это сильно поубавило желание пытаться устроиться к вам работать :)

Я тоже слышал, что Йота использует мегафоновскую физическую сеть, но у меня есть еще одно свидетельство того, что что-то тут нечисто – друг также перешел с Мегафона на Йоту и тоже жалуется на отвратительное качество связи, планирует вернуться обратно.

Возможно, спорить не буду, опыта использования IB у меня нет. Доводилось просто видеть проекты с описанной мной кашей, в которой очень сложно разобраться.

Имхо, смысл не использовать IB есть, когда в приложении сложный UI с большим количеством переходов. В этом случае ваши макеты превратятся в вечнотормозящую (в Xcode) мешанину.

Дело в том, что constraints удобны для использования только в IB. Если отрисовывать интерфейс полностью кодом, то проще реализовать старый добрый layoutSubviews. А уже IB vs программная отрисовка — это отдельная большая тема для рассуждений: в каких-то случаях лучше одно, в других — другое.

А ассетов в списке нет :) Но да, вы верно заметили, ассеты тоже нужны.

Когда добавят поддержку арма и релизных сборок — можно начинать пробовать. Кроме этого из списка в нашем проекте есть только MapKit. Ехидно посмеиваюсь над любителями IB, автолэйаутов и свифта :)

Спасибо, как-то проглядел.

Я так понимаю, под «моделью» имеется ввиду ревизия внутреннего железа? Что тогда мешает злоумышленнику и дальше сидеть на «старой» версии?

Хм, а как в тройке реализована защита от несанкционированной записи? Иными словами, если хитрый человек каким-либо образом разберет алгоритм пополнения (реверс, утечка информации, etc), то он теоретически сможет ездить бесплатно, ведь карта-то оффлайновая?

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

Интересно, когда-нибудь появятся анализаторы, находящие архитектурные просчеты (ну или хотя бы проблемы с многопоточностью)? :)

Parameters
allowedCharacters

The characters not replaced in the string.

Последние 3 слова в названии метода относятся к параметру.

Наверное, я просто олдфаг, не обращайте внимания :)

Тогда все понятно, спасибо за разъяснение! Надеюсь, проект сильно поспособствует снижению преступности :)

Лично меня в свифте уже один только восклицательный знак убивает. Как можно при описании методов использовать такой символ? Вообще, язык выглядит как движение в сторону JavaScripta, что лично я считаю неприемлемым.