Без паники!

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

• проверить фичу на сборке из testflight (ручное тестирование)
• задебажить хитрый сценарий, который возникает на девайсе, но не на симуляторе (по проводу в Xcode)

Причины для перехода

Процесс публикации своих приложений

Я хотел делать приложения, которыми будет приятно пользоваться, и делиться ими с другими людьми, но недавно закрыли последнюю официальную "лавочку" для оплаты подписки разработчика apple, а без этого невозможно опубликовать приложения для iOS во всеми любимом AppStore.

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

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

Тем, кто не публиковал приложения сам, или кто публиковал только несколько сборок, наверное сложно будет представить как это происходит.

Вкратце процесс выглядит так:

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

И в целом даже с таким стремным процессом (оформление приложения в кабинете apple, модерация) я готов был мириться, пока схема работала хотя бы в таком виде.

Санкции

Бац - удалили банковские приложения. Бац - удалили еще пачку приложений.

Просто потому что политика, отлично.

Я конечно поразвлекался, пока загружал приложения от крупных компаний через их обходные пути, в том числе приложение РЖД, которое они распространяют через Testflight для обычных пользователей (ни в какие ворота, ну камон), но надоело.

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

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

Операционная система

iOS уже не тот. Даже если эта фраза выглядит избитой, то сейчас я для себя это ощутил сполна, когда перешел на iOS 26.

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

Мои требования к айфону стали слишком высокими, потому что я отлично помню iPhone 5s, который классно работал, и не лагал как iPhone 13 Pro.

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

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

Руки кривые? Да, но не у меня, а у тех умников, которые пропустили iOS 26 в продакшен и забили на ручное тестирование (по всей видимости, уже очень давно).

Месяц на андроиде

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

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

Сканер отпечатка пальцев

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

Системные приложения и баги

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

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

Темная тема не включается/выключается по расписанию при смене режима на "сон" и обратно, что является частой проблемой в купленном мной андроиде, и прочие мелкие проблемы.

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

Публикация своих приложений

Помните ту дикую инструкцию в самом начале статьи для публикации в аппсторе на iOS?

Тут шагов всего 2:

• сделать приложение (спасибо агентам за удобство и скорость в этом деле)
• установить себе на девайс (и при желании поделиться со всем интернетом)

Шок-контент!

Я и раньше знал об этом, но пока лично не попробовал, не думал, что это настолько удобно.

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

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

Сторонние магазины приложений

Я использую f-droid и repostore, и мне очень нравится!

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

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

Автоматизация

У меня в айфоне были 2 "быстрые команды", которые активировались либо голосом (как и любая быстрая команда) через Siri, либо нажатием на ярлык на рабочем столе:

• выхожу из дома (для включения блютус + lte, и выключения wifi)
• вернулся домой (обратный процесс)

В андроиде эти две команды включаются автоматически без необходимости нажимать на ярлык или выполнять голосовую команду, и это БЕЗ использования геолокации, чудеса!

Самое классное то, что настроить это можно было без хитровыпендренных завихрений приложения "Команды" (iOS), в котором черт ногу сломит (ну серьезно, никогда не любил процесс создания команд, но полезные команды там все же можно сделать) - просто в системных настройках есть раздел "Режимы и сценарии", где можно добавлять любые сценарии и делать это с намного более удобным UX.

А что с карьерой?

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

Заключение

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

Если статья соберет больше 5 лайков, расскажу про критерии, по которым я выбирал себе смартфон на андроиде, и что в итоге выбрал ✅

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

Предлагаю прочитать ридми - там есть достаточное количество примеров и описание этого инструмента, а сюда просто скопирую оттуда кусочек:

Как я это использую

Сценарий 1

В пет-проектах, над которыми давно не работал, использую основную команду /ponytail-audit - эта команда проверяет весь репозиторий, например, проверим SwiftUI-Days:

Now I have a complete picture of the entire codebase. Here's the audit:
yagni ItemSchema.swift + ItemMigrationPlan.swift (157 lines). Three versioned schemas duplicating the model + two custom migration stages that only set optional fields to nil. SwiftData lightweight migration handles this automatically when you just add optional properties. SwiftUI-Days/Models/ItemSchema.swift, SwiftUI-Days/Models/ItemMigrationPlan.swift
shrink BackupFileDocument.swift (217 lines). RawBackupItem duplicates BackupItem with different encode/decode strategy — same 5 fields, two Codable impls. BackupWrapper envelope format + legacy flat array = two parsing paths for one export format. Merge into a single type, drop the legacy path. SwiftUI-Days/Models/BackupFileDocument.swift
yagni Analytics — 4 files (AnalyticsProvider protocol + FirebaseAnalyticsProvider + NoopAnalyticsProvider + AnalyticsService) for one real provider. The protocol has one method and one implementation in production. A single AnalyticsService with a Firebase-only init (or a log closure parameter) replaces 4 files. SwiftUI-Days/Services/Analytics/
yagni SectionTitleView.swift (35 lines). A .bold().foregroundStyle(isEnabled ? .primary : .secondary).frame(maxWidth: .infinity, alignment: .leading) modifier on Text. That's a one-line View extension, not a file. SwiftUI-Days/Screens/CommonViews/SectionTitleView.swift
yagni EditSectionView.swift (30 lines). Used in one screen (EditItemScreen). Inline the SectionTitleView + TextField pair. SwiftUI-Days/Screens/Detail/EditSectionView.swift
yagni ReadSectionView.swift (33 lines). Used in one screen (ItemScreen). Inline the SectionTitleView + Text pair. SwiftUI-Days/Screens/Detail/ReadSectionView.swift
yagni DaysEditButton.swift (13 lines). Button { action } Label(.edit, systemImage: "pencil"). Used in two places; inline Button directly is less code than the file overhead. SwiftUI-Days/Screens/Main/DaysEditButton.swift
yagni DaysDeleteButton.swift (19 lines). Same as DaysEditButton. SwiftUI-Days/Screens/Main/DaysDeleteButton.swift
yagni ItemDatePicker.swift (14 lines). A DatePicker with .bold(). Inline. SwiftUI-Days/Screens/Detail/ItemDatePicker.swift
yagni ItemDisplayOptionPicker.swift (24 lines). A Picker with SectionTitleView. Used in two screens; inline both calls. SwiftUI-Days/Screens/Detail/ItemDisplayOptionPicker.swift
yagni ColorTagFilterSheetState.swift (36 lines). Compute-only struct used by one sheet. The three computed properties + two methods can live in the sheet body. SwiftUI-Days/Screens/Main/ColorTagFilterSheetState.swift
yagni Binding+mappedToBool.swift (21 lines). Single-use extension. Inline init(bindingOptional:) at the call site in AppDataScreen. SwiftUI-Days/Extensions/Binding+mappedToBool.swift
yagni ThemeIconScreen+IconViewModel.swift IconError (10 lines). Single-case error enum. Use a descriptive string instead. SwiftUI-Days/Screens/More/ThemeIcon/ThemeIconScreen+IconViewModel.swift
delete BackupFormat.android case. iOS-only app. SwiftUI-Days/Models/BackupFormat.swift
delete AppDataError.swift (5 lines). Single-case enum used once. Use a string literal. SwiftUI-Days/Models/AppDataError.swift
delete ColorTagFilterSheet+Preview.swift (31 lines). 10 static let constants configuring hue/saturation/brightness/count for previews. The previews call static constants that equal literal numbers — use the numbers directly. SwiftUI-Days/Preview Content/ColorTagFilterSheet+Preview.swift
stdlib Color+Hex.swift body (51 lines discounting preview). Hand-rolled hex-to-UInt64 scanner. Scanner already does scanHexInt64. The bit-shifting color extraction is just CGFloat math that UIColor component accessor already provides. Could halve the line count. SwiftUI-Days/Extensions/Color+Hex.swift
shrink DisplayOption.unitsStyle (20 lines). Switch-picking .full/.short/.abbreviated based on which components are nonzero. This is polish: DateComponentsFormatter auto-selects a reasonable style. SwiftUI-Days/Models/DisplayOption.swift
shrink Item.makeDaysCount creates a new DateComponentsFormatter per call. A static let formatter saves the allocation. SwiftUI-Days/Models/Item.swift
shrink FeedbackSender.platformName — nested function inside a computed var body. Extract or inline. SwiftUI-Days/Services/FeedbackSender.swift
yagni ThemeIconScreen+IconVariant.variantNumber — manual switch self returning 1...7. A @frozen enum with Int raw value gives this for free. SwiftUI-Days/Screens/More/ThemeIcon/ThemeIconScreen+IconVariant.swift
net: -~660 lines, -1 dependency (Firebase could go closure-based but kept), -1 file (BackupFormat.android dead path)

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

