Всем привет! Хочу поделиться своим первым опытом в разработке мобильной игры для iOS — в жанре roguelite. Это pet‑проект, который неожиданно для меня самого дорос до релиза в App Store, так что расскажу и про идею, и про технические идеи. Надеюсь, будет интересно почитать:)
Я проходил курс по разработке под iOS и решил, что лучший способ реально закрепить материал — сделать несколько реальных проектов. Одним из таких проектов стал LootShrine — ссылка на игру в App Store.
Я врач с более чем 30-летним стажем, последнее время работал доцентом медицинского вуза. Недавно я вышел на пенсию и получил то, о чем мечтал всю трудовую жизнь — много свободного времени, и часть его желательно тратить с пользой (а не только играть на ПК, что я, конечно, тоже люблю).
Я не пишу код каждый день уже много лет, последний продакшен на PHP отгрузил году в 2009. Но за последние годы инструменты дошли до состояния, когда сольный pet‑проект с распознаванием речи на устройстве собирается силами одного человека. Эта статья про то, как я сделал голосовой дневник мыслей для когнитивно‑поведенческой терапии (КПТ), почему распознавание речи у меня крутится прямо на телефоне, и какие на этом пути были технические развилки. Кода почти не будет, будет архитектура и обоснование решений.
Ещё несколько лет назад разговоры об iPad как полноценном инструменте разработчика воспринимались скептически. Машинка для Netflix, блокнот для набросков, планшет для презентаций — но только не рабочая среда для написания и деплоя кода. У этого скептицизма были основания: iPadOS долго не имела нормальной многозадачности, инструментов для работы с серверами почти не существовало, а необходимость постоянно переключаться между приложениями делала любой серьёзный рабочий процесс мучительным.
Сегодня картина изменилась кардинально, и сразу по двум причинам, которые усиливают друг друга.
Уровень: middle/senior мобильная разработка, React Native, SQLite Стек: Expo SDK 54, React Native, expo-sqlite, drizzle-orm, AsyncStorage, TypeScript Что внутри: архитектура, код из продакшна, грабли, цифры
Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат.
Я выпустил Simplphoto — бесплатное приложение для iPhone, в котором собрал три вещи, которых мне не хватало: ручную камеру, stop motion и коллажи.
Все началось от идеи уменьшить вмешательство ИИ в процесс фотосъемки, поэтому в Simplphoto сделан упор не на «магическое улучшение», а на более понятный и контролируемый процесс съёмки.
В разделе Camera я делаю ставку на ручной контроль и на то, чтобы итоговый кадр был более ожидаемым в различных условиях. Настройки включают привычные для полноценного фотоаппарата настройки:
ISO;
Shutter speed;
Когда рассказывают про архитектуру Flutter-приложения, всё обычно выглядит слишком аккуратно.
Есть Bloc, есть Dio, есть go_router, есть get_it. Где-то рядом лежат репозитории, модели, пара экранов и слайд со стрелками. На демо это звучит убедительно: “вот UI-слой, вот data-слой, вот state management”. Кажется, что если взять правильный набор пакетов, дальше система почти сама соберётся.
У меня так не вышло.
Начиная писать Flutter-приложение, для стейт-менеджмента часто хватает простого setState или решения по типу BLoC/Cubit без излишеств. Но с течением жизни проекта ваши блоки могут начать превращаться в god objects. Внутри хендлеров могут находиться и запросы в сервисы, и валидация, и эмиттеры состояния, а для крупной страницы точно одним ивентом не обойдешься. В таких условиях разработка сильно затрудняется, становится сложно поддерживать и масштабировать проект, снижается тестируемость.
Если ты разрабатываешь под Android и нужно сохранять информацию на телефоне, без базы данных не обойтись. В системе есть встроенная SQLite — бесплатно и надёжно, но есть минус: чтобы с ней работать, приходится писать SQL-запросы вручную, в коде разбирать объект Cursor и не забывать закрывать соединения. Я сам сталкивался с тем, что из-за такой возни появляются баги и тратится много времени.
Перевод статьи Лорелея Уитмен, RevenueCat
Рынок подписочных приложений быстро меняется. Старые приложения по-прежнему доминируют по доле выручки, но новые каждый день наводняют cторы. ИИ-приложения «умирают» быстрее, чем успевают выходить, а зона безопасной выручки для среднего приложения стремительно исчезает. «Выживания» больше нет: либо процветаешь, либо выгораешь.
