Библиотека мобильного разработчика

ИИ в кармане: работа с контекстом через RAG

23 января в 19:00 обсудим архитектуры работы LLM с локальными данными на открытом уроке к курсу «Разработка ИИ агентов». Узнаем, как научить ассистента отвечать по документам пользователя без лишних затрат ресурсов.

Занятие ведёт Игорь Стурейко, тимлид в «Газпроме» и AI-архитектор на Kubernetes. В своём видеосообщении Игорь рассказывает о проектировании автономных агентов и практическом опыте в ML, накопленном за 20 лет.

На вебинаре разберём:

— использование RAG для контекстного поиска в приложениях;
— интеграцию векторных баз данных (FAISS, Chroma);
— фреймворки для связи интерфейса с логикой ИИ-агентов.

📅 Когда: 23.01 в 19:00 МСК

Узнать подробности

⚙️ SwiftDataTables — показ таблиц в iOS

SwiftDataTables позволяет отображать наборы данных в виде красиво отформатированных таблиц для iOS. Главная цель для конечного пользователя — как можно быстрее получить полезную информацию из таблицы с помощью таких функций, как упорядочивание, поиск и листание. Для разработчика — обеспечить простую реализацию с расширяемыми опциями.

Основные возможности включают:

🔘 Сортировка — Нажмите на заголовки столбцов для сортировки по любому столбцу
🔘 Поиск — Встроенная строка поиска фильтрует по всем полям
🔘 Фиксированные столбцы — Заморозьте столбцы с левой или правой сторон
🔘 Гибкий размер — Автоматически рассчитываемая или пользовательская ширина столбцов и высота строк
🔘 Настраиваемый — Настройте заголовки, нижние колонтитулы, цвета и многое другое через делегат или объект конфигурации
🔘 Шаблон источника данных — Статические данные или динамический контент по протоколу

💻 SwiftDataTables на GitHub

🐸 Библиотека мобильного разработчика

#буст #iOS

🐸 Библиотека мобильного разработчика

#BugOrFeature

🎮 Модульность в iOS

С ростом кодовой базы iOS-приложения перед командой встаёт ключевой вопрос: внедрять ли модульную архитектуру? Это мощный инструмент для управления сложностью, но не серебряная пуля для всех проектов.

🔹 Что такое модульность?

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

🔹 Когда она оправдана, а когда — нет?

🔘 Не нужно: для небольших проектов, прототипов или приложений с неясным будущим. На этом этапе модульность создаст лишние накладные расходы.

🔘 Нужно: когда бизнес-направление определено и проект обречён на рост. Модульность помогает установить границы ответственности и предотвратить превращение системы в монолит.

🔹 Три столпа модульной кодовой базы

1. Базовый слой (Foundation): фундамент приложения. Содержит общие модели данных, сетевой стек и техническую инфраструктуру. Должен быть максимально универсальным и не зависеть от модулей выше.

2. Сервисные модули (Services): общие возможности, используемые несколькими фичами (например, кэширование, аналитика). Они зависят только от Foundation.

3. Функциональные модули (Features): пользовательские сценарии с началом и концом (например, "оформление заказа", "лента новостей"). Они зависят от Foundation и Services, но не должны зависеть друг от друга.

🔹 Типичные ошибки

Многие команды внедряют модульность, следуя тренду, но не проектируют связи. Результат:

🔘 Паутина взаимозависимых модулей

🔘 "Божественные" сервисы, которые знают обо всём

🔘 Скрытые циклические зависимости

🔘 Иллюзия разделения через мосты на протоколах, которые только усложняют отладку

🔹 Ключевые принципы успеха

🔘 Чёткие контракты: Думайте о публичном API модуля, как будто вы публикуете библиотеку на GitHub.

🔘 Контроль навигации: Переходы между фичами должны управляться внешним координатором (например, координатором приложения), а не происходить напрямую.

🔘 Самостоятельная сборка: Функциональный модуль должен уметь собирать свой внутренний граф зависимостей самостоятельно, получая только необходимые данные и сервисы извне.

🔘 Протоколы с умом: Используйте протоколы для конкретных целей (изоляция зависимостей, тестирование), а не ради "гибкости".

🔹 Итог

Модульность — это осознанная практика, а не механический рефакторинг. Её успех зависит не столько от инструментов (Tuist, Swift Package Manager), сколько от архитектурного мышления и командной дисциплины. Правильно реализованная, она превращает код в долгосрочный актив, а не в обузу.

Согласны, что проектировать связи важнее, чем просто резать код на модули? Делитесь опытом в комментариях 💬

📌 Лучшие вакансии для мобильных разработчиков

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #MiddlePath #iOS

📱 Топ вакансий для мобильных разработчиков за неделю

KMP Developer — от 185 000 до 310 000 ₽, удалёнка

Middle+ / Senior iOS Developer — удалёнка

KMP - Kotlin Multiplatform (Android / iOS) разработчик — от 2 000 $, удалёнка

Flutter-разработчик — удалёнка

iOS разработчик — офис (Москва)

➡️ Еще больше топовых вакансий —‍ в нашем канале Mobile jobs

🐸 Библиотека мобильного разработчика

#свежак

✨ Отображаем Markdown в SwiftUI

