Мобильный разработчик пишет программы, которые живут на смартфоне: рисует экраны и кнопки, программирует логику, учит приложение ходить в интернет за данными, хранить их офлайн и дёргать железо телефона — камеру, геолокацию, push-уведомления, отпечаток пальца. Но главное отличие его работы не в этом. Мобильщик не контролирует устройство, на котором крутится его код, и не он решает, попадёт ли его работа к людям. За него это решают двое: ревьюеры Apple и Google.
Это и есть профессия, если снять с неё рекламный глянец. Не «делать красивые приложения», а уместить продукт в чужие правила — правила тысяч разных телефонов и двух корпораций, которые стоят на входе в магазин с правом сказать «нет». Программирование тут — половина работы. Вторая половина начинается там, где другие разработчики уже свободны.
Дальше — по слоям. Сначала что мобильщик физически делает руками. Потом чем эта работа отличается от веба и бэкенда — и почему отличие меняет всё. Потом как выглядит обычный его день. И в конце — кому такой склад ума подходит, а кому стоит держаться от мобилки подальше.
Марина заказывает еду в метро. Поезд ныряет в тоннель, связь отваливается, она открывает приложение — и корзина пустая. Всё, что она набрала, исчезло. Через две станции интернет вернулся, но настроение уже нет. «Безрукие, — думает она про разработчиков. — Не могут сделать, чтобы просто работало».
Марина не знает, что только что описала чужую должностную инструкцию. «Сделать, чтобы корзина не пропадала без интернета» — это конкретная задача конкретного мобильного разработчика. Называется офлайн-кэширование. Кто-то её либо не сделал, либо сделал плохо, либо ему не дали на неё время. И вот это раздражение Марины — лучший тест на профессию. Одних оно злит как пользователей и проходит. Других цепляет иначе: а как вообще сделать, чтобы работало без сети? Где хранить корзину, чтобы она пережила тоннель? Второй вопрос — уже мысль разработчика.
Начнём с физики. Что мобильщик делает руками за день.
Любое приложение — это несколько слоёв одной программы, и разработчик собирает их все. Возьмём ту же доставку еды. Есть интерфейс — экраны, кнопки, списки ресторанов, корзина: это пользователь видит и трогает. Есть логика — что происходит, когда нажал «добавить»: товар падает в корзину, пересчитывается сумма, меняется кнопка. Есть работа с сетью — приложение лезет на сервер, тянет список ресторанов поблизости, отправляет заказ. Есть работа с данными — корзина и история заказов хранятся прямо в телефоне, чтобы открывались мгновенно и без интернета. И есть работа с железом — геолокация подтягивает рестораны рядом, push прилетает с «курьер выехал», камера сканирует карту для оплаты.
Один экран доставки — это все пять слоёв сразу. Мобильный разработчик не специализируется на «кнопках» или «сети» — на junior-уровне он делает всё понемногу, а с ростом уходит вглубь. Kotlin для Android, Swift для iOS — на этих языках пишется и интерфейс, и логика, и обращения к камере. Это не пять разных профессий. Это одна, в которой надо уметь спускаться от красивого экрана до данных в памяти телефона.
И вот тут начинается то, что отличает мобилку от всего остального в разработке.
Веб-разработчик контролирует сервер. Один компьютер, его компьютер: он знает мощность, видит логи, может зайти и починить на лету. Сайт открывается в браузере, а браузер примерно одинаков у всех.
Мобильщик отдаёт свой код на тысячи чужих телефонов и больше его не видит. Дешёвый бюджетник с крошечным экраном и нехваткой памяти. Флагман с экраном в полпланшета. Телефон трёхлетней давности на старой версии Android. И всё это одновременно — приложение обязано работать на каждом. Нельзя спроектировать «под нормальный телефон»: нормального телефона не существует, есть зоопарк. Проектируют под худший случай — маленький экран, слабое железо, медленная сеть. Если влезло туда, влезет везде.
Отдельная боль — офлайн. Сайт без интернета просто не грузится, и это всем привычно. От мобильного приложения ждут другого: заметки должны открываться в самолёте, плеер — играть скачанное, карты — показывать маршрут в подземном паркинге. Связь на телефоне рвётся постоянно — лифт, метро, дача, — и приложение, которое в эти моменты умирает, удаляют. Поэтому мобильщик думает про данные иначе, чем веб-разработчик: что сохранить локально, что показать из памяти, пока сети нет, как потом тихо досинхронизировать, когда связь вернётся. Корзина Марины — ровно про это. Тот, кто её делал, либо не подумал про тоннель, либо подумал и сэкономил.
Это не «веб, только на телефоне». Это другая физика. И поверх неё стоит ещё один барьер, которого у веба нет вовсе.
Веб-разработчик публикует сам. Купил домен, залил файлы на сервер — сайт живёт, никого не спросив. Мобильный разработчик так не может. Его приложение попадает к людям только через магазин — App Store у Apple, Google Play у Google, — и магазин его проверяет.
Apple проверяет вручную. Живой человек скачивает ваше приложение, открывает, тыкает и решает, пускать или нет. Завернуть могут за что угодно: непонятный интерфейс, нарушение одного из сотен пунктов гайдлайнов, формулировку «не несёт пользователю ценности». Google помягче и больше доверяет автоматике, но тоже банит и тоже выкатывает требования. Гайдлайны платформ — это толстые документы на сотни страниц, и их приходится знать, потому что нарушение означает, что твоя работа недели две будет лежать на полке, пока ты переделываешь.
Заблуждение новичка звучит так: напишу приложение — выложу — готово. Реальный цикл другой: написал — отправил на проверку — завернули — переделал — отправил снова — выложил. Мобильщик делает продукт сразу для двоих: для пользователя и для ревьюера-вахтёра, который стоит на входе. Это уникальная для мобилки штука. Никто не проверяет сайт перед запуском на «соответствие ценностям».
И есть совсем грубый, физический барьер. Под iOS можно разрабатывать только на технике Apple. Среда, в которой собирают iOS-приложения, существует исключительно под macOS.
Нет Mac — нет iOS-разработки. Точка.
Android в этом смысле демократичнее: Kotlin пишут на любом компьютере, хоть на старом ноутбуке с Windows. Но если тянет именно к iPhone, первым делом смотрят не на курс, а на то, есть ли в доме Mac. Ни у веб-разработчика, ни у бэкендера такого условия нет в принципе.
Теперь развеем главную картинку из головы новичка: программист сидит и восемь часов пишет код. Так не бывает почти ни у кого, а у мобильщика — особенно.
Утро — короткий созвон команды: что сделал вчера, что делаешь сегодня, где застрял. Дальше задача из таск-трекера. И задача нередко звучит так: «приложение вылетает на старых Android при повороте экрана». Не «напиши новую красивую фичу» — а «найди и убей баг, который видно только на конкретной модели телефона у одного из ста пользователей». Полдня может уйти на то, чтобы вообще воспроизвести этот вылет: достать нужный эмулятор или физический телефон, повторить ровно те действия, поймать момент. Код, который чинит баг, — три строки. Расследование до них — три часа.
Между этим — тестирование на разных устройствах, потому что починил на одном, сломал на другом. Код-ревью: читаешь, что написали коллеги, они читают твоё. Разговор с дизайнером — «вот так не влезет на маленький экран, дай запасной вариант». Разговор с бэкендером — «добавьте, пожалуйста, это поле в ответ сервера, иначе мне нечего показать». Вечером — собрать приложение и проверить, что после твоих правок ничего не отвалилось в другом месте.
Чистого написания нового кода в таком дне хорошо если треть. Остальное — расследование чужих багов, тесты на зоопарке устройств, согласования. Кто шёл в профессию «писать код», а получил «целый день ловить вылет на телефоне, которого у тебя нет», — разочаровывается быстро. Кто относится к багу как к детективу — живёт счастливо.
Под одним словом «мобильный разработчик» живут три разных человека.
Android-разработчик пишет на Kotlin, работает на любом компьютере, и под ним — гигантская аудитория: в России это большинство телефонов. Расплата — тот самый зоопарк: тысячи моделей от десятков производителей, и на каждой может вести себя по-своему. Главная боль Android — «у меня работает, а у пользователя вылетает».
iOS-разработчик пишет на Swift, работает только на Mac. Аудитория меньше, но платит охотнее, поэтому под iOS часто выпускают раньше. Устройств немного и они предсказуемые — тестировать проще. Расплата — Apple со своим ручным ревью, который заворачивает строже и придирчивее.
Кросс-платформенный разработчик берёт один инструмент — чаще всего Flutter с языком Dart или React Native — и пишет одно приложение сразу под обе платформы. Бизнесу дешевле: одна команда вместо двух. Расплата прячется глубже: такой инструмент закрывает платформу слоем абстракции, и пока всё хорошо — всё хорошо, но когда что-то ломается «под капотом», на уровне самой Android или iOS, разбираться всё равно приходится по-нативному. Абстракция течёт, и тогда нужно знать то, что она прятала.
Это не лестница «хуже — лучше». Это три профиля под разные задачи и разный склад человека. Какой из них брать первым — отдельный большой разговор; здесь важно одно: «мобильный разработчик» — это не одна дверь, а три, и за каждой свой коридор.
Соберём портрет. Мобилка — для человека, которому важен осязаемый результат. Не строчка в отчёте, а штука в руках: дал телефон маме — «смотри, это я сделал», и она тычет пальцем в твою работу. Для того, кто терпелив к расследованию: баг на одной модели из ста его не бесит, а раззадоривает. И — это редко проговаривают — для того, кто умеет жить по чужим правилам без бунта. Гайдлайны Apple, ревью Google, ограничения железа — всё это рамки, и мобильщик внутри них работает каждый день.
Кому не стоит. Тому, кто ненавидит ограничения и хочет полной свободы делать как вздумается, — мобилка вся про чужие рамки, тут свобода заканчивается на входе в магазин. Тому, кто не выносит рутину тестов и охоты за багами на устройствах. И тому, кто пришёл с мечтой «напишу гениальное приложение и разбогатею»: в команде девять дней из десяти ты поддерживаешь и чинишь чужой код, а не строишь свой стартап.
Три заблуждения новичков, которые лучше похоронить сразу. Первое: «это как сайты, только на телефоне» — нет, другая физика: офлайн, железо, ревью, зоопарк устройств. Второе: «выучу Flutter и не надо знать платформу» — надо, абстракция течёт ровно в тот момент, когда что-то сломалось. Третье: «главное — придумать крутую идею» — идея ничего не стоит без умения провести приложение через разработку, тесты и проверку магазина живым, а не на словах.
Не покупая курс и не записываясь никуда, профессию можно примерить сегодня. Возьмите любое приложение в телефоне и доведите его до сбоя: выключите интернет, поверните экран, нажмите назад в неожиданном месте. Поймайте свою реакцию. Если приложение зависло и вас это просто разозлило как пользователя — нормально, это не ваше. Если в голове щёлкнуло «а почему оно так, как это вообще сделано и как бы я починил» — вот это и есть склад мобильного разработчика. Не любовь к телефонам. Любопытство к тому, что у них внутри ломается.
И трезвая рамка напоследок. Вся профессия — про жизнь в чужих границах: чужое устройство, чужие гайдлайны, чужой ревьюер на входе. Если границы злят и хочется их снести — мобилка измотает. Если границы — это интересный пазл, который надо собрать так, чтобы работало у всех и пустили в магазин, — тогда добро пожаловать, это ваш пазл. Деньги, кстати, в порядке: junior на входе получает 105 000–130 000 ₽ по медиане предлагаемых зарплат hh.ru за 2026 год, дальше — заметно выше. Но идти в профессию ради цифры, не примерив склад ума, — самый дорогой способ потерять полгода.
Если щёлкнуло, но всё ещё неясно — мобилка ли это вообще и под Android или iOS заходить, — пройдите Профтест на этом сайте. За пять минут он сопоставит ваш склад ума, бэкграунд и наличие техники (есть ли тот самый Mac) с подходящими ИТ-направлениями и покажет, стоит ли вам в мобильную разработку.
А корзина Марины, которая пропала в метро, — теперь вы знаете, чья это была недоработка. И знаете, как её чинят: сохранить локально, показать из памяти, досинхронизировать, когда связь вернётся. Если, читая это, вы поймали себя на мысли «ну так надо было просто кэшировать» — поздравляю, вы только что подумали как мобильный разработчик.
