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

Привет, Хабр! Это Вадим из команды AvitoTech. Весной мы собрали в московском офисе более сотни разработчиков, чтобы обсудить самые актуальные для Go-комьюнити темы: начиная со сложностей при переходе на язык Go и заканчивая извечным вопросом о пользе хард- и софт-скиллов. Выбрали девять самых «горячих» тем, поговорили с модераторами соответствующих дискуссий дринкапа, выделили главное и принесли вам в этой статье. Призываем ваши мнения в комментарии!

Дело было в Питере ― я шел по брусчатке и оступился. Чтобы сохранить лицо, я пожертвовал руками. Ну и как теперь жить и работать? ― спросите вы. Рассказываю. Спойлер: больничный я не брал.

Продолжаем погружение в мир функционального программирования! Тема новой статьи — функциональные типы данных и их структуры. Из неё вы узнаете о принципе неизменности данных, о понятии State Machine и о способах его применения в программировании.

А ещё мы исследуем функциональную библиотеку Kotlin Arrow, обсудим поддержку Null, поток данных и функциональную обработку ошибок, а также начнём проектировать Data и Domain слои демонстрационного приложения. В общем, скучать не придётся!

Если вы хоть раз вбивали в Google или Яндекс что-то вроде «куда сходить в Москве», «необычные маршруты по городу» или «экскурсии без гида», то вы знаете — в ответ чаще всего всплывает список из пяти переоценённых мест и пары скопированных текстов из TripAdvisor.

Я проверила десятки сервисов — от стандартных туристических агрегаторов до приложений с «альтернативными» маршрутами. Но везде натыкалась на одно и то же: коммерческие рекомендации, переписанные друг у друга списки "топ-10 мест" и полное отсутствие настоящей городской атмосферы.

А что, если маршрут по городу можно было бы придумать самому — не просто накидав точки, а собрав историю? С фото, видео, аудио, воспоминаниями, текстами, вайбом. Или, возможно, быстро открыть такой маршрут от коренного жителя района и пройтись по самым скрытым и уникальным местам, по-новому взглянув на город?

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

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

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

Меня зовут Кристина Павлив, я руководитель продукта в МТС: с нуля прорабатывала идею и развиваю приложение МТС Field, которым пользуются наши полевые инженеры.

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

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

Из-за экономических санкций и удаления приложений из App Store и Google Play российские организации были вынуждены отойти от привычных всем репозиториев, предоставив злоумышленникам больше возможностей для обмана пользователей: загрузка и обновление приложений по внешним ссылкам даже для банковских клиентов стали привычными. Более того, пользователи ищут более удобную альтернативу известным приложениям

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

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

Недавно наткнулся на новость о том, что количество приложений в Google Play Store сократилось на 47%.

Я сам энтузиаст разработки под Android и последние 5 лет работал над альтернативой для Google Play Music и Podcast под названием MusicSync. Так что, будучи близким к теме человеком, мне захотелось поделиться своим опытом обслуживания приложений и заодно пояснить, почему меня эта новость нисколько не удивила.

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

Если же говорить о приложении Android, то обслуживать его в качестве хобби-проекта гораздо хлопотнее. Вот некоторые из проблем, с которыми мне приходилось сталкиваться.

Если вы активно работаете с консолями разработчика Google Play и App Store, вам нужно это знать! Без лишних слов: рандомная подборка неочевидных вещей в сторах и не только, которые сделают метрики лучше, жизнь проще, а работу веселее.

На этом Google IO google показал новый инструмент разработки - https://jules.google.com

В чем плюсы: пока бесплатный, работает на gemini, и это AI Agent.

Что это значит (пример):
Часто бывает проблема, что кол-во модулей в проекте или библиотек которые хотелось бы сделать, превышает кол-во которое можно поддерживать. Особенно если ведешь open source библиотеку.

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

Чтобы начать, обычно можно использовать небольшой промпт чтобы предсоздать план по которому Jules будет частично следовать (на самом деле она пересоздаст план, но имея рефренсы ей будет проще):

