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

Высококонкурентный рынок в e-commerce не прощает ͏ошибок. 89% клиентов готовы поменять сервис после одного негативного опыта в сервисе. При этом, привлечение нового͏ стоит бизнесу до 25 раз дороже, чем удержание текущего. Поэто͏му важность ка͏чества ͏сервиса становится н͏е вспомогательной, а важнейшей функцией, ͏которая вл͏ияет на ͏удержан͏ие, прибыль и͏ репутацию бренда.

Аналитик студии комплексной разработки цифровых решений CleverPumpkin Алёна Сорокина и эксперты «Сантехника-Онлайн», METRO и Gulliver Group разбирают какие инструменты клиентской поддержки помогают e-commerce продуктам расти и удерживать клиентов.

Perfetto показывает те проблемы с производительностью приложения, которые другой профайлер просто не заметит. И не важно, занят ли процессор системными задачами, когда поток готов работать, или GC блокирует UI на 50 миллисекунд — Perfetto всё подсветит.

Ещё не знаете об этом крутейшем инструменте? Тогда эта статья для вас. Привет! Меня зовут Андрей Гришанов. Расскажу вам, что такое Perfetto и как использовать его максимально эффективно.

Привет, Хабр! Меня зовут Иван Кузнецов, я Android‑разработчик в Кинопоиске. В прошлой статье я научил Jetpack Compose показывать рекомпозиции в реальном времени, но это был скорее учебный стенд: куча модификаторов, обёрток и примеры, которые нужно готовить вручную.

Я хотел чего‑то более полезного: чтобы IDE сама показывала, какие composable‑функции перерисовываются прямо сейчас, а какие скипаются и какие параметры реально меняются. Нажал Run — и редактор превратился в живую тепловую карту UI.

Ради этого пришлось сделать то, чего нормальные люди обычно избегают: залезть под капот Kotlin Compiler Plugin и научиться внедрять код в промежуточное представление на этапе компиляции, разобраться в битовых масках Compose и поднять TCP‑сервер внутри IntelliJ, чтобы запущенное приложение могло стучаться прямо в IDE.

Так появился Riflesso — плагин, который переносит идею Layout Inspector прямо в редактор кода и делает Compose прозрачным. В этой статье я разберу его архитектуру и покажу, как компилятор, клиентская библиотека и плагин IDE собираются в один инструмент.

Как говорится, когда коту делать нечего - у него яйца блестящие...

В 2025 участились случаи блокировки ...всего интернета?... , в частности популярных мессенджеров, таких как WhatsApp, Telegram, коими я и моя семья привычно пользовались..

Споры по поводу нашумевшего мессенджера MAX не утихают и по сей день...

По привычке, если хочешь что-то сделать хорошо - сделай сам, так решил создать свой мессенджер, с блэкджеком и проститутками, с шифрованным трафиком, не видимым для DPI, голосовыми вызовами, без привязки к номеру телефона и вообще к чему либо, и интерфейсом таким , каким его хотел видеть именно я! ;)

Естественно, разработка будет под Android. Никаких санкционных айфонов в этом рассказе!

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

Дальше была разработка самой технической части: список контактов, отправка сообщений.
Вау, это заработало!

И тут я понял, что нужно сделать шикарный дизайн, в стиле киберпанковских игрушек...

Снепшот-тестирование — один из немногих надёжных способов контролировать визуальную целостность SwiftUI-компонентов. Но что делать, если ваш проект ограничен Xcode 13.3 и Swift 5.6, а большинство компонентов дизайн-системы обёрнуты в UIViewRepresentable?

Меня зовут Денис Третьяков, я iOS-разработчик в ПСБ. В этой статье расскажу, как мы организовали снепшот-тестирование SwiftUI-компонентов в условиях жёстких ограничений, с какими проблемами столкнулись и как их решили.

Всем привет!

Завершил обновление предыдущей версии книги и выкладываю в открытый доступ второе издание «Основы Dart: Community edition». От полной версии ее отличает то, что в ней отсутствует глава по разработке тг-ботов на Dart и сквозной проект - игра «Крестики-нолики», которая улучшается практически после каждой главы и сопровождается заданиями на самостоятельную проработку по ее улучшению (своего рода «проект-песочница» из которого я вытряс всю душу и придумал задания, способные привести к знатному подгоранию пятой точки ^_^).

