Или если у вас простая иконка, которая почему-то получает тень или стекло при установке приложения на девайс, эта статья для вас.

Предыстория

В Xcode 26.1 добавили баг при создании сборки приложения - ассеты иконок, сделанных в Icon Composer добавляются в итоговый архив несколько раз, что приводит к заметному увеличению веса приложения. Ссылки на форум: первая, вторая.

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

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

Однако для простых иконок это приводит к некрасивому результату:

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

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

Так не пойдет.

Решение

Результат в мегабайтах

Вес приложения снизился почти на 4 мегабайта!

И при этом новые градиентные иконки весят в 5-7 раз больше, чем простые однотонные. Но простые, как мы уже знаем, система покрывает своим стеклом или тенью, а выглядит это некрасиво.

Интересный момент: в темной теме ни стекло, ни дополнительная тень на иконки не накладывается - по крайней мере в счётчике дней так.

Заключение

Если у вас в приложении много альтернативных иконок, или вы используете Icon Composer для создания ваших иконок, то будет здорово вернуться к ассетам и подождать, пока композер починят (а починить его не могут уже больше 5 месяцев).

Зачем заставлять пользователя скачивать лишние мегабайты мусора вместе с нормальным приложением?

Проблемный сценарий

На одном девайсе создаю запись в приложении, жду, сворачиваю/разворачиваю приложение, проверяю на другом девайсе через минуту - там эта запись не появляется.

Решение

Открываем https://icloud.developer.apple.com/

Находим запись с ошибкой, например так:

Проверяем схему (типы записей) в development и production

Нестыковки найти очень легко: в моем случае в production-схеме буквально не было нужного типа записи с полями из iOS-приложения.

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

После нажатия "Deploy" можно подождать пару минут и повторить тест на проблемном сценарии. У меня проблема была решена через 2 минуты после деплоя актуальной схемы в прод.

Заключение

Когда я в первый раз настраивал Swift Data, то вообще не заглядывал в консоль icloud.developer, не проверял ничего связанного со схемами, и даже статей на эту тему не искал и не читал. Оказалось, настроить синхронизацию с облаком несложно, нужно только знать как это делается 😅

Спасибо интернету! И нейросетям 😉

За год изменилось немного: появился чип 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.

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