За год изменилось немного: появился чип m5 и вышел Xcode 26...

Макбук для работы

Рекомендации по поводу рабочего макбука двигаем на 1 цифру вперед, то есть на работе заказываем MacBook Pro m5 pro - как обычно, даже в базовой конфигурации это будет отличный вариант на несколько лет вперед.

Если компания не выдает технику, то есть смысл взять то, на что хватает денег из линейки m3-m5. m1-m2 не рассматриваем, потому что они уже прилично состарились, а m2 и вовсе проиграл в некоторых тестах предшественнику.

Макбук не для работы

В 2020 году я купил себе MacBook Pro 13'' m1 за 150к (на официальном сайте с доставкой на дом, чудеса вообще), и он отлично прослужил мне до второй половины 2025 года, когда я его продал за 64к - это была отличная продажа и я очень доволен таким успехом, и покупатель будет еще долго доволен, т.к. ему макбук нужен был не для программирования, а для повседневного использования.

В 2026 не могу рекомендовать макбуки из линейки m1-m2, так что находим выгодные варианты m3-m5 (как и для работы) на маркетплейсах и радуемся запасу производительности на ближайшие 3-5 лет.

Очевидно, m5 прослужит лучше в течение 5 лет, чем m3, но для рядового пользователя, полагаю, разницы не будет вообще - не всем же нужно запускать Xcode/Android Studio каждый день по несколько раз и ждать выполнение unit/ui-тестов 😁

Macbook Neo

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

Этот раздел статьи не для слабонервных!

.

.

.

.

.

.

Я серьезно, если вы фанат Apple или просто ярый поклонник всех макбуков, то лучше не читать дальше!

.

.

.

.

.

.

Вы еще тут? Окей, поехали)

Специально для этой модели я покажу скриншоты цен (актуально на конец марта - начало апреля 2026) без рекламы конкретного маркетплейса, и потом мы вместе сравним с ценами на другие модели на том же маркетплейсе, опять же не реклама:

Важная деталь: это сравнение цен на новые ноутбуки, т.е. не б/у, не паленые, а прямо новые.

Air m4 дороже на 23к руб (на этом маркетплейсе), но и по большинству параметров он намного лучше.

У мелких перекупщиков на других популярных сайтах можно найти тот же air m4 за 69к.

Внимательный читатель может спросить: "Зачем покупать дорогой air m4, если можно купить новый модный и молодежный neo дешевле?".

На это я отвечу внимательному читателю: "Если не получается найти разницу при беглом сравнении параметров обеих моделей под свои потребности, то не нужно платить больше".

Потом сообразительный читатель может спросить: "Зачем вообще покупать макбук в 2026 году за такие деньги не для ios-разработки, когда можно купить ноутбук на виндовс под любые потребности и по любой цене, в том числе от 15к и до 60к?"

На что я отвечу сообразительному читателю: "Отличный вопрос, мой дорогой читатель! Нет никакого смысла тратить деньги на макбук, если нет конкретных задач, для которых нужен именно макбук, и с которыми не справятся другие ноутбуки".

И пока другие блогеры и СМИ активно пиарят новый macbook neo как убийцу доступных ноутбуков на винде, мы с вами как самые сообразительные понимаем, что это пустой трёп, который нацелен только на отработку рекламного ТЗ, или на сбор хайпа (или и то, и другое разом).

И прежде чем набегут желающие защитить божественный бренд Apple от сравнения с безымянными ноутбуками, сначала вспомним, что этот раздел был не для слабонервных и не для фанатов Apple!

А теперь можно вместе подумать, что еще можно купить на оставшиеся 45к руб после покупки ноутбука на винде:

• Отличный новый андроид-смартфон
• Два хороших новых андроид-смартфона
• Хороший андроид-смартфон и еще один ноутбук на винде
• Два дополнительных ноутбука на винде
• 45 пицц по 1000 рублей каждая

Ну вы поняли, надеюсь 😉

Заключение

Итоговый выбор как всегда зависит от ваших конкретных задач (но не покупайте, пожалуйста, macbook neo), для которых выбирается макбук, и в большинстве случаев для разработки подойдет любая модель с чипом m4-m5.

Удачных покупок!

Есть разные способы загрузки фоток в эмулятор, например:

• перетащить файлы с фотками на экран эмулятора
• перетащить файлы с фотками в открытое приложение "файлы" на экране эмулятора
• открыть Device Explorer и добавить фотки в папку sdcard/DCIM

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

А вот кстати и желаемый результат:

Проблема

Все перечисленные ранее способы не сработали:

Решение

После копирования фотографий на эмулятор любым из ранее перечисленных способов выключаем эмулятор и жмем Cold Boot:

Заключение

Перед написанием этой статьи я пробовал добавить фотографии в эмулятор всеми перечисленными способами, даже стирал данные эмулятора и перезагружал его - ничего не помогало.

И только чудо-кнопка Cold Boot помогла.

