Как перейти на Tuist
Так уж вышло, что в нашем небольшом iOS-комьюнити меня считают апологетом Tuist. Насколько это правда и сколько действительно опытных разработчиков, знающих Tuist, нас окружает — мы опустим.
О плюсах Tuist многие уже наслышаны, а следующий вопрос, который возникает после «зачем он вообще нужен», — это «как перейти на Tuist».
Если кратко, вот официальная документация по миграции: Migrate an Xcode project.
Теперь по порядку:
1. Составляем базовый манифест Project.swift.
2. Надеемся на предоставляемый Tuist-ом набор утилит для выгрузки текущих настроек проекта и отдельных таргетов и генерируем файл xcconfig, который и будем использовать для создания проекта.
3. В Project.swift описываем все схемы основного проекта.
4. Переносим таргеты, начиная с самых базовых, корневых или с любых других, которые вам нравятся, ибо у самураев есть только путь, который (скорее всего) будет долгим.
Важно понимать, что все настройки проекта, которые годами врастали в xcodeproj, нужно будет перенести в конфигурацию Tuist-а. При этом желательно ничего не потерять по пути. Как сказано в доке: "Насколько утомительным будет этот процесс, зависит от сложности ваших проектов".
Лично моя боль — Target Membership (ловим файлы по всем таргетам, бррр)
Полезные ссылки:
- Tuist Docs Migrate an Xcode project
- Хабр Tuist: добавляем генерацию проекта в текущее приложение
- Migrating from CocoaPods to Tuist at Playtomic
- Неплохой мини-гайд с фб и крашлитикой
- YouTube App Dev Live Stream — Migrating an iOS App to Tuist
P.S. В ближайшее время поделюсь историей, как и зачем мы создаем несколько приложений из одного туист-проекта, передавая конфигурацию с бандлами, плистами и ресурсами извне, coming soon...
Так уж вышло, что в нашем небольшом iOS-комьюнити меня считают апологетом Tuist. Насколько это правда и сколько действительно опытных разработчиков, знающих Tuist, нас окружает — мы опустим.
О плюсах Tuist многие уже наслышаны, а следующий вопрос, который возникает после «зачем он вообще нужен», — это «как перейти на Tuist».
Если кратко, вот официальная документация по миграции: Migrate an Xcode project.
Теперь по порядку:
1. Составляем базовый манифест Project.swift.
2. Надеемся на предоставляемый Tuist-ом набор утилит для выгрузки текущих настроек проекта и отдельных таргетов и генерируем файл xcconfig, который и будем использовать для создания проекта.
3. В Project.swift описываем все схемы основного проекта.
4. Переносим таргеты, начиная с самых базовых, корневых или с любых других, которые вам нравятся, ибо у самураев есть только путь, который (скорее всего) будет долгим.
Важно понимать, что все настройки проекта, которые годами врастали в xcodeproj, нужно будет перенести в конфигурацию Tuist-а. При этом желательно ничего не потерять по пути. Как сказано в доке: "Насколько утомительным будет этот процесс, зависит от сложности ваших проектов".
Лично моя боль — Target Membership (ловим файлы по всем таргетам, бррр)
Полезные ссылки:
- Tuist Docs Migrate an Xcode project
- Хабр Tuist: добавляем генерацию проекта в текущее приложение
- Migrating from CocoaPods to Tuist at Playtomic
- Неплохой мини-гайд с фб и крашлитикой
- YouTube App Dev Live Stream — Migrating an iOS App to Tuist
P.S. В ближайшее время поделюсь историей, как и зачем мы создаем несколько приложений из одного туист-проекта, передавая конфигурацию с бандлами, плистами и ресурсами извне, coming soon...
tuist migration --help
docs.tuist.dev
Migrate an Xcode project · Migrate · Adoption · Projects · Features · Guides · Tuist
Learn how to migrate an Xcode project to a Tuist project.
🔥14❤2
Самые старые TODO-шки
Как часто вы перекладываете задачи на будущее? Как часто делаете это в коде?
Да, такое случается. Да, это не всегда "рэд флаг".
Главная проблема — это потеря фокуса на этих задачах в workflow команды в Jire или аналогах. Со временем в проекте копится целый «кладбищенский список» комментариев, о которых никто уже не помнит — кто их добавил, какой приоритет, в чем проблема, и какое может быть решение. По итогу, TODO-шки и FIXME-ки превращаются в незаметный археологический тех. долг.
Получается забавная ситуация... Комментарий есть, но реальной пользы никакой — только лишний шум и ощущение неустроенности в проекте.
Более мы не допускаем задачи-комменты: "Либо фикси сейчас, либо заводим задачу."
Вот вам самые забавные TODO-шки с разных проектов, самой старой стукнуло 9 лет, а от других появляется улыбка :)
Я оставил TODO, позже вернусь, доделаю, апрувните
Надо срочно в релиз!
Cейчас не лагает, потом придумаем по другому.
Как часто вы перекладываете задачи на будущее? Как часто делаете это в коде?
Да, такое случается. Да, это не всегда "рэд флаг".
Главная проблема — это потеря фокуса на этих задачах в workflow команды в Jire или аналогах. Со временем в проекте копится целый «кладбищенский список» комментариев, о которых никто уже не помнит — кто их добавил, какой приоритет, в чем проблема, и какое может быть решение. По итогу, TODO-шки и FIXME-ки превращаются в незаметный археологический тех. долг.
Получается забавная ситуация... Комментарий есть, но реальной пользы никакой — только лишний шум и ощущение неустроенности в проекте.
Более мы не допускаем задачи-комменты: "Либо фикси сейчас, либо заводим задачу."
Вот вам самые забавные TODO-шки с разных проектов, самой старой стукнуло 9 лет, а от других появляется улыбка :)
20❤8🔥5
Media is too big
VIEW IN TELEGRAM
UI разработка не востребована
В последнее время всё чаще можно услышать, что полноценная работа с UI уже не так востребована: бигтехы вовсю используют бдуй, а компании поменьше «красят» кнопки на SwiftUI. И те, и другие время от времени ковыряются в багах и костылях технологий и фреймворков — еще и делают это непринуждённо, попивая смузи и коммитя строки от курсора.
Отдельно вспоминаются коллеги, которые и вовсе уверены: UIKit — легаси, а начиная с iOS 19 вообще же все depreceted? Ну и что, что скролл где-то подлагивает? Вы что, ещё на UIKit пишете?!
Спорить с такими сложно, да и бесполезно. Действительно, есть те, кто перекладывает JSON-ы для бдуя, а кто-то успешно поддерживает SwiftUI-приложение и не знает особых хлопот.
Для меня же создание сложного и красивого UI — это настоящая дофаминовая бомба
Какие критерии хорошего UI?
- Плавные переходы состояний.
- «Физическая» природа анимаций.
- Приоритет жестов над тапами.
- Простота интеграции новых экранов и элементов.
- Высокая степень кастомизации.
- Высокая степень оптимизации и низкое энергопотребление.
Что ж, мне остается радоваться, что находятся проекты (спасибо iss), в которых разработчику сталкивается с вызовом, сделать хорошо, сделать стильно, сделать удобно.
Что крутого из UI мы реализовали в нашем последнем проекте:
- Лучший BottomSheet, еще и в Open Source.
- Навигационный стек поверх карты (child UINavigationController с пробросом жестов ниже — попробуйте на досуге).
- 9 видов transitions между экранами (3 push, 3 pop, 3 swipe pop).
- Pop swipe с любой части экрана (как в Telegram): погружаемся в UIGestureRecognizerDelegate и hitTest, а там пересекающиеся PanGestures, UIScrollView, так еще и нелинейная анимация в UIPercentDrivenInteractiveTransition.
При этом практически весь контент внутри bottom sheet-ов реализован на SwiftUI, и у этого тоже свои «приколы»: мы ломали SwiftUI как могли (для ознакомления вот бамп, бамп).
Для меня iOS-разработка — это в первую очередь про UI. Крутая архитектура, DI, многомодульность, с плохим UI не имеет смысла. И да, без UIKit пока никуда :)
П.С.
- Я намеренно не касаюсь здесь архитектуры приложения, хотя интерфейс напрямую влияет и на подкапотные части — так или иначе, от жизненного цикла приложения и экранов всё равно никуда не деться.
- Я намеренно не касаюсь коммерческой части разработки, в рамках которой прибыль > код. На канале я/мы растем, как кодеры :)
В последнее время всё чаще можно услышать, что полноценная работа с UI уже не так востребована: бигтехы вовсю используют бдуй, а компании поменьше «красят» кнопки на SwiftUI. И те, и другие время от времени ковыряются в багах и костылях технологий и фреймворков — еще и делают это непринуждённо, попивая смузи и коммитя строки от курсора.
Отдельно вспоминаются коллеги, которые и вовсе уверены: UIKit — легаси, а начиная с iOS 19 вообще же все depreceted? Ну и что, что скролл где-то подлагивает? Вы что, ещё на UIKit пишете?!
Спорить с такими сложно, да и бесполезно. Действительно, есть те, кто перекладывает JSON-ы для бдуя, а кто-то успешно поддерживает SwiftUI-приложение и не знает особых хлопот.
Для меня же создание сложного и красивого UI — это настоящая дофаминовая бомба
Какие критерии хорошего UI?
- Плавные переходы состояний.
- «Физическая» природа анимаций.
- Приоритет жестов над тапами.
- Простота интеграции новых экранов и элементов.
- Высокая степень кастомизации.
- Высокая степень оптимизации и низкое энергопотребление.
Что ж, мне остается радоваться, что находятся проекты (спасибо iss), в которых разработчику сталкивается с вызовом, сделать хорошо, сделать стильно, сделать удобно.
Что крутого из UI мы реализовали в нашем последнем проекте:
- Лучший BottomSheet, еще и в Open Source.
- Навигационный стек поверх карты (child UINavigationController с пробросом жестов ниже — попробуйте на досуге).
- 9 видов transitions между экранами (3 push, 3 pop, 3 swipe pop).
- Pop swipe с любой части экрана (как в Telegram): погружаемся в UIGestureRecognizerDelegate и hitTest, а там пересекающиеся PanGestures, UIScrollView, так еще и нелинейная анимация в UIPercentDrivenInteractiveTransition.
При этом практически весь контент внутри bottom sheet-ов реализован на SwiftUI, и у этого тоже свои «приколы»: мы ломали SwiftUI как могли (для ознакомления вот бамп, бамп).
Для меня iOS-разработка — это в первую очередь про UI. Крутая архитектура, DI, многомодульность, с плохим UI не имеет смысла. И да, без UIKit пока никуда :)
П.С.
- Я намеренно не касаюсь здесь архитектуры приложения, хотя интерфейс напрямую влияет и на подкапотные части — так или иначе, от жизненного цикла приложения и экранов всё равно никуда не деться.
- Я намеренно не касаюсь коммерческой части разработки, в рамках которой прибыль > код. На канале я/мы растем, как кодеры :)
Когда думаешь, что написал код с лучшими O(n), вспомни про сына маминой подруги, который всё решил за 5 строчек с рекурсией и с внешней переменной.
Задача с LeetCode
P.S. Оба решения бьют 100% по runtime
Задача с LeetCode
P.S. Оба решения бьют 100% по runtime
🗿7💯2🌚1
От меня бегут разработчики
на собеседованиях...
И немного о накрутке опыта
Два заголовка сразу, мощно?
Для нашего приложения Dhamer (транспортное приложение для города Мекка) мы в темпе искали нового iOS-разработчика: проект горел, времени на углубленную проверку по всем фронтам особо не было. Моей задачей было оперативно найти практика, поговорить об опыте, состыковаться и поскорей начать работать – минимум теории, just do iOS.
Кандидат №1:
Кандидат уверенно рассказывал, как на прошлом проекте за полгода полностью переделал навигацию – заменил какие-то запутанные роутеры и координаторы на (естественно) "удобные". Я начал задавать соответствующие вопросы: как устроены ссылки между контроллерами и координаторами, кто кого держит, где используются сильные, а где слабые ссылки. Но в ответ – путаница, неуверенность, противоречия, retain cycle-ы на каждом предположении, это вызвало у меня некоторую настороженность.
Перешли в лайвкодинг. Я попросил набросать базовые классы навигации в его решении, роутер бахнуть, ну или координатор (Ибо реализацию на слух я так и не понял).
Кандидат пишет одну строчку:
Думает 1 минуту… И просто выходит из Zoom. Больше на связь не вышел. "Ну, не по пути"
Кандидат №2:
Буквально следующий собес, минимум теории, обсуждение опыта. Вновь детали не помнит, да и вообще, все по классике, что обсуждать. Уже и не помню, на каком вопросе про опыт, но кандидат без слов ливает с собеседования с концами. "А может токсик на собеседующем?"
Кандидат №3:
Заряженный мидл, готовый сделать с нами новое крутое приложение. Да вот не задача, в резюме у него 3 года опыта над нашим (буквально) приложением Добро.РФ, да и в разделе компания также мы ISS, прямо в hh резюме, я даже не поверил нашему hr-у, пока сам не убедился. К слову, на этапе hr-a его и завернули, ибо с нами он не работал, но пообщаться было бы интересно. Может, поставил бы личный рекорд — три сбежавших кандидата за 1 день.
Может, история была интересней, если бы я нашел этих ребят на условном ОМ (раз такой хайп вокруг них сейчас) или движухе собес-паровозиков, но нет.
Так же не нулевая вероятность, что просто токсик на собеседующем затоксичел, а нормальные ребята пошли дальше.
UPD: По итогу мы сошлись с классными разработчиками, с которыми и сделали Dhamer, о чем в следующем посте ⬇️
на собеседованиях...
И немного о накрутке опыта
Два заголовка сразу, мощно?
Для нашего приложения Dhamer (транспортное приложение для города Мекка) мы в темпе искали нового iOS-разработчика: проект горел, времени на углубленную проверку по всем фронтам особо не было. Моей задачей было оперативно найти практика, поговорить об опыте, состыковаться и поскорей начать работать – минимум теории, just do iOS.
Кандидат №1:
Кандидат уверенно рассказывал, как на прошлом проекте за полгода полностью переделал навигацию – заменил какие-то запутанные роутеры и координаторы на (естественно) "удобные". Я начал задавать соответствующие вопросы: как устроены ссылки между контроллерами и координаторами, кто кого держит, где используются сильные, а где слабые ссылки. Но в ответ – путаница, неуверенность, противоречия, retain cycle-ы на каждом предположении, это вызвало у меня некоторую настороженность.
Перешли в лайвкодинг. Я попросил набросать базовые классы навигации в его решении, роутер бахнуть, ну или координатор (Ибо реализацию на слух я так и не понял).
Кандидат пишет одну строчку:
class Router {Думает 1 минуту… И просто выходит из Zoom. Больше на связь не вышел. "Ну, не по пути"
Кандидат №2:
Буквально следующий собес, минимум теории, обсуждение опыта. Вновь детали не помнит, да и вообще, все по классике, что обсуждать. Уже и не помню, на каком вопросе про опыт, но кандидат без слов ливает с собеседования с концами. "А может токсик на собеседующем?"
Кандидат №3:
Заряженный мидл, готовый сделать с нами новое крутое приложение. Да вот не задача, в резюме у него 3 года опыта над нашим (буквально) приложением Добро.РФ, да и в разделе компания также мы ISS, прямо в hh резюме, я даже не поверил нашему hr-у, пока сам не убедился. К слову, на этапе hr-a его и завернули, ибо с нами он не работал, но пообщаться было бы интересно. Может, поставил бы личный рекорд — три сбежавших кандидата за 1 день.
Может, история была интересней, если бы я нашел этих ребят на условном ОМ (раз такой хайп вокруг них сейчас) или движухе собес-паровозиков, но нет.
Так же не нулевая вероятность, что просто токсик на собеседующем затоксичел, а нормальные ребята пошли дальше.
UPD: По итогу мы сошлись с классными разработчиками, с которыми и сделали Dhamer, о чем в следующем посте ⬇️
50🙉10🌚3👍1💯1