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

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

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

Так я получил свои первые «проекты» и первую оплату — шоколадками.

История 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. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

Привет! Я Тимур, разработчик мобильных приложений в KTS.

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

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

Да, тема довольно холиварная, и в статье я не заявляю, что KMP лучше Flutter’а во всем. Каждая технология хороша под свои задачи. Вместо этого я расскажу о конкретном проекте, на котором KMP оказался более удачным выбором. Также коснусь вопросов архитектуры и миграции Android-приложения на iOS с помощью CMP, а заодно подсвечу подводные камни, с которыми пришлось разбираться в процессе.

N месяцев — столько ушло на то, чтобы ваше приложение стало тем, каким вы хотели его видеть. И вот оно – готово. Пора показать миру!

Но перед тем как приложение попадёт в руки пользователей, его должны одобрить строгие модераторы App Store и Google Play. И вот тут начинается самое интересное. За последние годы требования стали такими, что даже опытные разработчики получают реджекты по полной программе. 

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

Все мы знаем или интуитивно понимаем, что ни одна, даже самая гениальная задумка, не добьется успеха без правильного маркетинга. Эта мысль неоднократно звучала в наших предыдущих статьях, где мы говорили, что без качественно составленного резюме, которое соответствует требованиям рынка (и фильтрам ИИ), и грамотной подачи себя на собеседовании невозможно получить заветный оффер. Поэтому сегодня мы решили осветить важную тему маркетинга, без которого ни кандидат, ни один IT-продукт не смог бы преуспеть. А в качестве первого примера отличного продуктового маркетинга мы возьмем приложение для онлайн-знакомств Bumble.

-Что, что?
-Bumble.
-Никогда не слышали...
-Это-то и интересно!

Самый простой и логичный способ сменить стек — поменять направление внутри компании. Мог так сделать дважды, но тогда бы и писать было не о чем. Буду рад, если кому-то мой опыт окажется полезным или интересным.

Зачем менять стек?

В 2019 году, работая над android-приложением Auto.ru, я часто думал, что надо что-то менять в карьере. Вот несколько тезисов:

- Стать CTO в будущем будет проще с опытом в бекенде...

Что такое мобильная ферма и зачем она нужна – расскажем о том, как устроена ферма СовкомТеха и поделимся отзывами коллег.