Будет здорово, если кому-то эта статья поможет сэкономить время в подобной ситуации

С чем имеем дело

В Xcode 26.3 нельзя подключить любую свою модель кроме предусмотренных из коробки

Да, есть настройка для добавления кастомного провайдера моделей, но она не совместима с Z.AI (провайдер GLM-моделей), например.

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

Я не использовал ChatGPT/Claude в Xcode, потому что у меня куплены другие подписки (cursor + Z.AI).

Сразу к результатам

Положительные моменты

• Чат работает? - чек
• Анимации в чате работают? - чек
• Градиенты в Xcode отображаются? - чек
• Код генерируется? - чек

Отрицательные моменты

• Модель может выполнять команды в терминале? - нет
• Модель может писать код в разных файлах, которые не открыты в Xcode? - нет
• При включении/выключении прокси Xcode обновляет статус в окне с чатом? - нет
• Модель может взаимодействовать с тестами или симулятором? - нет
• При начале нового диалога Xcode запоминает выбранную ранее модель? - нет

Больше всего меня удивил момент, когда модель написал код в одном из двух нужных файлов, а вместо изменения второго файла создала новый, что привело к ошибке компиляции, и эту ошибку комплияции она не смогла исправить, потому что не удалось, видите ли, сделать изменения в нужном файле.

Полагаю, дело в объеме второго файла - там больше тысячи строк кода, но в других инструментах (qwen-code, opencode, cursor) такой проблемы ни разу не было.

Сравнение с Android Studio

Вывод

То, что Apple нам рекламируют, по уже сложившейся традиции оказывается полной ерундой.

Нет никакого оправдания, почему в 2026 году Xcode не может дать доступ к терминалу подключенным нейросетям, или хотя бы дать дефолтный mcp для работы с тестами и симулятором.

Ну и отсутствие терминала уже ни в какие рамки не идет. Хоть я и не знаю почти никаких команд в терминале, и вообще не фанат модных движений типа TUI, но отсутствие терминала в Xcode - это показатель их провала.

Но вдруг у меня слишком высокие требования к инструментам?

Если вам нравится использовать Coding Assistant в Xcode, поделитесь обратной связью в комментариях, пожалуйста. Вдруг я чего-то не знаю, и там все отлично работает, если использовать это по-другому.

Предыстория и о чем статья

Чуть больше двух лет назад я начинал изучать верстку с использованием Jetpack Compose, потому что это похожая штука на SwiftUI, и даже успел за пару месяцев сверстать большинство компонентов дизайн-системы для приложения с площадками для тренировок (вот iOS-версия), но потом все же забросил это дело, потому что:

• хотелось развивать iOS-приложения, и я это успешно делал
• не хотелось тратить время на изучение андроид-разработки с нуля, когда я уже умею делать приложения для iOS
• в то время мне еще совсем не казалось, что есть смысл смотреть в сторону смены айфона на андроид (а теперь ситуация постепенно меняется)
• не пользовался нейросетями для разработки

Насчёт счётчика дней - именно с идеи этого приложения я и начинал свою карьеру в iOS-разработке, при этом сам же пользуюсь этим приложением на айфоне, и поэтому решил именно с него начать обучение андроид-разработке в этот раз.

В этой статье расскажу самое интересное и главное на мой взгляд про андроид-разработку с нуля и до публикации в русторе. И пара слов будет про рустор.

Что нужно знать и уметь

Язык программирования

Как ни странно, не нужно знать язык программирования, чтобы сделать андроид-приложение. Т.е. ни Kotlin, ни Java мне не пригодились. Первый я могу очень поверхностно читать (он похож на Swift), а второй вообще не знаю и не хочу знать . В разработке мне это не понадобилось совсем.

Софты

Нужно уметь формулировать свои мысли в слова, чтобы писать запросы в нейросеть.

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

Планирование

Для разработки андроид-приложения мне пригодились навыки планирования и деления задач на подзадачи (декомпозиция).

Абсолютно все задачи для нейросети я провожу через планирование. Нельзя просто сказать "Хочу такое приложение, чтобы в нем можно было запоминать события и считать дни" - получится полная фигня, хотя что-то может быть даже будет работать

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

Принципы разработки

В процессе разработки iOS-приложений я привык обращать внимание на разные моменты, а отдельно хочу выделить эти:

1. Пользовательский опыт (UX) и интерфейс (UI): дизайн должен быть интуитивным, простым и удобным для использования одной рукой; важна консистентность элементов управления и предсказуемое поведение.
2. Адаптивность: интерфейс обязан корректно отображаться на экранах разного размера и разрешения
3. Следование гайдлайнам: использование принципов Material Design для Android и Human Interface Guidelines для iOS для обеспечения привычного пользователям опыта

Формулировки взял из интернета, надеюсь что звучат понятно.

Это все не означает, что я знаю наизусть гайдлайны Android/iOS, или что я всегда планирую разработку для смартфонов и планшетов сразу, но я осознанно стремлюсь делать приложение так, чтобы пользователю было удобно и привычно, и чтобы пользователю не пришлось сталкиваться с ошибками, которые портят впечатление от использования приложения.

