В Swift 6.4 добавили три новых типа: UniqueBox, Ref и MutableRef. Раньше похожие задачи решались либо через классы с их счетчиками ссылок, либо через небезопасные указатели. Новые типы дают больше контроля над памятью и избавляют от лишних накладных расходов, оставаясь при этом в рамках стандартной модели безопасности Swift - без выхода в низкоуровневое программирование и без принудительного использования указателей.
Какая проблема была раньше:
Иногда нужно положить значение в кучу (например если оно большое или нужен стабильный адрес). Самый простой способ - завернуть значение в класс. Но у класса есть побочные эффекты: счетчик ссылок ивозможность случайно создать несколько ссылок на один объект, даже если вы этого не хотели. Получается, что вместо одного хозяина у значения появляются несколько и это создает лишнюю нагрузку на ARC.
UniqueBox - коробка с одним хозяином:
Это тип, который хранит значение в куче, но при этом имеет только одного владельца. Он не копируется автоматически, и у него нет счетчика ссылок. UniqueBox дает стабильный адрес для значения, но без балласта, который несут классы. Полезно для больших структур или когда значение должно быть доступно по стабильному адресу, но не должно иметь лишние ссылки.
Ref - доступ на чтение:
Этот тип дает временный доступ к значению для чтения. Он не владеет значением, а только заимствует его. Ref допускает множественные ссылки на одни и те же данные - читателей может быть сколько угодно. Но пока Ref жив, исходное значение нельзя изменить. Это защита от гонок на уровне компилятора.
MutableRef - доступ на запись:
В отличие от Ref, MutableRef дает эксклюзивный доступ на изменение. Сделать копию MutableRef не выйдет - доступ на изменение всегда один. Пока MutableRef активен, исходное значение заблокировано для любого доступа из других мест.
Когда нужно выделить память на куче или обеспечить стабильный адрес для значения, раньше приходилось использовать классы. Но они приносили с собой счетчик ссылок и неявную возможность множественного доступа к одним и тем же данным. Новые типы решают ту же задачу без этих накладных расходов. А для временного доступа к значению больше не нужны unsafe-указатели - Ref и MutableRef делают это на уровне компилятора, с полной типобезопасностью.
Для повседневной разработки эти типы, скорее всего, не понадобятся. Но если вы пишете производительные коллекции, работаете с буферами или создаете низкоуровневые абстракции - это важный шаг вперед. Swift продолжает развиваться в сторону большей выразительности без компромиссов по безопасности.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥7🤔3❤1
Жесты в SwiftUI выглядят просто: повесил .gesture на вью и оно реагирует. Но как только на экране появляются вложенные элементы, системные свайпы или несколько жестов на одной вью - начинается хаос. Вместо красивой анимации вы получаете неправильное поведение. Сегодня разберем три механизма, которые ставят жесты под контроль.
Маска жеста - кто вообще имеет право слышать касание:
По умолчанию жест привязан ровно к той вью, на которую вы его повесили. Если пользователь ткнул в дочернюю вью - родительская вью не реагирует. Но это не всегда удобно. Представьте, что вы хотите перетаскивать всю карточку, даже если палец попал на иконку внутри нее.
Тут вступает GestureMask. Это параметр модификатора .gesture(including:), который определяет, насколько глубоко в иерархии отслеживается ваш жест:
Кто главный на сцене - приоритеты внутри одной вью:
Бывает, что на одной вью висят два жеста. Например, тап и долгое нажатие. По умолчанию SwiftUI пытается распознать оба жеста и вы получаете двойную реакцию.
Решение - highPriorityGesture(_:including:). Этот модификатор говорит: «Этот жест важнее всех остальных на этой вью». Как только он начал распознаваться, остальные отменяются.
Как переспорить системные жесты - свайп назад и другие навязчивые привычки iOS:
Самый болезненный момент. Вы делаете кастомный горизонтальный свайп, а система перехватывает его своим - например, возвратом на предыдущий экран. Пользователь злится, потому что не может сдвинуть вашу карточку.
Модификатор .defersSystemGestures(on:) решает эту проблему. Он говорит системе: «Подожди, сначала пусть моя вью решит, что делать с этим свайпом». Если ваша вью не воспользовалась жестом (например, палец сместился меньше порога), тогда система запускает свой.
GestureMask, highPriorityGesture и defersSystemGestures - нужны только тогда, когда стандартное поведение SwiftUI не справляется. Пока на экране один жест на одну кнопку, все работает и без них. Но как только появляются вложенные вью и конкурирующие жесты, начинается хаос. Здесь главное не переборщить. Не надо лепить .all и высокие приоритеты везде подряд, иначе жесты начнут срабатывать там, где не должны, а пользователь решит, что приложение глючит.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
В этом году Apple наконец дала разработчикам прямой доступ к Apple Intelligence. Не через косвенные API, а полноценно. На WWDC26 показали новый ИИ-стек, пересобрали Xcode под работу с агентами и заодно обновили платформы.
Коротко про изменения в iOS:
iOS 27 поддерживает устройства от iPhone 11 и новее, приложения запускаются быстрее. Появились детские аккаунты с гибкими ограничениями. Siri получила отдельное приложение, больше контекста и Visual Intelligence. Apple Intelligence работает по смешанной схеме: легкие задачи решают модели прямо на устройстве, а для сложных запросов подключается Gemini в облаке. Shortcuts тоже прокачали - теперь не нужно вручную собирать цепочки действий, достаточно описать словами, что вы хотите сделать, и система сама сгенерирует готовый сценарий.
ИИ-инструменты для разработчиков:
Apple представила новые фреймворки для работы с ИИ.
Xcode 27 - агент становится частью IDE:
Самое большое изменение для ежедневной работы. Apple не просто добавила чат с ИИ, а встроила агента в полный цикл разработки - от идеи до поддержки.
Агент работает в несколько этапов:
Изменения от агента применяются только с подтверждением разработчика. Apple не пытается заменить инженера, а забирает рутину: подготовку локализации, поиск дорогих функций, регресс.
Другие изменения в Xcode 27:
WWDC 2026 задала направление: Apple окончательно открыла свой ИИ-стек разработчикам, перевела Siri на App Intents и встроила агентов в Xcode. Теперь не нужно гадать, как подключиться к Apple Intelligence - есть официальные API. Агент в Xcode не заменит разработчика, но возьмет на себя грязную работу. При этом Apple не забыла про производительность SwiftUI, работу с памятью и инструменты отладки. ИИ становится не фичей, а частью инструментария. И чем аккуратнее у вас проект, тем больше вы выиграете от нового Xcode.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12
Forwarded from Кот Денисова
Когда говорят о вайбкодинге, обычно представляют разработчика, который пишет промпты в ChatGPT и вставляет сгенерированный код, надеясь, что все заработает. Но на самом деле вайбкодинг существовал задолго до появления больших языковых моделей. Просто раньше вместо нейросети был разработчик, а вместо промпта - задача в Jira.
Как это работало всегда:
Схема знакома каждому:
Это и есть вайбкодинг. Код пишется, но никто из менеджеров его не читает. Результат оценивается по ощущениям. Просто раньше генератором кода был только разработчик, а промптом - описание задачи.
Почему это не замечали:
Когда кто-то говорит, что вайбкодинг - это несерьезно, стоит напомнить: десятилетиями вся индустрия работала именно так. Менеджер не знает, как устроен код. Он знает, как должен работать продукт. И оценивает результат по внешним признакам - работает или нет, удобно или нет, быстро или нет.
Разработчик же, получая задачу, часто не знает всех нюансов. Он пишет код, потом правит его по замечаниям, потом правит снова. Пока менеджер не скажет: «Ок, теперь то, что нужно». Это и есть итеративная разработка, в которой код часто становится черным ящиком даже для того, кто его писал.
Вайбкодинг не появился с ChatGPT. Он был всегда. Просто раньше генератором кода был разработчик, а теперь - нейросеть. И когда кто-то с презрением говорит о вайбкодинге, стоит вспомнить, что вся современная разработка во многом построена на том, что результат оценивают по внешним признакам, а не по качеству кода. Это не новость, это индустрия. Просто сейчас это стало заметно.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15💯11👀5🤔3🗿2❤1🔥1👏1
Всем привет! На WWDC26 показали то, о чем разработчики просили с момента появления AsyncImage в iOS 15 - поддержку кэширования.
Что изменилось:
Раньше AsyncImage при каждом появлении вьюхи на экране отправлял запрос в сеть, даже если вы только что загрузили данное изображение. Разработчики выкручивались своими силами: писали кастомные обертки, подключали сторонние библиотеки, вручную сохраняли изображения на диск.
В новой версии достаточно указать политику кэширования в URLRequest:
AsyncImage(request: URLRequest(
url: imageURL,
cachePolicy: .returnCacheDataElseLoad
))
Если картинка уже есть в кэше - она берется из него. Никаких дополнительных запросов.
На WWDC26 наконец-то доделали то, что должно было работать с момента появления AsyncImage. Кэширование - базовая вещь, которую в UIKit завезли еще много лет назад. Все это время разработчикам приходилось решать задачу, которая вообще не должна была существовать. Но теперь эта проблема осталась в прошлом.
Седьмой год SwiftUI, а мы все еще радуемся базовым вещам. Но прогресс есть и это здорово.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
Apple обновила гайдлайны для разработчиков и изменения довольно серьезные. Раньше компания просто отклоняла однотипные приложения из перенасыщенных категорий. Теперь политика ужесточилась: Apple может начать удалять уже существующие приложения, если они не обновляются, не улучшаются или не привлекают пользователей.
Кого коснется новая политика:
В списке категорий, которые Apple считает перегретыми - приложения для обоев, простые таймеры, звуковые эффекты, фонарики, гадания, сервисы знакомств. А также те, которые компания прямо называет низкокачественными и не требующими значительных усилий - игры для выпивки, приложения-имитации смешных звуков и подобные.
Раньше формулировки были более прямолинейными. Apple прямо перечисляла конкретные типы приложений, которые считает низкокачественными. Теперь тон стал жестче. Компания говорит о бездумном копировании существующих популярных приложений. И предупреждает: новые версии таких приложений не примут, а старые могут удалить, если они не предлагают существенно улучшенный пользовательский опыт.
Что грозит разработчикам:
Самый неприятный момент касается не только отдельных приложений. Apple предупредила, что разработчики, которые неоднократно отправляют низкокачественные или клонированные приложения, могут полностью потерять доступ к программе Apple Developer Program. То есть лишиться возможности публиковать что-либо в App Store в принципе.
При этом компания обещает, что процесс будет не внезапным. Существует система уведомлений: разработчикам сообщают, что их приложения устарели или плохо скачиваются, и дают время на улучшение. Только после этого, если ничего не меняется, приложение может быть удалено.
Apple наконец-то взялась за порядок в App Store. Удалять будут не только новые приложения-клоны, но и старые, которые годами не обновлялись и никому не нужны. Под раздачу попадают фонарики, обои, таймеры, гадания и подобные. Разработчикам, которые специализируются на таких приложениях, стоит задуматься. Повторные нарушения могут стоить не только отдельных приложений, но и всего аккаунта. С одной стороны, это ужесточение правил. С другой - давно назревшая чистка, которая пойдет на пользу и пользователям и добросовестным разработчикам.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15👀9🤔3🔥1🤯1
У каждого iOS-разработчика был момент, когда Xcode вдруг начинал вести себя странно: код не менялся, но сборка падала, SwiftUI Preview выдавал ошибку вместо интерфейса, зависимости переставали подключаться. В подобных случаях часто помогает удаление Derived Data.
Раньше приходилось вручную искать папку Derived Data, но в Xcode 27 это можно сделать прямо из выпадающего меню. Мелочь, а для тысяч разработчиков - это целое событие.
Что такое Derived Data:
Derived Data - это папка, куда Xcode складывает все, что генерирует в процессе сборки: скомпилированные модули, индексы, кэши пакетов, логи и прочие промежуточные артефакты. Это ускоряет повторные сборки.
Но у этого подхода есть обратная сторона. Если кэш расходится с актуальным состоянием проекта, Xcode начинает вести себя непредсказуемо.
Причина почти всегда одна: Xcode держится за устаревшее состояние. И единственный способ сбросить его - удалить Derived Data.
Как это работало раньше:
Самый простой способ удалить Derived Data - выполнить в терминале команду:
rm -rf ~/Library/Developer/Xcode/DerivedData
Но это удаляет кэш для всех проектов сразу. На машине, где несколько активных рабочих пространств, это означает лишние пересборки и потерю времени. Можно открыть Finder, найти папку и удалить только нужный проект. Но это каждый раз занимает лишнее время.
Что изменилось в Xcode 27:
В бете появился пункт в меню Product -> Delete Derived Data. Он удаляет кэш только для текущего проекта. Чисто, быстро, безопасно для других проектов.
Для CI и автоматизации по-прежнему есть командная строка:
xcodebuild -workspace App.xcworkspace -scheme App -derivedDataPath .build/DerivedData clean build
Но для локальной разработки новая возможность облегчает жизнь разработчиков.
Новый пункт меню Delete Derived Data в Xcode 27 - это не революция, но очень полезное дополнение. Apple наконец-то официально признала: кэш сборки - это техническая деталь, а не часть проекта. Его можно и нужно сбрасывать, когда он начинает мешать.
Но главное здесь не переборщить. Если вы удаляете Derived Data каждый день, проблема не в кэше. Он всего лишь маскирует реальную причину, которая прячется в конфигурации проекта, зависимостях или процессах сборки. Удаление кэша - это временное решение. Найдите и устраните корень проблемы, и тогда новый пункт меню понадобится вам гораздо реже.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍11❤3🗿1
Forwarded from Кот Денисова
Нашел интересную статью, в которой автор размышляет о том, что эффективнее: доделать одну задачу от начала до конца или параллелить несколько. В эпоху, когда агентов можно запускать десятками, этот вопрос становится все более актуальным.
Параллельная работа - это не всегда хорошо:
Автор честно признается: он пробовал запускать несколько агентов одновременно в разных проектах. И называет это ошибкой. Постоянное переключение между контекстами выматывает и снижает эффективность. Его текущая стратегия - работать не более чем с 1–2 проектами одновременно, причем либо близкими по смыслу, либо, наоборот, настолько разными, что они требуют разного типа энергии.
Почему не нужно хвататься за все подряд:
С появлением агентов стало слишком легко сразу же браться за любую идею или запрос. Пришел тикет в поддержку - можно сразу его закрыть, не планируя. Пришла новая идея - запустить агента, не думая. Но это отвлекает от главных целей и высасывает энергию.
Автор предупреждает: новый open-source проект или приложение - это не только радость от запуска, но и месяцы поддержки. Быстрый старт оборачивается долгим финишем, когда на последние 20% работы уходит столько же времени, сколько на первые 80.
Что должно двигать решениями:
Внутренняя мотивация. Если вы горите идеей - делайте. Но не потому, что «могу», и не только ради денег. Стоит браться за то, что вы готовы развивать месяцы или годы. Иначе оно того не стоит.
Возможностей у агентов много, но и рисков не меньше. Автор сравнивает это с Лигой чемпионов: нужны фокус, дисциплина и постоянное самосовершенствование. Не стоит распыляться. Лучше делать меньше, но доводить до конца, чем хвататься за все подряд и не завершать ничего.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🙏6❤3🔥1🤔1
@State в SwiftUI стал macro. Синтаксис не изменился, но поведение стало лучше.На WWDC26 компания Apple перевела
@State с property wrapper на macro. Для разработчиков это значит, что код останется таким же, как и раньше, но внутри все работает иначе. Основное изменение касается ленивой инициализации observable-объектов, хранящихся в @State.Что изменилось:
Раньше
@State был property wrapper. Теперь это attached macro. В документации указано:
@attached(accessor, names: named(init), named(get), named(set))
@attached(peer, names: prefixed(`_`), prefixed(__), prefixed(`$`))
macro State()
На практике синтаксис не меняется. Код, который вы писали раньше, продолжает работать. Разница только в том, как SwiftUI управляет хранением состояния.
Изменения на практике:
Самое важное - ленивая инициализация для observable-классов в
@State.Раньше, если вы писали так:
@Observable
class ViewModel {
var index = 0
init() {
print("Init")
}
}
struct MyView: View {
@State private var viewModel = ViewModel()
var body: some View {
Button("Index: \(viewModel.index)") {
viewModel.index += 1
}
}
}
Инициализатор ViewModel мог вызываться каждый раз, когда SwiftUI пересоздавал структуру вью. Даже если сам объект хранился и не терялся, его инициализация все равно выполнялась. Это приводило к лишней работе, особенно если в инициализаторе были тяжелые операции.
Теперь, с macro версией
@State, объект создается один раз - когда SwiftUI создает хранилище состояния для вью. И больше не пересоздается при каждом обновлении родителя.Когда это особенно заметно:
Это изменение особенно полезно, когда вы храните в
@State тяжелые объекты: модели с подписками, кэшами, сетевыми запросами при инициализации. Раньше приходилось использовать обходные пути - например, хранить опциональный объект и создавать его в .task.
// Раньше приходилось делать так, чтобы избежать повторной инициализации
@State private var viewModel: ViewModel?
var body: some View {
MyView(viewModel: viewModel)
.task {
viewModel = ViewModel()
}
}
Теперь это больше не нужно. Можно просто писать:
@State private var viewModel = ViewModel()
И быть уверенным, что объект создастся только один раз.
Apple сделала
@State macro, чтобы улучшить производительность в типичных сценариях. Синтаксис остался прежним, код не требует изменений, но observable-объекты в @State теперь инициализируются один раз. Это избавляет от лишнего кода и делает поведение более предсказуемым.Переход на macro для такого базового механизма - это важный сигнал. Apple уверена в своей macro-системе и готова переносить на нее ключевые API. А для разработчиков это просто означает, что SwiftUI становится чуть более эффективным и предсказуемым.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15
Telegram для iOS - это технически сложный продукт. В кодовой базе 2.1 миллиона строк, 700+ модулей, 86% написано на Swift. Проекту больше 13 лет. Но при этом приложение регулярно лагает на флагманских устройствах, открывает по несколько дублей окон и годами крешится при редактировании изображений.
Почему так происходит, если код считается одним из лучших в индустрии?
Ответ звучит неожиданно: разработчики пишут на Swift, но мыслят в парадигме объектно-ориентированного программирования, как будто работают с Java. А Swift для этого не предназначен.
В чем проблема ООП в Swift:
Swift - это язык, архитектура которого заточена под Protocol Oriented Programming. Компилятор умеет оптимизировать код, написанный в этой парадигме: убирать лишние вызовы, встраивать функции, специализировать дженерики. Все это дает производительность, близкую к C.
Но когда разработчики используют классы и иерархии наследования так, как это делают в Java, компилятор не может применить эти оптимизации. Каждый вызов метода идет через виртуальную таблицу, а это в 3-4 раза медленнее прямого вызова.
Цена ООП-подхода в Swift:
На небольших проектах разница незаметна. Но на масштабах Telegram она становится критичной. По оценкам, из-за ООП-подхода приложение теряет от 10% до 25% производительности CPU. Лишние 20-30% памяти уходят на аллокации в куче там, где можно было использовать структуры.
Фреймрейт в ключевых пользовательских сценариях мог бы быть выше на треть. А количество крашей сократилось бы просто потому, что исчезла бы часть неожиданных мутаций общего состояния, которые неизбежны при работе с классами.
Типичные симптомы ООП-мышления в коде Telegram:
В кодовой базе есть классы на 11 тысяч строк. Например, ChatControllerImpl. Это прямой результат парадигмы, которая поощряет концентрацию логики в одном месте.
Постфикс Impl - еще один характерный признак. Это наследие Java 90-х, где один интерфейс равнялся одной реализации. В Swift протокол - это описание способности, а не место в иерархии. Когда у протокола есть ровно одна реализация с суффиксом Impl, это почти всегда симптом: протокол создан по привычке, а не осознанно.
Ссылочный хаос - еще одна проблема. Классы передаются по ссылке и два модуля могут держать один объект, незаметно меняя его состояние. В POP со структурами семантика копирования явная, без неожиданных сайд-эффектов.
Telegram - это огромный и сложный проект. Его разработчики проделали колоссальную работу. Но архитектурный подход, выбранный много лет назад, сегодня тормозит приложение. ООП в Swift - это не просто устаревший стиль. Это потерянная производительность.
Swift дает возможность писать почти так же быстро, как на C, но только если использовать его правильно. Protocol Oriented Programming - это не просто модный термин, а путь к реальной оптимизации. И чем крупнее проект, тем заметнее разница.
Telegram мог бы работать быстрее, потреблять меньше памяти и реже падать. Для этого не нужно переписывать все с нуля. Достаточно начать мыслить в парадигме языка, а не тащить за собой привычки из прошлого.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍21❤13🗿5
Forwarded from Flutter & Dart | Мобильный трудоголик
Привет. В последнее время все только и говорят о разработке с помощью ИИ-агентов. Кто-то в восторге, кто-то скептичен. Но мало кто задумывается, как выбор технологий влияет на эффективность работы с LLM. Майкл Томсен, инженер из команды Flutter, выпустил разбор на эту тему. Он объясняет, почему мультиплатформенная архитектура Flutter дает неожиданные преимущества в эпоху агентской разработки. Основная мысль простая: одна кодовая база вместо трех - это не только удобно для людей, но и критически важно при работе с ИИ.
В чем была ценность Flutter раньше:
Еще до эры агентов Flutter решал классическую проблему: вместо трех команд (iOS, Android, веб) можно иметь одну, которая пишет код на Dart и запускает его везде. От 95% до 99% кода в реальных проектах переиспользуется. Это давало:
Что изменилось с приходом ИИ-агентов:
Когда разработкой занимаются агенты, нативный подход (Swift под iOS, Kotlin под Android, JavaScript под веб) начинает пробуксовывать. Агенту нужно сгенерировать одну и ту же логику трижды, на разных языках, с разными нюансами. Это приводит к трем проблемам.
Во-первых, растет потребление токенов. Каждая генерация и каждое исправление умножаются на количество платформ. Во-вторых, возникают отличия в реализации между платформами. Агент может начать галлюцинировать и на одной платформе фича будет работать не так, как на другой. В-третьих, сложнее отлаживать и поддерживать.
Почему Flutter решает эти проблемы:
Flutter предлагает единую кодовую базу на Dart. Агент пишет все один раз, а не три. Токенов тратится меньше, генерация быстрее, логика не расходится.
Кроме того, у Flutter есть архитектурные особенности, которые делают его удобным для агентской разработки. Сильная статическая типизация Dart работает как система самопроверки: если агент сгенерировал не то, компилятор сразу укажет на ошибку. Это снижает количество галлюцинаций.
Flutter был удобен для команд, которые хотят поддерживать несколько платформ без тройного объема работы. В эпоху ИИ-агентов этот подход становится еще более актуальным. Меньше кода - меньше токенов. Одна логика - нет платформенного различия. Сильная типизация - меньше галлюцинаций. Горячая перезагрузка - быстрая проверка.
Для агентской разработки Flutter выглядит прагматичным выбором.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤7🗿4🤔2🫡2🔥1
Раньше в SwiftUI была четкая граница. Если вы хотели реализовать перетаскивание с помощью стандартных средств ваш выбор был List с его onMove. Для LazyVStack, HStack, Grid или кастомных макетов приходилось писать решение вручную. Не было никакого готового функционала для этого.
В iOS 27 это изменилось. SwiftUI получил новый API: reorderable() и reorderContainer. Теперь любой контейнер может поддерживать перетаскивание и перестановку элементов.
Как это работает:
Новый API состоит из двух частей. Первая - reorderable(). Она ставится на динамический контент, который может участвовать в перетаскивании. Чаще всего это ForEach.
ForEach(items) { item in
ItemRow(item: item)
}
.reorderable()
Вторая - reorderContainer(for:). Она определяет родительский контейнер, внутри которого разрешена перестановка.
.reorderContainer(for: Item.self) { difference in
items.apply(difference: difference)
}
Этот подход хорошо ложится в логику SwiftUI. Поведение элемента живет с динамическим контентом. Границы взаимодействия - с контейнером. Разделение четкое и предсказуемое.
Простой пример:
Допустим, у вас есть плейлист в виде кастомного вертикального списка. Раньше пришлось бы реализовывать перетаскивание вручную. Теперь это всего лишь несколько строк кода:
struct PlaylistView: View {
@State private var items: [PlaylistItem] = [...]
var body: some View {
ScrollView {
LazyVStack(alignment: .leading, spacing: 8 ) {
ForEach(items) { item in
Text(item.title)
.padding()
.background(.thinMaterial)
.clipShape(RoundedRectangle(cornerRadius: 12))
}
.reorderable()
}
.padding()
.reorderContainer(for: PlaylistItem.self) { difference in
items.apply(difference: difference)
}
}
}
}
reorderable() ставится на ForEach, reorderContainer - на LazyVStack. SwiftUI берет на себя всю логику жестов, а вы только обновляете данные в замыкании.
Модель данных остается за вами:
API не сохраняет новый порядок автоматически. Он дает ReorderDifference описание того, что и куда переместили. А вы уже сами решаете, как применить это к модели.
.reorderContainer(for: PlaylistItem.self) { difference in
items.apply(difference: difference)
}
Можно применить apply(difference:) к массиву. А можно обработать вручную, если логика сложнее: проверка прав на перемещение, обновление sortIndex в базе данных, синхронизация с сервером. API не навязывает конкретный способ.
Управление доступностью перетаскивания:
У reorderContainer есть параметр isEnabled. Это удобный способ включать и выключать перестановку без условной логики на уровне жестов.
.reorderContainer(
for: PlaylistItem.self,
isEnabled: isEditing
) { difference in
items.apply(difference: difference)
}
Как только isEditing становится true, reorder активируется. Контейнер по-прежнему управляет областью взаимодействия, а состояние решает, активно ли оно.
SwiftUI в iOS 27 наконец-то избавился от ограничения, которое долго раздражало разработчиков. Теперь перетаскивание работает в любом контейнере, а не только в List. Можно использовать reorderable() и reorderContainer с LazyVStack, HStack, Grid и кастомными макетами. API оставляет контроль над моделью данных за разработчиком, что важно для сложных приложений. И поддерживает перемещение между разными коллекциями.
Для пользователей это означает привычное поведение перетаскивания в любых интерфейсах. Для разработчиков - меньше ручного кода и более предсказуемый API.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍12❤4👀1
Вместе с выходом новой версии Xcode компания Apple сделала давно ожидаемый шаг - полностью отказалась от поддержки процессоров Intel. Xcode 27 теперь работает исключительно на процессорах Apple Silicon. Для многих разработчиков это не стало неожиданностью, но все равно требует внимания.
Почему Apple отказалась от Intel:
Переход на собственные процессоры Apple начался еще в 2020 году и с тех пор компания последовательно двигалась к полному отказу от Intel. Причин несколько. Процессоры Apple Silicon обеспечивают значительно лучшую производительность на ватт - они быстрее и при этом потребляют меньше энергии. Это особенно заметно при работе с тяжелыми задачами вроде компиляции крупных проектов.
Кроме того, унификация архитектуры позволяет Apple лучше оптимизировать связку железа и софта. В отличие от Intel, где приходилось подстраиваться под чужие процессоры, теперь вся экосистема работает на единой архитектуре. Это дает прирост производительности не только в Xcode, но и во всей системе в целом.
Когда я впервые перешел с MacBook с процессором Intel на MacBook с M1, я был в полном восторге. Ноутбук работал бесшумно, совершенно не грел колени, не включал вентиляторы при работе и работал без подзарядки значительно дольше. При этом он справлялся с компиляцией проектов в разы быстрее. Разница была заметна с первых минут и стало очевидно, что процессоры Apple - это не просто переход от стороннего производителя чипов к собственному производству, а совершенно иной подход к тому, как должен работать современный ноутбук.
Что изменилось в Xcode 27:
Помимо изменения системных требований, Xcode 27 получил несколько заметных улучшений. Проекты теперь открываются быстрее - это результат оптимизаций под Apple Silicon и изменений во внутренней архитектуре IDE.
Настройки синхронизируются через iCloud, что удобно для тех, кто работает на нескольких устройствах. Можно не тратить время на перенос конфигураций между машинами.
Панель инструментов стала полностью настраиваемой. Разработчики могут перестраивать ее под свои рабочие процессы, убирая лишние элементы и добавляя нужные.
Появилась поддержка тем, которые меняют оформление не только редактора кода, но и всего приложения. Это мелочь, но визуально приятная.
Самое заметное изменение - Device Hub, который заменил привычный Simulator. Теперь симуляторы и физические устройства собраны в одном окне. Управление стало удобнее, а переключение между устройствами быстрее.
Apple окончательно завершила переход на собственную архитектуру в инструментах разработки. Xcode 27 - еще один шаг в этом направлении. Для разработчиков это означает более быструю работу, лучшее энергопотребление и доступ к новым возможностям IDE. Но и обязательство обновить железо тем, кто все еще использует технику на Intel.
Переход на Apple Silicon оказался не просто маркетинговым ходом. Разница в производительности и комфорте работы действительно заметна. И Xcode 27 - еще одно подтверждение того, что будущее экосистемы Apple - за собственными процессорами.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17❤9🤯4🔥1👀1
Swift Package Index, сервис, который используют тысячи Swift-разработчиков для поиска пакетов и проверки их совместимости, официально стал частью Apple. Сделка состоялась, но условия не раскрываются. В блоге проекта появилась запись о том, что Swift Package Index присоединился к Apple.
Что такое Swift Package Index:
Это поисковая система и индексатор метаданных для Swift-пакетов с открытым исходным кодом. Разработчики используют Swift Package Index, чтобы находить пакеты, проверять их совместимость с платформами и версиями Swift, смотреть документацию, оценивать активность авторов и состояние пакета в целом.
Одна из главных фишек сервиса - автоматическое тестирование каждого пакета на поддерживаемых платформах и версиях Swift. Это дает уверенность перед тем, как добавить зависимость в проект. Сейчас в индексе уже больше 10 тысяч пакетов. Только за прошлый год было обработано более 3,5 миллиона билдов на совместимость.
Что изменится для разработчиков прямо сейчас:
В официальном сообщении подчеркивают: для разработчиков и авторов пакетов ничего не меняется. Пакеты индексируются как раньше, документация хостится как раньше. Проект остается с открытым исходным кодом. Инженеры Apple будут участвовать в развитии вместе с сообществом.
Так что если вы пользуетесь Swift Package Index сегодня - завтра все будет работать точно так же.
Что изменится в будущем:
Самое интересное - в планах. В сообщении прямо называют направления, над которыми будут работать: подписание пакетов, идентификация авторов, безопасность и надежность экосистемы.
Это может означать, что Swift Package Index постепенно превратится из удобного поисковика в более официальный слой доверия вокруг Swift-зависимостей. Возможен сценарий, когда Xcode позволит искать и добавлять пакеты прямо из IDE, без необходимости вручную вставлять URL репозитория. Управление зависимостями станет проще и удобнее.
Присоединение Swift Package Index к Apple - это хорошая новость для Swift-сообщества. Сервис получит больше ресурсов для развития, оставаясь при этом открытым проектом. А главное - Apple прямо говорит о планах улучшить безопасность и надежность экосистемы пакетов.
Для разработчиков это значит, что в будущем управление зависимостями станет проще, а доверие к пакетам - выше. Пока все остается как есть. Но следующие месяцы должны показать, каким будет новый Swift Package Index под крылом у Apple.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15
На WWDC26 компания Apple показала обновления и для UIKit. Не радикальные, не революционные, но заметные. И главное - они подтверждают: UIKit никуда не уходит. SwiftUI будет на первых ролях, это очевидно. Но UIKit остается надежным фундаментом и Apple продолжает его развивать.
В этом году изменений не так много и почти ничего из добавленного не выглядит эффектно. Но в каком-то смысле это справедливо и для iOS 27 в целом. Основной фокус - Siri и ИИ. А UIKit получил точечные улучшения, которые делают его более гибким и адаптивным.
Навигация и кнопки:
Большая часть изменений коснулась навигационной панели и ее элементов. И здесь явно прослеживается одна тенденция: адаптация под разные размеры экранов и форм-факторы. Интересно, с чем бы это могло быть связано?
Каждый контроллер теперь может влиять на то, будет ли его навигационная панель уменьшаться при прокрутке. Это полезно для экранов с большим количеством контента.
Пример использования:
navigationItem.barMinimizeBehavior = .onScrollDown
navigationItem.barMinimizationSafeAreaAdjustment = .enabled
Также появилась возможность ранжировать кнопки в панели. UIKit теперь знает, какие действия важнее сохранять на экране, когда места становится мало. Адаптивные интерфейсы - iPad, Stage Manager, изменяемые окна - везде, где ширина панели постоянно меняется, это становится критичным.
Пример использования:
saveItem.visibilityPriority = .high
shareItem.visibilityPriority = .standard
Еще одно небольшое, но полезное изменение - возможность убрать стандартный отступ у кнопки на панели инструментов:
colorItem.isPaddingRemoved = true
Сцены, окна и ориентация:
Apple продолжает двигаться в сторону многооконных приложений с изменяемыми размерами. И здесь тоже есть подсказки: все это особенно актуально для грядущих складных устройств.
Теперь можно запросить системное подтверждение перед закрытием сцены. Это полезно для приложений работы с документами, редакторов текста и инструментов для работы, где закрытие окна может стереть несохраненные данные.
Пример использования:
windowScene.closureConfirmation = UISceneClosureConfirmation(
title: “Несохраненные данные",
message: "Закрыть несохраненные данные?",
actions: [...]
)
Из интересного, еще появилась возможность регистрировать неинтерактивную сцену для внешнего дисплея. Вспомогательные экраны для презентаций, панели мониторинга, справочные представления - все это теперь проще интегрировать.
И самое важное - каждая сцена теперь может объявлять собственный набор поддерживаемых ориентаций. Видео-сцена может оставаться горизонтальной, а сцена для просмотра или редактирования поворачиваться как угодно.
Пример использования:
func supportedInterfaceOrientations(
for windowScene: UIWindowScene
) -> UIInterfaceOrientationMask {
.landscape
}
Таббары и сайдбары:
Таббары и сайдбары получили несколько настроек для управления тем, что показывать и чему отдавать главный акцент.
Теперь можно визуально выделить одну вкладку, которая важнее остальных. Подходит для ключевых действий вроде написания сообщения, поиска, корзины или создания нового элемента.
Пример использования:
tabBarController.prominentTabIdentifier = "compose"
Также появилась возможность указать предпочтительное размещение: сайдбар или таббар. Приложения, ориентированные на сайдбар, теперь могут аккуратно сворачиваться в таббар на компактных устройствах или в сценариях со складными экранами.
Пример использования:
tabBarController.mode = .tabSidebar
tabBarController.sidebar.preferredPlacement = .sidebar
Еще несколько лет назад можно было задаваться вопросом, не собирается ли Apple отказаться от поддержки UIKit. Сейчас это выглядит маловероятным. SwiftUI становится лучше каждый год и будет на первом место, но UIKit остается надежным фреймворком и продолжает быть важной частью экосистемы.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Кот Денисова
Средний срок работы разработчика в крупной ИТ-компании - 2–3 года. Чтобы вырастить из джуна самостоятельного мидла, нужно 2–4 года. От мидла до сеньора - еще 3–5 лет. Итого: чтобы получить сеньора из новичка, требуется 5–9 лет. Это просто арифметика.
Если индустрия сокращает найм джунов три года подряд (2024, 2025, 2026), эффект проявится не сразу. Он ударит в 2029–2033 годах, когда иссякнет поток мидлов, и в 2032–2036 годах, когда иссякнут сеньоры. Компании, которые сейчас экономят на джунах, будут биться за оставшихся опытных инженеров и жаловаться на дефицит талантов. Но винить будут кого угодно, только не себя.
Почему это происходит:
Логика проста и на первый взгляд убедительна. Джуниор стоит компании 90-120 тысяч в месяц и требует 3-6 месяцев менторства, прежде чем начнет приносить реальную пользу. GitHub Copilot - 10 долларов в месяц. Claude Code и Cursor - 20 долларов. Сеньор с ИИ делает всю ту работу, ради которой раньше держали штат новичков. Марк Бениофф объявил, что компания Salesforce не будет нанимать новых инженеров, сославшись на ИИ. Сундар Пичаи из Google заявил, что ИИ позволяет делать больше тем же составом. Многие компании отказываются от джунов в пользу ИИ.
Но проблема глубже:
Джуны - это не просто расходы. Они тестируют документацию. Если новичок не может поднять окружение по README, значит, онбординг сломан. ИИ такого сигнала не даст. Джуны задают неудобные вопросы, которые вскрывают скрытые допущения. «Почему мы вообще делаем это так?» - это вопрос, который чаще всего задают те, кто еще не привык к костылям кодовой базы. И самое главное, джуны - это конвейер будущих сеньоров. Сокращение найма сегодня - это пустота на старших позициях через 5–9 лет.
А что с ИИ?
Компании заявляют о 25-процентном росте производительности от ИИ. Реальные измерения показывают около 2% на каждые 25% внедрения. Разрыв между ожиданиями и реальностью - примерно 12-кратный. ИИ пишет шаблонный код на 55% быстрее. Но шаблонный код никогда не был узким местом.
Спираль выгорания сеньоров:
Без джунов сеньоры делают больше, работают дольше и выгорают быстрее. Они ревьюят ИИ-код и принимают больше решений. Ирония: компании сократили джунов, чтобы снизить менторскую нагрузку на сеньоров. Но эту нагрузку заменила еще более тяжелая работа по проверке ИИ-кода. Джуны хотя бы учатся и становятся полезнее. ИИ-код не улучшается - вы вечно ревьюите одни и те же ошибки.
Проблема не в том, что ИИ пишет код лучше джунов. Проблема в том, что компании перестали смотреть дальше следующего квартала. Сокращая найм начинающих сегодня, они экономят на зарплатах и менторстве. Но через пять лет эти же компании будут жаловаться на критическую нехватку кадров, платить бешеные деньги за перекупленных сеньоров и удивляться, почему рынок пуст.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍24💯16❤5🤯5👀2🔥1
Apple выпустила Container 1.0 - собственный инструмент для работы с Linux-контейнерами на macOS. Это не просто очередной фреймворк. Это попытка Apple изменить подход к изоляции, управлению средами и рабочим процессам разработчиков. Давайте разберем, что это такое и почему важно.
Что такое Apple Container:
Apple Container - это CLI-инструмент для создания и запуска Linux-контейнеров в виде легких виртуальных машин на Mac. Он написан на Swift и оптимизирован для Apple Silicon.
В отличие от Docker, где все контейнеры работают внутри одной общей Linux-виртуальной машины, Apple Container запускает для каждого контейнера отдельную легкую виртуальную машину. Это дает аппаратный уровень изоляции для каждого контейнера и обеспечивает более высокую безопасность.
Основные характеристики:
Container Machine - новая концепция:
В версии 1.0 появилась концепция Container Machine - контейнеров с сохранением состояния. Это позволяет останавливать и перезапускать контейнеры, сохраняя файловую систему внутри . По сути, они работают как обычные виртуальные машины, но с легкостью и скоростью контейнеров.
Пока есть ограничения: память, выделенная контейнеру, не возвращается обратно в систему и освобождается только при перезапуске . В остальном инструмент выглядит зрелым.
Почему это важно для iOS-разработчиков:
Казалось бы, iOS-разработчикам не нужны контейнеры. Но современная разработка все чаще требует локальных бэкендов - базы данных, сервисов аутентификации, API для тестирования . С Apple Container можно поднять все эти зависимости локально, не засоряя систему и не беспокоясь о совместимости версий.
Что можно делать с Apple Container уже сейчас:
Все это без необходимости использования Docker и оплаты лицензии.
Apple Container - это не просто клон Docker. Это попытка Apple переосмыслить контейнеризацию на macOS, сделав ее нативной и безопасной. Контейнеры запускаются в отдельных виртуальных машинах, что дает лучшую изоляцию. Они написаны на Swift и интегрируются с системой. Технология еще на раннем этапе, но у нее большой потенциал.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18🔥8❤4🙏1
Apple добавила в iOS и iPadOS 27 режим восстановления, который работает прямо на устройстве. Раньше при серьезных сбоях или неудачном обновлении нужно было подключать iPhone к компьютеру, переводить в специальный режим и восстанавливать прошивку через Mac или ПК. Теперь часть проблем можно решить прямо на устройстве, без помощи компьютера.
Как это работает:
Все достаточно просто. Выключаете устройство. Затем удерживаете боковую кнопку. После появления логотипа Apple продолжаете держать кнопку. Система показывает индикатор загрузки и переходит в меню дополнительных инструментов.
Что доступно в меню:
В режиме восстановления доступны несколько опций:
Также отображается заряд аккумулятора и статус подключения к известным Wi-Fi сетям.
Почему это важно:
Раньше при серьезных проблемах iPhone превращался в кирпич и нужно было искать кабель, компьютер и использовать iTunes или Finder. Теперь достаточно запустить новый режим восстановления на iPhone и выбрать нужный инструментами.
Особенно ценно это для тех, у кого нет компьютера или ноутбука. Ведь таких большинство пользователей iPhone. Раньше им при серьезном сбое приходилось бежать к знакомым или в сервис. Теперь все решается на месте.
Режим диагностики - отдельный плюс. Можно проверить устройство на аппаратные проблемы без посторонних приложений. Это экономит время и нервы.
Wi-Fi в режиме восстановления - умное решение. Устройство может скачать свежую прошивку прямо из меню восстановления. Не нужно качать IPSW на компьютер и заливать через кабель.
Это одна из незаметных функций, которые делают iOS надежнее. Apple постепенно убирает зависимость от компьютера и это правильный путь.
Теперь даже если система не загружается, вы не остаетесь один на один с проблемой. Устройство само предлагает инструменты для спасения. Это шаг в сторону большей автономности и удобства для пользователей. Особенно для тех, у кого нет компьютера под рукой.
В Android подобные возможности тоже есть, но они более ограничены и часто требуют дополнительных действий или знания специфических комбинаций кнопок для разных производителей. Apple снова показывает, как делать восстановление простым и доступным для обычного пользователя.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥8❤4🙏2👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Раньше, чтобы скрыть или показать навигационную панель при скролле, нужно было отслеживать позицию прокрутки вручную. Слушать изменения scroll offset, вычислять направление, анимировать изменение состояния навбара. Это работало, но требовало лишнего кода и было не всегда предсказуемо.
В iOS 27 появился новый модификатор, который делает все это стандартными средствами, без костылей.
Как это работает:
Модификатор toolbarMinimizeBehavior позволяет указать, как должна вести себя панель инструментов при прокрутке содержимого.
ScrollView {
ContentView()
}
.toolbarMinimizeBehavior(.onScrollDown, for: .navigationBar)Когда пользователь скроллит вниз, навигационная панель минимизируется, освобождая больше места для контента. Все, что нужно было сделать разработчику - добавить одну строчку кода. Без UIScrollViewDelegate, без GeometryReader, без onPreferenceChange.
Когда это может пригодиться:
Такой подход полезен для экранов, где контент - главное. Ленты новостей, каталоги товаров, библиотеки, результаты поиска, длинные списки с большим количеством элементов. Все, где пользователь тратит много времени на скроллинг, а навигационная панель только занимает полезное пространство.
Что важно знать:
При минимизации навбара безопасная область (safe area) автоматически корректируется. Контент не перекрывается, отступы сохраняются. Это поведение работает по умолчанию и в большинстве случаев его достаточно.
Если нужен более тонкий контроль, есть toolbarMinimizationSafeAreaAdjustment, который позволяет управлять этим поведением. Особенно это может пригодиться на экранах с кастомными заголовками или сложной версткой.
toolbarMinimizeBehavior - это небольшой, но полезный модификатор, который решает задачу, которую раньше решали кучей костылей. Он не требует отслеживания scroll offset, не ломается при изменении ориентации и работает предсказуемо.
SwiftUI продолжает закрывать пробелы, которые раньше заставляли разработчиков писать лишний код. Это один из таких случаев. Просто и без боли.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17
Forwarded from Кот Денисова
Компании Anthropic и Microsoft ужесточают условия для бизнес-клиентов: фиксированные подписки уходят в прошлое, компаниям придется платить за реально потребленные токены. Индивидуальных пользователей пока не трогают, но тренд очевиден: дешевые токены заканчиваются. И тот, кто сейчас не пользуется возможностью учиться на топовых моделях за копейки, рискует оказаться в сильном отставании.
Как меняется рынок:
Раньше компании массово покупали подписки Claude за 200 долларов на каждого сотрудника и радовались. Теперь Anthropic переводит корпоративных клиентов на оплату по факту. Microsoft сделала то же самое. В отчетах стартапов Кремниевой долины видны траты в сотни тысяч долларов в месяц на ИИ-подписки. При этом Дарио Амадей из Anthropic признал: пользователи Max-подписки тратят токенов на 5000 долларов, платя при этом всего 200.
Почему это важно для новичков:
Пока есть возможность пользоваться топовыми моделями за 20-200 долларов - ее нужно использовать. Тренировать навыки, нарабатывать опыт, учиться правильно формулировать запросы. Потому что когда цены вырастут, учиться будет поздно - разрыв между теми, кто уже умеет эффективно работать с ИИ, и теми, кто только начинает, станет критическим.
Если вы сейчас пользуетесь бесплатными или дешевыми версиями ИИ - вы делаете ошибку. Сейчас уникальный момент, когда можно получить доступ к топовым технологиям за копейки. Упустите его - будете догонять тех, кто успел. И догонять будет сложно, потому что разрыв в навыках нарастает экспоненциально. Платите пока можно и тренируйтесь, пока есть время.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13💯8❤6🤔2🤯1👀1
В Swift есть встроенные механизмы, которые делают отладку быстрее и чище. Они не требуют подключения дебаггера, не заставляют вас ставить брейкпоинты и часами шагать по каждой строчке кода. Сеньоры используют их постоянно, а джуны часто проходят мимо, потому что привыкли к одному только принту. Давайте разберем пять таких инструментов.
assert - ловим логические ошибки на этапе разработки:
assert проверяет условие и, если оно ложно, останавливает выполнение программы. Работает только в дебаг-сборке - в релизе эти проверки просто вырезаются.
Допустим, вы пишете функцию, которая вычисляет квадрат числа. Вы точно знаете, что ноль сюда передавать нельзя. Добавляете проверку:
func calculateSquare(x: Double) -> Double {
assert(x != 0, "Число не может быть нулем")
return x * x
}
Если кто-то случайно вызовет calculateSquare(x: 0), приложение упадет с сообщением об ошибке. И вы сразу увидите проблему, а не будете полдня выяснять, почему результат не сошелся.
Важный момент: assert не подходит для проверки пользовательского ввода. Его задача - ловить ошибки в вашей логике, те самые ситуации, которые не могут произойти, но почему-то происходят.
file, function, line - добавляем контекст в логи:
Обычный print выводит просто сообщение. Чтобы понять, откуда оно пришло, приходится лезть в код. Есть способ лучше - использовать литералы
#file, #function и #line. Они подставляют имя файла, функции и номер строки прямо во время компиляции.Оборачиваем print в удобную функцию:
func log(_ message: String,
file: String = #file,
function: String = #function,
line: Int = #line) {
print("[\(file):\(line)] \(function) - \(message)")
}
Теперь вместо print("Ошибка") пишем log("Ошибка"), и получаем в консоли что-то вроде:
[ViewController.swift:42] updateUser() - Ошибка
Никакого копирования имен функций и номеров строк руками. Все само подставляется.
CustomDebugStringConvertible - настраиваем вывод своих типов:
Когда вы пишете print(user), Swift выводит стандартное представление: User(name: “Artem”, age: 33, role: "Admin"). Для маленьких структур ок, но когда полей много - в консоли каша.
Протокол CustomDebugStringConvertible позволяет переопределить этот вывод:
extension User: CustomDebugStringConvertible {
var debugDescription: String {
"👤 \(name), роль: \(role)"
}
}
Теперь print(user) покажет: "👤 Artem, роль: Admin". Коротко и понятно. Часто используемые типы данных можно снабдить такими расширениями - и отладка станет намного приятнее.
Сеньоры используют эти пять инструментов не потому, что они умнее, а потому что так быстрее. assert, литералы
#file, #function и #line, протокол CustomDebugStringConvertible, тип Mirror и функция dump встроены в стандартную библиотеку Swift и доступны без подключения дополнительных зависимостей. Перестаньте терять часы на однообразный print и просто начните применять то, что уже есть под рукой. Отладка станет чище, а логи - понятнее.Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17❤11