Разработка мобильных приложений *

Привет! Соблюдая традиции Хабра, представлюсь. Меня зовут Антон Митрохин. В Тензоре я middle+ разработчик, но недавно мне доверили задачу уровня senior — обратились с просьбой добавить реакции в мобильные приложения. «Хорошая точка роста», — подумал я и согласился. В статье расскажу, как мне вместе с командой удалось реализовать новый функционал.

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

Это рассказ о том, как я в свободное время реализовал свою старую идею, и как мне в этом помог ИИ. Я решил сделать приложение, которое превращает Википедию в говорящий аудиогид и полностью написал его с помощью ИИ, хотя никогда не занимался мобильной разработкой. ИИ использовался для создания аудио рассказов и для написания самого приложения.

Всем привет! Меня зовут Андрей. По профессии я занимаюсь стратегией и развитием нового бизнеса в российском телекоме. Но мне всегда была близка история создать что-то своё, полезное, красивое и технологичное. И недавно я это сделал, создав GIFTbase.

Ниже, кратко расскажу про путь, который прошли я и моя идея, зародившаяся ещё в 2018 году, в эпоху отсутствия продвинутых языковых моделей, до наших дней и недавнего релиза приложения в Play Store. Возможно, эта история будет полезна или поучительна некоторым читателям с такими же планами, как были у меня.

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

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

В новом дайджесте самый задаваемый вопрос с собеседования и приватный Android без слежки, новые инструменты в Google Play и App Store, своя мобильная ОС с нуля на Rust, магия ИИ-музыки, концентрированный маркетинг и многое другое. Подключайтесь!

История Solar appScreener началась в одной из российских IT-компаний, в которой тогда работала команда основателей «Солара». Они занимались консалтинговым бизнесом и наблюдали кардинальные изменения на рынке, которые стали почвой для будущей разработки продукта в сегменте application security.

К 2014-2015 гг. проблема безопасной разработки приложений стала острой и заметной не только для отраслевого сообщества, но и регулярно привлекала внимание общественности. Более чем в 75% успешных кибератак уже тогда эксплуатировались «дыры» в ПО, которое в то время было самых слабым звеном с т.з. технической защиты. Например, 15% от всего количества опубликованных уязвимостей приходилось на уязвимости для платформы Android. Громким событием первой половины 2010-х также был хакерский взлом AppStore, в ходе которого в ряд приложений был внедрен вредоносный код XCodeGhost.

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

Так возникла идея российского AppSec-продукта: для отечественных компаний, на родном языке, с понятными рекомендациями, четким анализом и наукоемкими технологиями под капотом.

Помню, как будто это было вчера. На уроке раздается голос учителя: «Чтобы перейти в 11-ый, каждому из вас нужно реализовать свой проект. Творчество приветствуется!». Кажется, вот оно: знак сделать то, о чем уже давно подумывал, — создать собственное приложение! Защищаю идею перед учителем, получаю одобрение. Впереди целый учебный год, казалось бы, у меня гора времени. Вот только я никогда в жизни не разрабатывал мобильные приложения…

Меня зовут Ваня, я Python-разработчик, а в свободное время пишу для блога MWS. Сегодня решил поделиться историей-воспоминанием, как в школьные времена приступил к разработке своего первого в жизни мобильного приложения, а потом дорабатывал его уже в университете. Тут не будет истории успеха в духе «я монетизировал приложение и разбогател» и каких-то уникальных лайфхаков. Зато покажу на своем примере, что для создания приложения в качестве эксперимента не нужно знать все языки программирования и обладать суперскилами в разработке. Главное — не бояться пробовать. А еще те, кто только в начале своего пути, смогут научиться на моих ошибках и учесть детали, которые в свое время не учел я. Приступим!

Привет! Меня зовут Андрей Максимкин. Я iOS-разработчик в hh.ru. В своих статьях (тут, тут и не только) мы уже не раз говорили о большой любви к тестам и их важной роли в нашем процессе разработки. В этой статье хочу поделиться опытом использования snapshot-тестов, начиная с этапа внедрения. Статья будет полезна для QA и iOS-разработчиков разных уровней. Обсудим не только теорию, но и напишем реальный snapshot-тест — как в нашей практике.

Вместо вступления

Сначала расскажем про snapshot-тесты и для чего они нужны. Snapshot тесты — это метод тестирования, который используется для защиты внешнего вида компонентов и интерфейсов от незапланированных изменений. Они позволяют зафиксировать эталонное состояние компонента и в дальнейшем использовать как образец. Это помогает выявлять изменения в пользовательском интерфейсе, которые могут возникнуть в результате обновлений кода.

