AI-ассистент для написания текстов в мобильном приложении

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
AI-ассистент для написания текстов в мобильном приложении
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    745
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1162
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    563

Реализация AI-ассистента для написания текстов (Writing Assistant) в мобильном приложении

Мы разрабатываем AI-ассистент (Writing Assistant) для мобильных приложений — это не просто поле ввода с кнопкой «улучшить». Это редактор, который работает в контексте: понимает тип документа (письмо, пост, отчёт), поддерживает стриминг, не сбрасывает курсор при вставке и переживает фоновый режим без потери состояния. Такая функциональность требует соблюдения App Store Review Guidelines (раздел 4.2 о минимальной функциональности) и Play Store политик.

Именно на этих деталях ломаются 80% реализаций. Мы видели проекты, где AI-генерированный текст либо сбрасывал курсор, либо лагал при быстром выводе (>20 символов/сек), либо терялся после свёртывания приложения. За 5 лет работы и 20+ проектов по интеграции AI в мобильные приложения мы накопили арсенал решений. Наш Writing Assistant повышает Engagement на 40% и сокращает время написания текста в 2 раза.

Архитектура редактора с AI

Первый выбор — использовать нативный UITextView/EditText или кастомный редактор. Мы рекомендуем нативный компонент в 90% случаев: он корректно обрабатывает выделение, undo/redo и пагинацию. Однако с AI-функциями появляется нетривиальная задача: вставка сгенерированного текста без разрушения позиции курсора и выделения.

// iOS: вставка AI-текста через NSTextStorage без сброса курсора
func insertAIText(_ text: String, at range: NSRange) {
    guard let textView = self.textView else { return }
    let storage = textView.textStorage
    let cursorOffset = textView.selectedRange.location
    storage.beginEditing()
    storage.replaceCharacters(
        in: range,
        with: NSAttributedString(string: text, attributes: defaultTypingAttributes)
    )
    storage.endEditing()
    let newOffset = cursorOffset + (text.count - range.length)
    textView.selectedRange = NSRange(location: max(0, newOffset), length: 0)
}

На Android с EditText аналог через Editable.replace() + сохранение SelectionStart/SelectionEnd через android.text.Selection.

Компонент Преимущества Недостатки
Нативный UITextView/EditText Бесплатно, стабильно, поддержка Accessibility Ограниченная кастомизация на Android
Кастомный редактор (TextKit/Canvas) Полный контроль над рендерингом Сложно реализовать выделение и undo/redo

Нативный вариант лучше кастомного в 90% случаев, так как экономит инженерные часы и упрощает поддержку.

Как обеспечить стриминг без лагов?

Writing Assistant обязан стримить текст — пользователь видит, как AI печатает. Технически это AsyncStream<String> (iOS) или Flow<String> (Android), каждый чанк добавляется в конец активного параграфа.

Типичная проблема: при быстром стриминге (> 20 символов/сек) UITextView начинает лагать на длинных текстах. Причина — NSTextStorage триггерит layout pass на каждое изменение. Наше решение — батчинг апдейтов:

private var streamBuffer = ""
private var streamTimer: Timer?

func appendStreamChunk(_ chunk: String) {
    streamBuffer += chunk
    if streamTimer == nil {
        streamTimer = Timer.scheduledTimer(withTimeInterval: 0.05, repeats: false) { [weak self] _ in
            guard let self else { return }
            self.textView.textStorage.beginEditing()
            self.textView.textStorage.append(NSAttributedString(string: self.streamBuffer))
            self.textView.textStorage.endEditing()
            self.streamBuffer = ""
            self.streamTimer = nil
        }
    }
}

Каждые 50 мс — один layout pass вместо 20. На iPhone SE 2nd gen разница видна невооружённым глазом.

Почему важно контекстное меню AI?

Writing Assistant обычно предлагает несколько действий: продолжить текст, переписать выделенное, изменить тон, сократить, расширить. Если показывать все кнопки сразу — UI превращается в хаос. Правильная схема: контекстное меню появляется только при наличии выделения (для «переписать», «изменить тон»), floating action button появляется в конце параграфа (для «продолжить»). Два разных триггера — два разных UX-паттерна.

Действие Триггер Тип меню
Продолжить текст Конец параграфа Floating button
Переписать Выделение текста Contextual menu
Изменить тон Выделение текста Contextual menu
Сократить Выделение текста Contextual menu
Расширить Выделение текста Contextual menu
// Android Compose - floating assistant button
@Composable
fun WritingAssistantOverlay(
    textFieldState: TextFieldState,
    onContinue: () -> Unit,
    onRewrite: (String) -> Unit
) {
    val hasSelection = textFieldState.selection.length > 0
    AnimatedVisibility(visible = !hasSelection) {
        FloatingActionButton(
            onClick = onContinue,
            modifier = Modifier.align(Alignment.BottomEnd)
        ) {
            Icon(Icons.Default.AutoAwesome, "Продолжить")
        }
    }
    AnimatedVisibility(visible = hasSelection) {
        ContextualMenu(
            items = listOf("Переписать", "Изменить тон", "Сократить"),
            onSelect = { action ->
                val selected = textFieldState.text.substring(textFieldState.selection)
                onRewrite("$action: $selected")
            }
        )
    }
}

