Привет! Сегодня хочу поделиться, как мне кажется, очень полезной информацией о такой важной теме, как Opaque types vs Existensial Types vs Generics — что это такое, в чем разница и что выбрать. Я действительно считаю эту тему важной, поскольку это мощнейшие инструменты, которые нам дает swift, чтобы сделать код более гибким, поддерживаемым, универсальным и без лишнего дублирования. Итак, погнали.
Граф зависимостей KMP‑приложения можно собрать обычным Kotlin‑кодом — без рефлексии, кодогенерации, аннотаций и DSL. Composition root и конструкторы, никакой магии. Звучит как шаг назад от зрелых DI‑фреймворков — пока не посмотришь, кому такая форма удобна: тебе, новому человеку в команде и твоему ИИ‑агенту.
Hola, Amigos! На связи Павел Гершевич, Mobile Team Lead агентства продуктовой разработки Amiga. Мы с командой подготовили для вас перевод статьи о том, как можно кастомизировать иконку приложения динамически. Всем приятного чтения!
Когда-то давно я разрабатывал геолокационную соцсеть, где на карте живут «облака» — посты, привязанные к точке. И этих облаков на экране могло быть очень и очень много. Наивный подход «одно облако = одна аннотация-UIView» упирается в потолок уже на десятках точек: карта превращается в слайд-шоу. Здесь история о том, как я пять раз упёрся в производительность и в итоге переехал на GL-слои с data-driven выражениями: три движка рендера на разных зумах, круги постоянного реального размера в метрах через metersPerPixel, а вся zoom-зависимость считается на GPU. И отдельно — как анимировать прозрачность GL-слоя, у которого вообще нет анимируемого свойства
Бывает, что realtime на проекте уже нужен, а WebSocket по каким-то причинам нет. Остаётся long-polling: клиент шлёт «бесконечный» HTTP-запрос, сервер держит его, пока не появятся новые сообщения, отвечает - и клиент тут же открывает следующий. Звучит просто, ровно до первого запуска на живом устройстве где-нибудь в метро. Дальше начинается то, ради чего и написана статья: гонки при переподключении, дубли локальных пушей и два независимых потока сообщений в одном ответе. Разбираю на примере реального iOS-сервиса, который я разрабатывал более 5 лет
Тестирование мобильных устройств на производстве — это процесс, где цена ошибки очень высока. Баг в приложении можно исправить в обновлении, а дефект аппаратной части планшета или смартфона обычно обнаруживается после сборки устройства, а иногда — только у конечного пользователя, и устранить его намного сложнее. Поэтому важно находить дефекты на всех этапах производства: от поверхностного монтажа до сборки готового планшета.
Привет, Хабр! Меня зовут Сергей, я ведущий инженер программист в отделе разработки приложений в YADRO. В статье расскажу, как мы создавали систему производственного тестирования Android-планшетов, которая используется на этапах сборки и в отделе технического контроля.
Если после релиза Android‑приложения вы внезапно получаете краши, утечки памяти и жалобы на пропадающие данные, проблема может скрываться в нескольких строках кода вокруг Activity и Fragment.
В этой статье собрали пять ошибок жизненного цикла, которые регулярно встречаются даже в реальных коммерческих проектах.
Я сделал анти-шагомер на Expo и React Native: приложение, которое награждает за неподвижность и ругает за шаги. Снаружи это шутка про anti-wellness, внутри — Android step counter, background tasks, локальные пуши, Zustand, native-модуль для TYPE_STEP_COUNTER и state machine для чек-апа “я живой, но мне лень”. Рассказываю, что сломалось по дороге и почему фоновая логика в мобильной разработке — это не cron.
Привет! Это Анна, руководитель Flutter-команды Friflex. Я иногда провожу технические собеседования с Flutter-разработчиками и вижу, с чем чаще всего сталкиваются начинающие специалисты.
В этой статье я собрала чек-лист для подготовки: как рассказать об опыте, какие темы повторить и как вести себя, если вы не знаете ответ или сильно волнуетесь.
Привет, Хабр! Jetpack Compose в 2026 году стал стандартом разработки UI на Android, но в проектах регулярно повторяется одна и та же история: на экране со списком в пару сотен элементов прокрутка идёт рывками, профайлер показывает скачки кадров до 200 миллисекунд, а команда чешет голову и предлагает откатиться обратно на RecyclerView.
Проблема почти всегда не в Compose, а в том, как написан UI: recomposition спроектирован как дешёвая операция, но эта дешевизна работает только при соблюдении ряда правил, которые в документации описаны рассыпанно и часто игнорируются.
Разберём пять ошибок, из-за которых производительность Compose-экранов проседает заметно для глаза, и покажем, как их находить и чинить.
Если серьёзно — зависимостей у 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.
Готовый децентрализованный бэкенд без своего сервера — звучит заманчиво. На личном опыте двух приложений разбираю, где Nostr реально экономит месяцы работы, а где упирается в одно базовое ограничение и начинает мешать: заметки, чаты, ленты, communities, организации.
Привет, Хабр!
Я Дмитрий, iOS-разработчик из команды Салют — мы делаем устройства и программное обеспечение для Умного дома Сбер. У нас много собственных устройств и ещё больше устройств брендов-партнёров, которые поддерживает платформа. Релизный круговорот фичей и интеграций заставляет думать: как оптимизировать процесс доставки новых функций пользователям?
В статье расскажу про опыт разработки, внедрения и поддержки нашей собственной backend-driven UI парадигмы (BDUI) — подхода, в котором сервер управляет не только данными, но и вёрсткой интерфейсов.
Я хотел одну простую вещь: чтобы на втором мониторе тихо играло lo-fi, а за виджетами крутилась уютная анимированная сцена. Готового решения не нашлось — зато нашёлся чужой MIT-проект, у которого я в итоге выкинул главный модуль и собрал из остатков совсем другой продукт. Это девлог о том, что я удалил, что добавил и на каких граблях потанцевал.
Под задачу подходящих инструментов хватало, но каждый закрывал только часть. Wallpaper Engine — живые обои, но без радио. Lofi.co — музыка в браузере, но не обои рабочего стола. Noisli — эмбиент, но без всего остального. Покупать три подписки ради фона под код было жалко, поэтому я полез на GitHub смотреть, что можно собрать самому.
Нашёл meel-hd/lofi-engine под MIT — аккуратный Tauri-проект со встроенным генеративным движком, который синтезировал lo-fi прямо в браузерном рантайме. Идея красивая, но мне быстро стало понятно, что я хочу совсем другого продукта. Так появился форк, который я в итоге назвал LoFiTyan.
В новом дайджесте вопросы доступного пространства в условиях ненадежного поведения horizontalSizeClass и выход Android 17, гид в смешанной реальности с использованием Android XR и живой космос на Metal, иерархия корутин в Android, приложение с расписанием автобусов, скам сети с подписками, домашний сервер с Qwen Code за 25к и многое другое. Подключайтесь!
В современном UI помимо удобства есть еще свистелки и гуделки, чтобы зацепить взгляд пользователя. И, зачастую, такой свистелкой являются анимации: нажал кнопку, а у тебя вокруг спец-эффекты, поставил палец вверх, а он красиво подпрыгнул, и так далее.
Большинство таких анимаций, которые вы видите в приложениях практически каждый день, сделаны с помощью Lottie. Например, тут, в Telegram, часть анимированных стикеров и эмодзи сделаны как раз с помощью Lottie.
Почему именно Lottie? Lottie — это JSON-based формат векторной анимации, поэтому он легковесный, легко масштабируется, не требует видеокодеков, хорошо выглядит на экранах с разным DPI.
Разбор того, как отказаться от системного UINavigationBar и собрать собственный навигационный бар на обычном UIView: с коллапсирующим large title как у Apple, встроенной строкой поиска и произвольными панелями под заголовком — и так, чтобы он работал и с UITableView, и со списками на Texture (AsyncDisplayKit). Внутри — устройство компонента и честный разбор компромиссов из реального продакшена.
Для простых анимаций хватает UIView.animate и CABasicAnimation, но для сложных синхронных цепочек этого мало. Разбираю, почему Timer на 1/60 секунды рвёт анимацию под нагрузкой, и как CADisplayLink решает это, синхронизируясь с реальным обновлением экрана. Показываю свой DisplayLinkAnimator: строго согласованные констрейнты нескольких view, кастомные timing-функции и многоточечные кривые Безье (которых не даёт CAMediaTimingFunction), пауза и возобновление — с примерами кода.
Уже девять лет я делаю приложение с расписанием автобусов для посёлка Иртышский в Омской области. И почти всё это время сам там не живу - уехал через полгода после запуска, а приложение осталось, им до сих пор пользуются.
И сразу скажу: я не программист. Работаю в IT системным аналитиком, а код пишу для себя, как хобби. Захотел бы научиться программировать всерьёз - пошёл бы на курсы и научился. Но мне это никогда не было нужно. Нужно было получить желаемую утилиту, а программирование тут просто инструмент. Это - моё творчество.
А вспомнил я про эти девять лет сегодня вечером. Сегодня 18 июня 2026 года, и ровно семь лет назад, день в день, я научил приложение скачивать расписание из интернета — до этого оно лежало прямо в сборке. Сегодня этот способ убрал, расписание теперь приходит по‑другому. Провозился полвечера, а потом посчитал - приложению‑то уже девять лет.
В первой части статьи были рассмотрены следующие распространённые способы организации конкурентного кода при работе с потоками и корутинами: критические секции, атомарные переменные, реактивные переменные, барьерная синхронизация.
В этой части будут разобраны другие важные подходы: семафоры, каналы передачи данных, горячие потоки, модель акторов, последовательные обработчики задач, thread confinement.
Для каждого из этих подходов рассмотрим конкретные реализации, выделим плюсы и минусы, приведём примеры использования. В конце объединим все реализации в общую таблицу.