Знаете, я думаю, Вы победили нас. Лично я сдаюсь. Я парализован и раздавлен Вашей неоспоримой логикой и богатым, всеобъемлющим жизненным опытом.
Пойду съезжу в аэропорт и продам мак кому-нибудь в очереди на регистрацию на рейс на Гоа. Потом куплю ThinkPad и прикреплю его к рабочему столу на гвозди. Не знаю, зачем мне второй ThinkPad, но надо – значит надо.
Потрясающие колонки ноутбука – это действительно оксюморон. Но "потрясающие колонки для ноутбука" – вполне себе применимо. Можно посмотреть много обзоров и убедиться, что с релиза M1 Pro-серии несколько лет макбуки по качеству звука были недосягаемы. Только где-то в последний год стали появляться ноутбуки на Windows, которые сопоставимы. Но при этом если сравнить мой M1 Pro MacBook Pro 16" и средней паршивости колонку даже от JBL, то мак будет бледно выглядеть. Я это знаю, потому что я так делал :) Я уж молчу про более качественные портативные колонки или, тем более, про мою средней руки стереосистему от Yamaha. Которая даже не напольная.
Но при этом сравнивать мак по качеству звука нужно всё-таки с сопоставимыми устройствами. То есть с другими ноутбуками, а не с напольниками. И не с портативными колонками. Какой смысл сравнивать с напольниками, если напольники можно подключить к маку? Или к ноутбуку на Windows? Если уж на то пошло, то Ваши напольники ужасны, потому что я был в IMAX, и, уверен, звук там был лучше. И, следуя Вашей логике, сравнивать напольники с звуковой системой IMAX вполне оправданно, ведь и то, и другое – источник звука.
Хотя в целом мы с Вами, конечно, во взглядах сходимся)
У маковского тачпада, помимо, собственно, его качества, киллер фича в том, что жесты все поддерживаются на уровне системы, и они везде всегда одинаковы. Это даёт разработчикам приложений стимул их интегрировать. На Windows очень долго с жестами был вообще полный зоопарк. Сейчас какие-то жесты вроде pinch-to-zoom и скролла двумя пальцами устаканились, но это капля в море, и я не знаю, как обстоят дела с более сложными.
Из-за этого, даже если на Windows сделать отличный тачпад, с крутыми жестами и т.д., пользоваться им можно будет в полутора приложениях, которые поддерживают эти жесты. Будем надеяться, ситуация будет меняться к лучшему.
Ну, это мимо. У меня хороший домашний компьютер на Windows, неплохая файлохранилка на Linux, а мак мой стоит далеко не 450к. Ну и дома есть ещё ноутбук на Windows стоимостью плюс-минус как мой мак. Хороший, сам выбирал.
Просто ещё лет 10-15 назад, когда я впервые пробовал macOS (точнее, MacOS X в те времена), мне казалось, что было бы странно, если бы система, которая имеет наследие с 1984 года и построена на собственной философии, работала бы так же, как Windows. И я не говорю "лучше" или "хуже", я говорю "так же" (или "также", никогда не запомню правила для этого слова). Поэтому я старался подходить к системе со свежим взглядом, не пытаясь прогнуть её под свои виндовые привычки, а стараясь разобраться, почему что-либо сделано тем или иным образом. Например, сворачивание окон в Windows и macOS – это совершенно разные операции, и это многих сбивает с толку. Ближайший эквивалент сворачивания окна из Windows – это закрытие окна на macOS. А сворачивание окна – это "откладывание ненужного сейчас окна на потом", для чего на Windows нет отдельной операции. Если использовать сворачивание окон на macOS как сворачивание на Windows, жизнь будет полна страданий, потому что оно для этого не приспособлено. "Развернуть" на macOS не разворачивает на весь экран, потому что замысел в том, что эта кнопка увеличивает размер окна так, чтобы вместить весь его контент. Мне больше нравится подход Windows, поэтому у меня стоит Rectangle, и я разворачиваю окна через него. Рабочий стол на macOS исторически предполагалось использовать именно как реальный рабочий стол – выносишь на него то, с чем сейчас работаешь и потом убираешь оттуда. Эта концепция растёт ещё из Xerox PARC. Использую я его таким образом? На самом деле, скорее нет. Но и как на Windows тоже не использую. В итоге получается что-то посередине. Вся система полна таких моментов, и если принять, что macOS – это своя самобытная система, которая не обязана соответствовать ожиданиям, навязанным другими системами (также как Windows не обязана соответствовать ожиданиям, навязанным macOS), то многие вещи обретают смысл, а порой начинают помогать, а не мешать, т.к. понимание причины, по которой что-то сделано, зачастую даёт возможность понять, какие преимущества это даёт, и как этим можно пользоваться себе во благо,
Ну и вот диалог открытия / сохранения. Он работает не так, как в Windows, и у этого была конкретная идея. Понимание того, почему оно так сделано, даёт ключ к тому, как извлечь из этого пользу. Это я и постарался отразить в своём сообщении. Не всегда путь, который избирает macOS лучше или удобнее, чем путь Windows, но конкретно в этом случае я, субъективно, не вижу преимуществ у Windows-реализации.
В этом плане Finder действительно гораздо удобнее. Просто Microsoft решили, что диалог открытие – это окно Проводника. Единственная причина, по которой это кажется интуитивным – это потому что Вы к этому привыкли. На самом деле, диалог открытия / сохранения – это семантически отдельная сущность, и вполне логично, что у неё своё поведение. Зачем мне может понадобиться драг-н-дропнуть что-либо в папку, открытую в диалоге сохранения, как делает Проводник? Если я зашёл в диалог сохранения, значит, я хочу что-то сохранить. Значит, любой ввод в диалоге сохранения – это что-то, применительно к процессу сохранения. Это логично.
Я постоянно пользуюсь этой возожмностью, например, когда у меня уже открыта папка, куда нужно сохранить файл. Драг-н-дропаешь эту папку или любой файл из неё в диалог сохранения – и вуаля.
По личному опыту (10+ лет на каждой из платформ) в Microsoft за хоткеи отвечает пьяная мартышка с завязанными глазами. Тут в комментариях ругают macOS за "аккордовые" сочетания клавиш, но в macOS эти аккорды почти всегда плюс-минус удобны. Каждый раз с содроганием вспоминаю годы работы в Visual Studio, где хочешь действие – изволь нажать два аккорда подряд, логики в которых я так и не увидел. Правда, это было больше 10 лет назад, может быть ситуация улучшилась. Может быть я тогда не разобрался, но я честно пытался, и мне не удалось. И я отдельно не простил им того раза, когда я выучил хоткеи для Word 2007, а они поменяли их в 2010 (просто взяли и поменяли хоткеи в программе, которой ежедневно пользуется половина мира, подумаешь?).
Ну и говорить про то, что в Windows большинство действий можно сделать и драг-н-дропом, и через меню, и хоткеями – это несколько абсурдно в контексте обсуждения macOS) Потому что, во-первых, macOS – это прямо-таки драг-н-дропная система, Windows даже не близка. Это не обязательно хорошо или плохо, это просто разный взгляд на вещи, и на macOS прямо любят drag-n-drop. Однако и по меню Windows не близка, увы. В macOS единый подход к использованию меню, стандартизованный на уровне системы. Стандартные системные компоненты для реализации меню, которые используются (напрямую или за счёт фреймворков) в большинстве приложений. При этом, насколько я помню, на уровне Human Interface Guidelines прописана взаимосвязь контекстного меню и основного. В любом приложении есть удобный нечёткий поиск по всем пунктам меню. Как, например, в IntelliJ Idea, только во всех приложениях. На любой пункт меню в любом приложении можно стандартными настройками системы повесить хоткей внезависимости от того, предусмотрел это разработчик или нет. Распространённые стандартные действия также имеют стандартизованный хоткей. Я открываю любое приложение на macOS, даже если вижу его впервые, нажимаю "Cmd + ," и, с вероятностью 95%, увижу настройки приложения. Ну и спорное с точки зрения многих решение с "одним меню на всех наверху" мне тоже нравится. Плюсы в том, что в меню гораздо проще попадать мышкой, т.к. не нужно целиться в конкретную точку – граница экрана не даст мышке улететь далеко. И экономия места – не нужно отдельное меню под каждое приложение. Но я понимаю, что не всем это заходит)
Ну и я уж молчу про то, что хоткеи с Cmd несравненно удобнее хоткеев с Ctrl, т.к. загнуть мизинец в левый нижний угол клавиатуры – то ещё страдание, когда пальцы на ASDF. Cmd всегда под рукой – только сдвинуть большой палец чуть-чуть в сторону. Тот самый палец, который самый большой и сильный, и при этом используется обычно только для пробела.
Не поймите неправильно, у macOS полно минусов. Finder тут только ленивый не попинал, и я солидарен – работа с сетевыми каталогами – это боль, отсутствие нормальной адресной строки – боль. Меня Finder не так бесит исключительно потому, что я половину действий делаю через консоль, но это ведь не от хорошей жизни)) Рабочие столы раньше были прекрасной фичей, но потом Apple замедлили анимацию, и теперь работать невозможно, а вернуть скорость анимации тоже нельзя, т.к. Apple "так видит". Листнуть между столами жестом на трекпаде – почти полная секунда до момента завершения анимации, это очень выбивает из контекста. Иконки приложений в менюбаре, если не влазят, просто не показываются. Никакой индикации того, что они там есть. А ещё они конфликтуют за место с тем самым единым меню на всех, и там тоже не всё гладко. Переключение раскладок занимает иногда вечность. Вроде бы в последних версиях стало получше, раньше приходилось городить костыли, если часто переключаешься, иначе я регулярно часть следующего слова печатал в старой раскладке, потому что оно "ещё думает". TimeMachine была восхитительной киллер-фичей, но Apple придумали "революционную APFS", "улучшили безопасность", и теперь TimeMachine – жалкая тень себя прошлой. Один инкрементальный бекап в несколько гигабайт с SSD на SSD занимает ЧАСЫ, и это даже не полный образ диска.
Я могу долго продолжать) Но в вопросе преимуществ хоткеев / меню / драг-н-дропа macOS над Windows я понимаю автора выше полностью)
Так у MS патент был, вроде как. Как раз на днях истёк. И "так совпало", что в макось завезли управление окнами не-курильщика (возможно, ещё не щупал) :) А так да, без Rectangle или аналога тяжко.
Про View в куче я, боюсь, не понял. Вы не могли бы пояснить, пожалуйста? LeakWatcher лежит в State / StateObject, жизненный цикл которого управляется SwiftUI, мы туда не лезем. Ссылок на само View мы вообще нигде не храним. С LeakWatcher напрямую не работаем.
А, я подумал, что Вы подход автора предлагаете доработать) Это-то понятно, я сам так и делаю обычно. Но это неравноценно.
Во-первых, это может сделать только разработчик, потому что только разработчик владеет полной информацией о том, какой метод когда должен быть вызван, какие внутри объекты и т.д. Да и то, когда проект большой, один разработчик знает одну часть, другой другую. Части друг друга они знают, но не досконально. Соответственно, во время тестирования (отделом QA) это делаться не будет. Во-вторых, это "ручной" подход. А это значит, что он муторный, времязатратный и провоцирует ошибки. В случае подхода из статьи же мы можем быть уверены, что если ViewModel (или что-либо, что мы отслеживаем) утечёт – мы об этом узнаем. Причём хоть сейчас, хоть в QA. И мы можем больше об этом не думать.
Так что то, что Вы предлагаете – вполне рабочий подход, имеющий своё место, но подход в статье обладает несомненными плюсами.
Мы с FrD1 разные люди, я просто тоже не совсем понял, что Вы имеете в виду) Вы не могли бы пояснить? Что бы Вы написали в deinit ViewModel-и / ViewController-а? И сделали ли бы Вы какие-нибудь ещё изменения?
А Вы не замеряли, есть ли заметные накладные расходы по производительности при использовании этого подхода?
Насколько часто Вы пользуетесь этими аннотациями? Только для ViewModel или для каких-то более мелких объектов тоже?
Вы оставляете эти проверки в release-версии?
Примерно аналогичный описанному выше функционал предоставляет инструмент Leaks в Instruments. На нём подробно останавливаться не будем.
Но ведь не совсем? Instruments позволяет именно обнаружить утечки, они "подсвечиваются" по ходу работы приложения. Или применительно к SwiftUI этот инструмент работает не очень хорошо? Я в SwiftUI пока не пробовал им пользоваться.
UPD: комментарии, на которые были ссылки, пропали совсем-совсем) Так что ссылки неактуальны. Ну и один мой ответ, который там был. Без "Тут было НЛО", просто пустота. В профиле автора комментариев их тоже нет. Ну вот и славно :)
Знаете, я думаю, Вы победили нас. Лично я сдаюсь. Я парализован и раздавлен Вашей неоспоримой логикой и богатым, всеобъемлющим жизненным опытом.
Пойду съезжу в аэропорт и продам мак кому-нибудь в очереди на регистрацию на рейс на Гоа. Потом куплю ThinkPad и прикреплю его к рабочему столу на гвозди. Не знаю, зачем мне второй ThinkPad, но надо – значит надо.
Потрясающие колонки ноутбука – это действительно оксюморон. Но "потрясающие колонки для ноутбука" – вполне себе применимо. Можно посмотреть много обзоров и убедиться, что с релиза M1 Pro-серии несколько лет макбуки по качеству звука были недосягаемы. Только где-то в последний год стали появляться ноутбуки на Windows, которые сопоставимы. Но при этом если сравнить мой M1 Pro MacBook Pro 16" и средней паршивости колонку даже от JBL, то мак будет бледно выглядеть. Я это знаю, потому что я так делал :) Я уж молчу про более качественные портативные колонки или, тем более, про мою средней руки стереосистему от Yamaha. Которая даже не напольная.
Но при этом сравнивать мак по качеству звука нужно всё-таки с сопоставимыми устройствами. То есть с другими ноутбуками, а не с напольниками. И не с портативными колонками. Какой смысл сравнивать с напольниками, если напольники можно подключить к маку? Или к ноутбуку на Windows? Если уж на то пошло, то Ваши напольники ужасны, потому что я был в IMAX, и, уверен, звук там был лучше. И, следуя Вашей логике, сравнивать напольники с звуковой системой IMAX вполне оправданно, ведь и то, и другое – источник звука.
Хотя в целом мы с Вами, конечно, во взглядах сходимся)
DEL, промахнулся
Люблю диванных аналитиков :)
P.S. Кстати, я согласен, отличный ноутбук) Защита от проливания мне особенно нравится. Не отказался бы от такого на маке.
У маковского тачпада, помимо, собственно, его качества, киллер фича в том, что жесты все поддерживаются на уровне системы, и они везде всегда одинаковы. Это даёт разработчикам приложений стимул их интегрировать. На Windows очень долго с жестами был вообще полный зоопарк. Сейчас какие-то жесты вроде pinch-to-zoom и скролла двумя пальцами устаканились, но это капля в море, и я не знаю, как обстоят дела с более сложными.
Из-за этого, даже если на Windows сделать отличный тачпад, с крутыми жестами и т.д., пользоваться им можно будет в полутора приложениях, которые поддерживают эти жесты. Будем надеяться, ситуация будет меняться к лучшему.
Ну, это мимо. У меня хороший домашний компьютер на Windows, неплохая файлохранилка на Linux, а мак мой стоит далеко не 450к. Ну и дома есть ещё ноутбук на Windows стоимостью плюс-минус как мой мак. Хороший, сам выбирал.
Просто ещё лет 10-15 назад, когда я впервые пробовал macOS (точнее, MacOS X в те времена), мне казалось, что было бы странно, если бы система, которая имеет наследие с 1984 года и построена на собственной философии, работала бы так же, как Windows. И я не говорю "лучше" или "хуже", я говорю "так же" (или "также", никогда не запомню правила для этого слова). Поэтому я старался подходить к системе со свежим взглядом, не пытаясь прогнуть её под свои виндовые привычки, а стараясь разобраться, почему что-либо сделано тем или иным образом. Например, сворачивание окон в Windows и macOS – это совершенно разные операции, и это многих сбивает с толку. Ближайший эквивалент сворачивания окна из Windows – это закрытие окна на macOS. А сворачивание окна – это "откладывание ненужного сейчас окна на потом", для чего на Windows нет отдельной операции. Если использовать сворачивание окон на macOS как сворачивание на Windows, жизнь будет полна страданий, потому что оно для этого не приспособлено. "Развернуть" на macOS не разворачивает на весь экран, потому что замысел в том, что эта кнопка увеличивает размер окна так, чтобы вместить весь его контент. Мне больше нравится подход Windows, поэтому у меня стоит Rectangle, и я разворачиваю окна через него. Рабочий стол на macOS исторически предполагалось использовать именно как реальный рабочий стол – выносишь на него то, с чем сейчас работаешь и потом убираешь оттуда. Эта концепция растёт ещё из Xerox PARC. Использую я его таким образом? На самом деле, скорее нет. Но и как на Windows тоже не использую. В итоге получается что-то посередине. Вся система полна таких моментов, и если принять, что macOS – это своя самобытная система, которая не обязана соответствовать ожиданиям, навязанным другими системами (также как Windows не обязана соответствовать ожиданиям, навязанным macOS), то многие вещи обретают смысл, а порой начинают помогать, а не мешать, т.к. понимание причины, по которой что-то сделано, зачастую даёт возможность понять, какие преимущества это даёт, и как этим можно пользоваться себе во благо,
Ну и вот диалог открытия / сохранения. Он работает не так, как в Windows, и у этого была конкретная идея. Понимание того, почему оно так сделано, даёт ключ к тому, как извлечь из этого пользу. Это я и постарался отразить в своём сообщении. Не всегда путь, который избирает macOS лучше или удобнее, чем путь Windows, но конкретно в этом случае я, субъективно, не вижу преимуществ у Windows-реализации.
В этом плане Finder действительно гораздо удобнее. Просто Microsoft решили, что диалог открытие – это окно Проводника. Единственная причина, по которой это кажется интуитивным – это потому что Вы к этому привыкли. На самом деле, диалог открытия / сохранения – это семантически отдельная сущность, и вполне логично, что у неё своё поведение. Зачем мне может понадобиться драг-н-дропнуть что-либо в папку, открытую в диалоге сохранения, как делает Проводник? Если я зашёл в диалог сохранения, значит, я хочу что-то сохранить. Значит, любой ввод в диалоге сохранения – это что-то, применительно к процессу сохранения. Это логично.
Я постоянно пользуюсь этой возожмностью, например, когда у меня уже открыта папка, куда нужно сохранить файл. Драг-н-дропаешь эту папку или любой файл из неё в диалог сохранения – и вуаля.
По личному опыту (10+ лет на каждой из платформ) в Microsoft за хоткеи отвечает пьяная мартышка с завязанными глазами. Тут в комментариях ругают macOS за "аккордовые" сочетания клавиш, но в macOS эти аккорды почти всегда плюс-минус удобны. Каждый раз с содроганием вспоминаю годы работы в Visual Studio, где хочешь действие – изволь нажать два аккорда подряд, логики в которых я так и не увидел. Правда, это было больше 10 лет назад, может быть ситуация улучшилась. Может быть я тогда не разобрался, но я честно пытался, и мне не удалось. И я отдельно не простил им того раза, когда я выучил хоткеи для Word 2007, а они поменяли их в 2010 (просто взяли и поменяли хоткеи в программе, которой ежедневно пользуется половина мира, подумаешь?).
Ну и говорить про то, что в Windows большинство действий можно сделать и драг-н-дропом, и через меню, и хоткеями – это несколько абсурдно в контексте обсуждения macOS) Потому что, во-первых, macOS – это прямо-таки драг-н-дропная система, Windows даже не близка. Это не обязательно хорошо или плохо, это просто разный взгляд на вещи, и на macOS прямо любят drag-n-drop.
Однако и по меню Windows не близка, увы. В macOS единый подход к использованию меню, стандартизованный на уровне системы. Стандартные системные компоненты для реализации меню, которые используются (напрямую или за счёт фреймворков) в большинстве приложений. При этом, насколько я помню, на уровне Human Interface Guidelines прописана взаимосвязь контекстного меню и основного. В любом приложении есть удобный нечёткий поиск по всем пунктам меню. Как, например, в IntelliJ Idea, только во всех приложениях. На любой пункт меню в любом приложении можно стандартными настройками системы повесить хоткей внезависимости от того, предусмотрел это разработчик или нет. Распространённые стандартные действия также имеют стандартизованный хоткей. Я открываю любое приложение на macOS, даже если вижу его впервые, нажимаю "Cmd + ," и, с вероятностью 95%, увижу настройки приложения.
Ну и спорное с точки зрения многих решение с "одним меню на всех наверху" мне тоже нравится. Плюсы в том, что в меню гораздо проще попадать мышкой, т.к. не нужно целиться в конкретную точку – граница экрана не даст мышке улететь далеко. И экономия места – не нужно отдельное меню под каждое приложение. Но я понимаю, что не всем это заходит)
Ну и я уж молчу про то, что хоткеи с Cmd несравненно удобнее хоткеев с Ctrl, т.к. загнуть мизинец в левый нижний угол клавиатуры – то ещё страдание, когда пальцы на ASDF. Cmd всегда под рукой – только сдвинуть большой палец чуть-чуть в сторону. Тот самый палец, который самый большой и сильный, и при этом используется обычно только для пробела.
Не поймите неправильно, у macOS полно минусов. Finder тут только ленивый не попинал, и я солидарен – работа с сетевыми каталогами – это боль, отсутствие нормальной адресной строки – боль. Меня Finder не так бесит исключительно потому, что я половину действий делаю через консоль, но это ведь не от хорошей жизни)) Рабочие столы раньше были прекрасной фичей, но потом Apple замедлили анимацию, и теперь работать невозможно, а вернуть скорость анимации тоже нельзя, т.к. Apple "так видит". Листнуть между столами жестом на трекпаде – почти полная секунда до момента завершения анимации, это очень выбивает из контекста. Иконки приложений в менюбаре, если не влазят, просто не показываются. Никакой индикации того, что они там есть. А ещё они конфликтуют за место с тем самым единым меню на всех, и там тоже не всё гладко. Переключение раскладок занимает иногда вечность. Вроде бы в последних версиях стало получше, раньше приходилось городить костыли, если часто переключаешься, иначе я регулярно часть следующего слова печатал в старой раскладке, потому что оно "ещё думает". TimeMachine была восхитительной киллер-фичей, но Apple придумали "революционную APFS", "улучшили безопасность", и теперь TimeMachine – жалкая тень себя прошлой. Один инкрементальный бекап в несколько гигабайт с SSD на SSD занимает ЧАСЫ, и это даже не полный образ диска.
Я могу долго продолжать) Но в вопросе преимуществ хоткеев / меню / драг-н-дропа macOS над Windows я понимаю автора выше полностью)
А, мои извинения, значит я не в тему влез :) Возьмите плюсик. Я предположил, что речь может быть об этом.
Home / Pro / Ultimate / что там ещё есть.
Так у MS патент был, вроде как. Как раз на днях истёк. И "так совпало", что в макось завезли управление окнами не-курильщика (возможно, ещё не щупал) :) А так да, без Rectangle или аналога тяжко.
Про View в куче я, боюсь, не понял. Вы не могли бы пояснить, пожалуйста? LeakWatcher лежит в State / StateObject, жизненный цикл которого управляется SwiftUI, мы туда не лезем. Ссылок на само View мы вообще нигде не храним. С LeakWatcher напрямую не работаем.
Да, но мы их вручную не создаём. Они не утекут.
А, я подумал, что Вы подход автора предлагаете доработать) Это-то понятно, я сам так и делаю обычно. Но это неравноценно.
Во-первых, это может сделать только разработчик, потому что только разработчик владеет полной информацией о том, какой метод когда должен быть вызван, какие внутри объекты и т.д. Да и то, когда проект большой, один разработчик знает одну часть, другой другую. Части друг друга они знают, но не досконально. Соответственно, во время тестирования (отделом QA) это делаться не будет. Во-вторых, это "ручной" подход. А это значит, что он муторный, времязатратный и провоцирует ошибки. В случае подхода из статьи же мы можем быть уверены, что если ViewModel (или что-либо, что мы отслеживаем) утечёт – мы об этом узнаем. Причём хоть сейчас, хоть в QA. И мы можем больше об этом не думать.
Так что то, что Вы предлагаете – вполне рабочий подход, имеющий своё место, но подход в статье обладает несомненными плюсами.
Тогда все вопросы к накладным расходам снимаются)
Мы с FrD1 разные люди, я просто тоже не совсем понял, что Вы имеете в виду) Вы не могли бы пояснить? Что бы Вы написали в
deinitViewModel-и / ViewController-а? И сделали ли бы Вы какие-нибудь ещё изменения?Но в какой момент мы будем считать отсутствие вызова проверки в deinit утечкой?
Спасибо за статью! Интересный подход.
А Вы не замеряли, есть ли заметные накладные расходы по производительности при использовании этого подхода?
Насколько часто Вы пользуетесь этими аннотациями? Только для ViewModel или для каких-то более мелких объектов тоже?
Вы оставляете эти проверки в release-версии?
Но ведь не совсем? Instruments позволяет именно обнаружить утечки, они "подсвечиваются" по ходу работы приложения. Или применительно к SwiftUI этот инструмент работает не очень хорошо? Я в SwiftUI пока не пробовал им пользоваться.
Да нет, я не о Вас) у меня там были ссылки в комменте выше. Собственно, до сих пор есть. А самих комментариев уже нет :)
К тому же, Вы бы и не смогли удалить свои комментарии. На Хабре нельзя удалять комментарии. А тех комментариев нет)
UPD: комментарии, на которые были ссылки, пропали совсем-совсем) Так что ссылки неактуальны. Ну и один мой ответ, который там был. Без "Тут было НЛО", просто пустота. В профиле автора комментариев их тоже нет. Ну вот и славно :)