Сценарий 2

В процессе работы проверяю конкретный коммит с помощью команды /ponytail-review, например:

/ponytail-review коммит 8e82b6cad16c12c1dcca1574b6908304ef15ccc8

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

Ponytail review — коммит 8e82b6ca
Ниже только over-engineering, не correctness.
- ColorTagFilterSheetState.swift:1 yagni Целая структура + enum для двух if-else (applyEnabled/resetEnabled/toggledColorHex/resetResult). Всё в 4 строчки в теле view. Удалить файл.
- MainScreenFilterState.swift:11 shrink itemsCountForFilterButton — синоним visibleItems.count. Убрать, заменить на visibleItems.count в isFilterButtonVisible.
- ColorTagFilterSheet+Preview.swift:9 yagni colors1 = 1, colors3 = 3, colors8 = 8, colors30 = 30 — константы, равные числу. Лишние имена. Вставить числа в вызовы.
- docs/doc-main-screen-color-tag-filter.md:1 yagni 78 строк внутренней документации, которая устареет при следующем рефакторинге. Удалить, пока не появился внешний контрибьютор, которому она нужна.
Net removable: ~40 строк

Что с рабочим проектом

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

При этом польза ощутима при выполнении конкретных задач, когда срабатывает проверка на YAGNI из раздела "Как это работает", и получается меньше кода, чем могло бы быть без этих проверок.

Заключение

Это уже пятый инструмент для агентов, который я использую на постоянной основе внутри opencode, а полный список вот: serena, codegraph, rtk, openspec, ponytail, и все складывается очень даже удобно для работы с агентом 👍

Проблема

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

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

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

Я даже поробовал microsoft todo, но мне совсем не понравилось их приложение.

Решение

Нашел бесплатное и неплохое приложение для андроид Tasks.org, и сделал небольшой инструмент на свифте для экспорта из приложения "Напоминания" на макбуке в формат Tasks.org.

Разработку вел целиком с использованием opencode + openspec - рассказывал об этом подходе в предыдущей статье.

Как пользоваться

1. Клонировать репозиторий
2. Открыть терминал в папке проекта
3. Выполнить команду make export-tasks-org
4. Взять получившийся файл reminders_export_tasks_org.json из папки с проектом и импортировать в андроид-приложение Tasks.org
5. Профит

Выводы

Является ли это решение лучшим? Вряд ли. Единственным? Нет. При этом я сделал его довольно быстро, и было очень легко тестировать прямо на симуляторе в андроид-студии.

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

Удобно ли мне пользоваться приложением Tasks.org на андроиде? Вполне ✅

Было ли удобнее в стандартном приложении "Напоминания" от apple? 💯 Да

Дублировать документацию из гитхаба не буду - ее можно прочитать по ссылке в первом абзаце, а расскажу именно про мой опыт использования 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 помогла.

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