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

Установка в проекте

В терминале в папке с проектом выполнил команду openspec init и отметил нужные инструменты (opencode и т.д.)

Использование в работе

Запускаем opencode и начинаем вводить команду /o

Новая мелкая фича

Если есть полное понимание, что нужно делать, то можно сразу использовать /opsx-ff - я так делал два раза для мелких задач, где все максимально очевидно и обсуждать нечего, например:

/opsx-ff task1234-toggle

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

Отправляем промпт в работу, и получаем ответ типа такого:

I found existing toggle-related code in the project (reminder settings toggle, filter dialog toggle), but "task-1234-toggle" doesn't tell me what you want to build or fix.
What do you want this change to do? For example:
- Add a new toggle for some feature
- Fix a bug with an existing toggle
- Refactor toggle logic
Describe the feature/fix and I'll create all the OpenSpec artifacts.

Дальше отправляю промпт с кратким описанием фичи (ведь она мелкая):

нужно сделать фичефлаг для настройки возможности включения или отключения экрана с логами для разработчика на экране

Агент какое-то время думает и создает все необходимые документы (артефакты) по задаче:

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

После проверки/исправления всех документов можно сразу переходить к /opsx-apply или сохранить прогресс (делаем коммит) и переключиться на что-то еще.

Новая стандартная фича

Если хочется больше контроля над процессом создания документации, или еще не до конца известны все требования для задачи, то есть смысл начинать с команды /opsx-new, например:

/opsx-new task1234-medium-feature

Отправляем этот промпт и получаем ответ:

Here's the summary:
Change: task1234-medium-feature
Location: openspec/changes/task1234-medium-feature/
Schema: spec-driven (4 artifacts)
Progress: 0/4 complete
[ ] proposal ← ready now
[-] design (blocked by: proposal)
[-] specs (blocked by: proposal)
[-] tasks (blocked by: design, specs)
First artifact: proposal.md — establish why this change is needed.
Template:
## Why
<!-- Problem/opportunity, 1-2 sentences -->

## What Changes
<!-- Bullet list: new capabilities, modifications, removals -->

## Capabilities
### New Capabilities
- `<name>`: <description>

### Modified Capabilities
<!-- List only if spec-level behavior changes -->

## Impact
<!— Affected code, APIs, dependencies -->
Ready to create the first artifact? Run /opsx-continue or describe what this change is about and I'll draft it.

В таком сценарии можно делать все документы по порядку, начиная с proposal, который является кратким описанием задачи для последующей детализации в других документах, напишем промпт с использованием команды /opsx-continue:

/opsx-continue task1234-medium-feature нужно сделать фичефлаг для настройки возможности включения или отключения экрана с логами для разработчика на экране

Отправляем этот промпт и получаем ответ:

Created: proposal.md
Schema: spec-driven | Progress: 1/4
[x] proposal ✓
[ ] design ← unlocked
[ ] specs ← unlocked
[-] tasks (blocked by: design, specs)
What's in the proposal:
- Why: Нет способа просмотреть логи внутри приложения, нужна фиче-флаг для скрытия от обычных пользователей
- Capabilities: dev-log-screen (экран логов) + dev-log-feature-flag (флаг управления)
- Impact: AppSettingsDataStore, Screen, MoreScreen, новый DevLogScreen + ViewModel
Ready to create the next artifact? Run /opsx-continue — I'll draft either design.md or the spec files next.

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

В нашем случае для примера я "промотаю" создание документов командой /opsx-ff, чтобы показать как работает /opsx-apply:

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

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

Верификация статуса

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

Когда к задаче нужно вернуться, то можно проверить статус с помощью команды /opsx-verify, это я и сделал в нашем случае, вот итоги проверки:

No critical issues found.
3 warnings to consider — all minor. The implementation correctly follows all design decisions, covers all requirements and scenarios, and maintains code pattern consistency.
Ready for archive. ✓

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

Когда задачу "приняли" окончательно, ее нужно архивировать командой /opsx-archive:

Archive Complete
Change: task1234-medium-feature
Schema: spec-driven
Archived to: openspec/changes/archive/2026-06-27-task1234-medium-feature/
Specs: Delta specs preserved (new capabilities — no main specs to sync to)
All 4 artifacts complete. All 20 tasks complete.

Вот и все! Работа над задачей завершена, теперь любые доработки нужно делать через отдельные задачи (/opsx-new или /opsx-ff).

Мой отзыв

Мне нравится использовать openspec, потому что:

1. Стандартизируется рабочий процесс - сначала документация, потом реализация по четкому плану
2. Появляется документация в удобном формате прямо в папке с проектом, а не где-то далеко в отдельной системе
3. Удобно отслеживать работу и возвращаться к задаче после длительного перерыва

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

Нюансы

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

Еще раз ссылка на репозиторий openspec, рекомендую попробовать самостоятельно 😉

Устанавливается одной командой, встраивается через hook и автоматом сжимает вывод команд перед тем, как он попадёт в контекст нейросети.

Как это работает

RTK перехватывает команды и применяет к ним четыре стратегии:

1. фильтрацию шума
2. группировку похожих элементов
3. обрезку лишнего
4. дедупликацию повторяющихся строк.

В результате модель получает ровно ту же информацию, но в 3–10 раз меньше токенов.

Примеры

git status

Без RTK (~67 токенов):

On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.serena/
	docs/

nothing added to commit but untracked files present

С RTK (~12 токенов):

* main...origin/main
?? .serena/
?? docs/

Шесть строк превратились в три — при этом полезная информация не потерялась.

git diff

Без RTK (~200 токенов):

diff --git a/Shared SwiftUI Content/100_ScenePhaseExample.swift b/Shared SwiftUI Content/100_ScenePhaseExample.swift
index 3a4b5c6d..7e8f9a0b 100644
--- a/Shared SwiftUI Content/100_ScenePhaseExample.swift
+++ b/Shared SwiftUI Content/100_ScenePhaseExample.swift
@@ -10,6 +10,7 @@ struct ScenePhaseExample: View {
     @State private var isActive = false

     var body: some View {
+        // MARK: - Main Content
         VStack(spacing: 20) {
             Text(isActive ? "Active" : "Inactive")
                 .font(.largeTitle)

С RTK (~40 токенов):

100_ScenePhaseExample.swift: +1
  + // MARK: - Main Content

RTK показывает только имя файла, количество изменённых строк и сами добавленные/удалённые строки — без служебной информации diff (индексы, заголовки патчей, контекстные строки).

Установка и настройка

С помощью homebrew:

brew install rtk

После установки нужно инициализировать hook для вашего рабочего инструмента:

rtk init -g                     # Claude Code / Copilot (по умолчанию)
rtk init -g --gemini            # Gemini CLI
rtk init -g --codex             # Codex (OpenAI)
rtk init -g --agent cursor      # Cursor
rtk init -g --agent windsurf    # Windsurf
rtk init -g --opencode          # opencode

После настройки для opencode в ~/.config/opencode/plugins/ появится файл rtk.ts, который автоматически будет перехватывать вызовы Bash-инструмента и переписывать команды через RTK.

Заключение

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

В прошлом году презентовали Xcode 26 с возможностью добавления других провайдеров нейросетей кроме chatgpt/claude, но вот незадача - это не так и просто сделать, если не погуглить дополнительно.

Для сравнения вот как выглядит настройка в Android Studio:

Если просто ввести в настройках Xcode те же данные, что в Android Studio, то ничего не выйдет.

Причина проблемы в поле URL: Xcode автоматически добавляет /v1/models или /models к URL провайдера для валидации подключения.

Поэтому нужно удалить часть URL с версией... чтобы Xcode сам подставил ее.

Гениально, не так ли?

И чтобы не было подозрений, что я рекламирую kimi для Xcode:

Всем удачных подключений!

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

Предыстория

В 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.

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

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

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

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