Привет, Хабр! Сегодня публикуем интервью с Русланом Давлетшиным, CTO в Hyperskill и членом программного комитета серии митапов для мобильных разработчиков AppsConf X. Главной темой беседы стала хайповая сейчас тема искусственного интеллекта
Мы поговорили с Русланом о том, как мобильным командам быстро проверять гипотезы, как им удалось сделать семь приложений за семь недель, какие инструменты использовать и какое будущее ждёт разработку, когда генеративный ИИ станет частью повседневности.
Про опыт
Расскажи, как ты начинал свой путь в мобильной разработке? Где работал? Какие проекты тебе больше всего запомнились?
В мобильной разработке я с 2012 года. Сперва пытался разрабатывать на Java for Mobile, делать игры под эту платформу. Потом появился Android, и в 2014-ом я перекочевал туда. IOS тогда мне был недоступен, поэтому сфокусировался на Android.
Первый рабочий опыт получил в компании Stepik, где работал с 2017-го. Это платформа, где пользователи учатся, проходят курсы, получают различное образование. Там я прошел путь от Android разработчика до роли Head of Mobile, в которой сочетал две зоны ответственности — техническую и продуктовую, такой мини-CEO был, принимал все решения. В этой роли получилось классно прокачать мобильные приложения и сильно улучшить метрики. Например, DAO мы увеличили в два раза, и даже попали в рекламу новых iPad от Apple.
Когда я стал Head of Mobile, то понял, что мне хочется быть тем самым звеном между бизнесом и разработкой, которое позволяет бизнесу лучше решать свои задачи с помощью технологий. И стало ясно, что важно не только писать хороший код, но и понимать, какие проблемы у компании и какие решения дадут наибольший рост.
После Stepik я перешёл в Hyperskill, где сейчас работаю CTO. На данный момент у нас два основных больших продукта:
Сам Hyperskill — платформа для проектного обучения программированию, где пользователи учатся техническим навыкам.
Edvancium — мобильное приложение, которое использует AI-технологии, чтобы сделать обучение максимально персонализированным.
Это приложение ещё на начальном этапе, мы пытаемся найти Product Solution Fit, очень много экспериментируем и стараемся сделать классный пользовательский опыт.
Также я был кофаундером студии мобильной разработки, что позволило мне поучаствовать в куче разных проектов, посмотреть, как люди пишут код в разных местах, какие у них процессы, и приобрести богатый опыт за достаточно короткий срок.
А какие тебя задачи на карьерном пути тебя больше всего вдохновляли?
Сначала в Stepik мне были интересны разработческие задачи, например, сделать хороший кодовый редактор в приложении. Получилось классное технологическое решение. Из больших продуктовых проектов — нужно было адаптировать опыт обучения пользователей под мобильный формат. Это была сложная задача, со множеством деталей, которая требовала плотного взаимодействия с другими командами, но именно она позволила значительно улучшить продуктовые метрики приложений.
В Hyperskill из интересных проектов — это внутренний инкубатор продуктов, где мы пытаемся экспериментировать с новыми вещами, которые стали доступными с развитием AI. Основной вызов в этом направлении — быстрое прототипирование. Мы постоянно экспериментируем с разными подходами, чтобы быстрее проверять гипотезы, благодаря чему в какой-то момент вышли с командой из пяти человек на темп одно приложение в неделю полностью с нуля, и при этом у нас был всего один разработчик. В таком состоянии выпустили семь приложений.
Это были уже полноценные рабочие версии?
Это было в первую очередь MVP, которое проверяло продуктовую гипотезу. При этом в приложении была полностью реализована основная функциональность, приносящая ценность пользователю, а также стандартный набор фичей, вроде авторизации, аналитики, подписок и так далее. По стеку приложения были на React Native с использованием фреймворка Expo, в качестве бэкенда использовали Supabase вместе с различными AI провайдерами.
А как использовали искусственный интеллект?
AI использовали на всех этапах создания продукта: для уточнения требований, прототипирования, разработки, чтобы быстрее и проще писать код. Для разработки в основном использовали стандартный на середину 2024 года сетап из Cursor и ChatGPT. Агентские инструменты в это время ещё не были распространены так широко, как сейчас. С помощью AI мы сгенерировали универсальный шаблон с набором фич, одинаковых для всех приложений, к которым позже добавили характерную для конкретного продукта функциональность.
Также искусственный интеллект активно использовался в бизнес логике продуктов для улучшения пользовательского опыта, например, для персонализации.
Как это было реализовано в каком-нибудь приложении в общих чертах?
Среди продуктов, которые мы сделали, было приложение для борьбы с прокрастинацией. Это был ToDoList, помогающий решить проблему старта: состояние, когда у тебя есть какая-то большая неопределенная задача, которую ты никак не можешь начать делать. Мы интегрировали в приложение AI, который разбивал для пользователя такие задачи на простые шаги. Дальше он уже втягивался и начинал выполнять остальные задачки.
Про развитие продуктов и роль ИИ
Развивался ли этот продукт как-то дальше?
Из той серии приложений пользователям лучше всего зашёл проект для прокрастинаторов. Его мы дальше не развивали, но эти и другие наработки использовали в Edvancium.
Расскажи про Edvancium. В чём его уникальность?
Это приложение, которое позволяет учить всё что угодно, оно на ходу генерирует и адаптирует контент под пользователя на основе различных параметров. В Edvancium встроено множество образовательных механик, которые планируют, подбирают и персонализируют обучающие материалы. В этом основное отличие от того же ChatGPT.
Как показывает практика, персонализация сильно помогает улучшить образовательный опыт, потому что ты лучше и быстрее усваиваешь новые концепции, если они похожи на те, что ты уже знаешь. Например, если у тебя есть опыт в Kotlin, и ты изучаешь Python, тебе говорят: «Эти конструкции в Python работают также как в Kotlin, а эти похожи, но есть такие различия» – это сильно сокращает время и количество новой информации для усвоения. Также персонализация поддерживает мотивацию тем, что делает обучение более актуальным в рамках рабочих или личных задач. Это, вместе с уже стандартными механиками вроде Spaced Repetition и интерактивных заданий, которые позволяют не только читать текст, но и с ним взаимодействовать, позволяет ускорить transfer of learning, то есть состояния когда человек настолько освоил навык, что может применять его на кейсах отличных от учебных.
То есть приложение помогает быстрее изучить всё что угодно. Как вообще пришла идея такого продукта?
Идея возникла в Hyperskill. В начале 2023, как только появились достаточно прокаченные LLM модели, мы сразу поняли, что хотим генерировать контент с их помощью, потому что это быстро, удобно и легко масштабируется. От этого уже всё пошло. Сначала мы научились генерить контент в формате Hyperskill без персонализации по конкретным запросам от наших экспертов. В этом направлении у нас получилось добиться относительно неплохих результатов, во второй половине 2023 мы вышли на состояние, когда больше половины сгенерированных задач успешно проходило все проверки в инкубаторе контента и тестирование на пользователях в продакшене. Дальше мы начали экспериментировать с персонализацией, но поняли, что Hyperskill — это большой и сложный продукт, и поэтому решили это супер-экспериментальное направление выделить в отдельное приложение.
Это стандартный процесс тестирования продуктовых гипотез, или вы как-то во время работы к нему пришли?
Мы пришли к такому процессу, потому что иногда пользователям проще показать какой-то MVP, чем долго объяснять, что ты хочешь сделать, чтобы протестировать свою гипотезу. Тем более, что сейчас с помощью AI собрать такой MVP можно всего за несколько дней. В итоге на тестирование уходит около недели — это немного.
Если говорить о процессах в команде, запускавшей мобильные продукты, то это выглядело следующим образом: к началу новой недели у нас была гипотеза продукта, далее за первые дни мы понимали, как должна выглядеть реализация, и оставшиеся дни проходили от ничего до работающего приложения под обе платформы – Android и iOS, которое проверяет эту гипотезу. После чего оставшаяся часть команды продвигала приложение через различные маркетинговые каналы, например Reddit. Таким образом мы набирали первую группу тестовых пользователей, собирали с них фидбэк, и делали вывод о результатах тестирования гипотезы.
Как ИИ помогает в мобильной разработке
Расскажи, на твой взгляд, насколько сейчас в разработке этот тренд на использование нейросетей сильный?
Мне кажется AI, уже достаточно сильно повлиял на весь процесс разработки продуктов. Думаю, есть смысл рассказать, как у нас он сейчас выглядит.
Как было раньше. На основе данных, общения с пользователями и понимания рынка, у продакт-менеджера появлялась продуктовая гипотеза. Он придумывал базовое решение, обсуждал его с UX-дизайнером, после чего тот готовил прототип. Этот прототип груммился с командой разработки. На встрече разработка могла сказать — здесь ОК, здесь есть вопросы, здесь так работать не будет, потому что вы переусложнили. В идеальной ситуации для утверждения всех спорных моментов было достаточно одной встречи, в худшем случае несколько, если фича сложная. Суммарно это могло занимать недели.
После этого решение уходило в разработку, разработчики писали код ещё несколько недель, постепенно реализовывая функциональность. На этом этапе, помимо бизнес логики фичи, обычно надо было написать много boilerplate. Эту проблему немного облегчали современные языки программирования, вроде Kotlin, и различные генераторы шаблонов для модулей или фичей. Но даже с этой помощью разработчик всё равно писал много однообразного кода. Также на этом этапе создавались тесты, про которые часто забывали. После готовности фича уходила в тестирование, где также проводила до недели. Всё вместе это много работы.
Сейчас тестирование гипотез сильно поменялось, потому что тот же продакт-менеджер может сам пойти в инструмент и сделать прототип для фичи, вместо того, чтобы обсуждать его с UX-дизайнером и разработкой. Сейчас для этого уже есть несколько хороших сервисов, например, Bolt и Replit, которые позволяют собрать полностью работающее приложение без погружения в технические детали. Раньше они были сфокусированы только на веб-разработке, но за последние месяцы в обоих сервисах появилась генерация React Native приложений на базе Expo.
Это позволяет значительно ускорить feedback loop, так как во время генерации прототипа менеджер как раз находит ответы на большинство вопросов, которые ему задала бы разработка, например, о пробелах в бизнес-логике, которые непонятно, как должны работать. Также менеджер может сразу оценить, решает ли его задумка проблему пользователя. Понятно, что дизайн прототипа скорее всего будет страшненький. Но при этом его можно потыкать и уже на этом этапе понять, работает или не работает решение, и есть ли пробелы, которые не позволяют его реализовать.
Зачастую, разработанный прототип уже можно показать тестовым пользователям, или даже раскатить на всех. Второй вариант скорее актуален для веба, потому что инструменты пока больше заточены на веб-разработку. При этом они не требуют почти никаких технических знаний и очень дружелюбны к нетехническим специалистам.
Например, с помощью Replit можно собрать полноценный лендинг, который тестирует гипотезу, и сразу же прикрутить Stripe для оплат, или добавить AI функциональность через OpenAI. У нас в Hyperskill был случай, когда мы тестировали гипотезу, что пользователи считают полезным и готовы платить за карьерное сопровождение. Весь лендинг полностью без разработки сгенерил один продакт-менеджер, сразу подключил Stripe, задеплоил, сделал рассылку и кому-то даже что-то продал. То есть дополнительной разработки вообще не понадобилось.
Если всё равно нужна разработка, то с прототипом разработчикам и всей остальной команде намного проще понять, что надо делать. Это сильно сокращает количество итераций и обсуждений.
Когда готов финальный вид фичи, начинают проектировать её реализацию. С помощью AI сначала генерируется общее описание архитектуры, далее идёт доменный слой или слой с бизнес логикой, а затем – presentation, data и другие. На этом этапе можно сразу сгенерировать автотесты и зациклить на них LLM, генерирующую код реализации, чтобы уменьшить количество ошибок.
Тестирование тоже сильно упрощается: тест-кейсы генерируются автоматически по описанию фичи. Постепенно появляются агентские инструменты, которые можно использовать для автоматизации тестирования. Это уже достаточно хорошо работает в вебе, где есть продукты вроде Browser Use.
Это агент, которому ты даёшь промпт на натуральном языке, он нажимает кнопочки на сайте и проходит пользовательский путь. У нас он работает по промпту вида «Открой текущий курс на Hyperskill и реши задачу дня». Агент даже корректно решает часть задачек без подсказок. Сами промпты для агента тоже можно генерировать с помощью AI. Основное отличие Browser Use от аналогов, вроде Operator от OpenAI и Computer Use от Anthropic, в том, что он работает не со скриншотами, а с DOM-структурой страницы, что ускоряет и удешевляет его работу.
Думаю, что в мобильной разработке тоже должно появиться что-то похожее, потому что это логичное направление. Уже есть несколько стартапов, которые двигаются в эту сторону, но пока однозначно хорошего решения, как Browser Use, для веба, нет.
Расскажи более подробно про технический этап?
Ты всегда начинаешь с описания фичи, по которому генерируешь архитектуру реализации. AI описывает доменные сущности, которые будут использоваться, их взаимодействия между собой. С этим сейчас хорошо справляется режим Architect Mode в расширении Roo Code для VSCode. Он понимает структуру проекта и может генерировать mermaid диаграммы, которые облегчают восприятие.
По этому описанию стоит сразу сгенерировать тесты и далее на каждом этапе просить AI агента автоматически проверять свой код через них. Главное проследить, чтобы LLM не замокала тесты и не захардкодила тест кейс в реализации. Этим иногда грешит модель Claude Sonnet 3.7, которая стала особенно креативной.
Далее с описанием и тестами итеративно генерируется реализация доменного слоя, и на его основе остальные части проекта. В промпте важно указать само описание, пункт про запуск тестов и запретить AI менять код вне пределов модуля или пакета с фичей. Когда код готов и тесты пройдены, можно переходить к следующим слоям. Условно промпты выглядят так: «На базе доменного слоя сгенери мне следующий слой, например, presentation или слой работы с данными». Конечно не всегда получается идеально, надо постоянно проверять, что пишет AI. Этот подход работает для всех слоев, кроме UI части, так как у нейросети пока что нет развитого чувства прекрасного, как у людей, которые могут делать хороший UX и UI.
Основная идея в итерационной генерации – не давать AI слишком большие задачи и ограничивать его работу в рамках одного модуля или пакета, чтобы самому оставаться в контроле генерируемого кода и не перегружать контекст модели.
Есть ещё несколько подходов, которые мы активно используем для улучшения качества генерации. Например для каждого модуля или крупного пакета можно создать файл с мета информацией про этот модуль, которая упростит понимание контекста для людей и AI агентов. Для этой задачи хорошо подходят модели с большим контекстным окном, вроде Google Gemini 2.5 Pro, здесь, как и в других задачах, имеет смысл применять итеративный подход. После ручной инициализации можно настроить CI для автоматического обновления этой информации на основе изменений в коде.
По аналогии поступаем с кодстайлом, просим LLM проанализировать код проекта или конкретных файлов и составить описание кодстайла, и потом через правила в IDE заставляем модель следовать ему. Сами правила настраиваются по-разному в зависимости от IDE, например в Cursor это делается через Cursor Rules.
Ещё сильно улучшить качество генерируемого кода помогают примеры или референсы. Если у тебя есть какой-то архитектурный паттерн, который ты хочешь применить, и он уже реализован в проекте, то можно так и указать в промпте: «При реализации используй этот паттерн также как в этом файле», это позволит получить желаемый результат с первого раза без длинных промптов.
На последок могу порекомендовать тяжелую артиллерию – расширения для долговременной памяти. Этот паттерн называется Memory Bank, он позволяет AI агенту не терять контекст на больших задачах. Его можно реализовать самостоятельно или использовать готовое решение, самое прокаченное из готовых – Task Master.
А что насчёт технического долга? Помогает ли искусственный интеллект с этим?
Да, помогает. У меня недавно был кейс, правда, он не связан с мобильной разработкой, но с техническим долгом. Мы пишем бэкенд на Python, и у нас был модуль, через который мы генерировали обучающий контент. Было много технического долга и код был среднего качества, с этим постоянно что-то хотелось сделать. Раньше было бы сложно дойти до этой задачи из-за низкого приоритета и больших временных затрат. Благодаря AI, усилий, которые надо потратить, стало меньше — до подобных задач стали доходить руки.
В Cursor есть очень крутое автозаполнение. Когда ты делаешь что-то одинаковое, он в какой то момент понимает твои намерения и начинает проактивно предлагать изменения, тебе остается только нажимать Tab. Ещё можно выделить кусок кода, сказать: «Перепиши по аналогии с этим файлом», дать референс на кусок, который уже хорошо написан, и он его перепишет также.
У меня было такое, что я отрефакторил большой кусок кода и потом пошёл переписывать тесты. С помощью AI получилось сразу обновить все тесты в файле примерно на тысячу строк. В промпте я описал изменения в API, дал ссылки на новый код и попросил AI проверить себя через запуск тестов. В результате рефакторинг тестов занял несколько минут, а раньше я бы сидел и менял руками каждую строчку.
Ещё забавный момент. С AI очень легко делать правки в фичах. Раньше было так — ОК, есть какая-то фича, надо пойти, что-то поменять, запушить. Сейчас в некоторых ситуациях можно просто взять описание задачи, засунуть его в качестве промпта для AI агента, например в Windsurf, и этого будет достаточно. Тебе остается запушить и отправить — задача готова!
Мы даже продакт-менеджеров и других нетехнических специалистов научили делать самостоятельно небольшие изменения в коде. Это стало возможно потому что Windsurf достаточно неплохо ориентируется по коду. Если вместе с этим человеку хотя бы базово рассказать, где что в коде лежит, то он вполне сможет какие-то вещи сам менять. Так можно очень легко и быстро подправить бизнес-логику, тексты, модальные окна, поехавшую вёрстку. Раньше такие задачи часто могли потеряться в сложных процессах команд, а теперь каждый может просто пойти и сделать это, сразу создав pull request с изменениями.
Про будущее и как развиваться дальше мобильному разработчику
Куда это всё может вырасти, по твоему мнению? Как разовьётся? Как тебе кажется, в будущем ИИ действительно заменит разработчиков, как сейчас нас пугают?
Если речь про процесс разработки, то я думаю, что человек еще долго будет у руля, но с помощью AI мы будем постоянно повышать уровень абстракции, с которым работаем.
Следующим логичным шагом мне кажется – развитие и распространение такого формата работы, когда разработчик большую часть времени оперирует на уровне бизнес логики проекта, скорее всего на уровне модулей. Когда он начинает делать изменения в текущей логике или новую фичу, то сначала вместе с AI, на основе требований и особенностей системы, генерирует несколько вариантов RFC, или другой аналог описания архитектуры. После чего опять же с помощью AI ранжирует и выбирает лучший вариант.
Далее AI агент полностью автономно рендерит код на основе выбранного RFC сразу вместе с тестами. При этом AI сам выбирает язык программирования, который лучше подходит для этой задачи. Например, если нужен супер-перформанс, то С++, если это не важно, любой другой язык, который удобен. Если разработчику нужно будет посмотреть код на незнакомом языке, то с помощью AI его можно будет “перевести” на тот, который будет понятен. Таким образом знание конкретного языка становится менее приоритетным.
Будто бы в целом сами LLM под это готовы, но у нас пока нет инструментов и подходов работы с кодом, которые бы позволили удобно реализовать этот формат. Я бы ожидал скоро увидеть IDE нового формата, AI-ready архитектуру проектов и развитие тулов для детерминированных проверок решений AI, которые позволят модели быстрее получать фидбек и исправлять свои ошибки. В контексте стека я ожидаю дальнейшего развития кроссплатформы на базе Kotlin Multiplatform или Flutter для крупных проектов, и ренессанс React Native для небольших проектов.
Еще один тренд, который был и раньше, но, на мой взгляд, станет еще более важен – это переход разработчиков из Software Engineer в Product Engineer, то есть большего вовлечения инженеров в продуктовые процессы и решения. В продуктовых компаниях будут всё больше цениться инженеры, которые могут на основе пользовательских болей самостоятельно решить что делать и потом реализовать это продуктовое изменение, включая UX и бизнес логику, с помощью AI.
А что делать сейчас? Куда развиваться мобильным разработчиком в таких условиях?
Я бы выделил следующие направления:
Проектирование архитектуры и system design.
Чтение чужого и, в особенности, кода, написанного AI.
Умение командовать, ставить задачи и контролировать результат работы команды AI агентов.
Понимание продукта, насмотренность и умение принимать продуктовые решения.
И самое главное – это умение пользоваться AI инструментами в рабочих задачах.
Как бы ты посоветовал развивать каждый из пунктов?
Основное — это практика. Чем больше разных задач, задействующих навык, ты решаешь, тем лучше им владеешь.
В рамках архитектуры стоит пробовать брать более абстрактные технические задачи чем, те к которым вы привыкли. Будет полезным найти ментора внутри вашей команды, который сможет давать вам фидбек, если такого человека нет, то можно использовать AI, который будет подсветит сильные и слабые стороны в ваших решениях.
При ревью кода старайтесь не просто смотреть на код, а прямо пытаться понять, что он делает внутри. Если какой-то кусок кода непонятен, то можно просить тот же AI объяснить его, а если хочется углубиться в какую-то тему, то тут подойдут образовательные MCP, которые подключаются прямо в IDE.
С точки зрения продукта, вам необходимо знать кто основные пользователи вашего продукта, какую задачу решает ваш продукт для них и какие продуктовые метрики считаются главными. С этой информацией вы можете постепенно брать больше продуктовой ответственности на себя – например полностью продумать и реализовать небольшую фичу под менторством вашего продакт менеджера. Еще важную роль играет насмотренность и хороший вкус, для тренировки этих параметров советую посмотреть разборы кейсов от Growth Design.
При изучении AI первая задача – не отрицать и принять AI как часть нашей жизни. Далее начинать делегировать ему все больше и больше своих задач, попутно пробуя разные инструменты и подходы. Делегирование задач AI агентам в целом похоже на работу с Junior сотрудниками, для тренировки этого навыка можно начать с воркфлоу, про который я рассказывал раньше.
Сейчас появляется очень много AI тулов, кроме самих тулов – постоянно улучшаются техники работы с ними и с LLM в целом. Чтобы спастись от перегрузки информацией, для себя в личном todo листе я веду отдельный беклог AI тулов, которые я постепенно изучаю, применяя на рабочих задачах. Также могу порекомендовать пройти обучающие проекты в Enlighter, чтобы изучить различные техники работы с AI в IDE.
А что сейчас кажется тебе самым больным местом в твоей профессии и в отрасли? Что сложно, что вызывает опасение и тревожность за будущее?
Есть большая тема про ограничения AI. До этого было прямо совсем неудобно, потому что все SOTA модельки были закрытые, ими было сложно пользоваться. Сейчас появилось много открытых моделей, которые не сильно уступают SOTA моделькам. Те же DeepSeek или Qwen, они доступны и не так сильно уступают топовым reasoning моделям. Есть другие открытые модели, которые тоже можно использовать чуть ли не локально. Организации могут разворачивать их у себя в контуре, особенно если нужна приватность кода. Это сильно упрощает жизнь, потому что раньше модель типа o3 была только у OpenAI, и если у нас нет доступа к OpenAI, тогда всё, для нас закрыт этот путь. Сейчас стало сильно проще.
Плюс форки VS Code уже все, кому не лень, сделали. У них тоже можешь использовать свои модели внутри, если у тебя есть свой сервис, где эти модели лежат. У себя внутри мы используем LiteLLM, через который проксируем все доступные модели.
В общем, я с оптимизмом смотрю в будущее, потому что эта гонка всех подстегивает выпускать всё более крутые модели.
Про боли могу сказать так. В последнее время был некоторый застой в мобильной сфере. Раньше было несколько крупных миграций – если брать Android, то сначала все переходили с Java на Kotlin, потом с RxJava на корутины, эволюционировали архитектурные подходы с MVC до MVP и MVI.
А в последнее время всё достаточно спокойно, ничего не происходит, всё устаканилось. Был некоторый застой, сейчас AI снова открыл новую веху, потому что теперь нужно под ИИ адаптироваться всем — и архитектуре, и людям учиться с этим работать. Как раз в этом должна помочь наша серия митапов. Потому что тема AI будет хорошо покрыта программой докладов.
Мы собираем практические кейсы, где люди смогут не только вдохновиться, но ещё унести с собой подходы, про которые мы тут много говорили, и начать это применять. Даже с учётом ограничений, которые в России есть — чтобы что-то внедрить на следующий день у себя в компании, и ускорить всех.
Например, про ИИ для мультиплатформенных приложений и LLM на IOS расскажем на бесплатном онлайн-митапе AppsConf X уже совсем скоро – 24 июля. Ждём всех, кто так или иначе задействован в мобильной разработке и хочет понять возможности использования AI-инструментов в работе и адаптации их под свои нужды.
На других митапах, 14-15 августа, в онлайне поговорим на следующие темы:
Миграция на SPM: что мы выиграли (и что потеряли?).
XCTest или SwiftTesting: правда ли, что трава стала зеленее?
Производительность под микроскопом — инструменты для мониторинга производительности iOS-приложений.
Разработчик и софт-скилы: инструмент влияния без полномочий.
Модуляризация на максималках: собираем разные приложения как конструктор.
А осенью встречаемся оффлайн: 4 сентября в Питере и 25 сентября в Москве. Вступайте в наше сообщество мобильных разработчиков, чтобы не пропустить анонсы, явки и пароли: https://t.me/appsconf.