Промпты для разных действий AI подбираются под конкретный сценарий. Например, для продолжения текста используется инструкция дополнить текст в том же стиле. Для переписывания — указать стиль и язык. Для изменения тона — задать конкретный тон. Все промпты на английском и без лишних указаний. Примеры:

# Продолжение текста
Continue the following text naturally, maintaining the same style, language, and tone.
Write 1-3 sentences only. Do not repeat what was already written.
Text: {last_500_chars}

# Переписать выделенное
Rewrite the following text. Keep the core meaning but improve clarity and flow.
Language: {detected_language}. Style: {business|casual|formal}.
Text: {selected_text}

# Изменить тон
Rewrite this text in a {formal|casual|empathetic|assertive} tone.
Preserve all key information. Output only the rewritten text.
Text: {selected_text}

Как восстановить состояние после фонового режима?

Если пользователь свернул приложение в процессе генерации, iOS отправит задачу в URLSession с background конфигурацией или просто отменит запрос. Нужно сохранить промпт и статус в UserDefaults/SharedPreferences и восстановить при возврате. При долгих генерациях (> 15 секунд) переходим на Background Tasks API на iOS или WorkManager на Android — стриминг в фоне невозможен, но можно получить итоговый результат через push notification.

Мы гарантируем, что ваш ассистент не потеряет ни одного символа — все состояния сохраняются по чекпоинтам.

Процесс работы

  1. Анализ требований — определяем список действий ассистента, языки, тона. (1-2 дня)
  2. Проектирование архитектуры — выбираем стек (iOS: SwiftUI + Combine, Android: Jetpack Compose + Coroutines), проектируем промпты. (2-3 дня)
  3. Реализация — интеграция стриминга, контекстного меню, сохранения состояния. (5-15 дней)
  4. Тестирование — проверка всех кейсов: сброс курсора, фоновый режим, быстрый стриминг. (2-3 дня)
  5. Деплой — загрузка в App Store и Google Play с соблюдением App Store Review Guidelines. (1-2 дня)

Что входит в работу

  • Исходный код модуля Writing Assistant для iOS и Android.
  • Документация по промптам и настройке AI-модели.
  • Инструкция по деплою в App Store и Google Play.
  • Техническая поддержка в течение месяца после запуска.

Сроки: базовый ассистент с кнопкой «улучшить» — 3–5 дней. Полноценный редактор со стримингом, контекстным меню, режимами и сохранением состояния — 3–4 недели. Поддержка офлайн-режима с on-device моделью (через CoreML/TFLite) — отдельно от 2 недель.

Получите консультацию по вашему проекту — мы оценим сложность и предложим оптимальное решение. Свяжитесь с нами, чтобы обсудить детали интеграции.

AI и ML в мобильных приложениях: CoreML, TFLite и on-device модели

Мы различаем два принципиально разных подхода: приложение с on-device AI и приложение, которое просто вызывает облачное API. Первое работает без интернета, не отправляет данные пользователя на сторонние серверы и отвечает за 50 миллисекунд. Второе зависит от задержки сети и тарифного плана. Выбор архитектуры — ключевой этап, который напрямую влияет на стоимость, приватность и пользовательский опыт. Наш опыт показывает: в 70% проектов on-device инференс оказывается дешевле в долгосрочной перспективе за счёт исключения серверных затрат.

Как выбрать между CoreML и TFLite для on-device инференса?

CoreML — нативный фреймворк Apple для запуска ML-моделей на устройстве. Поддерживает Neural Engine (начиная с A11 Bionic), GPU и CPU как fallback. Модели конвертируются в формат .mlmodel через coremltools из PyTorch, ONNX или TensorFlow. Конвертация — не всегда тривиальна: кастомные слои требуют реализации MLCustomLayer, а квантизация до INT8 иногда заметно роняет точность на специфических данных. Мы гарантируем, что итоговая модель проходит валидацию на реальных данных до и после конвертации.

TensorFlow Lite — кросс-платформенная альтернатива для Android и Flutter. На Android использует NNAPI (Neural Networks API) для хардварного ускорения — с Android 10 NNAPI стабильнее, до этого лучше явно использовать GPU delegate через GpuDelegate. Типичная ошибка: модель обучена на нормализованных данных в диапазоне [0,1], а в приложении на вход подаётся [0,255] — инференс работает, но с бессмысленными результатами без ошибки. Мы включаем модуль автоматической валидации входных данных в SDK.