Как упаковать веб-приложение в нативную обёртку, пройти модерацию и снова стать доступным в App Store и Google Play — без дублирования разработки.

В какой-то момент всё становится серьёзным — даже в приложениях про любовь. Команда Redspell, создатели игры Senses (интерактивные романтические истории), решили стать одними из первых, кто интегрировал новую платёжку от RuStore — Pay SDK. И встроили — с нуля, но в итоге с ростом метрик.

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

Расширяем кругозор. Слышали про парадигму функционального программирования? Если вы iOS-разработчик, то, наверное, да, а если вы Android-разработчик, то, скорее всего, нет. Пришло время это исправить.

Привет! Меня зовут Женя Бондарев. И сегодня мы поговорим о теории функционального программирования, её особенностях и о том, что она может дать вашему Android-приложению. А ещё начнём писать pet-проект на функциональной архитектуре. Поехали!

Вместе с Самиром, Flutter-разработчиком в Surf, мы разберём, что за зверь этот Flutter Web. Посмотрим, что происходит у него «под капотом», какие трудности возникают в проде, как адаптировать UX под веб и какие виджеты помогут сделать интерфейс удобным.

Привет, Хабр! Анимации – это та самая вишенка на торте, которая превращает просто работающее приложение в нечто, чем приятно пользоваться, что хочется «потрогать». Но как сделать так, чтобы эта вишенка не превратилась в тыкву, тормозящую весь UI и съедающую батарейку?

За годы практики я перепробовал, кажется, всё: от простейших AnimatedContainer до замороченных кастомных решений с физикой и глубокой интеграцией с Rive. И сегодня я хочу поделиться с вами этим опытом, собрав в одном месте всё, что нужно знать о создании анимаций во Flutter в 2025 году. Это будет настоящий лонгрид-энциклопедия, так что заварите кофейку или что покрепче!

Мы пройдемся по основам, заглянем под капот продвинутых техник, разберем популярные пакеты и, конечно же, поговорим о том, как не убить производительность и добиться заветных 60+ FPS. Вся информация и ссылки тщательно проверены и актуальны (насколько это возможно предсказать) на июнь 2025 года. Поехали!

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

В мобильных приложениях весь текст, который видит пользователь, разработчики хранят в виде строк — strings. Когда приложение работает только на одном языке, процесс относительно простой: дизайнер обновляет тексты в макетах, разработчики — в strings.

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

В этой статье дизайнер интерфейсов CleverPumpkin Фёдор Миронов, расскажет, как наша команда справляется со сложностями локализации — путь от макета в Figma до финальной сборки на Android и iOS. Как синхронизироваться с разработчиками и переводчиками? Почему Crowdin стал нашим незаменимым инструментом и как с его помощью команда избегает хаоса, экономит время и ресурсы, повышает качество перевода и ускоряет релизы.

Часть 2: Загрузка данных and Improving или "Хождение по промтам"

Цель этой публикации — показать процесс взаимодействия с ИИ при написании мобильного приложения. Обычно в таких историях публикуют исходный промт, а затем готовый результат. Здесь же хотелось показать более подробно именно сам процесс «Хождения по промтам», как по ходу выстраиваются «взаимоотношения» и происходит взаимообучение ИИ и разработчика. Думаю это будет полезно как уже работающим с ИИ для написания кода, так и тем, кто только начинает входить в этот сегодняшний main stream.

Статья написана в продолжение поста, в котором рассказывалось как с помощью Claude Sonnet 3.7 было написано небольшое мобильное приложение на SwiftUI. Это пользовательский список фильмов. И да, я знаю, что таких приложений вагон и маленькая тележка, но как любому разработчику не нравится брать что‑то навороченное и непонятное, а хочется, как всегда, сделать что‑то «простое и удобное».

Загрузка данных

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

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

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

Хорошая отказоустойчивость начинается с мышления.

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

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

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

Расскажем, как использовать библиотеки OkHttp и Retrofit — инструменты, ставшие стандартом де-факто в Android-разработке, — для построения надёжной и быстрой сетевой прослойки. Статья ориентирована на мобильных разработчиков, особенно тех, кто работает с Kotlin и Coroutines.