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

Привет, Хабр! На связи Кристиан Бенуа, 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, которые позволят выкрутить читаемость на максимум.

В этом выпуске особенности Struct в Swift и RemoteCompose в Android, знакомство с Frida и новые умные очки Google, сломанное ценообразование приложений с подпиской, навигация на SwiftUI, создание анимированных полос и многое другое. Заходите!

Это статья из официального блога OpenAI, но подход меня так зацепил, что решил перевести для всех. Я тоже часто переношу веб-приложения на мобилки примерно таким же способом и было очень здорово увидеть такой же подход (архитектура+рабочее_приложение-как-пример) у по сути создателей сильного AI. Пишу про разные похожие интересные вещи тут

В ноябре мы представили миру приложение Sora для Android, предоставив любому пользователю с Android-устройством возможность превращать короткие текстовые промпты в живые видео. В день запуска приложение заняло 1-е место в Play Store. За первые 24 часа пользователи Android сгенерировали более миллиона видеороликов.

За этим запуском стоит история: первая версия продакшн-приложения Sora для Android была создана всего за 28 дней благодаря тому же агенту, который доступен любой команде или разработчику – Codex.

С 8 октября по 5 ноября 2025 года небольшая команда инженеров, работая бок о бок с Codex и израсходовав примерно 5 миллиардов токенов (вау), провела Sora для Android от прототипа до глобального запуска. Несмотря на скорость разработки и масштаб, приложение демонстрирует показатель стабильности (crash-free) 99,9% и архитектуру, которой мы гордимся. Если вам интересно, использовали ли мы какую-то секретную модель – нет, мы использовали раннюю версию модели GPT-5.1-Codex, ту самую, которую любой разработчик или компания могут использовать уже сегодня через CLI, расширение для IDE или веб-приложение.

С нуля собрали кредитное PWA-приложение за 6 месяцев. Рассказываем, какие решения помогли быстро выйти на рынок и выдержать рост.

Привет, Хабр! Меня зовут Юра Петров, я руководитель отдела разработки компании Friflex и автор канала «Мобильный разработчик». Это вторая статья в серии о платформах, которые поддерживает Flutter, и в ней на самом деле ничего не будет про чайник. Про чайник было в первой. 

А эта статья о том, как все-таки начать Flutter-проект так, чтобы можно было бы его легко портировать на другие платформы и сохранить себе кучу нервов.

Привет, Хабр! Сегодня поговорим о том, как Flutter-приложению выйти за пределы чисто Dart-мирка и воспользоваться возможностями родной платформы, например, вызвать API Android или iOS напрямую. Например, есть какая-нибудь классная фича в Android SDK, а в Flutter её нет. Как быть? Ответ — писать собственный плагин и использовать MethodChannel.

При разработке Flutter-приложений быстро возникает необходимость выполнять долгие операции: загрузку данных из сети, обращение к базе, работу с файлами, вычисления и т.п. Если делать это синхронно, основной поток блокируется, интерфейс «зависает», а пользователь видит «замороженный» экран. Асинхронное программирование в Dart позволяет вынести такие операции из UI-потока, не блокируя интерфейс.

В данной статье мы расскажем, как во Flutter использовать ключевые инструменты асинхронности Dart — Future, async/await, Stream, а также многопоточность через Isolate — и покажем, как применять их на практике в реальных приложениях.

Привет, на связи Ксюша, миддл-разработчик Surf. Миддлом я стала недавно. Когда я пришла в компанию, я, конечно, знала, что такое Git. Ну, по крайне мере, я так говорила. 

Как-то я, по чистейшей случайности, разумеется, перезаписала чужую ветку. А потом потратила часов 6, чтобы вернуть всё «как было». Благо, помог наш лид, который показал, что делать.

Так я и поняла, что Git — совсем не плохое слово из трёх букв. И теперь несу для всех, кто точно так же начинает свой путь в Git, подробную и понятную инструкцию работы с ним. Го разбираться.

Прошло 18 лет с появления первого смартфона и 12 июня 2025 года исполнилось ровно 10 лет с анонса Android Enterprise инициативы, десятилетию которой Google посвятил отдельную статью в своём блоге. Идея готовилась совместно и была поддержана Samsung платформой KNOX.

За эти десять лет на нашем рынке люди узнали, что такое Mobile Device Management, появилась небольшая, но прочная ниша на рынке IT специалистов. Количество идей с предложениями рутовать телефон, чтобы запилить корпоративную фишку, сократилось почти до нуля за эти годы.

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

Привет, Хабр! Меня зовут Максим Сазонов, я android-разработчик в ПСБ. 

Сегодня предлагаю разобрать путь создания кастомного тулбара от первой кривой реализации до оптимизированного решения. 

И главная проблема, которую надо решить при создании этого компонента  это центрирование title и subtitle. Эта проблема возникает потому что у нас может быть тулбар с разным количеством иконок по обе стороны от заголовка, текстом и иконками или только с title. И если ширина иконок у нас стандартна (44 dp), и достаточно просто умножить эту ширину на количество иконок справа, чтобы понять свободное пространство для title и subtitle, то с текстом с одной или с двух сторон всё намного сложнее, так как мы не можем заранее вычислить ширину этого текста, а значит не можем правильно центрировать и задать ширину title и subtitle.

В статье я расскажу, как я решил этот вопрос.

Привет, Хабр!

Многие во Flutter привыкли собирать интерфейс из виджетов, не задумываясь, как они вообще устроены. Действительно, стандартных виджетов хватает почти на всё. Почти. Иногда возникает задача, где готовых решений нет или их производительности недостаточно. В такие моменты хочется залезть в движок Flutter и написать что-то своё на уровне рендеринга. Звучит немного страшненько, но я посмотрим, как сделать собственный RenderObject (конкретно RenderBox) с нуля.