Нужно выполнять асинхронные операции, поддерживать многозадачность в приложении? Async/await к вашим услугам - просто и приятно. Кооперативный пул эффективно переключает потоки между задачами, а компилятор проверяет типы на потокобезопасность. И даже можно подсоединять старые части кода, написанные ещё на GCD!
Вот только приложение на проде почему-то начало виснуть…
«Что нового в Swift» Июнь был насыщенным месяцем для Swift: анонсы на WWDC и мероприятия сообщества по всему миру. Мы пригласили организаторов одного из них поделиться своими впечатлениями:
«По всему миру локальные группы встреч и конференции объединяют разработчиков Swift, и некоторые из них появились даже раньше самого Swift! У многих есть каналы на YouTube, где они публикуют видео со своих мероприятий, так что вы можете подключаться удалённо. Давайте выделим несколько.
В мае на встрече SF Swift прошёл доклад Дэна Федермана «Agentify Your Swift Repo», в котором рассказывается о создании агента для CI и обратной связи при ревью кода. Swift Barcelona имеет своё представительство на YouTube, а некоторые группы, например новое сообщество MLX India, публикуют плейлисты мероприятий, включая недавний доклад об использовании MLX Swift в iOS-приложениях, который стоит посмотреть. Существует даже организованный сообществом YouTube-канал Swift Community Meetups, который проводит онлайн-встречи и содержит серию кросс-платформенных докладов о Swift.
Эти группы поддерживают разработчиков несколькими важными способами:
Локальное сообщество: они налаживают связи между разработчиками Swift и организациями на местах.
Пространство для экспериментов: благодаря менее формальному формату и иногда незавершённым проектам встречи создают пространство для обмена идеями, получения обратной связи и обучения друг у друга.
Я призываю больше людей участвовать в жизни местных Swift-сообществ. Если ваша группа начнёт публиковать контент и видео, пожалуйста, поделитесь этим на форумах Swift в категории Community Showcase.»
Самая вычислительно прожорливая индустрия в истории считает на языке, который медленнее C примерно в 70 раз и занял 26-е место из 27 по энергоэффективности. Разбираемся, как Python стал королём ИИ, во сколько обходится его корона — в микросекундах, гигаватт-часах и удвоенном труде инженеров, — и почему новые территории (on-device, edge, локальный инференс) уже отвоёвывают компилируемые языки, в первую очередь Swift. С цифрами, ссылками на первоисточники и разбором честных контраргументов.
В iOS 26 у UISlider появился liquid-glass-вид и физика доводки (settle) после того, как пользователь отпускает палец. Если честно, я не проверял, как это выглядело в старых версиях и как оно работало, так как до iOS 26 ни в своих проектах, ни в тех, что я писал на работе, я не использовал стандартный компонент, так как его внешний вид никого не устраивал. У такой доводки есть побочный эффект: если в этот момент дернуть setValue(_:animated:) извне, наш слайдер на один кадр едет в новую точку, а потом откатывается туда, куда его тянет settle. removeAllAnimations() не помогает: анимация идёт не через CABasicAnimation, а через property-driver на display link. Дальше про то, как я нашёл рабочий путь это исправить.
Я хотел сделать маленькую OSD-панель яркости на macOS так, чтобы она выглядела как системный HUD: не просто полупрозрачная плашка поверх обоев, а нормальное стекло, через которое видно и немного преломляется рабочий стол. По дороге выяснилось неприятное: SwiftUI .glassEffect для такой задачи не подходит вообще, публичный NSGlassEffectView даёт только половину результата, а вид, близкий к системному HUD, появляется уже после ковыряния приватного CAFilter glassBackground. Ниже — весь путь, с кодом, ошибками и местами, где я сам сначала чинил не то
Привет, Хабр! На связи снова Максим из ATI.SU.
В прошлых статьях мы разобрались, как искать логи и креш‑отчёты на iOS‑устройствах — и делали это вручную. Этот навык остаётся базовым на проекте любого размера: без него невозможно понять причину сбоя. Но есть и вторая часть работы — сами проверки, то есть прогон пользовательских сценариев. Пока приложение небольшое, их можно прокликивать руками. По мере роста количество однотипных проверок увеличивается, и повторять их вручную перед каждым релизом становится всё дороже.
Возникает логичный вопрос: можно ли автоматизировать именно эту рутину — прогон сценариев, — чтобы проверки проходили без нашего участия, а нам оставалось разбираться с причинами сбоев, если такие возникнут? Здесь нам помогут нативные автотесты на XCUITest. Они позволяют системно, а не от случая к случаю, прогонять пользовательские сценарии, отслеживать падения и проверять стабильность. А когда тест краснеет, в дело снова вступают логи и креш‑отчёты — те самые, что мы научились искать в предыдущих статьях.
Этой статьёй мы открываем цикл о UI‑тестировании iOS приложений. Начнём с основ: разберёмся, какое место UI‑тесты занимают в пирамиде тестирования, познакомимся с инструментами и постепенно перейдём к построению устойчивых тестов с применением проверенных паттернов.
Swift — это современный язык программирования, лежащий в основе многих приложений, работающих на платформах Apple наших дней. Мне показалось, что было бы неплохо немного вернуться к истокам Apple, к Apple II. Это была первая массовая серия компьютеров Apple, первоначально выпущенная в 1977 году с процессором MOS 6502 с частотой 1 МГц.
Почему мы отказались от «AI в каждой кнопке» и зато встроили AES-GCM в детское приложение
Откуда вообще взялось MIO
MIO — это история про собственные родительские потребности, с которыми сталкиваешься, когда ребёнку исполняется 5 лет.
Family Vault - Ключи и envelope - E2E и что внутри
Наш осознанный шаг к безопасности. Для всех, без подписки и дополнительных оплат. Мы не говорим про конкурентное преимущество — мы говорим о важности оставаться уверенным, что твои данные не утекут.
9 лет назад я разрабатывал геолокационную соц.сеть на заказ, где мы отображали чаты на карте. До релиза не дошло, но интересного опыта было получено много. В очередной статье из серии рассказываю про то, как обрабатывать нажатия на MapBox и любой другой карте (Google, Yandex – не важно) и находить нужные объекты на ней, привязанные к координатам.
Продолжение истории про проект геолокационной соцсети: “как мы людей в круги расставляли”. Рассказываю о том, как можно красиво отобразить пользователей, которые рядом с вами на карте, чуть менее тривиальным образом с помощью SpriteKit
Привет! Сегодня хочу поделиться, как мне кажется, очень полезной информацией о такой важной теме, как Opaque types vs Existensial Types vs Generics — что это такое, в чем разница и что выбрать. Я действительно считаю эту тему важной, поскольку это мощнейшие инструменты, которые нам дает swift, чтобы сделать код более гибким, поддерживаемым, универсальным и без лишнего дублирования. Итак, погнали.
Когда-то давно я разрабатывал геолокационную соцсеть, где на карте живут «облака» — посты, привязанные к точке. И этих облаков на экране могло быть очень и очень много. Наивный подход «одно облако = одна аннотация-UIView» упирается в потолок уже на десятках точек: карта превращается в слайд-шоу. Здесь история о том, как я пять раз упёрся в производительность и в итоге переехал на GL-слои с data-driven выражениями: три движка рендера на разных зумах, круги постоянного реального размера в метрах через metersPerPixel, а вся zoom-зависимость считается на GPU. И отдельно — как анимировать прозрачность GL-слоя, у которого вообще нет анимируемого свойства
Бывает, что realtime на проекте уже нужен, а WebSocket по каким-то причинам нет. Остаётся long-polling: клиент шлёт «бесконечный» HTTP-запрос, сервер держит его, пока не появятся новые сообщения, отвечает - и клиент тут же открывает следующий. Звучит просто, ровно до первого запуска на живом устройстве где-нибудь в метро. Дальше начинается то, ради чего и написана статья: гонки при переподключении, дубли локальных пушей и два независимых потока сообщений в одном ответе. Разбираю на примере реального iOS-сервиса, который я разрабатывал более 5 лет
Если серьёзно — зависимостей у RuSwitcher действительно ноль: только системные фреймворки и чистый Swift, никакой телеметрии и ничего постороннего в Package.swift. Но начнём с боли.
Если вы пишете на двух языках, то знаете эту боль: набрал полстроки, поднял глаза — а там ghbdtn вместо «привет». На Windows эту проблему закрывает Punto Switcher. А на macOS? Его Mac‑версию Яндекс забросил ещё в 2017-м, да и у самого Punto хватает «сюрпризов»: встроенный кейлоггер‑«дневник», телеметрия, навязывание Яндекс‑сервисов и закрытый код. Мне хотелось простого, открытого и без слежки — поэтому я написал своё: RuSwitcher, лёгкий переключатель раскладки в меню‑баре. Open source (MIT), ноль зависимостей, ноль телеметрии.
В статье — как это устроено внутри: перехват клавиатуры через CGEventTap, динамический маппинг любых двух раскладок через UCKeyTranslate, и отдельно — раздел «грабли», включая историю про то, как я случайно выложил релиз, где DMG назывался 2.1.0, а внутри лежала сборка 2.0.3.
Разбор того, как отказаться от системного UINavigationBar и собрать собственный навигационный бар на обычном UIView: с коллапсирующим large title как у Apple, встроенной строкой поиска и произвольными панелями под заголовком — и так, чтобы он работал и с UITableView, и со списками на Texture (AsyncDisplayKit). Внутри — устройство компонента и честный разбор компромиссов из реального продакшена.
Для простых анимаций хватает UIView.animate и CABasicAnimation, но для сложных синхронных цепочек этого мало. Разбираю, почему Timer на 1/60 секунды рвёт анимацию под нагрузкой, и как CADisplayLink решает это, синхронизируясь с реальным обновлением экрана. Показываю свой DisplayLinkAnimator: строго согласованные констрейнты нескольких view, кастомные timing-функции и многоточечные кривые Безье (которых не даёт CAMediaTimingFunction), пауза и возобновление — с примерами кода.
Три ночи я был уверен, что у меня сломан рендер.
Вертикальные картинки — те самые 9:16, под обои телефона и под сторис, — на экране разъезжались горизонтальными полосами. Как будто старый телевизор поймал помехи. Квадрат рисуется нормально. Горизонталь — нормально. А вертикалку рвёт в труху.
Три раза я её «починил». И все три раза чинил вообще не то.
Правда оказалась дурацкой и красивой одновременно: файлы были в полном порядке. Рвало только то, как macOS показывала их на экране. Но к этому моменту я уже немного поседел.
Это не история из серии «смотрите, какой я молодец». Это честный рассказ, как обычный человек без программистского образования за неделю собрал себе на Mac локальный генератор картинок — и на какие грабли наступил по дороге. Я энтузиаст, не разработчик. И сразу самое важное, чтобы потом не было неловко: я не написал ни одной строчки кода. Ни единой. Даже Xcode толком не открывал. Код писал вместе со мной Claude Code, модель Opus 4.8. И сам движок генерации — тоже не мой. А моё во всём этом — то, что движок не топит ваш Mac и не показывает вам битые картинки. Звучит мелко? Вот про эту мелочь и весь рассказ. Прятать тут нечего, про границы расскажу честно прямо сейчас.
В мобильной разработке мы привыкли, что красивый анимированный фон — это либо видео, либо пара слоёв с CAGradientLayer и медленным параллаксом. Для большинства задач этого хватает. Но иногда хочется большего: настоящий живой космос — туманности, которые медленно перетекают друг в друга, планеты с кольцами, звёзды разных классов и в центре — чёрная дыра с аккреционным диском, как в «Интерстелларе».
У меня есть небольшая аркада-раннер про полёт сквозь космос. Фон там — не картинка, а процедурная сцена, которую целиком рисует фрагментный шейдер: каждый пиксель экрана вычисляется математикой из шума. Сначала всё это жило на SpriteKit, а потом я переписал на Metal — и вот тут началось самое интересное, потому что красивая сцена на десктопе и та же сцена на телефоне — это две очень разные истории.
Расскажу, как я это делал, на какие грабли наступил, и почему в итоге пришлось рисовать фон… полосками.
Я долго пользовался разными кодинг‑агентами, и на их фоне Claude Code для меня заметно выделялся: качеством решений, удобством работы и вниманием к деталям. В какой‑то момент мне захотелось не просто пользоваться таким инструментом, а понять, что на самом деле происходит у него под капотом. Так я сел писать собственного агента на Swift, с нуля, без использования готовых решений.
Довольно быстро стало понятно, что сложность не в том, чтобы вызвать модель и попросить ее сгенерировать код. Настоящая сложность начинается там, где система должна стабильно работать: удерживать контекст, пользоваться инструментами, справляться с ошибками и непредсказуемыми ответами модели. На обвязку вокруг модели и уходит почти все время.
Дальше я разберу места, где это проявляется: от устройства главного цикла до управления контекстом. Многие выводы задним числом кажутся очевидными, но на практике они становятся понятны, только тогда когда строишь агента сам и упираешься в каждую проблему руками.
AI сделал нас быстрее, очень сильно быстрее, но у этого момента есть побочный эффект. Наверно многим, кто уже столкнулся в вайбкодингом в своих проектах, знакомо такое чувство когда радуешься от того, что фичи делаются быстро и потом в какой-то момент ты понимаешь, что система деградировала настолько, что новое впиливается все сложнее и сложнее, кол-во багов растет, тех долг накапливается и кажется, что проще все снести и переписать.
