Мобильная разработка

Вы когда-нибудь открывали приложение, где переход между экранами выглядит так, будто интерфейс собрали на коленке за час до дедлайна? Экран мигает, элементы прыгают, анимация тормозит и вы инстинктивно хотите закрыть это безобразие. Проблема не в том, что разработчик не умеет делать анимации. Проблема в том, что он не понимает, как работает восприятие пользователя.

Давайте же разберем как делать переходы в iOS-приложениях так, чтобы они не раздражали, не ломали флоу и не заставляли пользователя думать "что-то пошло не так". Выясним почему 60 FPS - это не всегда гладко, как избежать типичных багов вроде джанка и мигания, правильно использовать matchedGeometryEffect, писать кастомные переходы без костылей и отлаживать всё это дело до идеального состояния. В конце разберём реальный кейс - переход от списка к детальной странице без единого моргания экрана.

Всем привет! Меня зовут Влад Шатиленко, я продакт-менеджер в команде технической платформы Авито. Раньше я был разработчиком: начинал с аутсорса, затем работал в стартапе, где со временем перешёл в продакты. Сейчас в Авито занимаюсь развитием инструментов backend-driven UI — о них и пойдёт речь дальше. Статья будет полезна командам, которым важны скорость экспериментов, быстрые изменения интерфейса и кроссплатформенность.

Android-приложение может быть написано аккуратно и архитектурно выверено, но это не гарантирует быстрый запуск и стабильную работу в проде. Значительная часть задержек рождается на уровне ART: загрузка классов, интерпретация dex-кода, JIT-компиляция «горячих» методов и постоянный сброс прогрева после обновлений.

В статье разберём, как Baseline Profiles позволяют управлять install-time оптимизациями, что именно они меняют в жизненном цикле приложения и почему в реальных кейсах это даёт измеримый прирост производительности.

Привет! Меня зовут Евгений Шаламов, я продакт-менеджер в Битрикс24 и отвечаю за мобильное направление. В нашем основном продукте, в веб и десктопной версиях, реализованы десятки инструментов и сценариев, но весь этот масштаб сложно уместить в мобильный интерфейс. Да и сценарии работы в веб и на мобильном устройстве сильно отличаются. Поэтому мы актуализировали мобильное приложение и сделали из него рабочий инструмент, удобный для многих пользователей.

В последнем релизе мы представили обновленный интерфейс мобильного Битрикс24. Нам нужно было решить, как реализовать некий «обязательный минимум» для различных групп пользователей, ведь приложением пользуются сотрудники с совершенно разными ролями. 

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

Пример кода в проекте сделан на Flutter, но сама идея не привязана к Dart.

Весь код и текст этой статьи можно найти тут на GitHub.

В новом дайджесте происходит что-то серьезное: наложенные окна и 37 000 unit-тестов против Gradle, новый Flutter и эксперимент с эмоциональным банкингом, Developer Knowledge API от Google, опасности в Android, подводные камни миграции на Swift и многое другое. Заходите!

Swift 6 вводит более строгие проверки изоляции конкурентности и поддерживает поэтапную миграцию, модуль за модулем. Хотя рекомендуемая Apple стратегия выглядит мягкой, на практике вы можете столкнуться со скрытыми сбоями во время выполнения, особенно когда в проекте одновременно сосуществуют модули на Swift 5 и Swift 6.

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

Вы узнаете, как на самом деле работает магия приложения Локатор (Find My в англоязычной версии): от аппаратных хитростей контроллера питания до пост-квантовых алгоритмов шифрования. Мы разберем, почему «выключенный» iPhone - это лишь иллюзия для пользователя, как математика защищает ваши координаты от самой Apple и почему ваш смартфон превращается в криптографический маяк, когда гаснет экран. Статья будет интересна разработчикам, специалистам по безопасности и всем, кто хочет понимать реальные возможности (и ограничения) современной электроники.

Часто можно увидеть такую картину: разработчик влюбляется в концепт из Dribbble, тратит два дня на реализацию сложнейшей цепочки переходов, а потом удивляется, почему его iPhone 15 Pro начинает греться через пять минут использования приложения. Анимация - это всегда сделка с дьяволом (железом). Вопрос лишь в том, насколько выгодный курс обмена вы сможете выторговать.

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

Сегодня мы с радостью объявляем о выпуске Flutter 3.41, что знаменует собой важную веху на нашем совместном пути! Это захватывающее время для разработчиков; этот релиз отражает наше стремление расширить возможности нашего сообщества в формировании направления развития Flutter. Благодаря 868 коммитам от 145 уникальных участников, Flutter 3.41 обеспечивает дополнительную прозрачность и модульность, что еще больше улучшает опыт внесения вклада в Flutter.

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

Здесь столько всего интересного, так что давайте сразу же приступим…