Система контроля версий (Git)

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

Гит позволяет вести разработку с высокой степенью уверенности в сохранении результатов работы. Поскольку нейросеть регулярно ломает код, то при помощи гита можно вернуться на предыдущий этап, когда все работало.

Инструменты

Я заранее определил идею для приложения, у меня был готовый дизайн в iOS-приложении, поэтому переходим к выбору инструментов.

Android Studio

Тут запускаю приложение на эмуляторе и нажимаю иногда кнопку для форматирования кода, фича кстати классная, вот демо:

Cursor

Тут происходит основная разработка.

Часто после генерации кода в курсоре мне приходится вручную исправлять пропущенные импорты в Android Studio для каких-нибудь кнопок или отступов, но это не требует знания языка программирования:

Qwen Code CLI

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

Использовал для составления планов, исправления мелких ошибок, больших (но простых) рутинных задач типа перемещения файлов в проекте и т.д. - может работать часами и не упирается в лимит, в отличие от курсора. Ну и отвечает менее качественно, так что компромисс.

Perplexity

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

Сроки

Начал разработку 29 декабря 2025 года, релиз в русторе опубликовал через 19 дней - 17 января 2026 года. Код приложения в гитхабе - там можно посмотреть историю коммитов (первый коммит и коммит с тегом 1.0).

19 дней я округлил до трех недель просто для красоты. Если считать прямо по 8 часов разработки, то выйдет около 12 дней. В отпуске я сделал 90% работы, а после отпуска за несколько вечеров все доделал и выпустил релиз.

Что мне понравилось

Работа с Android Studio

После Xcode это показалось просто прорывом во многих аспектах, кроме разве что тестов. Запускать тесты в студии очень неудобно, ну или я еще не научился делать это удобно: в Xcode есть одно меню для запуска нужных тестов, а в студии я такое не нашел 🫣

Больше всего понравилось:

• форматирование кода, о котором раньше уже написал и показал скриншоты
• превью Jetpack Compose (запускается быстро, никаких крашей в фоне, удобнее чем в Xcode)
• наличие терминала и плагинов, например, для работы с Makefile

В терминале я и квен запускал, и команды из Makefile (пока не нашел плагин для работы с Makefile) - этого очень не хватает в Xcode:

Вес приложения

Андроид приложение значительно легче iOS-версии. Опубликованное в русторе приложение весит всего 2.6 мб (AAB-файл), APK в гитхабе весит всего 3.85 мб, тогда как iOS-версия весит 5.9 мб, причем около 40% веса добавилось из-за перехода с Xcode 16.4 на Xcode 26

Минимальная версия Android

Приложение работает на версии Android 8 и выше, релиз этой версии андроид был в 2017 году. Вся верстка на Jetpack Compose, стабильная версия которого вышла в 2021 году!

iOS-приложение работает на версии iOS 17 и выше, релиз этой версии iOS был в 2023 году. Эту версию системы я выбрал, чтобы использовать упрощенный инструмент для хранения данных приложения (Swift Data). Вся верстка на SwiftUI, который появился в 2019 году и был настолько дырявым, что его мало кто использовал в первые 2 года после релиза.

В общем, андроид ушел в большой отрыв в плане удобства верстки.

Что мне не понравилось

Навигация в Jetpack Compose

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

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

Gradle

Если бы это было моей работой, я бы разобрался в этом.

Но поскольку это не работа (а хобби), то ну его нафиг, потому что выглядит это нифига не весело, и ни разу не очевидно 🤪

Нахожу решения проблем, включая обходные решения, и на этом заканчиваю разбор.

Обилие инструментов

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

В том числе было непросто настроить линтер и форматирование кода - выбрал два инструмента (ktlint + detekt), которые конечно же конфликтуют в некоторых настройках

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

Эмуляторы

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

Рустор

Специально пишу на русском языке название этого магазина приложений, потому что, блин, это специальный магазин приложений конкретно для РФ. Нафига его называть английскими буквами?)

Требования к приложению

5 звезд за требования к приложению перед релизом - минимум полей для настройки приложения перед отправкой на модерацию.

В AppStore просто миллион полей, еще и разбросаны по разным местам на сайте.

Проверка приложения

5 звезд за скорость проверки приложения на релизе - меньше часа с момента первой отправки приложения до одобрения и публикации.

В iOS у меня был рекорд по скорости публикации одного из релизов - меньше часа, но это был не первый релиз, а это важно. Первый релиз в iOS у меня был долгим для каждого из трех приложений: модератор задает одни и те же бесполезные вопросы про монетизацию, целевую аудиторию и т.д., хотя в приложении не подключена монетизация, есть описание приложения на русском и английском языках, и заполнены все миллион обязательных полей в кабинете разработчика.

UX в русторе

