Блин забавно как в сети сейчас идет радость «ого в Xcode есть чатгпт и он автоматом генерирует доку, тесты и код». Как-то наивно радуются возможностям того, что было в курсоре пару лет назад. Эйфория чуть запоздала.

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

Docker от Apple

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

Давайте вспомним что это такое:

Контейнеризация — это метод изоляции приложений на одном сервере, который позволяет запускать их в отдельной «упаковке» вместе со всем необходимым — кодом, библиотеками и настройками. Эта упаковка называется контейнером.

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

Что это значит?
- Фреймворк создаёт отдельную лёгковесную виртуалку для каждого контейнера, обеспечивая высокий уровень изоляции, минимизируя attack surface и обещая время запуска "менее секунды"
- CLI-инструмент Container, написанный на Swift и с открытым исходным кодом, позволяет создавать образы из Dockerfile, запускать контейнеры с настройкой памяти, CPU, сетевых папок и поддержкой arm64 и amd64

Почему всё это важно?
- Например раньше мы могли запускать приложение в симуляторах. А теперь можно делать как это делают разрабы из ФААНГОВ. Собирать апку, ресурсы или модули на удаленном сервере и тянуть АПК в симулятор или в мак.
- Окружение будет стабильным на всех платформах
- В теории должно быть легче поддерживать CI/CD. Экономя сотни часов разработки

Посмотрим как это будет на практике, но выглядит многообещающе

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

Когда это вам полезно:
- поднимать мок-серверы для тестов, ресурсов
- тестировать сложные флоу с авторизацией, подписками, оплатой и безопасностью приложения
- вы занимаетесь utility модулями почти без ui
- у вас есть модули со сложными расчетами или проверками на сервере
- тестирование апи и контрактов
- можно запускать тесты и легко делать фейковые данные
- легко переключаешь между dev/test окружением
- меньше флаки тестов (очень много жрет на этом время)
- быстрее и удобнее запуск раннеров для проверок линтеров и тп
- ускоряется и упрощается кодогенерация
- у вас много зависимостей от чужих сервисов и вам это как-то нужно проксировать
- напишет мок-сервера (да да, таким занимаются сами иос инженеры)
- запуск статических анализаторов кода
- запуск кроссплатформенных модулей
- у вас есть всякие метрики качества кода выполняемые на сервере
- список обновляется

Кидайте еще свои примеры. Это я еще накидал навскидку. На macOS даже докер без приседаний не запустишь, а тут наконец все это будет легче.

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

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

Немного про виртуалки macOS и CI/CD

Еще одно заблуждение, которое обитает вокруг темы с виртуализацией. Это то, macOS НЕЛЬЗЯ накатать виртуально. Только реальный мак-мини или Claude.

Кто-то говорит, что нельзя ставить контейнеры macOS и можно только Linux. Официально это было правдой когда-то. Но если вспомнить, что есть реальность и практика, а не только чужие твиты и статьи, то легко узнать о неофициальных методах реальной жизни в условиях ограничений и выпилов из сторов… мы с вами живем в среде не благодаря, а вопреки. Выживая и адаптируясь.

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

Знаю немало разрабов кто сидит на хакинтоше и почти не страдает.

2. Образы для докера.

Образ №2

Так если все таки это можно, пусть и с условностями, так почему же об этом мало пишут?

Ну во-первых писать от имени компании как заменили на пиратские версии не очень хорошо.

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

Нет официальных поддержек. Но это не так страшно в снг мире, где мягко скажем не до официальных поддержек.

Я НЕ РЕКОМЕНДУЮ УСТАНАВЛИВАТЬ ПИРАТСКИЕ ВЕРСИИ И НЕ ПРОПАГАНДИРУЮ ЭТО…

Но можно ли накатить макос на виртуалку и сократить кучу бабок на покупке реальных устройств в условиях дефицита бюджета и поставок с наценками? Официально нет. Но неофициально да….

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

UPD: кстати нашел форум на редитте и в 2025 году хакинтошом стало пользоваться еще проще

Tart + macOS VM

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

Уже есть легальные (?) инструменты по запуску macOS на виртуалках без потери перфоманса. В комментах поста уже написали, что используют Tart.

Он построен на официальной технологии от Apple — Virtualization.Framework. Это значит:
- Он не “хакает” систему, а использует легальный и стабильный способ виртуализации, как VirtualBox или Parallels.
- Работает только на macOS с чипами Apple Silicon.

Короче, ты запускаешь macOS внутри macOS. Пример: у тебя есть MacBook с macOS Sonoma, и ты запускаешь в нём виртуалку с macOS Ventura — как будто второй Mac внутри твоего первого. Какие метрики это поможет улучшить и создаст бизнес импакт — ограничивает только ваша фантазия.

Топ? Топ

Теперь можно оценить всю мощь новости со своим докером от Apple.

Вы переоцениваете UI-архитектуры: Почему архитектуры UI временные и не так важны, как кажется

Разрабатывая приложения многие разрабы начинают с выбора архитектур UI слоя. Это ошибка.

Иногда перечитываю не полностью книги, а отдельные главы. Решил перечитать главу "UI Principle 2: UI architectures come and go" книги "Mobile System Design". Мне очень нравятся мысли и подходы книги и некоторые из них лучше переваривать порциями.

Например, я разделяю мнения, что к UI нужно подходить в конце. Сначала нужно уделить времени другим вещам. Даже автор книги подшучивает что про UI начали говорить только в середине книги.

Автор говорит:

Обычно под словом “архитектура” в мобильной разработке имеют в виду UI-архитектуру, а не архитектуру бизнес-логики (например, API, календарь и т.д.). Но если правильно спроектировать фичу, эти вопросы становятся менее важными. Мы научимся разделять UI и бизнес-логику так, чтобы можно было менять архитектуру без боли.

1️⃣ Первый принцип книги говорит: Откладывай реализацию UI

2️⃣ Второй принцип говорит: UI-архитектуры приходят и уходят

На этом этапе ты можешь задуматься:
“Какую архитектуру выбрать?”

- UIKit или SwiftUI?
- XML или Jetpack Compose?
- MVVM, MVC, MVI, Redux, TCA или вообще что-то своё?

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

Главная суть: Архитектуры как способ договориться внутри команды. Нет критической разницы если одна команда использует в своем модуле MVP, а другая VIPER. Ведь по сути все это одно и то же.

Автор ругает сторонние архитектурные фреймворки за частые изменения, сложность изучения новичкам, миграции в будущем (привет, TCA).

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

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

Не стоит также переживать, что архитектура отличается по приложению и есть старые версии. Это нормально.

Это нормально, когда приложение состоит из разных архитектур, каждая из которых появилась в разное время. Но у них есть общее: Бизнес-логика меняется реже, чем UI.

Новое API по background таскам

Продолжаю делиться самыми интересными новостями с WWDC, которые реально пригодятся вам на практике.

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

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

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

Инструмент должен наконец нам помочь лучше управлять сложными тасками.