Портфолио разработчика мобильных приложений: пошаговый аудит кейсов перед контрактом
Десять портфолио мобильных разработчиков лежат рядом — в среднем по сорок-шестьдесят скриншотов на каждое. Сетка, градиенты, подписи вроде «редизайн онбординга» или «новая навигация».
К десятому проекту глаз перестаёт различать детали, в голове остаётся размытое «вроде, неплохо». В этот момент заказчик выбирает не по архитектуре и метрикам, а по эстетике мокапов. Это дорогая ошибка: красивый экран рисуется за вечер, стабильное приложение — за месяцы работы с реальной аналитикой, краш-репортами и обратной связью от пользователей.
Ниже — методика аудита кейсов, которая за полтора-два часа работы с портфолио отделяет реальный опыт от витрины. Подходит для найма фрилансера, выбора подрядчика на аутсорсе, отбора мобильного разработчика в продуктовую команду.
Скриншоты — не доказательство компетенции
Красивый экран в Dribbble-стиле собирается за вечер в Figma. Работающее приложение с оффлайном, пуш-уведомлениями, корректной работой под нагрузкой и интеграцией с аналитикой — за месяцы. Эту разницу скриншот не показывает. Поэтому первый шаг аудита — вычеркнуть из сравнения всё, что выглядит как презентация, и оставить только то, что можно открыть руками.
Три источника правды в портфолио мобильного разработчика:
- Публикация в App Store или Google Play. Скачиваете, устанавливаете, проходите онбординг. Смотрите, не падает ли приложение на холодном старте, не теряется ли корзина при сворачивании, корректно ли работает системная кнопка «назад».
- Прототип в Figma с кликабельными флоу. Хороший разработчик выкладывает не статичную картинку, а интерактивный макет: можно прокликать основные сценарии и проверить, насколько продуманы переходы между состояниями.
- Исходный код в GitHub или GitLab для open-source проектов. Видно всё: архитектуру, структуру папок, наличие тестов, частоту коммитов, активность сообщества.
Если в портфолио только картинки и общее описание «делали приложение для ритейлера» — это сигнал к углублённой проверке. Не приговор, но повод задать вопросы.
Портфолио показывает не то, что разработчик умеет рисовать интерфейсы, а то, как он решает задачи бизнеса.
Технический аудит: что спрятано за фасадом
Скачали приложение — начинается самая нудная, но и самая показательная часть. Здесь проверяется, чем разработчик занимался последние два-три года.
Архитектура и стек
Запросите у исполнителя описание стека по каждому кейсу. Не маркетинговый перечень («используем Swift, Kotlin, Flutter»), а конкретику: какой state management выбран, где хранится кэш, как устроена работа с сетью, применяется ли Clean Architecture, MVP или модульная структура. По этим ответам видно, насколько глубоко разработчик погружён в проект.
Минимальный набор вопросов к кейсу:
- Какие фреймворки и библиотеки применялись и почему именно они
- Как организована работа с состоянием (Redux, BLoC, MVI, TCA, Combine)
- Есть ли юнит-тесты и покрытие критических сценариев
- Как настроен CI/CD — GitHub Actions, Bitrise, Fastlane
- Подключены ли Crashlytics, Firebase Performance, Sentry или аналоги
Хороший ответ звучит конкретно: «BLoC для бизнес-логики, Dio для сети, миграции через sqflite, покрытие тестами 62%». Плохой — общими фразами: «современный стек, лучшие практики, мы за качество». Второй вариант означает, что разработчик не готов показать реальное устройство проекта.
Производительность и стабильность
Запустите приложение на двух-трёх устройствах разного класса. Старый Android с 2 ГБ ОЗУ и свежий iPhone. Откройте одинаковые сценарии и сравните поведение:
| Параметр | Что проверить | Тревожный сигнал |
|---|---|---|
| Холодный старт | Время до интерактивного экрана | Больше 3 секунд на среднем устройстве |
| Расход памяти | Удержание в фоне 10 минут | Сброс корзины или потеря прогресса |
| Анимации | Плавность скролла и переходов | Пропуски кадров, дёрганые жесты |
| Работа без сети | Поведение в авиарежиме | Полная потеря функциональности |
| Пуш-уведомления | Доставка и дедупликация | Дубли, опоздания более 30 секунд |
Адаптивность и уважение к платформе
iOS и Android — разные философии. Хороший мобильный разработчик уважает гайдлайны обеих платформ. На iOS приложение использует нативные переходы, нативную навигацию, системные шрифты и Dynamic Type. На Android соблюдён Material Design, корректно работает back-стек, учитывается динамическая цветовая схема и edge-to-edge отрисовка. Layout адаптируется под планшеты и складные устройства, а не просто растягивается пропорционально.
Если во всех кейсах приложения выглядят как iOS-порт на Android или наоборот — повод усомниться в кросс-платформенной экспертизе.
Паттерны взаимодействия
Здесь внимание UX-аналитика переключается с технической части на пользовательскую. Проверьте, как приложение ведёт себя в нетипичных ситуациях:
- Что показывает экран при отсутствии данных — пустое состояние с CTA или белый лист
- Как обрабатываются ошибки сети — тост, модальное окно, ретрай-кнопка
- Есть ли скелетоны при загрузке или только спиннер по центру
- Поддерживается ли тёмная тема и системные настройки размера шрифта
- Корректно ли работает биометрический вход и автозаполнение из Keychain
- Что происходит при нехватке памяти на устройстве
Хорошее мобильное приложение продумано в этих сценариях. Плохое — падает, теряет данные, выдаёт пустые экраны.
Бизнес-результаты: цифры вместо слов
Красивый интерфейс — это пять процентов проекта. Остальные девяносто пять — то, что происходит после релиза. Разработчик, который гордится своей работой, знает, как приложение показало себя в сторах и в продакшене. Эти данные часто доступны публично: рейтинг, количество оценок, динамика обновлений. Их нужно сопоставить с тем, что говорит разработчик.
Метрики, которые стоит спросить
| Метрика | Зачем она заказчику | Ориентир |
|---|---|---|
| Рейтинг в App Store / Google Play | Качество выпущенных релизов | 4.2+ для зрелого проекта |
| Retention на 7-й и 30-й день | Главный показатель продукта | D7 от 25%, D30 от 12% |
| Crash-free sessions | Стабильность сборки | Выше 99.5% |
| Среднее время загрузки | Производительность на реальных сетях | До 2.5 секунд на 4G |
| Размер приложения | Следствие качества архитектуры | Менее 80 МБ для среднего проекта |
Если разработчик не готов назвать эти цифры хотя бы для одного-двух своих кейсов — он либо не отслеживал их, либо работал в режиме «сдали и забыли». Оба варианта для заказчика тревожные.
Retention как маркер глубины работы
Удержание пользователей — единственная метрика, которая показывает, понимает ли команда продукт. Хороший мобильный разработчик в кейсе пишет не «сделали приложение», а: «после редизайна онбординга D1-удержание вырос с 38% до 52%, основной драйвер — сокращение шагов с семи до трёх и замена обязательной регистрации на отложенную».
Такой текст говорит о трёх вещах одновременно: разработчик смотрел в аналитику, понимал, какие действия пользователя приводят к отвалу, и проектировал флоу под реальное поведение, а не под красивую схему на слайде. Если в кейсе нет ни одной продуктовой метрики — это техническая работа без участия в продукте.
AI и ML в мобильных кейсах 2026 года
В 2026 году опыт работы с AI/ML в мобильном контексте — не опция, а базовое требование для проектов, которые претендуют на актуальность. Это не значит, что каждый разработчик обязан обучать нейросети. Это значит, что он умеет встраивать готовые модели в приложение, работать с on-device inference и грамотно выбирать между облаком и устройством.
Что должно быть в портфолио:
- Кейсы с интеграцией LLM через API (OpenAI, Anthropic, локальные модели) с правильной обработкой rate limits, токенов, контекста
- Использование on-device моделей через Core ML, TensorFlow Lite или MediaPipe
- Реализация оффлайн-режима для AI-функций: распознавание речи, обработка изображений, локальные подсказки — с последующей синхронизацией при появлении сети
- Опыт работы с embeddings, RAG-пайплайнами, векторными базами на мобильном клиенте
| Сценарий | Технология | Что показывает в портфолио |
|---|---|---|
| Чат-ассистент в приложении | Streaming LLM API | Обработка обрывов сети, отмена запроса, инкрементальный рендер |
| Распознавание объектов на фото | Core ML / TFLite | Латентность, размер модели, fallback на сервер |
| Персонализация ленты | On-device embeddings | Локальное хранение, обновление профиля, A/B-тесты |
| Голосовой ввод | Whisper / Speech Framework | Подавление шума, сегментация, поддержка нескольких языков |
В 2026 году «AI в приложении» — это не фича, а инженерная задача со своими требованиями к архитектуре, бюджету и UX.
Если в портфолио нет ни одного упоминания AI/ML — это не повод отказывать разработчику, но повод уточнить, насколько быстро он сможет освоить направление. Для проекта, где LLM-ассистент в MVP, на изучение уйдёт 4–6 недель плотной работы — и это нужно закладывать в сроки.
Методика проверки: 15–30 минут на кейс
Пять-шесть кейсов в портфолио — рабочий минимум для оценки. Меньше — выборка слишком узкая. Больше — фокус размывается. На каждый кейс закладывайте от 15 до 30 минут. Ниже — алгоритм, который укладывается в эти рамки.
1. Откройте кейс, прочитайте задачу. Зафиксируйте: какая была боль клиента, какую метрику нужно было изменить, какой срок стоял.
2. Скачайте приложение из стора, если ссылка есть. Установите, проверьте холодный старт, основные сценарии, поведение в фоне.
3. Запросите у разработчика одностраничный разбор: что сделано, какие решения приняты, какие альтернативы отброшены. Хороший разбор занимает 1–2 страницы текста, плохой — общими фразами без конкретики.
4. Проверьте наличие кода в открытом доступе. Если код закрыт — попросите показать структуру проекта, названия ключевых модулей, примеры тестов.
5. Спросите про поддержку после релиза. Кто мониторит краш-репорты, как быстро фиксятся баги, есть ли процесс работы с обратной связью из стора.
6. Сопоставьте заявленные метрики с реальностью. Откройте App Store, посмотрите рейтинг, дату последнего обновления, количество оценок. Если рейтинг 3.8 и обновлений не было полгода — кейс лучше не брать за основу.
После 5–6 кейсов у вас складывается картина: какие задачи разработчик тянет сам, где у него сильная экспертиза, где он скорее опирался на чужую работу. Эта картина ценнее любой презентации.
Итог
Аудит портфолио мобильного разработчика — не про красивые экраны и не про количество скачиваний. Это про три вещи: понимает ли исполнитель задачу бизнеса, умеет ли он решать её технически, готов ли отвечать за результат после релиза. Проверка одного кейса занимает 15–30 минут, пять кейсов — около двух часов. Это время окупается до подписания контракта, а не после, когда приложение падает у каждого третьего пользователя.
Главный фильтр простой: если разработчик не может назвать конкретные метрики своих проектов, не показывает архитектуру и не даёт ссылки на сторы — это не портфолио, а визитка. С визитками контракт лучше не подписывать.