3 звезды - слишком часто выдает бессмысленные ошибки в стиле "что-то пошло не так" и просит заново авторизоваться. Пишу в поддержку - они просят скриншоты. Присылаю скриншоты - они пишут, что нужны другие скриншоты, и что я что-то делаю не так.

Аналитика по приложению

1 звезда - почти никакой аналитики нет, и это плохо. Даже в AppStore есть стандартная аналитика, включая падения приложения.

Поддержка рустора сказала, что можно установить их инструмент для сбора аналитики в качестве отдельной зависимости, но я решил, что пока рановато, и подключил Firebase для отслеживания падений приложения. К слову, пока падений нет, как и пользователей

Заключение

Вот такой врыв в андроид я совершил неожиданно для самого себя в конце 2025 года, и считаю это успешным результатом. Еще раз ссылка на код, и ссылка на приложение в русторе - буду признателен за отзывы и тестирование

Приложение делал, чтобы проверить, насколько это вообще реально без знания языка, ну и всей специфики андроида, и чтобы набить руку.

Сейчас в свободное время делаю приложение с площадками для тренировок (аналог iOS-версии), и там уже будет полный фарш с точки зрения логики и количества фичей, потому что в приложении больше 50 запросов к серверу и куча экранов, это будет интересно

Отдельно в платном канале напишу больше подробностей и практических примеров разработки в андроиде, включая планирование, тесты и правила/навыки ... для нейросети.

Спасибо за внимание!

Тесты в первом релизе

Вот обобщенный перечень тестов, которые были на момент первого релиза:

• Тесты для экрана выполнения тренировки (настройка, завершение шагов, получение результата, работа с таймером, турбо-дни и т.д.)
• Тесты для экрана превью тренировки (построение активности дня, редактирование комментариев, обновление данных, сохранение тренировки и т.д.)
• Тесты для управления статусом программы (получение статуса, запуск, сброс, синхронизация, журнал синхронизации, интеграционные тесты и т.д.)
• Тесты для работы с дневником тренировок (базовые операции, комментарии, разрешение конфликтов, обработка ошибок, тренировки и т.д.)
• Тесты для работы с инфопостами (синхронизация, парсинг, управление ресурсами, работа с YouTube, избранное и т.д.)
• Тесты для работы с прогрессом пользователя (базовые операции, синхронизация, работа с фотографиями, калькулятор прогресса и т.д.)
• Тесты для работы с пользовательскими упражнениями
• Тесты для настроек приложения
• Тесты для воспроизведения звука
• Тесты для обновления стран
• Тесты для обработки изображений
• Тесты для управления ресурсами изображений
• Тесты для работы с YouTube видео
• Тесты для моделей тренировок
• Тесты для моделей дней
• Тесты для моделей прогресса
• Тесты для моделей пользователя
• Тесты для моделей синхронизации
• Тесты для других моделей (HomeScreenModel, ShareAppURL, TimerSound)
• Тесты для создания программы тренировок (инициализация дня, работа с активностью дня, турбо-дни, пользовательские упражнения, типы выполнения и т.д.)

У меня была цель протестировать всю возможную логику, чтобы было проще поддерживать и развивать приложение в любое время: хоть сейчас, хоть через год, когда я скорее всего забуду большинство мелочей, влияющих на ту же синхронизацию данных с сервером и т.д.

Проблема первого релиза

Про релиз сделали пост на сайте, с которым синхронизируется приложение, и в их телеграм-чате - там я случайно увидел пост одного из пользователей:

Моя реакция, когда я увидел этот пост: 🤯🤦‍♂️

Для разработчика проблема очевидна: не получилось спарсить (обработать) какой-то из ответов сервера, а судя по скриншоту, это вообще происходит при первой авторизации, т.к. на главном экране ничего нет кроме алерта.

Это был единственный момент, который я не протестировал: зарегистрировать нового пользователя на сайте, а потом авторизоваться в iOS-приложении.

Т.е. я тестировал только существующих пользователей, и для них все работает корректно. Вот это поворот 🙂

С пользователем мне повезло, он прислал мне в личку детали по воспроизведению проблемы и я сходу смог у себя это повторить.

Причина проблемы

Проблема возникала при декодировании JSON ответа от сервера в структуру CurrentRunResponse.

Я использовал стандартные методы декодирования, которые не могли корректно обработать поле с датой: метод decodeIfPresent не мог правильно обработать случай, когда сервер возвращает null в JSON в поле с датой.

При этом использовалась стратегия декодирования даты iso8601, которая не поддерживала формат с дробными секундами, который иногда возвращал сервер.

Почему только для новых пользователей

Проблема возникала только для новых пользователей, которые еще не начинали тренироваться на сайте/в приложении, потому что сервер возвращал разные данные в зависимости от того, есть ли для пользователя запись на сервере о дате начала тренировок.

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

Исправление проблемы

Пришлось создать специальные методы декодирования, которые корректно обрабатывают все возможные случаи от сервера, и конечно на этот раз добавил тесты для этой логики, код можно посмотреть в гитхабе, а тут просто перечислю сценарии:

• Должен декодировать стандартный ISO8601 формат без дробных секунд
• Должен декодировать ISO8601 формат с таймзоной +03:00
• Должен декодировать ISO8601 формат с дробными секундами (одна цифра)
• Должен декодировать ISO8601 формат с дробными секундами (две цифры)
• Должен декодировать ISO8601 формат с дробными секундами (три цифры)
• Должен декодировать ISO8601 формат с дробными секундами (четыре цифры)
• Должен выбрасывать ошибку для невалидной даты
• Должен выбрасывать ошибку для пустой строки
• Должен выбрасывать ошибку для неправильного формата даты
• Должен декодировать опциональное поле Date? с валидной датой
• Должен декодировать опциональное поле Date? с null значением
• Должен декодировать опциональное поле Date? с отсутствующим ключом
• Должен декодировать server date time формат без часового пояса
• Должен декодировать опциональное поле Date? с server date time форматом
• Должен декодировать минимальную дату
• Должен декодировать минимальную дату в server date time формате
• Должен декодировать дату с максимальными дробными секундами
• Должен декодировать ISO short date формат
• Должен декодировать опциональное поле Date? с ISO short date форматом

Тесты во втором релизе

Все тесты генерировал с помощью нейросети с использованием нескольких простых правил, о чем напишу в другой раз, а на исправление проблемы вместе с написанием новых тестов потратил около часа.

После этого оформил запрос на ускоренную проверку релиза и ... два дня разбирался с модераторами и отвечал на их вопросы 😁

Заключение

Тестируем не только основную логику приложения, но и декодирование моделей, особенно в пет-проектах ☝️

Бонус

Год назад еще можно было сказать, что автотесты - это дорого, сложно, непонятно, непривычно и так далее. Потому что многие еще не умели пользоваться или не знали про режим агента у популярных IDE типа cursor/windsurf.

Сейчас нельзя сказать, что ты не умеешь писать тесты, или что это дорого и долго - подобные вещи будут просто наглым враньем.

Если не хочется разбираться в новых инструментах - нужно так и говорить прямо, что все, пора на пенсию, потому что слишком сложно сказать нейросети написать тесты для логики или для модели.

Предлагаю всем, кто еще не пробовал генерировать тесты с нейросетью - начните это делать наконец-то, чтобы не ковыряться во внезапных багах и не ломать уже существующий функционал наших классных приложений 😉

Если кто-то переживает, что у нас станет меньше работы при снижении количества багов, то это заблуждение - работы меньше не станет, как и багов, зато стабильности будет больше 👍

Постановка и демо

На главном экране в приложении 2 варианта UI: для широкого экрана (например, для iPad) и для узкого экрана (для iPhone). На этом экране можно открыть модальное окно с важной функциональностью, а для поддержки двух вариантов UI используется ViewThatFits (удобная штука для iOS 16+), но при повороте экрана на айфоне эта модалка закрывается сама:

Причина бага

Проблема возникает из-за хранения @State-свойства для модального окна внутри дочерней вьюхи, которая используется в обоих вариантах UI, а при повороте экрана ViewThatFits приводит к частичному сбросу состояний дочерних вьюх, которые исчезают.

Почему сброс частичный? Потому что на девайсе при повороте экрана модалка закрывалась, а при повороте обратно - сама появлялась, но не каждый раз

Код для этого случая можно посмотреть в гитхабе.

Если нужно скрыть кнопку в тулбаре, то нужно закрывать ее проверкой на if/else, а применять opacity больше нельзя - в iOS 26 будет такая фиговина как на скриншоте.

Демонстрация проблемы

Как должно быть

Причина неправильного поведения для пользователей с iOS 26

В проекте используется NavigationView, который все еще отлично работает сам по себе даже на iOS 26, а проблема возникает при отображении NavigationView внутри модального окна (sheet).

Варианты исправления

Вариант 1: самый быстрый и "очевидный"

Можно заменить в проекте все места, где используется NavigationView на NavigationStack ... и поднять минимальную версию iOS с 15 до 16. Таким образом можно сохранить исходное поведение и на старых версиях iOS, и на новых, но придется отказаться от пользователей на iOS 15*.

Вы можете справедливо заметить, что на iOS < 16 уже почти никого нет, и тем не менее там чуть больше 4% пользователей iPhone. Они не хотят или не могут обновиться, но ведь в нашем случае причина бага не в их девайсах, а где-то под капотом iOS 26, что вообще никак не касается других версий системы.

Вариант 2: менее быстрый

Можно сделать то же самое, что в варианте 1, но без поднятия минимальной версии iOS - достаточно сделать свою обертку для навигации, где внутри будет проверка на iOS 16: если возможно, используем NavigationStack, а если нет, то NavigationView.

Такой вариант я хотел применить еще на релизе iOS 18, но в то время это привело к крашам как раз в сценарии открытия NavigationStack внутри модального окна, причем именно на iOS 16+.