В новом дайджесте последствия уменьшения приложений и новый шаг в передаче зависимостей Swift, улучшение доступности в Android-приложениях и перформанс, лёгкий и быстрый DI-контейнер, Offline-First приложения, ускорение загрузки экрана, больше рекламы в App Store и многое другое. Заходите!

Шейдеры - легко, скриншоты - боль. Написал свой Liquid Glass для iOS 14-26, потому что Apple сделала API только для новых систем. GPU справляется за 2ms, а CPU тратит 90% времени на легальное получение пикселей экрана. Почему так и как с этим жить - под катом.

Всем привет! Меня зовут Тимур, я платформенный Android-разработчик с опытом 5+ лет в ритейле и e-com.

В этой статье разберём, почему перформанс на мобильных устройствах это не ощущения, а фактор, который влияет на конверсию и GMV. Покажу, какие метрики имеет смысл собирать на клиенте, как их мониторить, и приведу примеры кода для Android.

Присаживайтесь, наливайте чай/кофе — поехали.

После того как наш парк вырос до более 245 тысяч самокатов и велосипедов, а команда сервисных центров начала исчисляться сотнями человек, стало ясно: управлять статусами устройств, задач и процессов в нашем внутреннем сервисном приложении по старинке уже не получится. Представьте себе: нужно изменить статус самоката или работы, а механик, специалист по контролю качества и бригадир — роли с разными функциями — видят одни и те же кнопки, одни и те же статусы, в которые можно перевести самокат. Иногда нажимают не туда — и ремонт идет не по желаемому процессу, что-то может потеряться, сроки увеличиваются… Добавим в уравнение еще разные версии мобильного приложения с различным набором кнопок — в какой-то версии кнопку убрали, в какой-то добавили. В итоге вся надежда только на бэкенд, перед которым встала задача контролировать и валидировать действие каждого пользователя в приложении. 

В WCMA (Whoosh Control Maintenance App, писали о нем в предыдущей статье), нашем внутреннем приложении для управления флотом, мы столкнулись с этой проблемой в полной мере. Напомню, в этом приложении работает наша сервисная команда, через него мы обслуживаем самокаты и велосипеды в городе, следим за их зарядом, переставляем на спросовые парковки, а также восстанавливаем и чиним.  

Одна из первых версий WCMA была больше похожа на пульт-отмычку для самоката, приложение не было интуитивным: все переводы доступны, а значит люди нажимали куда попало, часто новички путались в процессах и кнопках, в целом было мало контроля над действиями пользователей. Это могло вызывать ошибки “в полях” или при ремонте флота. Чтобы это исправить, мы завели большее количество ролей в системе, и каждая роль получила свой особенный раздел в WCMA. А для надежности добавили много проверок на бэкенде, валидирующих действия команды.

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

Меня зовут Игорь Волынский, я backend-разработчик в команде WCMA Whoosh. И сегодня я расскажу, как мы решили эту проблему: построили централизованную и гибкую систему управления статусами, добавили условные переводы с хендлерами для проверки бизнес-правил и реализовали динамические сценарии для гибкого формирования UI. Спойлер: теперь наши механики и менеджеры видят только те действия, которые им реально доступны, а бэкенд гарантирует целостность данных на уровне системы.

Привет, Хабр! На связи Кристиан Бенуа, iOS-разработчиĸ в Т-Банĸе. Быстродействие мобильных приложений — один из критериев, влияющих на успех не только приложения, но и всего бизнеса.

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

Расскажу, как мы сделали pull request в swift-foundation и внесли несколько оптимизаций в JSONDecoder/JSONEncoder, ускорив сериализацию и десериализацию в два раза. В конце обсудим, как получить эту оптимизацию без ограничений по версии iOS и насколько можно ускорить работу с JSON в приложении.

Когда iOS‑приложение вырастает до сотен тысяч строк, появляется проблема: добавление зависимости в глубокий компонент требует изменений во всех промежуточных функциях. Эти функции зависимость не используют — они просто передают её дальше. Сигнатуры разбухают, рефакторинг превращается в массовую правку файлов, и значительная часть кода становится техническим шумом.

Проблема известна. Scala использует implicit parameters на уровне языка, Kotlin экспериментирует с context receivers, Android полагается на Dagger. А Swift не предлагает встроенного решения. Поэтому мы в команде Яндекс Браузера создали библиотеку Implicits — механизм неявной передачи зависимостей с compile‑time‑проверками. Она успешно работает в продакшне Браузера на полутора миллионах строк Swift‑кода, а ещё доступна в опенсорсе.

