Capacitor: от веба к мобильным приложениям. Часть 4. Интегрируем локальный LLM в проект
Привет, Хабр! Продолжаем серию статей о разработке мобильных приложений с помощью Capacitor. Если вы не читали предыдущие части, лучше начать с них:Часть 0. Зачем нужен CapacitorЧасть 1. Миграция проекта на CapacitorЧасть 2: Как написать свой плагинЧасть 3: OTA-обновленияВ этой части разберём, как запустить языковую модель прямо на телефоне — без сервера, без API-ключей и без постоянного интернета.Зачем локальный AI
Мобильная разработка за неделю #630 (11 — 17 мая)
Возвращаемся после небольшого майского перерыва с новым дайджестом - советы и хитрости Xcode 16 и как добиться 0 рекомпозиций в сложном кастомном UI, три раунда войны с Android-клавиатурой в WebView и обновление без разрешения пользователя, 10 оптимизаций Swift, которые улучшат производительность, тестирование Compose по-новому, декларативная навигация для Flutter, под капотом перезапуска приложения Бургер Кинг и многое другое. Заходите!
200 OK по протоколу, но не OK для клиента: автоматизация контроля совместимости API и приложения
Выпустить релиз — часы работы команды. Упасть на старте — 1 секунда. Узнать об этом не из отзывов пользователей — бесценно. Серверные тесты проходят, эндпоинт отвечает 200 OK, но мобильный клиент падает на первом же ответе API.Типичный сценарий: в user.id приходит null, у status появляется новое значение или меняется вложенная структура — и ответ API расходится с клиентскими моделями.
200 OK иногда = кома: почему API «работает», а приложение — нет (и как нам помог ИИ)
Статус 200 OK коварен своей тривиальностью.Бэкенд-тесты «зеленые», API честно отдает данные, а веб-клиент мгновенно подхватывает изменения. Кажется, что всё в порядке, но в это же время мобильные клиенты теряют работоспособность. Приложение не выдает сетевых ошибок, оно просто не может корректно обработать обновленный DTO: клиент ожидает одну структуру данных, а получает другую.Это не баг логики сервера, а технический разрыв между живым API и замороженным артефактом — версией приложения, которая ничего не знает о правках в схеме данных, сделанных через полгода после его релиза.
Один ИИнженер — десять рук: как мы исследовали LLM в AppSec
Всем привет, на связи Solar appScreener!В этой статье расскажем о нашем опыте использования ИИ в нашем собственном продукте.
За два месяца вместо года: как мы переписали 97 тысяч строк кода с Objective-C на Swift
Миграция большого iOS-проекта с Objective-C на Swift кажется понятной задачей ровно до тех пор, пока не начинаешь считать объём. В нашем случае это были 10 тысяч файлов, сотни тысяч строк кода и постоянная необходимость не останавливать развитие продукта. Ручной подход работал слишком медленно, поэтому мы начали автоматизировать миграцию с помощью LLM — и в итоге превратили её из бесконечного техдолга в воспроизводимый процесс.