Многим разработчикам нужно показывать в своих приложениях отформатированный текст: документацию, статьи, комментарии с разметкой. SwiftUI не имеет встроенной поддержки Markdown, но есть элегантное и мощное решение.

В статье рассматривается использование класса NSAttributedString из UIKit для преобразования Markdown в отформатированный текст и его отображения в SwiftUI через UIViewRepresentable.

🔹 Как это работает: ключевые компоненты

1. Преобразование Markdown в NSAttributedString

Основная "магия" происходит с помощью класса NSAttributedString. Для обработки Markdown можно использовать встроенный парсер iOS (начиная с iOS 15) или сторонние библиотеки, такие как Down или SwiftyMarkdown. Пример с NSAttributedString:

import UIKit
let markdownString = "**Hello**, *SwiftUI*!"
let options: [NSAttributedString.DocumentReadingOptionKey: Any] = [
    .documentType: NSAttributedString.DocumentType.html
]
// Преобразуем Markdown через HTML (один из подходов)
if let data = markdownString.data(using: .utf8),
   let attributedString = try? NSAttributedString(data: data,
                                                 options: options,
                                                 documentAttributes: nil) {
    // Используем полученный attributedString
}

2. Отображение в SwiftUI через UIViewRepresentable

Чтобы показать NSAttributedString в SwiftUI, создаём обёртку UIViewRepresentable для UITextView или UILabel:

import SwiftUI
struct MarkdownView: UIViewRepresentable {
    let attributedString: NSAttributedString
    
    func makeUIView(context: Context) -> UITextView {
        let textView = UITextView()
        textView.isEditable = false
        textView.attributedText = attributedString
        textView.backgroundColor = .clear
        return textView
    }
    
    func updateUIView(_ uiView: UITextView, context: Context) {
        uiView.attributedText = attributedString
    }
}

3. Использование в SwiftUI-интерфейсе

Теперь можно использовать MarkdownView как обычный SwiftUI элемент:

struct ContentView: View {
    let markdownText = "## Заголовок\nЭто **жирный** текст."
    var body: some View {
        MarkdownView(attributedString: parseMarkdown(markdownText))
            .padding()
    }
}

🔹 Альтернативные подходы

🔘 SwiftUI Text с ограниченной поддержкой Markdown (iOS 15+): В SwiftUI 3 появилась базовая поддержка Markdown внутри Text. Работает для простых случаев:

Text("**Жирный** и *курсив*")

🔘 Сторонние библиотеки: Down, SwiftyMarkdown или MarkdownUI предоставляют более полную и гибкую поддержку Markdown, часто с более простым API.

🔹 Важные нюансы

🔘 Производительность: Для очень больших Markdown-документов преобразование в NSAttributedString может потребовать оптимизации.

🔘 Кастомизация: Если нужен нестандартный вид Markdown (например, синтаксис из другой системы), потребуется дополнительная обработка.

🔘 Версия iOS: Некоторые методы (как встроенный парсер) требуют iOS 15+.

🔹 Итог

Отображение Markdown в SwiftUI — задача, которая решается с помощью связки NSAttributedString и UIViewRepresentable. Для более простых случаев можно использовать встроенную в SwiftUI 3 поддержку Markdown, а для максимальной гибкости и функциональности — сторонние библиотеки. Это открывает двери для создания приложений с богатым текстовым контентом прямо внутри ваших SwiftUI-интерфейсов.

📌 Лучшие вакансии для мобильных разработчиков

🐸 Библиотека мобильного разработчика

#PixelPerfect #MiddlePath #Swift

Build failed: price_increment

Чтобы не переплачивать завтра, оформите подписку на профессиональный рост сегодня. После 20 января стоимость всех программ в Proglib.academy пойдёт вверх.

Собрать свой идеальный грейд

❓ Объект-выражение (анонимный объект/object expression)

Объект-выражение — это выражение, которое "на ходу" создает анонимный объект.

Для объекта-выражения не указывается имя!
Если же объекту всё-таки требуется имя, то его можно сохранить в переменной:

val tom = object {
        val name = "Tom"
        var age = 37
        fun sayHello() {
            println("Hi, my name is $name")
        }
    }
    println("Name: ${tom.name}  Age: ${tom.age}")
    tom.sayHello()

Анонимные объекты не являются синглтонами!
Каждый раз при выполнении объекта-выражения создаётся новый объект.

Анонимный объект является заменой анонимным внутренним классам в Java.

📌 Лучшие вакансии для мобильных разработчиков

🐸 Библиотека мобильного разработчика

#буст #JuniorKit #Kotlin

🗓 Новости недели

Приготовили для вас дайджест по актуальному из мира iOS, Android.

🔵 Как укротить SwiftLint в масштабах компании

В этой статье автор делится опытом настройки SwiftLint сразу для нескольких репозиториев — так, чтобы кодстайл оставался единым и не расползался со временем.

🔵 Как подружить Android и ICMP: заметки разработчика

В статье автор поговорит о поддержке протокола ICMP в контексте разработки приложений под Android.

🔵 Navigation3 + Koin в Compose Multiplatform

Автор поделиться своими наработками по тому, как можно удобно совмещать библиотеку Navigation3 и Koin в Compose Multiplatform проекте и какие подводные камни есть на текущий момент.

🐸 Библиотека мобильного разработчика

#свежак