Heat — это нативный клиент с открытым исходным кодом для iOS и macOS, позволяющий взаимодействовать с самыми популярными LLM-сервисами.

Фичи:

Поддержка популярных LLM-провайдеров (OpenAI, Mistral, Anthropic, Gemini)
Поддержка локальных LLM с открытым исходным кодом с помощью Ollama
Поддержка генерирования изображений (Stable Diffusion и Dall-e)
Поиск и просмотр веб-страниц для повышения точности ответов
Чтение и понимание календаря
Поиск в файловой системе (только для десктопа)
Базовое сохранение данных в памяти
Никаких зависимостей от сервера, кроме доступа к моделям

https://github.com/nathanborror/Heat

#ios

👉 @developer_mobila

Offline-First - это не просто кэширование GET-запросов

Многие путают Offline-Capable (показали кэш, если нет сети) и Offline-First (приложение полностью функционально без сети, сеть - лишь способ синхронизации).

На собеседованиях часто слышу: "Ну, сохраним в Room/Realm, а когда появится сеть - отправим на бэкенд". Звучит просто, пока не натыкаешься на Concurrancy & Conflict Resolution.

Допустим, у нас таск-трекер. Юзер А (в метро) меняет статус задачи на "Done". Юзер Б (в лифте) меняет описание этой же задачи. Оба выходят в онлайн. Что попадет в базу?

Если вы используете стратегию Last Write Wins (LWW), кто-то потеряет данные.

О чем стоит думать при проектировании синхронизации:

1. Optimistic UI: Мы обязаны показать изменение мгновенно. Но как откатить стейт, если сервер вернул 409 Conflict или бизнес-валидацию? Нужен надежный механизм транзакций на клиенте.

2. Queue Management: Очередь запросов должна быть персистентной. Но что, если первый запрос упал? Блокировать всю очередь? Или пропустить и нарушить причинно-следственную связь (causality)?

3. CRDTs (Conflict-free Replicated Data Types): Это "Святой Грааль" распределенных систем.
- Вместо хранения значения, мы храним операции.
- Математика CRDT гарантирует, что независимо от порядка применения операций, итоговое состояние у всех клиентов будет одинаковым (Eventual Consistency).


Практические выводы:

- Не пишите свои велосипеды для синка, если проект сложнее "To-Do листа". Это распределенная система в миниатюре.
- Смотрите в сторону решений, поддерживающих CRDT или дифференциальную синхронизацию "из коробки" (например, PowerSync, Replicache, или старый добрый Couchbase, если позволяет легаси).
- Если пишете сами - всегда версионируйте сущности (Vector Clocks) и проектируйте API так, чтобы сервер мог принимать патчи, а не целиковые объекты.

Offline-First - это не про базу данных на клиенте. Это про умение разруливать энтропию, когда Source of Truth временно недоступен.

#mobile #architecture #systemdesign #offlinefirst

👉 @developer_mobila

Конец года, и снова заканчиваются все подписки 😱

Узнали? Согласны? Не беда — мы как раз разыгрываем промокоды на год от Облака Mail и VK Музыки!

Условия участия простые:
🔹 подпишитесь на наш канал @mobilehubvk
🔹нажмите кнопку «Участвовать»
🔹 дождитесь 30 декабря — в этом посте мы выберем случайным образом 6 победителей

Информацию об организаторе, правилах и призах ищите по ссылке.

Удачи!

👨‍💻 Как писать чистый код на SwiftUI: вспоминаем паттерны

Легко написать работающий экран на SwiftUI. Сложно написать поддерживаемое приложение. Часто проблема кроется в непонимании того, какие паттерны уже "зашиты" в фреймворк.

В этой статье автор разбирает 5 основных паттернов, которые вы, скорее всего, уже используете, но не называете их своими именами:

🔹 Observer - основа реактивности SwiftUI.
🔹 Builder - магия, которая позволяет писать декларативный UI.
🔹 Adapter - мост в мир UIKit.
🔹 Decorator - суть всех модификаторов.
🔹 Strategy - способ гибкой настройки логики.

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

https://medium.com/ios-nest/design-patterns-in-swiftui-9091a4fa722e

#iOS #Engineering #SwiftUI

👉 @developer_mobila

💼 Вопрос с собеседования: «Как вы боретесь с утечками памяти?»

Этот вопрос гарантированно зададут на собеседовании и Android, и iOS разработчику. Лид хочет услышать не сухую теорию, а ваши инструменты.

Вот как отличается уровень ответов:

❌ Ответ Джуна:
«Утечка - это когда память не освобождается, забивается, и приложение падает с ошибкой Out Of Memory. Я стараюсь писать чистый код и надеюсь на Garbage Collector (или ARC в iOS)».
👉 Вердикт: Слишком абстрактно. Не понятно, умеет ли кандидат реально находить и чинить проблемы в коде.

