Мобильный трудоголик

👨‍💻 Почему некоторые разработчики отказываются от ИИ и что они теряют. Все еще встречаются разработчики, которые однажды попробовали ИИ чат-боты и на этом остановились. ChatGPT в 2022 году выдавал ерунду? Значит нейросети ничего не умеют и пишут ерунду. Никакой логики, почему через три года ситуация могла измениться. Просто застывшее убеждение, подкрепленное отсутствием желания попробовать снова. Как изменились инструменты: За это время технологии шагнули далеко. Современные ИИ не просто отвечают на вопросы - они анализируют весь проект, понимают контекст, вносят правки в несколько файлов одновременно. Да, ошибки случаются. Но частота не идет ни в какое сравнение с тем, что было на заре их появления. Двойные стандарты: При этом те же самые люди спокойно копируют куски кода с форумов, Stack Overflow, случайных статей и видеоуроков. По их мнению код от человека - это нормально, а от машины - плохо. Хотя качество кода из непроверенных источников никто не гарантирует. Про баги: Главный аргумент скептиков - ИИ плодит баги. Но их собственный код тоже далек от идеала. Просто свои ошибки кажутся простительными, а чужие - нет. Человек может накосячить с душой, а машина - бездушно. Но результат для бизнеса одинаковый. Кто на самом деле в выигрыше: Пока одни спорят в комментариях, их коллеги уже используют помощников и сдают задачи быстрее. Разрыв в продуктивности становится все заметнее. И со временем он только увеличится. 🔗 Читать подробнее 💡 Вывод: ИТ развивается непрерывно, и каждый разработчик, который хочет оставаться востребованным, обязан идти в ногу со временем. Инструменты изменились, и игнорировать это изменение означает сознательно отставать. Настоящая ценность специалиста всегда была не в умении печатать код, а в умении принимать архитектурные решения и видеть картину целиком. Отрицание прогресса не защитит карьеру, а только приблизит момент, когда коллеги, использующие современные средства, окончательно уйдут вперед. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

🔢 iOS 27: что изменилось в Siri SDK. Привет! С новым Siri на базе ИИ компания Apple обещает, что можно будет просто сказать «Найди ту футболку, которую я хотел купить пару месяцев назад» и Siri найдет ответ. Но как это работает для сторонних приложений? В iOS 27 обновился Siri SDK. Теперь приложения могут лучше интегрироваться с голосовым ассистентом. Разберем ключевые улучшения. AppEntity и IndexedEntity: Для того чтобы ваши данные могли участвовать в запросах к Siri, нужно создать легкую версию модели - AppEntity. Это не сама модель, а ее описание для системы. struct TeamEntity: AppEntity { static var defaultQuery = TeamEntityQuery() let id: String @Property(title: "Team Name") var name: String @Property(title: "Roster Size") var rosterSize: Int } Если ваши данные можно индексировать, достаточно добавить IndexedEntity. Система автоматически проиндексирует контент и Siri сможет его искать. extension TeamEntity: IndexedEntity {} С помощью @Property(indexingKey:) можно указать, какие именно поля должны участвовать в поиске. App Schemas: Apple подготовила готовые схемы для популярных типов данных: сообщения, контакты, задачи. Если ваше приложение попадает в одну из этих категорий, нужно просто указать схему через @AppEntity. @AppEntity(schema: .messages.message) struct MessageEntity: IndexedEntity { @Property(indexingKey: \.textContent) var body: AttributedString? } Xcode подсказывает доступные поля. Apple уже настроила Siri на понимание этих схем - контекст, уточняющие вопросы и связки между действиями работают почти без дополнительного кода. On-screen Awareness: Чтобы Siri могла отвечать на вопросы о том, что сейчас на экране, есть два подхода. NSUserActivity для одного элемента (например, фотографии). View annotations для списков (например нескольких сообщений или контактов). .userActivity("com.example.entity", element: entity.asEntity()) { entity, activity in activity.title = entity.title } Или с помощью модификатора .appEntityIdentifier. .appEntityIdentifier(EntityIdentifier(for: Entity.self, identifier: p.id)) Передача данных через Transferable: Для обмена данными между приложениями через Siri (например «Отправь это письмо» или «Создай событие») используется Transferable. extension TeamEntity: Transferable { static var transferRepresentation: some TransferRepresentation { IntentValueRepresentation( exporting: { entity in IntentPerson(name: .displayName(entity.name)) }, importing: { person in ContactEntity(name: person.name.displayString) } ) } } 🔗 Читать подробнее 💡 Вывод: Новый Siri SDK делает интеграцию с голосовым ассистентом более структурированной. AppEntity, IndexedEntity и готовые схемы закрывают большинство сценариев. On-screen Awareness позволяет приложениям делиться контекстом с Siri. Transferable дает возможность передавать данные между приложениями. Но есть белое пятно: что делать, если приложение не попадает в готовые схемы Apple? Как использовать весь потенциал нового Siri в этом случае? Ответа пока нет. Тем не менее, для большинства приложений подход понятный и достаточно простой. Начать стоит с конформности IndexedEntity - это самый быстрый способ сделать данные доступными для Siri без глубокой перестройки архитектуры. Подписаться на канал: ➡️ Telegram | Max

