Уже давно файлы имеют другую структуру и нормально мержатся, с XCode 5 вроде.
Был у меня проект, огромный интернет магазин, в котором было штук 50-60 UITableViewCell, все написано исключительно кодом. Просто понять какая из ячеек в каком месте используется и как выглядит, было уже нетривиальной задачкой.
Время загрузки на современных девайсах абсолютно не заметно, плюс реюз, плюс кеширование, оптимизация ради оптимизации?
Со сторибордами согласен, сам не использую, отдельные ксибы намного универсальнее.
p.s. Я даже не представляю как сейчас без автолайаута делать современные большие универсальные приложения. В вашем случае это еще приемлимо, но когда я вижу большой проект, где 50% кода каждого контроллера составляет метод viewDidLoad и layoutSubviews, хочется побить по рукам. MVVM не спасает, просто выносит этот кошмар чуть подальше от глаз.
Единственная блудварь под макось которую я видел, это PuntoSwitcher который пытается поставить Яндекс.Браузер. Просто даже сам факт того, что у мак-ос апа кастомный установщик, уже повод задуматься о целесообразности этого приложения (за редким исключением).
Проблема множественных нажатий не ограничивается навигейшен контроллером как в статье. Серчбар + пуш, поповер + пуш, модальное окно + поповер, поповер + поп, и т.д. Все сильно зависит от дизайна и архитектуры приложения, во многих случаях, такие действия к крешу не приведут, но могут вылезти различные UI баги. Поэтому, все кнопки, ячейки, барбаттонитемы которые как-то меняют не данные, а представления на экране, должны иметь exclusiveTouch, это самая простая и железная защита от багов такого рода.
Первое, что я говорю нашим тестировщикам, это тестить такие вот кейсы с множественными нажатиями. Тот мегакостыль, который вы тут описали просто взорвал мне мозг. И то, он полностью не решает проблему двойных нажатий, только внутри навигейшен контроллера. А если у вас две кнопки фильтруют/меняют датасорс таблички, одновременное их нажатие, скорее всего, убъет контроллер. И для этого, у UIView есть пропертя exclusiveTouch, плохо, что она по дефолту не YES. И ее нельзя поставить глобально через UIAppearance, например.
В общем, горе от ума. Плохо, что большинство iOS разработчиков не читают документацию, а предпочитают StackOverflow Driven Development.
В Украине вообще с некоторыми именами в документах сложно. Родители назвали меня Филипп, в свидетельстве о рождении перевели как Пилип, как бы оно транслитерировалось в загранку, страшно представить. Но путем нехитрых денежных манипуляций, исправил сначала в паспорте имя на Фiлiпп, а затем и в загранке на Philip. Хоть это и противоречит стандартам, зато теперь у меня нормальное, и самое важное, одинаковое имя и фамилия во всех документах.
Ну, современные шутеры, уже давно не CS1.6 где единственный необходимый скил, это уменне отстреливать хедшоты. Сейчас большую роль играет тактика и командная игра, в голову попасть сильно сложнее, пуля летит не прямо, а снижается под воздействием гравитации и ветра, это все надо учитывать. К тому же, автоприцел может наводить только на грудь, дальше уже сам. И то, сильно зависит от настроек игрока и логики игры. Многие игры используют автоприцел только в сингле, в мультике он у всех принудительно отключен.
Был у меня проект, огромный интернет магазин, в котором было штук 50-60 UITableViewCell, все написано исключительно кодом. Просто понять какая из ячеек в каком месте используется и как выглядит, было уже нетривиальной задачкой.
Время загрузки на современных девайсах абсолютно не заметно, плюс реюз, плюс кеширование, оптимизация ради оптимизации?
Со сторибордами согласен, сам не использую, отдельные ксибы намного универсальнее.
p.s. Я даже не представляю как сейчас без автолайаута делать современные большие универсальные приложения. В вашем случае это еще приемлимо, но когда я вижу большой проект, где 50% кода каждого контроллера составляет метод viewDidLoad и layoutSubviews, хочется побить по рукам. MVVM не спасает, просто выносит этот кошмар чуть подальше от глаз.
В общем, горе от ума. Плохо, что большинство iOS разработчиков не читают документацию, а предпочитают StackOverflow Driven Development.