✅ Ответ Мидла:
«Утечки чаще всего возникают, когда объекты удерживаются дольше, чем нужно.
Классика жанра:
🤖 Android: Ссылка на Activity или Context внутри статического поля или долгоживущего фонового потока.
🍎 iOS: Retain Cycle (циклические ссылки), когда два объекта сильно ссылаются друг на друга (часто бывает в кложурах).

Как я их ищу:

1. Инструменты: Не гадаю на кофейной гуще, а запускаю Android Profiler (или библиотеку LeakCanary) / Xcode Instruments (Leaks & Memory Graph).
2. Лечение: Использую WeakReference или [weak self], чтобы разорвать сильную связь».

👉 Вердикт: Четкое понимание причины + знание профайлеров + конкретное решение.

💡 Совет: Перед следующим собеседованием запустите свой пет-проект с профайлером. Даже если там нет утечек, вы сможете сказать: «Я проверял свой проект через Instruments/Profiler, потребление памяти стабильное». Это огромный плюс в карму.

Сталкивались с OOM (Out Of Memory) в реальных проектах или пока проносило? 👇

#собеседование #карьера #ios #android #tips

👉 @developer_mobila

☠️ Баг, который вы не видите, а пользователи ненавидят

Представьте: пользователь заполнил длинную форму регистрации, свернул приложение, чтобы скопировать код из SMS, возвращается... а экран пустой. Данные исчезли. 🤬

Это System-initiated process death. Самая частая причина удаления приложения у пользователей и головная боль разработчиков.

Почему это происходит?
ОС (Android или iOS) всегда не хватает оперативной памяти. Когда ваше приложение уходит в фон, система может «тихо» убить его процесс, чтобы освободить ресурсы для активного окна (например, Камеры).

❌ Ошибка новичка:
«Я храню данные в ViewModel (Android) или в переменной контроллера (iOS), они же живут долго!»
Реальность: ViewModel переживает поворот экрана, но умирает вместе с процессом. Синглтоны тоже сбрасываются.

✅ Как делать правильно (Level Up):

🤖 Android:
Перестаньте полагаться только на поля класса. Используйте SavedStateHandle.
Это специальный механизм внутри ViewModel, который сохраняет небольшие кусочки данных (ID, поисковый запрос, ввод пользователя) в системный бандл. Система бережно восстановит его даже после смерти процесса.
Гуглить: SavedStateHandle, Parcelable.

🍏 iOS (SwiftUI/UIKit):
В SwiftUI для простых данных (например, выбранная вкладка или текст) используйте обертку @SceneStorage. Она автоматически сохраняет и восстанавливает состояние.
Для сложных данных — сохраняйте их в локальную БД (CoreData/Realm/SwiftData) при каждом изменении, а не при закрытии экрана.

🛠 Как проверить себя (Челлендж на 5 минут):
Не верьте эмулятору. Проверьте свой текущий проект прямо сейчас:

1. Запустите приложение и введите данные в любое поле.
2. Сверните приложение (Home).
3. Android: В настройках разработчика включите опцию «Don't keep activities» (Не сохранять действия).
4. iOS: В Xcode нажмите Debug -> Simulate Memory Warning или остановите дебаг и запустите другое тяжелое приложение.
5. Вернитесь в свое приложение.

Если данные исчезли или случился краш, поздравляю, вы нашли критический баг. Время фиксить!

Знали про SavedStateHandle или по старинке сохраняли всё в базу данных? 👇

#android #ios #bugs #middle #architecture #обучение

👉 @developer_mobila

🛑 Хватит спамить принтами! Дебажим как профи

Признавайтесь, делали так?
У вас есть цикл на 100 элементов, и ошибка вылетает только на 87-м. Вы ставите обычный брейкпоинт и 86 раз яростно жмете «Resume Program» (▶️), проклиная всё на свете, пока не дойдете до нужного состояния.

Или еще хуже:
Log.d("TAG", "Я тут")
Log.d("TAG", "А теперь тут, значение i = $i")

Есть способ элегантнее, который отличает опытного разработчика от новичка - Conditional Breakpoints (Условные точки останова).

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

Как это сделать за 5 секунд:

🤖 Android Studio (IntelliJ IDEA):

1. Поставьте обычный красный брейкпоинт.
2. Нажмите на него правой кнопкой мыши.
3. В поле "Condition" напишите условие на языке Kotlin/Java.
Пример: item.id == 87 или user.name.contains("Test") && i > 50
4. Готово! Студия проигнорирует первые 86 итераций и остановится точно там, где нужно.

🍎 Xcode:

1. Поставьте синий брейкпоинт.
2. Нажмите на него правой кнопкой (или двойной клик) -> "Edit Breakpoint".
3. В поле "Condition" пишите условие на Swift.
Пример: indexPath.row == 87

💡 Бонус-фича для тех, кто не любит останавливаться:
В настройках брейкпоинта уберите галочку Suspend (Остановить) и поставьте галочку Log Message (Evaluate and log).
Теперь IDE будет сама писать в консоль значения переменных при прохождении этой точки, не останавливая приложение. Это те же принты, только вам не нужно пачкать ими код и пересобирать проект!

Какая ваша любимая фишка дебаггера, о которой мало кто знает? Делитесь в комментариях 👇

#productivity #androidstudio #xcode #debug #tips #middle

👉 @developer_mobila

🔐 Вы только что подарили хакерам доступ. Где НЕЛЬЗЯ хранить ключи

Классическая история: вы пишете пет-проект, используете API (например, ChatGPT или Firebase), и пишете прямо в коде:
val apiKey = "sk-proj-12345..."

Потом git push, и вы идете спать.
А утром ваш ключ заблокирован, или с карты списали деньги за чужой трафик.

🤖 Реальность: Боты сканируют публичные репозитории GitHub на наличие строк, похожих на ключи, за секунды после публикации. Удалить коммит не поможет, он уже в кеше у злоумышленников.

Как делать правильно (Middle Way):

Секреты никогда не должны попадать в систему контроля версий (Git). Они должны жить только локально на вашем компьютере.

🤖 Android:
Используйте файл local.properties. Он по умолчанию добавлен в .gitignore.

1. Откройте local.properties и добавьте: MY_API_KEY="ваш_ключ".

2. В build.gradle (app) считайте его и прокиньте в код:

defaultConfig {
    buildConfigField("String", "API_KEY", gradleLocalProperties(rootDir).getProperty("MY_API_KEY"))
}

3. В коде используйте: BuildConfig.API_KEY.

🍏 iOS:
Вариантов много, но самый простой для старта:

1. Создайте файл Secrets.xcconfig (или .plist).
2. Сразу же добавьте его в .gitignore.
3. Запишите ключ туда.
4. В настройках проекта (Build Settings) подключите этот конфиг или считывайте файл программно.

🛡 Золотое правило:
Если вы клонируете свой проект на чистый ноутбук, он не должен собраться сразу. Он должен попросить вас создать локальный файл с ключами. Это не баг, это безопасность.

Признавайтесь, случалось случайно комитить пароли или токены? 👇

#security #android #ios #git #tips #middle #safety

👉 @developer_mobila

💉 Dependency Injection: Зачем усложнять, если можно просто написать new?

Когда новичок видит код с кучей аннотаций @Inject или модулей, у него возникает вопрос: "Зачем всё это? Я же могу просто создать объект внутри класса!"

❌ Код Джуна (Hard dependency):

class UserRepository {
    // Мы "приварили" конкретную базу данных к репозиторию
    private val database = SQLiteDatabase() 

    fun getUser() { ... }
}

В чем проблема?
Представьте, что вы строите дом. Этот код как если бы вы вмуровали кофемашину прямо в стену кухни.

1. Хотите заменить кофемашину на новую? Придется ломать стену (переписывать код класса).
2. Хотите протестировать кухню, не варя кофе? Не получится, машина там намертво.

✅ Код Мидла (Dependency Injection):

class UserRepository(private val database: Database) { 
    // Мы просим дать нам ЛЮБУЮ базу данных через конструктор
}

В чем суть?
Вы говорите: "Мне для работы нужна база данных. Дайте мне её, я не хочу сам её создавать".
Это как розетка. Вы не вмуровываете технику в стену, вы просто втыкаете вилку. Сегодня это дешевый чайник (тестовая база), завтра мощная кофемашина (реальный сервер).

🛠 Инструменты (Что учить):

🤖 Android:

• Hilt (Dagger): Стандарт от Google. Мощный, проверяет ошибки при компиляции, но сложный в настройке.

• Koin: Service Locator (технически не совсем DI, но решает те же задачи). Простой, пишется на чистом Kotlin, но ошибки могут вылезти в рантайме. Идеально для старта.

🍏 iOS:

• Swinject: Классика DI контейнеров.

• Swift Native: В современных проектах часто используют просто Factory Pattern или передачу зависимостей через init, без сторонних библиотек. Это самый чистый путь.

💡 Совет:
На собеседовании на вопрос "Что такое DI?" не начинайте рассказывать про даггер.
Скажите просто: "Это принцип, когда объекты не создают свои зависимости сами, а получают их извне. Это нужно для тестируемости и гибкости кода". Это ответ уровня Senior.

А что используете вы в своих проектах? 👇

#architecture #di #hilt #koin #ios #android #middle #patterns

👉 @developer_mobila