🔢 iOS 27: что нового в SwiftData. С момента появления SwiftData разработчики периодически сталкивались с ограничениями. Фильтрация по enum требовала костылей. Группировка данных в секции была недоступна. Наблюдение за изменениями вне SwiftUI View - сложной задачей. В iOS 27 компания Apple закрыла большинство этих пробелов. Разберем ключевые улучшения. Enum-предикаты стали реальностью: До iOS 27 фильтрация по enum-свойствам была больной темой. Если модель содержала enum, приходилось сохранять его raw-значение в отдельное поле и строить предикаты уже на основе него. Теперь это работает напрямую. _books = Query(filter: #Predicate<Book> { $0.category == .fiction }) Модель становится чище. Не нужно дублировать данные только для фильтрации. Группировка в секции: Появилась поддержка группировки результатов через параметр sectionBy в макросе @Query. @Query(sort: \Expense.name, sectionBy: \Expense.budgetName) var expenses: [Expense] При этом данные группируются прямо в базе, а не в памяти. Есть ограничение: значение для группировки должно быть сохраненным свойством. Связанные свойства (например, expense.budget?.name) пока не поддерживаются. Приходится дублировать данные. Составные предикаты: Раньше, чтобы объединить несколько условий, нужно было собрать все в один большой предикат. Сейчас появились Predicate(all:) и Predicate(any:). let searchPredicate = #Predicate<Book> { $0.name.localizedStandardContains(search) } let bestSellerPredicate = #Predicate<Book> { $0.isBestSeller == isBestSeller } _books = Query( filter: Predicate(all: [searchPredicate, bestSellerPredicate]) ) Удобно для динамических фильтров. Предикаты можно собирать по частям и комбинировать. Атрибут .codable: Новый параметр для макроса @Attribute. Если тип нельзя разложить на колонки, но он реализует Codable, SwiftData может сохранить его как BLOB. @Attribute(.codable) var identifier: MKMapItem.Identifier Важный нюанс: данные, сохраненные через .codable, нельзя использовать в фильтрах и сортировках. Это просто сериализованный кусок данных. 🔗 Читать подробнее 💡 Вывод: SwiftData в iOS 27 стала более практичной. Меньше костылей, больше возможностей. Enum-предикаты убирают дублирование. Секции упрощают представление данных. .codable закрывает проблему со сложными типами. ResultsObserver позволяет строить логику на изменениях без привязки к UI. Это не революция, но плотное обновление, которое делает SwiftData пригодным для более сложных проектов. Особенно тех, где данные нужно не просто показывать, но и обрабатывать, синхронизировать и обновлять за пределами интерфейса. Но еще не все проблемы решены. Группировка по связанным свойствам до сих пор не работает. Хранилище изменений через HistoryObserver требует ручной работы с токенами. Но направление верное. Подписаться на канал: ➡️ Telegram | Max

🔢 iOS 27: CADisplayLink для UIWindowScene. В iOS 27 компания Apple изменила подход к работе с CADisplayLink. Раньше его создавали через UIScreen. Теперь через UIWindowScene. Изменение выглядит небольшим, но оно меняет модель владения и делает код более предсказуемым в многоконных приложениях. В чем разница между Timer и CADisplayLink: Timer и CADisplayLink решают разные задачи. Timer привязан к интервалам времени, он срабатывает по расписанием цикла выполнения. CADisplayLink синхронизирован с частотой обновления экрана. Это принципиальная разница. Timer подходит для задач, где не важен каждый кадр. Обратный отсчет, периодический опрос сервера, обновление данных в фоне. CADisplayLink для визуальных задач, где важна плавность и синхронизация с экраном. Анимации, игры, рендеринг, физика. Если попытаться использовать Timer для визуального движения, он будет менее плавным, потому что Timer не учитывает момент обновления кадров. Он просто срабатывает, когда приходит время. Что нового в iOS 27: В iOS 27 компания Apple добавила новый способ создания CADisplayLink прямо через UIWindowScene. Старый метод через UIScreen объявлен устаревшим. // Новый способ в iOS 27 if let scene = view.window?.windowScene { displayLink = scene.displayLink { link in print(link.targetTimestamp - link.timestamp) } displayLink?.add(to: .main, forMode: .common) } Это логичный шаг. В многоконных приложениях, особенно на iPad с Stage Manager, одна сцена активна, другая нет, третья вообще на другом дисплее. Глобально думать про экран становится неудобно. Проще сказать: «вот конкретная UIWindowScene и вот работа, которая должна синхронизироваться с ее дисплеем». Почему это важно: Это улучшает модель владения. Если анимация или рендеринг принадлежат конкретному окну, то и CADisplayLink должен жить рядом с этим окном. Так проще управлять жизненным циклом, а не продолжать делать работу для сцены, которая уже неактивна. В многоконных приложениях становится проще думать о поведении каждой сцены отдельно. Одна сцена может обновляться с частотой 120 Гц, другая с 60 Гц. CADisplayLink, привязанный к конкретной сцене, автоматически подстраивается под ее дисплей. Когда использовать CADisplayLink, а когда Timer: Главное, что стоит запомнить: 🔵CADisplayLink нужен, когда работа связана с визуальным отображением и важна плавность. Пользовательские анимации, прогресс-бары, игровые циклы, синхронизация с рендерингом. 🔵Timer для всего остального. Обратный отсчет, обновление данных по расписанию, фоновые задачи. Он проще, дешевле и не требует такой аккуратной работы с жизненным циклом. CADisplayLink не замена Timer. Это специализированный инструмент для визуальных задач. 🔗 Читать подробнее 💡 Вывод: CADisplayLink в iOS 27 стал более сцено-ориентированным. Это небольшое API-изменение, но важное архитектурное решение. Оно отражает вектор развития UIKit в сторону многоконных приложений. Для разработчиков это значит, что визуальную работу теперь удобнее привязывать к конкретной сцене, а не к глобальному экрану. Проще управлять жизненным циклом, проще думать о многоконном поведении. Но главное правило остается прежним: CADisplayLink - это не универсальный таймер. Это инструмент для визуальных задач, где важна синхронизация с кадрами. Для всего остального есть Timer. Подписаться на канал: ➡️ Telegram | Max

🤖 Claude Code теперь умеет запускать и тестировать приложения в симуляторе. В Claude Code на десктопе появилась поддержка iOS Simulator. Теперь агент может запускать приложение в симуляторе, управлять им, делать скриншоты и проверять работу интерфейса. Панель с симулятором открывается прямо в приложении, рядом с чатом. Это не требует прав на доступ к экрану и не переключает рабочие окна. Как это работает: Когда Claude собирает или запускает приложение, он автоматически открывает симулятор в специальной панели. Можно попросить его проверить конкретный экран, пройти по потоку или зафиксировать баг. Симулятор показывает устройство в реальном времени. Видно, что делает агент и можно в любой момент вмешаться. Управлять симулятором можно как через Claude, так и вручную. Клики, свайпы, кнопки Home и Lock, поворот экрана - все работает прямо из панели. Можно делать скриншоты и записи экрана. Важно: у каждого сеанса свой симулятор. Это значит, что параллельные сессии не мешают друг другу. Что важно знать про доступ: Claude запрашивает разрешение на управление симулятором один раз на устройство. После того как вы разрешили, он может кликать, вводить текст и делать скриншоты без дополнительных запросов. Это не требует прав на доступ к экрану, потому что все происходит внутри симулятора. Действия вроде открытия URL или сборки проекта следуют обычным правилам разрешений. Их можно настроить отдельно. Если нужно отключить доступ - есть настройка в приложении. Для организаций доступны управляемые политики, которые отключают симулятор для всех. 🔗 Читать подробнее 💡 Вывод: Поддержка iOS Simulator в Claude Code - это шаг в сторону более глубокой интеграции агентов в процесс разработки. Теперь можно не просто генерировать код, но и проверять его работу в симуляторе. Агент сам запускает приложение, кликает по экранам, проверяет изменения. Разработчик видит все в реальном времени и может вмешаться в любой момент. Это не замена ручного тестирования, но серьезное ускорение для рутинных проверок. Особенно когда нужно быстро убедиться, что правка не сломала UI или поток. И главное - не приходится переключаться между окнами и терять контекст. Подписаться на канал: ➡️ Telegram | Max

👣 Как запустить Flutter-приложение на iPhone без Mac и подписки Apple Developer Всем привет! Недавно наткнулся на статью, в которой разработчик делится опытом тестирования Flutter-приложения на iPhone друга без Mac и без подписки Apple Developer. Знакомая ситуация: есть приложение на Flutter, нужно показать кому-то с iPhone. Mac нет, платить $99 в год за Apple Developer Program жалко. Оказывается, есть рабочий путь, и автор его подробно описал. Не магия, а грамотная сборка цепочки из четырех инструментов. Почему iOS сложнее Android: На Android тестовая установка занимает пятнадцать минут. Включил отладку по USB, запустил adb install, готово. Google Play Console - $25 единоразово. RuStore - бесплатно. С iPhone все иначе. Официальный путь Apple: Mac для Xcode, подписка $99 в год, TestFlight. Дорого и не всегда доступно. Схема из четырех шагов: Есть обходной путь, который обходится без Mac и без платной подписки. 🔵Первый шаг: включить на iPhone режим разработчика. Начиная с iOS 16, Apple вынесла этот тумблер в отдельный раздел, но он не появляется, пока на устройство не установлено dev-signed приложение. Чтобы обойти это, используется утилита Tenorshare iCareFone на Windows. Подключаете телефон, нажимаете «Enable Developer Mode», подтверждаете на телефоне. Тумблер появляется в настройках. Включаете его один раз. 🔵Второй шаг: собрать неподписанный .ipa через GitHub Actions. В бесплатных macOS-раннерах запускается сборка Flutter под iOS. Важно зафиксировать версию Flutter, использовать flutter precache --no-android --no-web для экономии времени и собирать с флагом --no-codesign. После сборки артефакт сохраняется в Actions. 🔵Третий шаг: подписать и установить через Sideloadly на Windows. Утилита подписывает .ipa вашим бесплатным Apple ID и ставит на телефон по USB. Подпись действует семь дней, максимум три приложения одновременно. Для тестирования достаточно. 🔵Четвертый шаг: подтвердить доверие на устройстве. При первом запуске iOS попросит подтвердить доверие профилю разработчика в настройках. Один раз - и приложение запускается. Нюансы, которые важно знать: 🔵У бесплатного Apple ID подпись живет 7 дней. Через неделю приложение перестанет запускаться - нужно перекатать через Sideloadly. 🔵Sideloadly может менять Bundle ID, добавляя суффикс. В этом случае при обновлении приложение будет восприниматься как новое, данные пользователя сбросятся. 🔵Если используется Firebase, файлы конфигурации должны быть в репозитории. Иначе сборка на CI упадет. 🔵Версию macOS-раннера лучше фиксировать явно, потому что macos-latest переключается на новые версии и сборка может сломаться. 🔗 Читать подробнее 💡 Вывод: Тестировать Flutter-приложение на iPhone без Mac и без $99 реально. Схема из четырех инструментов работает. Основная сложность не в настройке, а в том, чтобы найти все куски и собрать их в одно целое. Для инди-разработчика это рабочий путь, чтобы показать приложение друзьям и тестировщикам. Для полноценного релиза в App Store придется решать вопрос с оплатой подписки. Но тестирование на железе перестает быть барьером. Подписаться на канал: ➡️ Flutter & Dart | Мобильный трудоголик

🈸 Apple начала отклонять приложения за запросы отзывов на онбординге. Apple ужесточила контроль за запросами отзывов в приложениях. Раньше многие разработчики просили пользователей оценить приложение на экране онбординга, до того как человек успел сделать что-то полезное. Сейчас за такую практику приложения начали отклонять при ревью. Почему это происходит: В App Store Review Guidelines есть пункт 5.6.3, который запрещает манипуляции с элементами пользовательского опыта - чартами, поиском, отзывами. Раньше Apple не применяла его к запросам отзывов на онбординге, но теперь это изменилось. Некоторые приложения собирали тысячи оценок 5 звезд еще до того, как пользователь совершил хотя бы одно действие. Это считалось серой зоной. Сейчас Apple явно дала понять: такая практика больше недопустима. Пока неизвестно, будут ли проверять уже опубликованные приложения. Но при обновлении версий за такой подход могут отклонить. Когда просить отзыв правильно: Apple рекомендует запрашивать отзыв в естественные и радостные моменты - когда пользователь завершил действие, достиг чего-то или сформировал мнение о приложении. Это значит, что онбординг - неподходящее место. Первое открытие приложения и заполнение профиля - тоже. Нужно дождаться момента, когда пользователь реально взаимодействовал с приложением. Для этого стоит отслеживать действия, которые говорят о вовлеченности: завершение задачи, достижение цели, возвращение в приложение после нескольких дней использования. 🔗 Читать подробнее 💡 Вывод: Apple больше не позволяет собирать рейтинги до первого действия пользователя. Запрос отзыва на онбординге теперь причина для реджекта. Это не новый гайдлайн, но раньше Apple не была такой строгой. Если в вашем приложении есть такой запрос, лучше убрать его до следующего обновления. Вместо этого стоит научиться определять момент, когда пользователь действительно сформировал мнение о приложении. Это может быть завершение задачи, достижение цели или несколько дней активного использования. Так рейтинги будут честнее, а приложение не отклонят. Подписаться на канал: ➡️ Telegram | Max

👨‍💻 Паника вокруг ИИ: где правда, а где преувеличение. Наткнулся на статью Мэтта Шумера (предпринимателя и инвестора в сфере ИИ) под названием «Something Big Is Happening» (Происходит что-то серьезное), в которой он честно описывает, что происходит в его индустрии. И его слова звучат тревожно. Но важно помнить, что нейросети - это прежде всего инструмент. И как любой инструмент, он обесценивает не профессию, а бесполезность. Переживания автора: Шумер утверждает, что ИИ уже заменил его в технической части работы. Он описывает результат, уходит на четыре часа, а возвращается к готовому продукту. ИИ сам пишет десятки тысяч строк кода, сам тестирует, сам исправляет ошибки. По его словам, это уже реальность. ИИ уже помогает разрабатывать следующий ИИ. Каждое поколение умнее предыдущего, а темп ускоряется. Он считает что следующие профессии тоже под угрозой: юристы, финансисты, врачи, бухгалтеры, писатели. Срок - от одного до пяти лет. Где автор абсолютно прав: Он прав в том, что разрыв между общественным восприятием и реальностью огромен. Большинство людей пробовали бесплатные версии ChatGPT образца 2024 года и сделали вывод: «Ничего особенного». Но платные модели (Claude Opus 4.6, GPT-5.2 и выше) - это совсем другая лига. Они уверенно сдают экзамены, пишут юридические документы и анализируют финансовые модели. Он также прав насчет сроков. Речь не идет о «через десять лет». Внедрение ИИ в юриспруденцию, бухгалтерию, поддержку клиентов идет уже сегодня. Управляющие партнеры крупных фирм, о которых пишет Шумер, не дураки. Они видят, что 20 долларов в месяц за подписку дают им мгновенную команду стажеров. Экономия времени и денег очевидна. Значит, через 1-3 года число вакансий для младших специалистов в этих сферах действительно сократится. Где я с ним не согласен: Да, ИИ стал невероятно мощным инструментом. Да, он ускоряет разработку в разы. Да, он берет на себя рутинные задачи и генерацию шаблонного кода. Но он не заменит действительно хороших программистов. Он заменит лишь тех, кто не составляет ценности для компании и команды. Если ваша задача - просто брать готовое техническое задание и превращать его в строчки кода, без попытки понять, зачем это нужно и как это впишется в общую картину - ИИ справится с этим лучше и быстрее. Если вы не решаете реальных проблем бизнеса, не влияете на продукт, не несете ответственности - вас действительно могут заменить. 🔗 Читать подробнее 💡 Вывод: Статья Шумера - хороший сигнал, но не повод для паники. ИИ меняет рынок, но не отменяет ценность настоящих инженеров. Если вы просто кодите по заданию - пора задуматься. Если вы решаете проблемы бизнеса - вам ничего не угрожает. Более того, у вас появляется новый мощный инструмент. А паниковать стоит тем, кто десятилетиями ничего не менял в своей работе и надеялся, что так будет всегда. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

🔢 Тайпчекер в Swift 6.4 стал быстрее. В Swift 6.4 продолжается работа над улучшением тайпчекера. Знаменитая ошибка «The compiler is unable to type-check this expression in reasonable time» во многих ситуациях теперь будет появляться реже. Слава Пестов в большом посте на Swift Forums делится прогрессом по роадмапу и показывает, как это работает на практике. О проблеме известно давно: Тайпчекер в Swift - это сложная система, которая пытается вывести типы выражений, когда они не указаны явно. Чем больше перегрузок, дженериков и неявных преобразований, тем сложнее компилятору найти правильный тип. Иногда он перебирает слишком много вариантов и либо выдает ошибку, либо компилирует слишком долго. В Swift 6.3 добавили механизм favoring - когда компилятор пытается угадать наиболее вероятный вариант перегрузки и проверяет его первым. Это работает хорошо, когда угадывание правильное. Но если нет - компилятор все равно перебирает все варианты, и это может занять много времени. Что изменилось в Swift 6.4: В Swift 6.4 появился механизм, который называется disjunction pruning - обрезка перегрузок. Суть простая: когда компилятор проверяет конкретную перегрузку функции, он может понять, что она точно не подходит. В таком случае он просто исключает этот вариант из рассмотрения. Раньше компилятор мог потратить время на перебор вариантов, которые заведомо не работают. Теперь он сразу понимает, что вариант не подходит, и даже не пытается его проверить. Это работает в двух направлениях. Если из всех вариантов остался только один подходящий - компилятор сразу выбирает его, не тратя время на остальные. Если же подходящих вариантов не осталось - компилятор сразу понимает, что выражение ошибочно, и не пытается перебирать дальше. Улучшения в binding inference: Вторая важная область - вывод конкретных типов из неявных преобразований. Раньше, когда компилятор видел выражение вроде Int conv $T (где $T - неизвестный тип), он не мог сразу понять, чему равен $T. Приходилось откладывать решение и перебирать варианты позже. В Swift 6.4 появилась более точная логика, которая анализирует все ограничения на тип одновременно. Если все ограничения указывают на единственный возможный тип - компилятор выбирает его сразу. Если же ограничения противоречат друг другу - компилятор понимает, что выражение ошибочно, и не тратит время на перебор. Что это дает на практике: Есть несколько примеров, которые раньше компилировались очень долго или вообще не компилировались. 🔵Побитовые операции с UInt64: func f(word: UInt64, offset: Int, numBits: Int) -> UInt { return UInt((word >> offset) & ((1 << numBits) - 1) & ((1 << numBits) - 1) & ((1 << numBits) - 1)) } В Swift 6.3 это выражение было слишком сложным для тайпчекера. В Swift 6.4 компилируется мгновенно. 🔵Операции с SIMD: func f() { let u = SIMD2<Float>(0, 1) let v = SIMD2<Float>(1, 2) let r = [2*u + 3*v, 4*u + 5*v, 5*u + 6*v, 6*u + 7*v] } Теперь тоже компилируется быстро. 🔵Словари с IUO (implicitly unwrapped optional): func f(str: CFString!) { let _ = [ str: String(str), str: String(str), str: String(str) ] } Раньше было слишком сложно, теперь - мгновенно. 🔵Цепочки вызовов с lazy, flatMap, map, filter - раньше занимали секунды, теперь миллисекунды. 🔗 Читать подробнее 💡 Вывод: Swift 6.4 не делает тайпчекер идеальным, но делает его заметно быстрее в распространенных сценариях. Механизмы disjunction pruning и улучшенный binding inference позволяют компилятору быстрее принимать решения и избегать перебора заведомо неподходящих вариантов. Это не решит все проблемы с тайпчекингом, но во многих случаях ошибка «unable to type-check in reasonable time» станет встречаться реже. А в некоторых сложных выражениях компиляция ускорится в десятки раз. Хорошее улучшение для повседневной разработки. Подписаться на канал: ➡️ Telegram | Max

🔢 От ScrollViewReader до ScrollPosition - как изменилась программная прокрутка в SwiftUI. До iOS 17 программный скролл в SwiftUI требовал использования ScrollViewReader. Этот контейнер давал доступ к ScrollViewProxy с единственным методом scrollTo(_:anchor:). API было односторонним: можно было задать позицию, но нельзя было прочитать, где находится пользователь. Скролл к краю или к конкретному оффсету тоже был проблемой - приходилось ставить якорные вью на границах контента. Начиная с iOS 17, SwiftUI начал менять подход. scrollPosition(id:anchor:) заменил прокси-подход на привязку к состоянию. А iOS 18 добавил еще больше возможностей. Как задать начальную позицию: По умолчанию ScrollView показывает верхнюю часть контента. defaultScrollAnchor(_:), появившийся в iOS 17, позволяет изменить это поведение. Типичный пример - чат, где контент должен начинаться снизу. ScrollView { LazyVStack { ForEach(messages) { message in MessageView(message: message) } } } .defaultScrollAnchor(.bottom) В iOS 18 появилась более точная перегрузка defaultScrollAnchor(_:for:), которая принимает ScrollAnchorRole. Например, роль alignment позволяет центрировать небольшой контент, сохраняя нижнюю привязку для длинных списков. Программный скролл через scrollPosition: iOS 17 добавил scrollPosition(id:anchor:) для управления скроллом через привязку к состоянию. iOS 18 расширил API: появился scrollPosition(_:anchor:) с привязкой к ScrollPosition. Это структура, которая может хранить позицию как идентификатор, край или сырой оффсет. Пример: кнопка для перехода к последнему сообщению в чате. Объявляем ScrollPosition, передаем в модификатор и вызываем scrollTo(id:) при нажатии. struct ChatView: View { let messages: [Message] @State private var position = ScrollPosition() var body: some View { ScrollView { LazyVStack { ForEach(messages) { message in MessageView(message: message) .id(message.id) } } } .defaultScrollAnchor(.bottom) .scrollPosition($position) .onAppear { position = ScrollPosition(id: messages.last?.id) } .safeAreaBar(edge: .bottom) { Button { withAnimation { position.scrollTo(id: messages.last?.id) } } label: { Text("Перейти к последнему") } } } } 🔗 Читать подробнее 💡 Вывод: SwiftUI прошел путь от ScrollViewReader с односторонним управлением до гибкого API с двусторонней связью. Теперь можно не только двигать скролл, но и читать его состояние. Ключевые инструменты: defaultScrollAnchor для начальной позиции, scrollPosition для управления и чтения, onScrollGeometryChange для отслеживания геометрии. API мощные, но с нюансами. viewID - единственный способ читать позицию при ручной прокрутке. edge, point, x и y работают только для программно установленных значений. Понимание этих различий помогает строить интерфейсы, которые естественно реагируют на действия пользователя. Подписаться на канал: ➡️ Telegram | Max

🈸 Как изменится продвижение приложений в App Store с выходом iOS 27. На WWDC26 компания Apple показала несколько обновлений, которые касаются не только разработчиков, но и тех, кто занимается продвижением приложений. Изменения в App Store и App Store Connect затронули визуальное оформление карточек, управление креативами и персонализацию рекомендаций. Header вместо Feature Banner: В карточке приложения появился новый визуальный элемент - Header. Раньше на этом месте мог быть только баннер, который добавлялся через модерацию Apple и был доступен не всем. Теперь хэдер можно будет загружать самостоятельно через App Store Connect. Главное отличие от скриншотов и промороликов - header не обязан показывать только интерфейс приложения. Это может быть брендовый креатив, сезонное изображение, видео с атмосферой продукта. Например приложение доставки еды может показывать аппетитный бургер, а не скринкаст с каталогом товаров. Хэдер можно использовать в нескольких местах: на главной странице приложения, в поисковой выдаче, на странице с товарами приложения и в рекламных объявлениях Apple Ads. Причем это один и тот же ассет, который загружается один раз и применяется в разных местах. Те приложения, которые не внедрят качественные хэдер, рискуют потерять клики и установки на фоне конкурентов. Визуал в выдаче становится еще одним фактором конкуренции. Библиотека ассетов: Самое практичное изменение - появление Asset Library в App Store Connect. Теперь все медиа (скриншоты, проморолики, хэдер) хранятся в одном месте и организованы по платформам и размерам. Главное преимущество: креативы можно загружать и отправлять на модерацию без выпуска нового билда приложения. Раньше, чтобы поменять скриншоты к новому году или подстроить графику под рекламную кампанию, нужно было ждать новый релиз. Теперь маркетинг не зависит от разработчиков при работе с визуальным составляющим в App Store. Загруженные ассеты можно переиспользовать в разделе с товарами приложения, In-App Events и рекламных кампаниях. Все из одной библиотеки, без дублирования загрузок. Персонализированные рекомендации: Apple анонсировала новый тип подборок - персонализированные коллекции. Они формируются не модераторами, а алгоритмами на основе поведения пользователя. App Store анализирует, какие приложения пользователь устанавливает и как использует, и на основе этого адаптирует рекомендации. Коллекции будут появляться на вкладках «Приложения», «Игры» и в поиске. К каждому приложению будет выводиться объяснение, почему оно релевантно конкретному пользователю. Для маркетологов это означает, что органический трафик станет качественнее, но менее предсказуемым. Алгоритмы - это черный ящик. Чтобы попадать в рекомендации, придется работать в тесной связке с разработчиками. App Intents теперь важны не только для Siri, но и для того, чтобы алгоритмы Apple Intelligence правильно считывали семантику приложения и понимали, кому его рекомендовать. 🔗 Читать подробнее 💡 Вывод: WWDC26 принесла несколько полезных обновлений для тех, кто продвигает приложения в App Store. Хэдер добавляет новый визуальный слой в карточку приложения и поисковую выдачу. Библиотека ассетов убирает зависимость маркетинга от разработчиков при работе с визуалом. Персонализированные рекомендации открывают новые возможности для органического трафика, но требуют более тесной работы с семантикой приложения. Самое важное изменение - маркетинг теперь может обновлять креативы независимо от релизов. Это серьезно упрощает работу с визуалом и ускоряет эксперименты. Если вы занимаетесь продвижением приложений, стоит изучить новые возможности до осеннего релиза iOS 27. Подписаться на канал: ➡️ Telegram | Max

👣 GenUI в действии: команда Flutter раздала 3000 чашек кофе с ИИ-рисунками на пенке Команда Flutter решила поделиться опытом создания необычного демо-проекта, который они показали посетителям Google Cloud Next и Google I/O. В статье разработчики рассказывают, как построили приложение для кофейни, где каждый посетитель мог заказать латте с изображением, сгенерированным нейросетью прямо на пенке. Проект назывался GenLatte. За два мероприятия команда раздала 3000 чашек. Как это работает: На первый взгляд все просто. Посетитель подходил к киоску, открывал веб-версию Flutter-приложения и описывал свое место мечты. Это могло быть что угодно: домик у озера, снежный лес, закат на пляже. Промпт ограничивался 50 символами, чаще всего это было одно-два слова. Дальше в дело вступала нейросеть Nano Banana. Система брала короткую фразу и разворачивала ее в полноценный промпт для генерации изображения. При этом создавалось сразу четыре варианта картинки, все разные по композиции и настроению. Пользователь выбирал понравившийся и изображение отправлялось на печать на пенке латте. Персонализация через GenUI: Самое интересное происходило после того, как пользователь видел сгенерированные изображения. Под каждой картинкой была кнопка Tweak - это была не просто доработка фильтра, а полноценная генеративная настройка через UI. Gemini предварительно подготавливал четыре вопроса о том, как можно изменить изображение. Например, для домика у озера это могли быть вопросы о времени суток, погоде, наличии людей или конкретных деталях. В зависимости от выбранного типа вопроса система подставляла разные элементы управления: текстовое поле для открытых вопросов или кнопки для выбора из вариантов. Это и есть GenUI в действии - интерфейс, который собирается на лету под конкретную задачу. После того как пользователь отвечал на вопросы, система отправляла обновленный промпт обратно в Nano Banana и генерировалась новая версия изображения. Все это происходило в реальном времени. Техническая архитектура: Проект построен на Flutter и Firebase. Вся логика собрана в монорепозитории, где объединены Flutter-приложение, Firebase-бэкенд и общий код для бизнес-логики. Такой подход позволил избавиться от дублирования зависимостей, переиспользовать код и выполнять атомарные деплои. Внутри самого Flutter-приложения было реализовано пять отдельных экранов: 🔵Экран заказа для посетителей. 🔵Экран бариста с актуальными заказами. 🔵Экран модератора для проверки безопасности контента. 🔵Экран очереди для ожидающих. 🔵Экран с недавними заказами в виде плавающих пузырьков. 🔗 Читать подробнее 💡 Вывод: GenLatte - это не просто забавный демо-проект. Это показательный пример того, как Flutter, Firebase и генеративный ИИ работают вместе в реальных условиях. 3000 чашек кофе - это не шутка. Проект показал, что с помощью Flutter можно быстро собирать сложные мультиплатформенные приложения, а Firebase закрывает все вопросы с бэкендом и масштабированием. И главное - GenUI перестает быть абстрактной концепцией. Приложение само решало, какой интерфейс показать пользователю в ответ на его действия. Конечно, код проекта доступен в репозитории flutter/demos, но авторы предупреждают: он не поддерживается и предназначен только для вдохновения. А вдохновения там действительно много. Когда в ближайшее время задумаетесь о том, как можно применить генеративный ИИ в своем проекте - вспомните историю о латте с нейросетевым рисунком. Это хорошая иллюстрация того, насколько широко могут разойтись технологии, которые вчера казались просто игрушками. Подписаться на канал: ➡️ Flutter & Dart | Мобильный трудоголик

🍎 Apple купила Play: Create Better Apps - приложение, которое помогало создавать прототипы интерфейсов приложений на SwiftUI. Apple продолжает приобретать инструменты для разработчиков. Вслед за Swift Package Index компания купила Rabbit 3 Times - создателей приложения Play. Это визуальный конструктор для iOS и macOS, который позволял быстро создавать прототипы на SwiftUI. Что такое Play: Play - это бесплатный инструмент, в котором разработчики и дизайнеры могли собирать интерфейсы с помощью SwiftUI-фреймворков и сразу видеть, как они будут выглядеть на устройстве. Готовые проекты можно было экспортировать в Xcode через платный сервис Play to Xcode. В июне 2025 года Play получил Apple Design Award в номинации «Инновации». Apple тогда написала: «Play - это продуманный и доступный инструмент, который позволяет создавать интерактивные прототипы с использованием SwiftUI-фреймворков». Что известно о сделке: Apple сообщила о сделке в Европейскую комиссию в феврале 2026 года. В документах указано, что Apple приобретает активы компании Rabbit 3 Times и получает право нанять часть сотрудников. Это типичная схема acquihire - покупка не столько продукта, сколько команды. Условия сделки не раскрываются. Но уже в апреле 2026 года компания Rabbit 3 Times объявила о прекращении поддержки Play для iPhone и Mac. Приложения исчезли из App Store. Платный сервис Play to Xcode стал бесплатным для облегчения перехода. На сайте компании осталось только сообщение: «Мы работаем над чем-то новым». Зачем это Apple: Вариантов несколько: 🔹Первый: Apple купила Play ради сотрудников. Команда Rabbit 3 Times - опытные разработчики, которые уже доказали, что умеют создавать сложные инструменты на SwiftUI. Такие люди всегда нужны. 🔹Второй: Apple хочет использовать наработки Play для улучшения Xcode. Визуальный конструктор, который генерирует SwiftUI-код, может лечь в основу нового инструмента внутри Xcode. 🔹Третий: Play может стать основой для визуального Xcode - альтернативы Swift Playground, но для взрослых разработчиков. Сейчас в экосистеме Apple есть пропасть между Playground (для обучения) и полноценным Xcode. Play как раз закрывал этот промежуток. 🔗 Читать подробнее 💡 Вывод: Apple продолжает собирать инструменты для разработчиков. Play - вторая крупная покупка за последнее время. Как и в случае с Swift Package Index, компания забирает то, что уже работает в сообществе. Play был удобным инструментом для быстрого прототипирования на SwiftUI. Теперь его больше нет в открытом доступе. Остается надеяться, что наработки не пропадут, а появятся в Xcode в том или ином виде. Подписаться на канал: ➡️ Telegram | Max

🔢 Что нового в Swift 6.4. Разбираем изменения с WWDC26. На WWDC26 компания Apple представила Swift 6.4 - очередное обновление языка, которое делает повседневный код чище и выразительнее. В этом материале - самое важное из того, что появилось в новой версии. anyAppleOS - теперь доступность проще: Раньше, чтобы указать, что API доступен на всех платформах Apple, приходилось перечислять каждую ОС отдельно. В Swift 6.4 это можно сделать одной строкой. // Было @available(macOS 27, iOS 27, watchOS 27, tvOS 27, visionOS 27, *) func showStatus() { ... } // Стало @available(anyAppleOS 27, *) func showStatus() { ... } Если для одной платформы нужно другое поведение, можно комбинировать anyAppleOS с переопределением. Тот же токен работает внутри #if os(anyAppleOS). @diagnose - точное управление предупреждениями: Новый атрибут @diagnose позволяет управлять предупреждениями на уровне отдельных объявлений. Можно подавить предупреждение, превратить его в ошибку или оставить как есть. @diagnose(DeprecatedDeclaration, as: ignored, reason: "Миграция постепенно") func makeApolloMission() -> Mission { CrewedMission(rocket: makeSaturnIRocket(), ...) } Это точечный инструмент, а не флаг на весь проект. Особенно полезно при поэтапной миграции или проверке критических участков кода. Что нового в работе с Sendable: В Swift 6.4 исправили несколько мелких неудобств. weak var раньше требовал @unchecked Sendable. Теперь можно писать weak let и это проходит обычную проверку Sendable. final class Spacecraft: Sendable { weak let dockedAt: SpaceStation? } Если класс должен явно отказаться от Sendable, теперь это можно указать через ~Sendable. class Mission: ~Sendable { ... } Async внутри defer: Раньше вызвать асинхронную функцию из блока defer было нельзя - приходилось писать обходные решения. В Swift 6.4 это ограничение убрали. defer { await logger.flush() } Защита от отмены задачи: withTaskCancellationShield создает участок кода, где Task.isCancelled всегда возвращает false. Это нужно для операций, которые должны завершиться даже после отмены задачи - например, сброс буфера файла, чтобы избежать повреждения данных. extension EmergencyTransponder { func sendSOS() { withTaskCancellationShield { radio.send(makeSOSPacket()) } } } mapKeyedValues для словарей: Существующий mapValues передает в замыкание только значение. Новый mapKeyedValues дает и ключ и значение. let displayNames = missions.mapKeyedValues { mission, window in makeDisplayName(for: mission, in: window) } FilePath в стандартной библиотеке: Тип FilePath переехал из Swift System в стандартную библиотеку. Он корректно обрабатывает различия в представлении путей между платформами и парсит компоненты единообразно. var path: FilePath = "/Users/khoa/Documents" path.components.append("Projects") path.components.append("app") print(path.components) // [ "Users", "khoa", "Documents", "Projects", "app" ] 🔗 Читать подробнее 💡 Вывод: Swift 6.4 - не революционный, но очень плотный релиз. Apple сфокусировалась на том, чтобы убрать мелкую боль из повседневного кода и одновременно добавить инструменты для высокопроизводительной и кроссплатформенной разработки. Из новинок стоит обратить внимание на anyAppleOS, @diagnose, улучшения при работе с Sendable и новые типы для работы с памятью. Подписаться на канал: ➡️ Telegram | Max Закрытый канал: 🚀 Мобильный трудоголик PRO

🔢 Инструменты отладки в Swift, которые часто используют сеньоры. В Swift есть встроенные механизмы, которые делают отладку быстрее и чище. Они не требуют подключения дебаггера, не заставляют вас ставить брейкпоинты и часами шагать по каждой строчке кода. Сеньоры используют их постоянно, а джуны часто проходят мимо, потому что привыкли к одному только принту. Давайте разберем пять таких инструментов. assert - ловим логические ошибки на этапе разработки: assert проверяет условие и, если оно ложно, останавливает выполнение программы. Работает только в дебаг-сборке - в релизе эти проверки просто вырезаются. Допустим, вы пишете функцию, которая вычисляет квадрат числа. Вы точно знаете, что ноль сюда передавать нельзя. Добавляете проверку: func calculateSquare(x: Double) -> Double { assert(x != 0, "Число не может быть нулем") return x * x } Если кто-то случайно вызовет calculateSquare(x: 0), приложение упадет с сообщением об ошибке. И вы сразу увидите проблему, а не будете полдня выяснять, почему результат не сошелся. Важный момент: assert не подходит для проверки пользовательского ввода. Его задача - ловить ошибки в вашей логике, те самые ситуации, которые не могут произойти, но почему-то происходят. file, function, line - добавляем контекст в логи: Обычный print выводит просто сообщение. Чтобы понять, откуда оно пришло, приходится лезть в код. Есть способ лучше - использовать литералы #file, #function и #line. Они подставляют имя файла, функции и номер строки прямо во время компиляции. Оборачиваем print в удобную функцию: func log(_ message: String, file: String = #file, function: String = #function, line: Int = #line) { print("[\(file):\(line)] \(function) - \(message)") } Теперь вместо print("Ошибка") пишем log("Ошибка"), и получаем в консоли что-то вроде: [ViewController.swift:42] updateUser() - Ошибка Никакого копирования имен функций и номеров строк руками. Все само подставляется. CustomDebugStringConvertible - настраиваем вывод своих типов: Когда вы пишете print(user), Swift выводит стандартное представление: User(name: “Artem”, age: 33, role: "Admin"). Для маленьких структур ок, но когда полей много - в консоли каша. Протокол CustomDebugStringConvertible позволяет переопределить этот вывод: extension User: CustomDebugStringConvertible { var debugDescription: String { "👤 \(name), роль: \(role)" } } Теперь print(user) покажет: "👤 Artem, роль: Admin". Коротко и понятно. Часто используемые типы данных можно снабдить такими расширениями - и отладка станет намного приятнее. 🔗 Читать подробнее 💡 Вывод: Сеньоры используют эти пять инструментов не потому, что они умнее, а потому что так быстрее. assert, литералы #file, #function и #line, протокол CustomDebugStringConvertible, тип Mirror и функция dump встроены в стандартную библиотеку Swift и доступны без подключения дополнительных зависимостей. Перестаньте терять часы на однообразный print и просто начните применять то, что уже есть под рукой. Отладка станет чище, а логи - понятнее. Подписаться на канал: ➡️ Telegram | Max Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Эпоха дешевых токенов заканчивается. Что делать обычным пользователям? Компании Anthropic и Microsoft ужесточают условия для бизнес-клиентов: фиксированные подписки уходят в прошлое, компаниям придется платить за реально потребленные токены. Индивидуальных пользователей пока не трогают, но тренд очевиден: дешевые токены заканчиваются. И тот, кто сейчас не пользуется возможностью учиться на топовых моделях за копейки, рискует оказаться в сильном отставании. Как меняется рынок: Раньше компании массово покупали подписки Claude за 200 долларов на каждого сотрудника и радовались. Теперь Anthropic переводит корпоративных клиентов на оплату по факту. Microsoft сделала то же самое. В отчетах стартапов Кремниевой долины видны траты в сотни тысяч долларов в месяц на ИИ-подписки. При этом Дарио Амадей из Anthropic признал: пользователи Max-подписки тратят токенов на 5000 долларов, платя при этом всего 200. Почему это важно для новичков: Пока есть возможность пользоваться топовыми моделями за 20-200 долларов - ее нужно использовать. Тренировать навыки, нарабатывать опыт, учиться правильно формулировать запросы. Потому что когда цены вырастут, учиться будет поздно - разрыв между теми, кто уже умеет эффективно работать с ИИ, и теми, кто только начинает, станет критическим. 🔗 Читать подробнее 💡 Вывод: Если вы сейчас пользуетесь бесплатными или дешевыми версиями ИИ - вы делаете ошибку. Сейчас уникальный момент, когда можно получить доступ к топовым технологиям за копейки. Упустите его - будете догонять тех, кто успел. И догонять будет сложно, потому что разрыв в навыках нарастает экспоненциально. Платите пока можно и тренируйтесь, пока есть время. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

🔢 SwiftUI теперь умеет скрывать навигационную панель при скролле. Раньше, чтобы скрыть или показать навигационную панель при скролле, нужно было отслеживать позицию прокрутки вручную. Слушать изменения scroll offset, вычислять направление, анимировать изменение состояния навбара. Это работало, но требовало лишнего кода и было не всегда предсказуемо. В iOS 27 появился новый модификатор, который делает все это стандартными средствами, без костылей. Как это работает: Модификатор toolbarMinimizeBehavior позволяет указать, как должна вести себя панель инструментов при прокрутке содержимого. ScrollView { ContentView() } .toolbarMinimizeBehavior(.onScrollDown, for: .navigationBar) Когда пользователь скроллит вниз, навигационная панель минимизируется, освобождая больше места для контента. Все, что нужно было сделать разработчику - добавить одну строчку кода. Без UIScrollViewDelegate, без GeometryReader, без onPreferenceChange. Когда это может пригодиться: Такой подход полезен для экранов, где контент - главное. Ленты новостей, каталоги товаров, библиотеки, результаты поиска, длинные списки с большим количеством элементов. Все, где пользователь тратит много времени на скроллинг, а навигационная панель только занимает полезное пространство. Что важно знать: При минимизации навбара безопасная область (safe area) автоматически корректируется. Контент не перекрывается, отступы сохраняются. Это поведение работает по умолчанию и в большинстве случаев его достаточно. Если нужен более тонкий контроль, есть toolbarMinimizationSafeAreaAdjustment, который позволяет управлять этим поведением. Особенно это может пригодиться на экранах с кастомными заголовками или сложной версткой. 🔗 Читать подробнее 💡 Вывод: toolbarMinimizeBehavior - это небольшой, но полезный модификатор, который решает задачу, которую раньше решали кучей костылей. Он не требует отслеживания scroll offset, не ломается при изменении ориентации и работает предсказуемо. SwiftUI продолжает закрывать пробелы, которые раньше заставляли разработчиков писать лишний код. Это один из таких случаев. Просто и без боли. Подписаться на канал: ➡️ Telegram | Max Закрытый канал: 🚀 Мобильный трудоголик PRO

🍎 iOS 27: iPhone больше не нужно подключать к компьютеру для восстановления. Apple добавила в iOS и iPadOS 27 режим восстановления, который работает прямо на устройстве. Раньше при серьезных сбоях или неудачном обновлении нужно было подключать iPhone к компьютеру, переводить в специальный режим и восстанавливать прошивку через Mac или ПК. Теперь часть проблем можно решить прямо на устройстве, без помощи компьютера. Как это работает: Все достаточно просто. Выключаете устройство. Затем удерживаете боковую кнопку. После появления логотипа Apple продолжаете держать кнопку. Система показывает индикатор загрузки и переходит в меню дополнительных инструментов. Что доступно в меню: В режиме восстановления доступны несколько опций: 🔹Помощник восстановления. 🔹Утилита для обновления системы. 🔹Режим диагностики. 🔹Форматирование и сброс до заводских настроек. 🔹Восстановление с помощью компьютера. Также отображается заряд аккумулятора и статус подключения к известным Wi-Fi сетям. Почему это важно: Раньше при серьезных проблемах iPhone превращался в кирпич и нужно было искать кабель, компьютер и использовать iTunes или Finder. Теперь достаточно запустить новый режим восстановления на iPhone и выбрать нужный инструментами. Особенно ценно это для тех, у кого нет компьютера или ноутбука. Ведь таких большинство пользователей iPhone. Раньше им при серьезном сбое приходилось бежать к знакомым или в сервис. Теперь все решается на месте. Режим диагностики - отдельный плюс. Можно проверить устройство на аппаратные проблемы без посторонних приложений. Это экономит время и нервы. Wi-Fi в режиме восстановления - умное решение. Устройство может скачать свежую прошивку прямо из меню восстановления. Не нужно качать IPSW на компьютер и заливать через кабель. 🔗 Читать подробнее 💡 Вывод: Это одна из незаметных функций, которые делают iOS надежнее. Apple постепенно убирает зависимость от компьютера и это правильный путь. Теперь даже если система не загружается, вы не остаетесь один на один с проблемой. Устройство само предлагает инструменты для спасения. Это шаг в сторону большей автономности и удобства для пользователей. Особенно для тех, у кого нет компьютера под рукой. В Android подобные возможности тоже есть, но они более ограничены и часто требуют дополнительных действий или знания специфических комбинаций кнопок для разных производителей. Apple снова показывает, как делать восстановление простым и доступным для обычного пользователя. Подписаться на канал: ➡️ Telegram | Max Закрытый канал: 🚀 Мобильный трудоголик PRO

🍏 Apple Container: нативный инструмент для запуска контейнеров на macOS. Apple выпустила Container 1.0 - собственный инструмент для работы с Linux-контейнерами на macOS. Это не просто очередной фреймворк. Это попытка Apple изменить подход к изоляции, управлению средами и рабочим процессам разработчиков. Давайте разберем, что это такое и почему важно. Что такое Apple Container: Apple Container - это CLI-инструмент для создания и запуска Linux-контейнеров в виде легких виртуальных машин на Mac. Он написан на Swift и оптимизирован для Apple Silicon. В отличие от Docker, где все контейнеры работают внутри одной общей Linux-виртуальной машины, Apple Container запускает для каждого контейнера отдельную легкую виртуальную машину. Это дает аппаратный уровень изоляции для каждого контейнера и обеспечивает более высокую безопасность. Основные характеристики: 🔹Нативная работа на Apple Silicon: никаких затрат на Rosetta. 🔹Легкость: запуск контейнеров происходит за доли секунды. 🔹Полная совместимость с OCI-образами: можно использовать стандартные образы из любых реестров. 🔹Интеграция с macOS: доступ к домашней папке через монтирование. Container Machine - новая концепция: В версии 1.0 появилась концепция Container Machine - контейнеров с сохранением состояния. Это позволяет останавливать и перезапускать контейнеры, сохраняя файловую систему внутри . По сути, они работают как обычные виртуальные машины, но с легкостью и скоростью контейнеров. Пока есть ограничения: память, выделенная контейнеру, не возвращается обратно в систему и освобождается только при перезапуске . В остальном инструмент выглядит зрелым. Почему это важно для iOS-разработчиков: Казалось бы, iOS-разработчикам не нужны контейнеры. Но современная разработка все чаще требует локальных бэкендов - базы данных, сервисов аутентификации, API для тестирования . С Apple Container можно поднять все эти зависимости локально, не засоряя систему и не беспокоясь о совместимости версий. Что можно делать с Apple Container уже сейчас: 🔹Поднимать локальные базы данных и сервисы для разработки. 🔹Изолировать тестовые среды для проверки приложений. 🔹Создавать воспроизводимые окружения для CI/CD. 🔹Запускать Swift-приложения на сервере в контейнерах. 🔹Тестировать код в среде, близкой к проду. Все это без необходимости использования Docker и оплаты лицензии. 🔗 Читать подробнее 💡 Вывод: Apple Container - это не просто клон Docker. Это попытка Apple переосмыслить контейнеризацию на macOS, сделав ее нативной и безопасной. Контейнеры запускаются в отдельных виртуальных машинах, что дает лучшую изоляцию. Они написаны на Swift и интегрируются с системой. Технология еще на раннем этапе, но у нее большой потенциал. Подписаться на канал: ➡️ Telegram | Max Закрытый канал: 🚀 Мобильный трудоголик PRO