В hh.ru мы активно разрабатываем нашу собственную дизайн-систему (ДС). Дело в том, что компоненты ДС могут иметь широкий набор свойств: цвета, размеры, скругления. Проверять корректность, например, цветов обычным ручным тестировщикам на длинной дистанции невозможно, поэтому возникла потребность автоматизировать проверки. Кроме того, при рефакторинге кода некоторые компоненты могут сломаться — хотелось бы находить такие проблемы сразу. Snapshot-тесты показались лучшим решением этих проблем.

Когда-то давно в hh.ru уже были snapshot-тесты. На тот момент они были написаны на экраны приложения. Эти экраны часто меняли свой дизайн, тесты вели себя нестабильно и падали, поэтому их приходилось переписывать. В итоге от snapshot-тестов отказались. Так что в своей новой попытке внедрения snapshot-тестов решили не писать тесты для экранов, а только для ДС. 

Мои родители и вся моя семья живут в Риге, а большинство наших родственников — в России и Украине. Когда привычные мессенджеры начинают работать с перебоями, хочется иметь простой и независимый способ связи. Самый простой способ из мне известных — WebRTC.

В рамках развития собственного понимания тонкостей парной разработки программ с участием LLM‑агентов я решил создать PWA для видеочата на базе WebRTC при помощи Codex-агента.

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

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

Вот один из недавних ярких примеров

В начале октября в сети появились фотографии Тилли Норвуд — первой актрисы, сгенерированной искусственным интеллектом в студии Xicoia (подразделение продюсерской компании Particle6). Реакции были неоднозначными: кто-то восхищался прогрессом, кто-то воспринял это как угрозу рабочим местам и вновь вспомнил про восстание машин.

Октябрь был насыщенным и вдохновляющим: новые релизы, статьи, переводы с Medium и целая волна полезных пакетов. Flutter не останавливается, а сообщество растёт с каждой неделей! 🚀

Когда проект растёт, а вместе с ним — количество проверок, CI превращается в марафон. Мы в Циан через это прошли: кодовая база растёт, тестов становится всё больше, и каждое изменение начинает тормозить весь пайплайн.

В этой статье расскажу, как мы сократили время выполнения unit-тестов с помощью Impact-анализа — метода, который позволяет запускать только те тесты, которые действительно нужны. Это продолжение моего подхода к оптимизации проверок в Android — в первой статье я показывал, как ускорить статические анализаторы. Теперь — про unit-тесты.

Примеры кода будут на JUnit, но подход подходит ко всем проверкам, которые гоняются через Gradle. В конце статьи — рабочий пример на GitHub, который можно адаптировать под себя.

Я верил, что с приходом ИИ жизнь разработчика превратится в сказку. ИИ будет писать код, а я — придумывать фичи и строить продукт. В реальности я полдня пишу промты, а еще полдня трачу на правки за Copilot. Быстрее написать код самому.

Почему промты занимают так много времени и как компании учат сотрудников использовать ИИ, чтобы он не портил никому жизнь — рассказываю в статье.

Ну как, вы уже обновили свои приложения для поддержки новых требований Google? Если нет, то эта статья будет вам особенно полезна =) Напомню, что с 1 ноября 2025 года приложения, таргетирующиеся Android 15 и выше, должны поддерживать 16-килобайтные страницы памяти.

Как вы помните по предыдущим статьям, я работаю в МойОфис в команде разработки мобильной версии высоконагруженного корпоративного мессенджера Squadus (бэкенд на Node.js, NestJS и Meteor, а веб-интерфейс на React). Мы уже успешно перестроились на новые стандарты Google, и поэтому могу компетентно рассказать, что именно требуется, как адаптировать под это React Native-приложение и что делать, если используемая библиотека ещё не успела обновиться.

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

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

Меня зовут Игорь Зверев, я руководитель группы разработки автонавигации в Яндекс Картах. Сегодня я расскажу, как мы подошли к решению этой задачи: что изменили в процессе разработки, как создали и используем систему RAM‑классов для выпуска требовательных функций и какие технические выводы сделали на этом пути.

Вопрос запуска полноценного рабочего места на мобильном устройстве в последнее время становится все более актуальным – конечно не для всех пользователей, а для тех, кто работает в дороге, должен заполнять документы или обращаться к корпоративным системам, как говорится «в полевых условиях». В этой статье мы расскажем о том, чем RED OS Mode отличается от других подходов к решению этой задачи.

В новом выпуске 7 способов найти логи и поймать баг на iOS, разбираем «Telega» по винтикам и делаем эффект глюка, очки на Android XR, что ждёт Kotlin Multiplatform разработчика на собесе, реверс обфускации Amazon Kindle Web, удаление Tea и TeaOnHer из App Store и многое другое. Заходите!

Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.

Эта память не используется, не выделяется, она просто утекает. Простецкое приложение калькулятора страдает большей утечкой памяти, чем компьютеры десятилетие назад.

Случись такое в 2000-х, это бы привело к внесению срочных патчей и служебной проверке. Сегодня же это лишь очередной баг-репорт в очереди.

Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.