Вариант 3: поменять способ открытия родительского окна

Можно открывать экран с "площадкой" не в модальном окне, а в том же стеке навигации, что не требует изменения минимальной версии iOS и никаких проверок на версию iOS вообще не нужно добавлять, но немного поменяется подход к открытию некоторых экранов ... и все продолжит работать даже на iOS 26+, чудеса!

Что я сделаю

Скорее всего, буду выбирать между первыми двумя вариантами. Все же это нишевое приложение, и там очень мало пользователей, и даже если кто-то сидит в приложении на iOS 15, то все основные функции там останутся доступными еще очень долго, пока на сервере никаких глобальных изменений не сделают (а там очень редко что-то меняется).

Заключение

Жидкое стекло принесло нам немало багов, и в том числе задело исправно работавшую навигацию на старом добром NavigationView.

Главное, что все еще есть решения таких проблем, в том числе и обходные.

Больше деталей

Есть iOS-приложение с жизненным циклом на UIKit (AppDelegate), которое никто раньше не адаптировал для темной темы.

В Info.plist есть ключ UIUserInterfaceStyle со значением Light, что по умолчанию включает всегда светлую тему, даже если на девайсе активна темная тема.

Пользователи давно просят добавить поддержку темной темы, и пришло время это реализовать. Процесс займет неопределенное время, в ходе которого будет сделано несколько сборок для тестирования.

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

План

1. Удаляем из Info.plist неактуальный ключ UIUserInterfaceStyle
2. Добавляем тоггл в дебаг-меню
3. Складываем логику в отдельный сервис
4. Дорабатываем AppDelegate

Первые 2 пункта не очень интересные: удалить ключ из Info.plist очень легко, а добавить тоггл в дебаг-меню - по-разному, в зависимости от проекта.

В нашем случае добавить тоггл было легко, поэтому перехожу к третьему шагу.

Складываем логику в отдельный сервис

Управление поддержкой темной темы - это новая фича, которую хочется покрыть тестами, поэтому сделаем небольшой сервис, который будет заниматься этой логикой, и позже напишем тесты.

Для управления поддержкой темной темы нам нужна ссылка на window, которая в нашем случае есть в AppDelegate, и значение тоггла из дебаг-меню:

import UIKit

enum DarkModeSwitcher {
  @discardableResult
  static func applyIfNeeded(window: UIWindow?, isDarkModeEnabled: Bool) -> Bool {
    guard let window else {
      return false
    }
    let desired: UIUserInterfaceStyle = isDarkModeEnabled ? .unspecified : .light
    guard window.overrideUserInterfaceStyle != desired else {
      return false
    }
    window.overrideUserInterfaceStyle = desired
    return true
  }
}

Вот сценарии для юнит-тестов:

1. Включение darkMode включает .unspecified, если ранее было .light и возвращает true
2. Отключение darkMode устанавливает .light, если ранее было .unspecified и возвращает true
3. Повторный вызов с тем же значением не меняет стиль и возвращает false
4. Вызов с nil окном безопасен и возвращает false

Дорабатываем AppDelegate

Первым делом дорабатываем метод application(_:didFinishLaunchingWithOptions:), который вызывается при запуске приложения:

func application(
 _ application: UIApplication,
 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
 // ...
 DarkModeSwitcher.applyIfNeeded(
  window: window,
  isDarkModeEnabled: isDarkModeEnabled // <- ссылка на тоггл в дебаг-меню
 )
 // ...
 return true
}

Чтобы тестировать было удобнее, вызовем DarkModeSwitcher еще и при "разворачивании" приложения, т.е. когда оно переходит в активное состояние - таким образом можно будет сразу после переключения тоггла в дебаг-меню свернуть и развернуть приложение и сразу же увидеть темную тему (если она активна на устройстве):

func applicationDidBecomeActive(_: UIApplication) {
  DarkModeSwitcher.applyIfNeeded(
    window: window,
    isDarkModeEnabled: isDarkModeEnabled
  )
}

Готово! Теперь можно продолжать процесс переезда на темную тему и не волноваться о том, что пользователи могут увидеть промежуточный результат, ну и не "солить" код в отдельной ветке.

Бонус: SwiftUI

Как уже можно было догадаться, если жизненный цикл вашего приложения использует SwiftUI, то достаточно модификатора preferredColorScheme - в него нужно передать значение тоггла из дебаг-меню и ... готово!

Заключение

Код сервиса-переключателя для темной темы вместе с тестами можно посмотреть в гитхабе. Если интересно почитать про план адаптации темной темы в этом приложении с нуля, ставьте лайк 👍

Кому будет полезно

• Новичкам, кто хочет научиться делать автотесты на Python (популярные языки мало отличаются в этом плане - дальше в статье все расскажу)
• Действующим специалистам в этой теме - если ты уже пишешь автотесты самостоятельно, то эта статья может быть особенно полезной
• Менеджерам, которые хотят снизить нагрузку на ручных тестировщиков (автотесты работают намного быстрее, чем живые люди - это факт)
• Всем желающим, кто умеет читать и нажимать на кнопки в этом нашем "айти"