В этой статье я расскажу о поиске собственного подхода для передачи зависимостей в коде на Swift, о том, как внедрение Implicits позволяет существенно сократить boilerplate, ускорить рефакторинг и улучшить читаемость кода благодаря локальному объявлению только реально используемых зависимостей, а также покажу реальные примеры из продакшн‑кода мобильной версии Яндекс Браузера.

Привет! Меня зовут Саша Тотилас и я руковожу командой разработки в hh.ru. Хочу поделиться с Хабром результатами A/B-эксперимента: при оптимизации одного из экранов нашего приложения мы ускорили загрузку контента и выяснили, как это влияет на продуктовые метрики, а также собрали интересные инсайты.

Я не буду глубоко погружаться в технические детали, а сосредоточусь на подготовке эксперимента и интерпретации результатов. Статья будет полезна не только для  мобильных разработчиков, но и для аналитиков и продактов.

Залипающий hover на мобильных устройствах – частый баг. Раньше мы решали это просто плагином PostCSS Hover Media Feature, он оборачивает все псевдоклассы :hover в медиазапрос @media (hover: hover) {}. Так мы проверяли поддержку hover и отключали его на мобилках. Но во время тестирования одного проекта оказалось, что на некоторых устройствах hover продолжает залипать.

Привет, Хабр! Меня зовут Антон Макарычев, я ведущий инженер-программист в команде мобильной разработки kvadraOS. Сейчас мы с коллегами работаем над приложением «Заметки»: уже реализовали Drag-and-Drop между разными экранами в Compose, рисование на холсте, экспорт заметок в PDF или TXT и другие полезные функции. И сегодня я хочу рассказать, как рождалась наша ключевая функциональность — редактор. 

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

Всем привет! С вами Ян, пентестер из компании Xilant. В течении следующих нескольких статей мы поговорим о тонкостях взлома iOS и её приложений. В свою очередь я бы хотел из этого сделать нескучную историю с кучей полезного и мемного контента.

И всё начинается с того, что у нас в руках красивый блестящий iOS-девайс, но ничего мы с ним сделать не можем кроме задуманных Apple процедур. Обычно, это называют «огороженным садиком» (Sandbox) или «стеклянной тюрьмой» (Glass Prison). Но если вы хотите «покинуть тюрьму»,  единственный способ — побег или Джейлбрейк (JailBreak / JB).

Скриншот-тестирование — это метод автоматической проверки пользовательского интерфейса на визуальные регрессии. В этой статье — практическое руководство по внедрению такого подхода в Android-приложение с использованием библиотеки Roborazzi. Рассмотрим базовую настройку, интеграцию с CI, а затем расширим возможности тестов с помощью кастомизации Roborazzi.

Как в 2ГИС/Яндекс.Картах/Google Maps аккуратно смещать камеру и маркер в “сцену” при нажатии, даже когда карта повернута: определить видимую область, проверить положение точки, вычислить сцену с учётом паддингов, при необходимости сдвинуть или центрировать маркер.

С математическими расчетами и картинками.

Это самый простой способ создания программ для Р-ФОН.

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

Уникальность телефона Р-ФОН заключается в том, что на нём можно сразу запускать программы, работающие на компьютерах с процессорами ARM и операционными системами «РОСА Фреш» и «РОСА Хром». Это существенно облегчает разработку. И написание, и запуск, и отладку, и работу в программе можно сначала обкатать на компьютере, и лишь на последнем этапе скопировать программу на телефон и протестировать уже на нём.

Естественно, для работы со специфическими для телефона компонентами, такими как GPS-приёмник и GSM-модем, требуется отдельный подход. Но для создания пользовательского интерфейса и, например, кода для работы по сети - компьютер более чем удобен.

Какой же компьютер с процессором ARM подойдёт? Неплох компьютер на процессоре Байкал-М, но он дороговат, и его ещё нужно поискать. А вот компьютер на основе Raspberry Pi можно назвать народным. Подойдёт 64-разрядный, то есть, начиная с версии Raspberry Pi 4. Мне достался Pi 400, и всё описанное ниже было опробовано именно на нём.

Ниже описан мой опыт написания простых тестовых программ для Р-ФОН, использующих различные графические инструментарии (Qt, PyQt, GTK3, GTK4, SDL2).

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

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