Для задач классификации изображений, детекции объектов и сегментации доступны готовые оптимизированные модели. YOLOv8 в CoreML формате запускает детекцию кадра 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite с GPU delegate — около 8 мс на Pixel 7 при классификации.

Параметр CoreML TFLite
Платформы iOS, macOS, watchOS Android, iOS, Linux, embedded
Хардварное ускорение Neural Engine, GPU, CPU NNAPI, GPU (OpenCL/OpenGL), CPU
Поддержка квантизации FP16, INT8 (с coremltools) FP16, INT8, dynamic range
Кастомные операции Через MLCustomLayer (Swift) Через делегаты (Java/Kotlin)
Размер бандла модели ~3–5 МБ (MobileNetV2 quantized) ~2–4 МБ

Что делать, если нужна генерация текста на устройстве?

Запуск небольших языковых моделей на устройстве стал реальностью в последние несколько лет. Apple Intelligence использует собственные модели через Private Cloud Compute, но для сторонних разработчиков доступны другие пути.

llama.cpp с Metal backend на iOS — работающий подход для phi-3-mini (3.8B параметров, 4-bit квантизация, ~2.3 ГБ). Инференс: 15–25 токенов/секунду на iPhone 15 Pro. Для интеграции в Swift используем Swift Package llama.swift или обёртку через C-интерфейс llama.h. Бинарник к приложению не прикладываем — модель скачивается при первом запуске и хранится в Application Support. Наши сертифицированные разработчики настраивают инкрементальную загрузку, чтобы не блокировать первый запуск.

На Android аналог — Google AI Edge (бывший MediaPipe LLM Inference API) с поддержкой Gemma-2B. Работает через GPU delegate, на Tensor G3 чипе Pixel 8 Pro — около 20 токенов/секунду.

Ограничения реальны: модели больше 4B параметров на мобильных устройствах по-прежнему медленны. Для сложных задач рассуждения on-device LLM уступает GPT-4o в качестве. Гибридный подход — on-device для коротких задач и приватных данных, облако для сложных запросов — часто оптимален. Оценим ваш кейс и предложим баланс производительности и приватности — пишите.

Интеграция OpenAI API и других облачных моделей

Для сценариев, где cloud inference допустим, интеграция OpenAI, Anthropic или Google Gemini — это HTTP клиент + streaming SSE. В Swift удобно через AsyncThrowingStream для стриминговых ответов. В Kotlin — через Flow.

Критически важно: API-ключи никогда не хранятся в бандле приложения. Даже обфусцированный ключ извлекается из IPA за 10 минут через strings или frida. Правильная архитектура: мобильное приложение → собственный backend → OpenAI API. Backend контролирует rate limiting, логирует запросы, защищает ключ.

Что входит в работу (deliverables)

  • Обученная и квантизированная модель под целевое устройство (документация по метрикам)
  • SDK для интеграции (Swift/Kotlin/Flutter) с примерами вызова
  • Тесты производительности на 3–5 реальных устройствах
  • Инструкция по обновлению модели OTA
  • Поддержка при прохождении модерации App Store / Google Play (проверка соответствия Guidelines 4.2, 5.1)
  • 2 недели технической поддержки после релиза

Типичный пайплайн проекта

  1. Анализ задачи — замеряем latency, privacy, size, поддерживаемые устройства.
  2. Прототипирование модели — в Python, оценка accuracy на целевых данных.
  3. Конвертация и квантизация — под CoreML/TFLite с валидацией.
  4. Интеграция в приложение — модель оборачивается в сервисный слой (легко подменять CoreML → TFLite → облако).
  5. Тестирование — на реальных девайсах, замер FPS, RAM, батареи.
  6. Деплой — через TestFlight / Firebase App Distribution, мониторинг метрик.

Сроки: интеграция готовой CoreML/TFLite модели — 1–2 недели, разработка кастомной модели с мобильной оптимизацией — от 6 недель, on-device LLM чат с персонализацией — 4–8 недель.

Почему мы беремся за сложные кейсы?

10+ лет опыта в мобильной разработке, 50+ внедрённых AI/ML решений, гарантия совместимости с актуальными версиями iOS и Android. Все проекты проходят code review и нагрузочное тестирование. В стоимость уже входит подготовка документации для модерации и обучение вашей команды.

Свяжитесь с нами — мы поможем выбрать архитектуру и внедрить ML в ваше приложение под ключ. Закажите аудит существующего решения — бесплатно оценим потенциал экономии серверных затрат (в некоторых проектах экономия достигает $10k в месяц).