Прежде чем начинать

Ключевые моменты, влияющие на успех при изучении автотестов:

1. Мотивация - если не хочется узнавать новое и учиться, можно закрывать статью
2. Отсутствие страхов: если страшно, если есть сомнения типа "а вдруг не получится", "а что если нужно уметь программировать", "да я не знаю математику", "да я не знаю Python" - лучше сразу закрыть статью, чтобы не страдать

Мой опыт в Python

В 2022 году я изучал Python в каком-то бесплатном мобильном приложении, потратил на это около 3-4 дней и не стал углубляться в детали, т.к. не использую этот язык в работе никогда, и вообще не использую его нигде.

Просто было любопытно посмотреть на один из самых популярных языков программирования, вот и все.

Как я пришел к автотестам в рабочем проекте

Сначала я начал активно писать (генерировать) автотесты в iOS-приложении, и после пары сотен тестов на Swift поинтересовался у наших тестировщиков, как они пишут свои тесты.

Свои тесты я пишу почти целиком с использованием курсора, о котором я уже писал тут и тут, поэтому предложил поделиться опытом, чтобы упростить их работу.

Оказалось, что ребята не пользуются курсором, и вообще автотестам нужно учиться, а это небыстро и т.д.

Я решил разобраться в этой теме.

Шаг 1

Первым делом запросил доступ к репозиториям с автотестами. Репозиторий - место, где хранится код проекта. Например, тут список моих репозиториев в гитхабе.

Шаг 2

Дальше нужно их клонировать, т.е. скачать себе на комп - для этого я использую GitHub Desktop, но можно пользоваться любыми инструментами, которые вам нравятся, даже просто командами в терминале (я их не заучивал, поэтому не использую).

Шаг 3

Когда все загружено, осталось открыть проект в курсоре и приступать к делу - вот тут и начинается самое интересное и веселое.

Разбираемся вместе с курсором

Открываем проект в курсоре и что мы видим? Как всегда - список папок с файлами, и просто файлы.

Если в проекте есть документация, хотя бы README.md, нужно обязательно туда заглянуть - вдруг документ не забросили и поддерживают в актуальном состоянии. Примеры ридми-файлов: первый, второй, третий.

Поскольку я вообще не представлял, как все работает в этом проекте, то я сказал курсору:

изучи этот проект и скажи, нужно ли мне что-то установить для работы с этим проектом и для написания/запуска тестов, или можно сразу писать тесты и запускать их? если можешь, попробуй запустить тесты

Курсор подумал, что-то сделал, и через пару-тройку минут выдал ответ:

Я подготовил окружение и проверил запуск части тестов.

• Что нужно установить/сделать:
• Установить Python 3.11+.
• Создать venv и поставить зависимости из requirements.txt (там свой PyPI-индекс, работает).
• Создать /.env.local рядом с config.py с переменными: BASE_URL, USER_PASSWORD, TESTERDAV_PASSWORD.
• Сгенерировать tests/_generated/actions.py.

Я уже выполнил:

• Установил Python 3.11 через Homebrew.
• Создал venv на 3.11, установил зависимости.
• Сгенерировал tests/_generated/actions.py.
• Скопировал .env в .env.local (для локального прогона; значения лучше заменить на корректные).
• Запустил безопасный тест без авторизации: 3 passed, 1 deselected.
• Тест с логином упал из‑за отсутствия валидных данных для логина (пустой токен).

Можно ли сразу писать и запускать тесты?

• Да, если у вас установлен Python 3.11+ и заполнен /.env.local. Тесты без авторизации уже успешно проходят. Для тестов с авторизацией нужно корректно заполнить логин/пароль в /.env.local.

1-2 предложения о прогрессе:

Я собрал окружение на Python 3.11, поставил зависимости, сгенерировал actions и запустил тесты: без авторизации — успех, авторизационные падают из‑за отсутствия валидных учётных данных. Готов подключить реальные значения в .env.local и прогнать полный набор.

Знаю ли я про окружения в Python - совсем нет. Как их настраивать? Без понятия.

При этом у меня в GitHub Desktop отобразилось несколько сотен новых файлов, что меня немного напрягло, и я написал в курсор:

проверь список изменений, которые мы не закоммитили - нужно ли что-то из этого добавить в гитигнор, чтобы не ломать работу другим коллегам в этом репозитории? и нужно ли нам оставлять тесты, которые ты создал в @actions/ , или это были просто пробные тесты и их можно удалить? если можно удалить, сделай это

Ответ курсора через 20 секунд:

• Проверил незакоммиченные изменения: изменены только .gitignore и README.md. Новых тестовых файлов я не создавал.
• Добавил в .gitignore: /.venv/, **/__pycache__/, .DS_Store. Это исключит локальные артефакты macOS и Python, чтобы не мешали коллегам.
• tests/_generated/actions.py уже игнорируется (правило /tests/_generated/* есть), оставляем как есть.
• Про «пробные тесты» в tests/api/actions/: новых не добавлял — папка уже была в проекте; удалять нечего.
• Итого:В гит добавлять больше ничего не нужно, кроме уже внесённого .gitignore и обновлённого README.md.
• Тесты в @actions/ не мной созданы и удалять их не нужно.

Все новые файлы исчезли из списка в гите после обновления gitignore курсором, все четко ✅

Дальше я сказал курсору создать Makefile с командами для настройки проекта и запуска тестов, чтобы коллегам в будущем было проще все настроить одной командой на macOS/linux, и проверить эти команды на работоспособность.

Про Makefile я писал тут и тут.

Примерно через 25 минут, когда я сам проверил команды из Makefile и убедился, что все работает, я попросил курсор написать новый автотест по аналогии с существующими - он написал тест и запустил, все ок ✅

Обновляем документацию

Пишу курсору:

теперь обнови ридми, чтобы там было краткое и понятное объяснение как запускать тесты и через стандартные команды (pytest), и через make-команды, и приведи по одному примеру для каждого варианта запуска тестов

Он обновил ридми, я внес пару корректировок, а потом задал пару уточняющих вопросов про окружения в Python:

получается, что для запуска тестов через команду pytest не нужно предварительно активировать окружение? или я неправильно понял? если нужно активировать окружение, то прямо в примере запуска тестов с pytest напиши это. а то сейчас путаница возникает, как будто при использовании pytest не нужно делать предварительно source .venv/bin/activate

Ответ:

Я обновлю раздел в README, чтобы в примере для pytest явно сначала шёл source .venv/bin/activate, а альтернативный вариант без активации был выделен отдельно, чтобы не было путаницы. Затем вернусь с кратким резюме.

Уточнил формулировку в README:

• Для обычного вызова pytest через оболочку нужно активировать окружение. В примере теперь явно:
• сначала source .venv/bin/activate
• затем pytest tests/... -q
• Отдельной строкой оставил альтернативу без активации: ./.venv/bin/pytest ...

Так путаницы не будет: либо source + pytest, либо прямой вызов бинарника из .venv.

проверь, есть ли в проекте какой-то пример оформления тестов? или инструкция по написанию тестов? я хочу добавить такой раздел в ридми, чтобы проще было начинать работать новым членам команды

В результате в ридми появился разделы "Запуск тестов на macOS" и "Как писать тесты" ✅

Выводы по этому проекту

1. Я потратил около 30 минут на полную настройку проекта на своем ноуте, но в следующий раз другим ребятам (у которых macOS/linux) это можно будет сделать за пару минут, просто выполнив одну команду в терминале
2. Разобрался как запускать существующие тесты и увидел как они проходят/падают
3. Написал свой первый тест на Python за 1 запрос в курсоре

Что было дальше

Дальше я повторил все с самого начала во втором проекте с UI-тестами для сайта, и это заняло в сумме около полутора часов, потому что:

1. Долго разбирался с кредами для тестовых учетных записей (логины, пароли, адреса почты), в итоге все нашлось, спасибо коллегам
2. Сгенерировал неправильную автоматизацию в Makefile сначала

В первом проекте ребята использовали другой файл для хранения секретов, а поскольку у меня вообще не было никакого опыта работы с этими проектами, то я даже не думал, что надо где-то это проверить.

В общем, есть такой файл config.py, где есть строка с явным указанием названия файла с кредами, например:

load_dotenv(find_dotenv(filename=".env"), override=True)

Как я в этом разобрался?

Написал курсору, чтобы он запустил любой тест, где есть авторизация, и поправил ошибки.

Он запустил первый тест с авторизацией, тест упал, потом курсор за минуту нашел проблему и поправил ✅

Заключение

Я хотел показать, что нет необходимости предварительно учить язык программирования, или покупать и проходить курсы по "тестированию с нуля", или просто платить кому-то деньги за обучение новому в "айти", прежде чем начинать заниматься делом. Можно сразу начинать разбираться в рабочих задачах.

Хочется чему-то научиться илиразобраться в новой теме? Открываем бесплатные инструменты типа перплексити и просим составить план обучения. Есть еще российские аналоги, но я ими ни разу не пользовался, поэтому не могу ничего полезного сказать про них.

Нет уверенности в правильности ответов нейросетей? Живые люди тоже ошибаются очень часто, в том числе менторы, блогеры и эксперты на платформах, где продаются курсы.

Боишься, что не получится? Я старался писать простым языком и делать акцент на том, что не нужно иметь опыт, чтобы его получить. Да, не нужен опыт работы, чтобы начать работать. Не нужно получать высшее образование, чтобы начать зарабатывать деньги.

У тебя все получится, главное взять на себя ответственность за свое обучение и терпеливо решать возникающие задачи (проблемы) 🚀