Я инженер ОВиК, и меня достало каждый день гуглить перевод кгс/см² в бары. Универсальные конвертеры не знают про Гкал/ч и кгс/м², а инженерные калькуляторы — платные или с рекламой. Написал своё Android-приложение на Python/Kivy: 10 категорий, 60 единиц измерения (включая все инженерные), 5 калькуляторов (скорость в трубе, тепловая мощность с гликолями, расширительный бак по СП 60.13330, потери на клапане, площадь изоляции). Работает полностью офлайн, бесплатно, без рекламы. Рассказываю как сделал, с какими граблями столкнулся и как выложил в RuStore.

Меня зовут Вячеслав, и я — «процессуальный хирург».
Сейчас адвокат. Из них 20 лет я провел по ту сторону баррикад — работал следователем, помощником прокурора и прокурором.

Моя работа в суде — не красивые речи, а поиск багов. Я берусь за дела, где система дала сбой: следствие допустило ошибку, суд закрыл глаза. Я провожу аудит материалов, нахожу фатальное нарушение (баг в процедуре) и «ломаю» приговор. Я не работаю ради процесса — я либо вижу техническую возможность отмены, либо честно говорю клиенту: «Тут WontFix».

Год назад я понял, что мне нужен инструмент, который работает так же бескомпромиссно, как я сам. Мне нужен был цифровой ассистент...

Давайте представим типичную ситуацию для разработчика: вы делаете фичу, код проходит ревью, тесты «зеленые». На первый взгляд все хорошо, вы отправляете её в релиз. А потом на проде обнаруживается визуальный баг: текст наехал на текст, цвет оказался не тот, отступ съехал. Бывало такое?

В чем проблема – ведь тесты были пройдены успешно? Дело в том, что юнит-тесты проверяют только логику. Им все равно на то, как выглядит экран.

А screenshot-тесты нужно писать вручную в большом количестве. В классическом подходе мы прописываем каждый тест, но что если у вас 50 экранов по 5 состояний на каждый? Так как же быть, если не хочется писать 250 тестов вручную, а проверку сделать нужно?

Сегодня пойдет речь о настойчивом, трудолюбивом молодом человеке, который с 14 лет начал свои первые и полезные стартапы, а не играл в “дотку”. Рассказ будет не из разряда - как стать миллионером, не о заезженной крипте и не о вкладах во что-то типа МММ. Да, шлейф сегодняшнего тренда - ИИ, будет. Куда уж без него, но это все в ненавязчивой форме и с пользой для общества.

Когда на WWDC представили iPhone Mirroring, многие скептично хмыкнули: «Ну, очередной VNC/AirPlay, что мы, трансляций экрана не видели?». Однако за окошком iOS на рабочем столе вашего макбука скрывается сложнейший инженерный стек. Это не просто стриминг картинки - это полноценная виртуализация управления, работающая в условиях жестких ограничений по питанию и безопасности. Сегодня мы препарируем iPhone Mirroring и узнаем, как Apple заставила задержку (latency) исчезнуть, а безопасность - не пострадать.

Разбираться во внутренностях AirDrop - это как препарировать фокус иллюзиониста: на сцене всё бесшовно, а за кулисами - вспотевшие инженеры пытаются заставить два разных радиомодуля не конфликтовать за общую антенну. Прочитав этот текст, вы поймете, как Apple фактически создала свой стек протоколов на базе стандартного железа, почему Bluetooth Low Energy - это «швейцар», а Wi-Fi - «грузчик», и как индустрия наконец-то пришла к единому стандарту передачи данных, который не заставляет владельцев Android чувствовать себя лишними на этом празднике жизни.

В этом выпуске модульная архитектура и уменьшение зависаний, переходы между общими элементами и продажа рефакторинга, слежка за акулами, жестокая реальность App Store, придуманные ГОСТы ChatGPT и многое другое. Заходите!

Если вам когда-нибудь приходила задача сделать страницу профиля как в популярных социальных сетях, то вы понимаете всю боль верстки такого дизайна на SwiftUI — особенно для версий iOS ниже 16. Готовые решения не гуглятся, полностью рабочих репозиториев нет, ИИ ещё не умеют в такие комплексные задачи, а Telegram скрывает похожий лэйаут за внутренними библиотеками. Давайте разбираться, что тут можно придумать.

Хаотичные события в Android (навигация, тосты, запросы) часто превращаются в источник багов и нечитаемого кода. В этой статье вы узнаете, как использовать sealed-интерфейсы Kotlin для создания полной, типобезопасной модели экрана, где состояния и события управляются отдельно и предсказуемо. Вы научитесь превращать одноразовые побочные эффекты в строго контролируемый поток команд, получите compile-time гарантии, избавитесь от багов с поворотом экрана и сможете легко тестировать любые события UI. Рассмотренный подход не только защищает от ошибок, но и кардинально упрощает масштабирование логики. Вы сможете добавлять новые события без риска сломать существующую функциональность, а ваш UI-слой станет чистым и декларативным. При этом всё, что нужно для внедрения - это понимание базовых принципов Flow и ViewModel.