🔢 NavigationStack в SwiftUI: современная навигация.

NavigationStack — это новый (с iOS 16+) и более мощный способ организации навигации в SwiftUI. В отличие от NavigationView, он дает полный контроль над стеком экранов и поддерживает сложные сценарии.

✅ Основные возможности:
🔹 Программное управление стеком экранов (пуш, поп, переход к корню).
🔹 Глубокая навигация по ссылкам (например, app://products/123).
🔹 Кастомные переходы между экранами.
🔹 Поддержка NavigationPath для хетерогенных данных в стеке.

♣️ Пример использования:

struct ContentView: View {
  @State private var path = NavigationPath()

  var body: some View {
    NavigationStack(path: $path) {
      List {
        NavigationLink("Экран 1", value: 1)
        NavigationLink("Экран 2", value: "Текст")
      }  
      .navigationDestination(for: Int.self) { value in
        Text("Число: \(value)")
      }  
      .navigationDestination(for: String.self) { value in
        Text(value)
      }
    }
  }
}

1️⃣ NavigationPath.

Тип-обертка для управления стеком. Может содержать разные типы данных:

path.append(1)
path.append("ABC")
path.removeLast()

2️⃣ navigationDestination(for:).

Определяет, какой экран показывать для каждого типа данных:

.navigationDestination(for: Product.self) { product in  
  ProductView(product: product)  
}

3️⃣ Программная навигация.

Button("Перейти к экрану 3") {  
  path.append(3)  
}  

Button("Назад") {  
  path.removeLast()  
}  

Button("В корень") {  
  path.removeLast(path.count)  
}

⚠️ Глубокая навигация.

Можно привязать навигацию к URL:

NavigationStack(path: $path) {
}
.onOpenURL { url in
  if url.path == "/products/123" {
    path.append(Product(id: 123))
  }
}

💡 Рекомендации:
🔸 Для iOS 15 и ниже используйте NavigationView.
🔸 Для модальных окон — sheet или fullScreenCover.
🔸 Не смешивайте NavigationStack и NavigationView.

NavigationStack — это эволюция навигации в SwiftUI. Он идеален для приложений со сложной навигацией, программного управления историей экранов и лубоких ссылок.

➡️ Подписаться на канал
Мобильный трудоголик

🔨 Xcode 26: ИИ может документировать фрагмент кода!

Установите бета-версию macOS Tahoe и Xcode 26, если хотите попробовать эту функцию.

➡️ Подписаться на канал
Мобильный трудоголик

🔗 Поддержка Universal Links на iOS.

Universal Links — это удобный способ открывать контент вашего приложения прямо из веб-ссылок. Они обеспечивают более плавный пользовательский опыт и упрощают обмен контентом.


🤔 Что нужно для настройки?


1️⃣ Серверная часть:

🔹 На вашем сервере должен быть доступен файл apple-app-site-association в формате JSON.
🔹 В нём указываются appID вашего приложения и разрешённые пути (paths).

♣️ Пример файла apple-app-site-association:

{
  "applinks": {
    "details": [
      {
        "appID": "TEAMID.hardworker.it",
        "paths": [
          "/shop",
          "/card",
          "/profile"
        ]
      }
    ]
  }
}

Где appID указывается в формате teamId.bundleId. paths содержит пользовательские пути, которые должны обрабатываться в приложении.


2️⃣ Настройка проекта Xcode:

🔹 Добавьте Associated Domains в Capabilities.
🔹 Укажите ваш домен с префиксом applinks:, например:

applinks:your-domain.com

3️⃣ Тестирование:

🔹 Откройте ссылки на реальном устройстве (в Notes, Safari, через сообщения или Telegram).
🔹 Иногда требуется переустановка приложения или перезагрузка устройства, чтобы изменения вступили в силу.

Ожидается обработка следующих ссылок:

https://your-domain.com/shop
https://your-domain.com/card
https://your-domain.com/profile

💡 Вывод:

Universal Links делают навигацию удобнее, а ваш сервис — доступнее.

➡️ Подписаться на канал
Мобильный трудоголик

👨‍💻 Почему в 2025 году сопроводительное письмо, тестовые задания и проекты на GitHub важны для устройства на работу.

Недавно Дэвид Ханссон (создатель Ruby on Rails) в интервью Лексу Фридману раскрыл два ключевых критерия при найме:
🔹 Качество кода в тестовом задании.
🔹 Мотивационное письмо.

Казалось бы — ничего нового. Но давайте разберём, почему именно эти пункты стали критически важными в 2025 году.


1️⃣ Тестовое задание: как перестать быть «подозрительным» кандидатом.
С появлением ИИ ассистентов вроде GitHub Copilot и ChatGPT работодатели стали скептически относиться к идеально написанным, но безликим решениям.

⚠️ Что проверяют:
🔹 Стиль кода (если он похож на шаблонный код от ИИ — это красный флаг).
🔹 Неочевидные решения (вас обязательно спросят: «Почему выбрали именно это решение?»).
🔹 Коммиты (история изменений показывает ход ваших мыслей).


2️⃣ Сопроводительное письмо: ваш секретный инструмент.
В 2025 году резюме без сопроводительного письма — как код без комментариев: вроде бы всё понятно, но чего-то не хватает. HR-ы и тимлиды признаются: «Письмо решает, кого пригласить, когда 100+ кандидатов с одинаковым опытом».

🤔 Почему письмо важнее, чем кажется?
🔸 Показывает вашу человечность: ИИ пишет резюме, но не может искренне объяснить, почему вы мечтаете работать в этой компании.
🔸 Раскрывает soft skills: Удалённая работа требует чёткой письменной коммуникации.
🔸 Компенсирует недостатки резюме: Нет коммерческого опыта или пробелы в резюме? Расскажите о причинах и пет проектах.

⚠️ Структура сопроводительного письма:
🔹 Персонализация: общие письма для всех компаний не работаю, нужна привязка к конкретной компании, куда вы откликаетесь.
🔹 Почему вы? Привяжите свой опыт к конкретной боли компании, которую необходимо решить.
🔹 Почему они? Докажите что вы реально заинтересованы в работе в данной компании, знакомы с ее историей, пользуетесь их продуктами и знакомы с технологиям, которые в ней используются.

💡 Вывод:
Хорошее письмо — это ваш голос в тишине. В 2025 году его отсутствие равноценно фразе «Мне всё равно, куда устраиваться».


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Работа с JSON в Swift: Codable, Encodable и Decodable.

Swift предлагает удобные протоколы для преобразования объектов в JSON и обратно. Разберём, как это работает.


1️⃣ Основные протоколы.

🔹 Decodable: только декодирование (JSON → объект).
🔹 Encodable: только кодирование (объект → JSON).
🔹 Codable: и то, и другое (typealias для Decodable & Encodable).

struct User: Codable {
  var name: String
  var age: Int
}

2️⃣ Декодирование (JSON → объект).

Используем JSONDecoder:

let json = """
{
  "name": "Иван",
  "age": 30
}
"""

guard let jsonData = json.data(using: .utf8) else { return }

do {
  let user = try JSONDecoder().decode(User.self, from: jsonData)
  print(user.name) // "Иван"
} catch {
  print("Ошибка: \(error)")
}

⚠️ Особенности:

🔸 Имена свойств должны совпадать с ключами JSON (или использовать CodingKeys).
🔸 Типы данных должны соответствовать.


3️⃣ Кодирование (объект → JSON).

Используем JSONEncoder:

let user = User(name: "Мария", age: 25)

do {
  let jsonData = try JSONEncoder().encode(user)
  let jsonString = String(data: jsonData, encoding: .utf8)
  print(jsonString ?? "") 
  // {"name":"Мария","age":25}
} catch {
  print("Ошибка: \(error)")
}

⚠️ Настройки:

let encoder = JSONEncoder()
encoder.outputFormatting = .prettyPrinted // Красивый вывод
encoder.dateEncodingStrategy = .iso8601   // Формат даты

4️⃣ Кастомные ключи (CodingKeys).

Если имена в JSON не совпадают со свойствами:

struct Product: Codable {
  var productName: String
  var price: Double

  enum CodingKeys: String, CodingKey {
    case productName = "product_name_title"
    case price
  }
}

5️⃣ Вложенные структуры.

JSON:

{
  "user": {
    "name": "Анна",
    "age": 28
  }
}

Swift:

struct Response: Codable {
  var user: User
}

struct User: Codable {
    var name: String
    var age: Int
}

7️⃣ Обработка опциональных значений.

struct Profile: Codable {
  var name: String
  var bio: String?  // Опциональное поле
}

Если поля нет в JSON, свойство получит значение nil.


8️⃣ Игнорирование полей.

Пропускаем ненужные свойства:

struct Settings: Codable {
  var theme: String
  var fontSize: Int

  // Не включаем в Codable
  var temporaryFlag: Bool = false
}

9️⃣ Ручная реализация.

Для сложных случаев можно реализовать методы вручную:

struct Custom: Codable {
  var id: UUID
  var tags: [String]

  init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)
    id = try container.decode(UUID.self, forKey: .id)
    tags = try container.decode([String].self, forKey: .tags)
  }

  func encode(to encoder: Encoder) throws {
    var container = encoder.container(keyedBy: CodingKeys.self)
    try container.encode(id, forKey: .id)
    try container.encode(tags, forKey: .tags)
  }
}

💡 Вывод:

🔸 Используйте Codable для большинства задач.
🔸 Настраивайте сложные случаи через CodingKeys.
🔸 Для нестандартных форматов реализуйте методы вручную.

Теперь вы легко сможете работать с любым JSON в Swift!

➡️ Подписаться на канал
Мобильный трудоголик

🔨 Apple представила Retention Messaging API позволяющий удержать подписчиков.

Компания Apple анонсировала новый Retention Messaging API, который поможет разработчикам снизить отток подписчиков. Теперь можно гибко настраивать сообщения для пользователей, которые хотят отменить подписку.


⚠️ Что это дает?

С помощью данного API можно показывать 4 типа сообщений:

🔹 Текстовое: напоминание о преимуществах подписки.
🔹 Текст + изображение: визуальное убеждение.
🔹 Смена тарифа: предложение перейти на другой тарифный план.
🔹 Промо-оффер: скидка или спецусловия.

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


🤔 Как это работает?

🔸 Пользователь нажимает «Отменить подписку».
🔸 Система запрашивает у вашего сервера подходящее сообщение (или использует стандартное).
🔸 Пользователь видит предложение: оставить подписку, перейти на другой тариф или воспользоваться скидкой.


👨‍💻 Как подключить?

🔹 Загрузите тексты и изображения в App Store Connect.
🔹 Настройте дефолтные сообщения (текст, либо текст + картинка).
🔹 Реализуйте серверный endpoint для динамического выбора сообщений.


🔗 Официальная документация на сайте Apple


💡 Вывод:

Retention Messaging API — это не просто новая фича, а стратегический инструмент для монетизации. Вместо пассивного наблюдения за оттоком подписчиков вы получаете:

🔸 Контроль над последним touchpoint перед отменой.
🔸 Данные для анализа поведения пользователей.
🔸 Рычаг влияния на ключевое бизнес-метрики.

Теперь ваша реакция на отток — не постфактум, а в момент принятия пользователем решения.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 XCTest уходит в прошлое? Разбираем плюсы и минусы Swift Testing.

С выходом Swift Testing многие задумались о миграции с XCTest. Но так ли всё гладко, как обещает Apple? Давайте разберём реальные подводные камни и лайфхаки для перехода.


🤔 Чем Swift Testing отличается от XCTest?

1️⃣ Обнаружение тестов.
🔹 XCTest: использует XCTestCase + Objective-C runtime.
🔹 Swift Testing: макросы @Test + Swift ориентированный подход.

2️⃣ Выполнение тестов.
🔹 XCTest: выполняется последовательно (один за другим).
🔹 Swift Testing: выполняется параллельно (каждый тест в отдельной Task).

3️⃣ Синтаксис.
Разница в коде:

// XCTest  
func testLogin() { XCTAssertEqual(result, expected) }  

// Swift Testing  
@Test func login() { #expect(result == expected) }  

⚠️ Главные проблемы миграции.

1️⃣ Ассерты вне контекста Task.
Swift Testing требует, чтобы проверки (#expect) выполнялись только внутри Task.

// Старая схема (XCTest)
func testAsync() {
  DispatchQueue.main.async {
    XCTAssertEqual(result, 42)
  }
}

// Неправильная миграция (упадёт в Swift Testing)
@Test func asyncTest() {
  DispatchQueue.main.async {
    #expect(result == 42) // Ошибка: вне контекста Task
  }
}

// Правильная миграция
@Test func asyncTest() async { // 1. Объявляем async тест
  let result = await withCheckedContinuation { continuation in
    DispatchQueue.main.async {
      continuation.resume(returning: 42) // 2. Возвращаем результат в контекст Task
    }
  }

  #expect(result == 42) // 3. Проверяем УЖЕ внутри Task-контекста
}

Ключевые моменты:
🔸 Тест должен быть async — это автоматически создаёт контекст Task.
🔸 Все асинхронные операции, которые не поддерживают async/await оборачиваются в withCheckedContinuation.
🔸 #expect вызывается после получения результата, но внутри области теста.

2️⃣ Проблемы с общим состоянием.
Параллельное выполнение тестов могут вызвать гонки данных.

♣️ Пример:

actor Counter {
  var count = 0

  func increment() {
    count += 1
  }
}  

@Test func testA() async {
  await Counter.shared.increment()
  #expect(await Counter.shared.count == 1) // Может упасть, если testB запустится раньше!  
}  

@Test func testB() async {
  await Counter.shared.increment()
}

✅ Решение:
Использование @Suite(.serialized) для последовательного выполнения:

@Suite(.serialized)
struct CriticalTests {
  @Test func testA() {
  }

  @Test func testB() {
  }
}

3️⃣ Наследование тестов не работает.
В XCTest можно было наследовать XCTestCase и автоматически получать все тесты родителя. В Swift Testing так не работает — тесты нужно дублировать.

Что делать:
🔸 Для простых сценариев использовать параметризованные тесты.
🔸 Для сложных, пока оставьте XCTest и мигрируйте постепенно.


💡 Вывод:
На Swift Testing стоит переходить если у вас современный проект, который использует Swift Concurrency и вам необходимо параллельное выполнение тестов.

Мой совет: Начинайте с гибридного подхода — подключайте Swift Testing для новых модулей, а старые тесты оставляйте в XCTest.


➡️ Подписаться на канал
Мобильный трудоголик

👨‍💻 Пять фатальных ошибок в карьере разработчика.

Друзья, привет! Давайте поговорим о том, как мы сами иногда мешаем своей карьере в разработке. Я замечал это и на себе, и на других — есть пять типичных ошибок, которые тормозят рост.


1️⃣ Думать вместо делать.
«Сначала изучу весь SwiftUI, потом начну писать код» — знакомо?

Вспоминаю, как сам начинал: вместо того чтобы бесконечно изучать теорию, я просто пробовал писать код. Да, он был кривой, да, с ошибками, но это работало! Сейчас многие застревают на этапе «сначала выучу всё идеально, потом начну». Так не бывает. Лучший способ научиться: делать, ошибаться и исправлять.


2️⃣ Слушать не тех людей.
«Мой друг-джун сказал, что VIPER — это мусор».

Когда я только начинал, один «опытный» знакомый уверял меня, что Swift — это модно только для мажоров, а за Java будущее и он будет использоваться везде вечно. Хорошо, что я не поверил. Часто советы дают те, кто сам ещё мало что понимает. Ищите советов среди тех, кто реально добился результатов в вашей сфере.


3️⃣ Бояться критики.
«Мой код идеален, это тимлид ничего не понимает!»

Да, неприятно, когда говорят, что твой код плох. Но именно так и растёшь! Я научился воспринимать замечания не как личное оскорбление, а как бесплатный урок. Заводил даже отдельный блокнот, куда записывал все конструктивные замечания — очень помогает не наступать на те же грабли.


4️⃣ Лениться и откладывать на потом.
«Сегодня устал, завтра начну».

Сколько раз вы откладывали изучение новой технологии, потому что «еще есть время»? Или обещали себе дописать пет проект, но в итоге смотрели сериалы? Я сам через это проходил. Правда в том, что идеального момента не будет никогда. Каждый отложенный месяц — это упущенные возможности, проекты и даже зарплата. Технологии меняются быстрее, чем мы собираемся их изучить.


5️⃣ Бояться перемен.
«Лучше синица в руках, чем журавль в небе. Останусь там, где хоть что-то платят».

🔹 Страх сменить проект: «а если новый окажется хуже».
🔹 Боязнь попросить повышение: «а вдруг откажут».
🔹 Страх откликнуться на интересную вакансию: «там же нужно будет учить новое!».

Я сам больше года не решался сменить работу, потому что был страх неопределенности, хотя все вокруг на рынке зарабатывали больше меня и работали над современными, интересными проектами.

Эти страхи кажутся разумными только в нашей голове. Со стороны они выглядят именно тем, чем и являются — отговорками, которые мешают нам расти.

В IT безопаснее прыгнуть в неизвестность, чем оставаться в зоне комфорта. Каждый раз, когда вы говорите «еще не готов», кто-то другой говорит «да» и получает ваши потенциальные бенефиты.


💡 Вывод:
Главное, что я понял: карьера строится не на гениальных озарениях, а на постоянных итерациях: попробовал, получил фидбек, исправил, повторил. Чем чаще этот цикл, тем быстрее рост.


➡️ Подписаться на канал
Мобильный трудоголик

🎨 Вышли официальные наборы компонентов дизайна iOS 26 и iPadOS 26.

Все обновленные компоненты и гайды доступны на сайте Apple.


🤔 Что внутри?

🔹 UI Kit (Figma, Sketch).
🔹 App Icon Template (Sketch, Photoshop, Illustrator, Figma).


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Современные механизмы блокировок в Swift: Mutex и Synchronization Framework.

В Swift существует несколько способов защиты данных от гонки (data races): NSLock, DispatchSemaphore, последовательные очереди (DispatchQueue). Но на WWDC24 компания Apple представила новый Synchronization Framework, включающий современный Mutex – стандартизированную блокировку взаимного исключения.


🤔 В чем разница между Lock и Mutex?
🔸 Lock: общее название механизмов синхронизации (например, NSLock, os_unfair_lock).
🔸 Mutex: частный случай блокировки, гарантирующий, что только один поток может владеть ресурсом в данный момент.


✅ Ключевая особенность Mutex:
🔹 Строгое владение – разблокировать может только тот поток, который заблокировал.
🔹 Поддержка Sendable, что делает его удобным для Swift Concurrency.


♣️ Пример использования.
Пример защиты счетчика:

final class Counter {
  private let count = Mutex<Int>(0) // Обернули значение в Mutex

  var currentCount: Int {
    count.withLock { $0 } // Безопасное чтение
  }

  func increment() {
    count.withLock { $0 += 1 } // Атомарная операция
  }

  func decrement() throws {
    try count.withLock {
      guard $0 > 0 else { throw Error.reachedZero }
      $0 -= 1
    }
  }
}

🆚 Mutex vs Actor.
🔸 Actor: идеален для асинхронного доступа, но требует await.
🔸 Mutex: синхронный, подходит для legacy кода или когда нельзя использовать async/await.


⚠️ Когда выбирать Mutex?
🔸 Нужна мгновенная синхронная блокировка.
🔸 Работа с не Sendable типами (например NSBezierPath).
🔸 Интеграция с кодом, не поддерживающим Concurrency.


💡 Важно:
🔹 Доступен с iOS 18 и macOS 15.
🔹 Не заменяет Actor, а дополняет инструментарий для работы с многопоточностью.

Mutex из Synchronization Framework – это современный, безопасный и эффективный способ защиты данных в Swift.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Принципы SOLID в Swift: полный гид с примерами.

Сегодня мы разберём 5 принципов SOLID, которые спасут ваш код от хаоса.

🤔 Что такое SOLID?

Это 5 принципов объектно-ориентированного дизайна, которые делают код:
🔸 Гибким к изменениям.
🔸 Понятным для других разработчиков.
🔸 Более тестируемым.

Акроним расшифровывается так:

1️⃣ S — Single Responsibility.

Один класс — одна зона ответственности. Пример:

// Неправильно. Класс делает все: логика, UI, сетевые запросы.
class ProfileViewController: UIViewController {
  func loadUserData() {
    URLSession.shared.dataTask(...) { [weak self] data in
      let user = decode(data)
      self?.nameLabel.text = user.name
      self?.avatarImageView.image = UIImage(data: user.avatarData)
    }.resume()
  }
}

// Правильно. Разделяем ответственность.
class UserLoader {
  func fetchUser() async throws -> User {
    // Запросы к бд или серверу и логика обработки данных
  }
}

class ProfileViewController: UIViewController {
  private let loader = UserLoader()

  func updateUI() async {
    let user = try? await loader.fetchUser()
    if let user {
      nameLabel.text = user.name
      avatarImageView.image = UIImage(data: user.avatarData)
    }
  }
}

2️⃣ O — Open-Closed.

Класс открыт для расширения, но закрыт для изменений. Пример:

// Неправильно. При добавлении нового типа ячейки придётся менять метод.
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
  let item = data[indexPath.row]
  if item is Photo {
    return PhotoCell()
  } else if item is Video {
    return VideoCell() // Добавили новое условие
  }
}

// Правильно. Один из вариантов правильного решения - решение через протокол. Новый тип ячейки = новая сущность, а не правки в коде.
protocol CellConfigurable {
  static var reuseID: String { get }
  func configure(with item: Any)
}

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
  let item = data[indexPath.row]
  let cell = tableView.dequeueReusableCell(withIdentifier: type(of: item).reuseID)
  (cell as? CellConfigurable)?.configure(with: item)
  return cell
}

3️⃣ L — Liskov Substitution.

Подклассы должны заменять родительские классы. Пример:

// Неправильно
class Bird {
  func fly() {
    print("Лететь!")
  }
}

class Penguin: Bird {
  override func fly() {
    fatalError("Пингвины не летают!") // Ошибка
  }
}

// Правильно
protocol Bird {
  func move()
}

class Sparrow: Bird {
  func move() {
    print("Лететь!")
  }
}

class Penguin: Bird {
  func move() {
    print("Плыть!")
  }
}

4️⃣ I — Interface Segregation.

Клиенты не должны зависеть от интерфейсов, которые они не используют. Пример:

// Неправильно
protocol TableViewDelegate {
  func didSelectRow(at indexPath: IndexPath)
  func heightForRow(at indexPath: IndexPath) -> CGFloat
  func willDisplayCell()
// ... 20+ методов
}

// Правильно: разделяем на мелкие протоколы, которые можно реализовывать при необходимости.
protocol TableViewSelectable {
  func didSelectRow(at indexPath: IndexPath)
}

protocol TableViewSizable {
  func heightForRow(at indexPath: IndexPath) -> CGFloat
}

5️⃣ D — Dependency Inversion.

Зависите от абстракций, а не от конкретных типов. Пример:

// Неправильно. Прямая зависимость от Firebase.
class AnalyticsService {
  private let firebase = FirebaseAnalytics()

  func track(event: String) {
    firebase.log(event)
  }
}

// Правильно. Гибкое решение.
protocol AnalyticsEngine {
  func log(event: String)
}

class AnalyticsService {
  private let engine: AnalyticsEngine // Зависим от протокола
    
  init(engine: AnalyticsEngine) {
    self.engine = engine
  }

  func track(event: String) {
    engine.log(event)
  }
}

💡 Вывод:
SOLID не просто теория, а практический инструмент для создания профессионального кода. Он требует больше времени на старте, но окупается с лихвой, так как упростит масштабируемость и тестирование проекта, позволит любому разработчику быстрее вникнуть в ваш код. Это как строить дом с фундаментом вместо хижины на песке.


➡️ Подписаться на канал
Мобильный трудоголик

👨‍💻 Тестировщики в мобильной разработке: почему без них не обойтись даже в стартапах.

Когда в команде появляется тестировщик, некоторые разработчики думают: «Ну вот, теперь будут придираться к каждой мелочи». Но на самом деле хороший QA — это не враг, а ваш главный союзник в создании качественного приложения и сейчас я расскажу почему.


1️⃣ Разработчик ≠ тестировщик.

Мы, разработчики, часто смотрим на код через призму «Как это должно работать», а тестировщики — через «Как это может сломаться».

Пример:
Вы добавили красивый анимационный переход между экранами. Всё работает на iPhone 15 Pro. Но тестировщик проверяет на старом iPhone 8 и обнаруживает, что анимация лагает. Без него этот баг мог бы улететь в прод.


2️⃣ Они экономят деньги компании.

Один пропущенный критический баг может:
🔹 Испортить первый опыт пользователей (и они удалят приложение).
🔹 Привести к отказу от подписки (если что-то сломалось в платежах).
🔹 Потребовать хотфиксов (а это внеурочные работы для разработчиков).

По данным исследований, исправление бага на этапе тестирования может быть в 5-10 раз дешевле, чем после релиза.


3️⃣ Они видят то, что вы не замечаете.

Разработчик проверяет «работает ли фича», а тестировщик — «можно ли её сломать».

Пример:
🔹 Приложение падает, если сменить язык системы во время загрузки данных.
🔹 Кнопка «Купить подписку» не нажимается, если нажать её слишком быстро.
🔹 На iPad интерфейс «поехал» из-за неправильных констрейнтов.


4️⃣ Они помогают улучшить UX.

Хороший тестировщик не просто ищет баги — он оценивает удобство использования.

Пример:
🔹 «Эта модалка появляется слишком часто — пользователи будут раздражаться»
🔹 «Нет индикатора загрузки — люди думают, что приложение зависло».
🔹 «Текст кнопки слишком длинный и обрезается на маленьких экранах».


5️⃣ Даже в маленькой команде они нужны.

Многие стартапы думают: «Мы же agile, сами всё проверим». Но:
🔹 Разработчики не успевают тестировать всё вручную.
🔹 Автоматические тесты не покрывают все сценарии.
🔹 Без QA страдает качество, а плохие отзывы в App Store снижают конверсию.


⚠️ Как правильно работать с тестировщиками?

🔸 Не воспринимайте замечания как личную критику: это про продукт, не про вас.
🔸 Всегда запрашивайте детали: если баг сложно воспроизвести, попросите скриншоты/видео.
🔸 Цените их мнение: иногда они предлагают реально полезные доработки UX.


💡 Вывод:

Тестировщик — это не «лишний человек» в команде, а гарантия качества. Чем раньше он найдёт проблему, тем дешевле её исправить.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Паттерны проектирования в Swift: Синглтон.

Синглтон (Singleton) — это паттерн проектирования, который гарантирует, что у класса будет только один экземпляр на протяжении всего жизненного цикла приложения, и предоставляет к нему глобальную точку доступа.

Данный паттерн является одним из самых популярных и одновременно спорных паттернов в iOS разработке.

Вот как это работает на практике:
Когда вы создаёте синглтон, вы делаете его конструктор приватным, чтобы предотвратить создание дополнительных экземпляров извне, а единственный экземпляр храните в статическом свойстве. Swift автоматически обеспечивает ленивую инициализацию — объект создаётся только при первом обращении к этому свойству.

Например, если у вас есть класс AppConfig, который управляет настройками приложения, его можно реализовать как синглтон:

final class AppConfig {
  static let shared = AppConfig()
  private init() {}

  var apiKey: String = "12345"
}

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

В нашем коде есть серьезный недостаток, если в будущем понадобится подменить apiKey для тестов, возникнут сложности. Более гибкий вариант: использование протоколов:

protocol ConfigService {
  var apiKey: String { get }
}

final class ProdConfig: ConfigService {
  static let shared = ProdConfig()
  private init() {}

  let apiKey = "prod_12345"
}

class TestConfig: ConfigService {
  let apiKey = "test_67890"
}

Теперь в проде используем ProdConfig.shared, а в тестах можем подсунуть объект TestConfig.


⚠️ Главная проблема синглтонов:
Они создают неявные зависимости. Представьте, у вас 20 классов, использующих AppConfig.shared. Вдруг понадобится сделать разные конфиги для разных пользователей. Придется переписывать половину приложения.

Поэтому я использую синглтоны только для логгеров и аналитики. Для всего остального лучше подходит dependency injection, потому что это делает зависимости прозрачными и даёт гибкость в управлении объектами.

♣️ Пример:

protocol APIServiceProtocol {
  func fetchData()
}

class APIService: APIServiceProtocol {
  func fetchData() {
  }
}

class DataManager {
  let apiService: APIServiceProtocol

  init(apiService: APIServiceProtocol) {
    self.apiService = apiService
  }

  func loadData() {
    apiService.fetchData()
  }
}

💡 Вывод:
Синглтон — мощный инструмент, но при неправильном использовании может принести больше вреда, чем пользы. Главная его опасность в том, что он создаёт скрытые зависимости, которые со временем превращают код в запутанный клубок. Лучше всего его использовать только для объектов, которые действительно должны существовать в единственном экземпляре.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 SwiftUI: как отследить, что вызывает обновление View.

Когда View в SwiftUI неожиданно перерисовывается, это может сбивать с толку. Но есть простой способ понять, что именно вызвало обновление.


♣️ Добавьте в body вашей View:

var body: some View {
  let _ = Self._printChanges()
  // Ваш код
}

✅ Данный код отобразит в консоли:

🔸 Какое свойство (@State, @ObservedObject и т.д.) вызвало обновление View.
🔸 Было ли обновление из-за изменения самой вьюхи.
🔸 Была ли смена её идентичности (@identity).


⚠️ Альтернативные способы отладки.

1️⃣ onAppear + print.

Text("Привет")
  .onAppear {
    print("View появилась")
  }

2️⃣ Кастомный модификатор для вывода в консоль.

extension View {
  func debugPrint(_ text: String) -> Self {
    print(text)
    return self
  }
}

// Использование:
Circle()
  .fill(.green)
  .debugPrint("Круг отрисован")

💡 Вывод:

🔹 Self._printChanges() — лучший способ понять, почему перерисовывается View.
🔹 onAppear и кастомные модификаторы помогут отследить жизненный цикл вью.

Вот так просто можно понять, почему вьюхи в SwiftUI вдруг решили перерисоваться.


➡️ Подписаться на канал
Мобильный трудоголик

👨‍💻 Неамбициозные разработчики — удобно, но смертельно для карьеры.

В интернете идет обсуждение, что не следует нанимать ярких и известных разработчиков, а следует нанимать тех, кто не хочет роста, не выступает на конфах и молча делает свою работу.

Что скрыто за этим?
Компании заморозили найм и хочет минимизировать сложных сотрудников. Но так ли это выгодно самим разработчикам?


❌ Почему стратегия «сиди и не высовывайся» проигрышная.

1️⃣ Знания устаревают — цена на рынке падает.
🔹 Сегодня SwiftUI и async/await — стандарт, а GCD уже называют «устаревшим».
🔹 Ценят боевой опыт, который принёс бизнесу деньги, а не пет проекты из 2018 года.

2️⃣ Зарплата и инфляция навыков.
Комфортная зона — это ловушка. Вот что происходит с зарплатой, когда ты отказываешься от роста:
🔹 Если не расти внутри компании, через 2-3 года окажешься ниже рынка.
🔹 Твой текущий стек дешевеет на 15-25% в год, пока рынок требует новых компетенций.
🔹 Сначала ты отказываешься от повышения — «мне и так норм». Потом компания замораживает индексацию — «кризис, потерпите».
🔹 HR давно ведут зарплатные матрицы. Твой «стабильный» грейд через 3 года сравняется с позицией джуниора.

3️⃣ Невидимость = риск.
🔹 ИТ — это эскалатор: если не идёшь вверх — скатываешься вниз.
🔹 Компании-лидеры рынка берут тех, кто решает сложные задачи, а не «стабильно тормозит».


🤔 Что же делать?
🔸 Разработчикам: постоянно прокачивайте экспертизу и смежные навыки.
🔸 Менеджерам: поощряйте рост — иначе через пару лет команда не сможет конкурировать.


💡 Вывод:
Выбор прост: остаться «удобным» и зависеть от настроений менеджмента или расти и диктовать свои условия.

ИТ любит тех, кто не стоит на месте!


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Retain Cycle в Swift: как не попасть в тонкую ловушку.

Retain cycle — одна из самых коварных проблем в Swift. Даже опытные разработчики могут не заметить, как создают цикл удержания ссылок, который мешает освобождению памяти. Разберём пример, который выглядит безобидно, но содержит скрытую угрозу.


⚠️ Что такое Retain cycle?
Retain Cycle (цикл удержания сильных ссылок) в Swift — это ситуация, когда два или более объекта удерживают друг друга через сильные ссылки (strong), не позволяя ARC (Automatic Reference Counting) освободить память. Это приводит к утечкам памяти, так как объекты никогда не освобождаются.


❌ Проблемный код.

class MyClass {
  var task: Task<Void, Never>?

  init() {
    task = Task { [weak self] in
      guard let self else { return }

      repeat {
        self.performSomeWork()  // <- Цикл удержания!
      } while !Task.isCancelled
    }
  }

  func performSomeWork() {
  }

  deinit {
    print("deinit")  // Не выполнится
    task?.cancel()
  }
}

🤔 Что не так?
🔸 guard let self создаёт сильную ссылку на весь блок Task.
🔸 Цикл repeat работает бесконечно, удерживая self → deinit никогда не вызовется.


✅ Как исправить?

1️⃣ Изменить область видимости сильной ссылки.
Перенесите guard внутрь цикла, чтобы ссылка освобождалась после каждой итерации:

task = Task { [weak self] in
  repeat {
    guard let self else { return }
    self.performSomeWork()  // Сильная ссылка только здесь
  } while !Task.isCancelled
}

2️⃣ Использовать слабую ссылку везде.
Если метод не требует обязательного self:

task = Task { [weak self] in
  repeat {
    self?.performSomeWork()  // слабая ссылка
  } while !Task.isCancelled
}

3️⃣ Вручную разорвать цикл.
Вызовите cancel() вне deinit, например, при закрытии экрана:

  task?.cancel()
  task = nil

⚠️ Чего лучше избегать?
Явный захват метода performSomeWork:

task = Task { [performSomeWork] in
  repeat {
    performSomeWork()  // Метод всё равно содержит неявный self
  } while !Task.isCancelled
}

Методы экземпляра неявно захватывают self, даже если переданы как замыкание.


🤔 Как отлавливать такие проблемы?
🔸 Тесты: Добавьте проверку на deinit с задержкой.
🔸 Instruments: Используйте Leaks и Allocations для поиска утечки памяти и цикличных ссылок.
🔸 Логирование: Добавьте print в deinit для критичных объектов.


💡 Вывод:
🔹 [weak self] — не панацея. Всегда анализируйте область видимости сильных ссылок.
🔹 Для бесконечных задач (repeat, while) используйте локальный guard или явный cancel.
🔹 Пишите тесты на освобождение памяти — это сэкономит часы отладки.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Бекпорт onChange с oldValue для iOS 16 в SwiftUI.

Всем привет! Сегодня поделюсь полезным расширением для тех, кто поддерживает iOS 16 в своих проектах. В iOS 17 компания Apple добавила улучшенную версию onChange с доступом к старому значению, но как быть, если нужно поддерживать и более ранние версии?

Решение: backport-реализация, о которой расскажу ниже:


♣️ Создадим совместимый вариант valueChanged:

public extension View {
  @available(iOS, deprecated: 17.0, message: "Используйте нативный onChange в iOS 17+")
  @ViewBuilder func valueChanged<V>(
    of value: V,
    handler: @escaping (_ previous: V, _ current: V) -> Void
  ) -> some View where V: Equatable {
    if #available(iOS 17, *) {
      onChange(of: value, handler)
    } else {
      onChange(of: value) { [value] newValue in
        handler(value, newValue)
      }
    }
  }
}

🤔 Как это работает?

🔸 На iOS 17+ использует нативный onChange.
🔸 На iOS 16 эмулирует поведение через захват текущего значения.
🔸 Сохраняет одинаковый интерфейс для всех версий.


✅ Добавим дополнительную возможность: отслеживание переходов.

Создадим метод для отслеживания смены конкретного значения:

public extension View {
  func trackTransition<V>(
    of value: V,
    from initialValue: V,
    action: @escaping () -> Void
  ) -> some View where V: Equatable {
    valueChanged(of: value) { old, new in
      if old == initialValue && new != initialValue {
        action()
      }
    }
  }
}

♣️ Пример использования:

struct ContentView: View {
  @State private var score: Int = 0

  var body: some View {
    VStack {
      Text("Score: \(score)")
      Button("Increase") { score += 1 }
    }
    .valueChanged(of: score) { old, new in
      print("Score changed from \(old) to \(new)")
    }
    .trackTransition(of: score, from: 0) {
      print("Score started changing from zero!")
    }
  }
}

Главное преимущество этого подхода - единый код для всех поддерживаемых версий iOS без дублирования логики.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 SwiftUI-Adapter: как поддерживать новые фичи SwiftUI и не терять совместимость.

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

Недавно я наткнулся на удобную Android-библиотеку, которая упрощает работу с разными версиями API и подумал: «Почему бы не сделать что-то подобное для SwiftUI?».

После этого родилась идея разработать инструмент, который избавит вас от бесконечных проверок #available и сделает код чище:

🔗 Ссылка на GitHub


🤔 Зачем это нужно?

Каждый раз, когда Apple выпускает новый модификатор в SwiftUI, нам приходится писать такие конструкции:

if #available(iOS 15.0, macOS 12.0, *) {
  YourView()
    .badge(5)
} else {
  YourView()
}  

SwiftUI-Adapter делает эту рутину за вас! Просто используйте единый синтаксис – проверки версий останутся под капотом:

YourView()
  .adapter.badge(5)

✅ Преимущества:

🔹 Не повлияет на производительность: все проверки производятся на этапе компиляции.
🔹 Чистая кодовая база: больше никаких #available в каждом втором файле.
🔹 Простота интеграции: добавляется за пару минут через SPM.
🔹 Открытый исходный код: полная прозрачность, возможность вносить правки и участвовать в развитии.


➡️ Подписаться на канал
Мобильный трудоголик

👨‍💻 Крах IT-пузыря: как выжить в эпоху ИИ и сокращений.

Минцифры кричит о нехватке кадров, а компании массово режут штаты. ИИ пугает заменой разработчиков. Что на самом деле происходит?


⚠️ Корень проблем.

1️⃣ Пузырь лопнул.
🔹 2020-2022: нанимали «впрок», раздували команды.
🔹 2024: кредиты подорожали, инвесторы потребовали окупаемости.
🔹 Итог: 20% меньше вакансий, 26% больше резюме (данные с hh).

2️⃣ Театр менеджмента.
🔹 Раньше: 50 человек «перерисовывали кнопки», лишь бы были задачи.
🔹 Сейчас: берут только самых эффективных или обращаются к аутсорсу.

3️⃣ ИИ-революция.
🔹 Искусственный интеллект уже способен заменить низкоклассифицированных сотрудников.
🔹 Ожидается что к 2027 году ИИ будем способен полностью заменить сеньоров.


🤔 Как выжить?

1️⃣ Стать незаменимым.
🔹 Осваивать ИИ-инструменты (ChatCPT, Copilot, DeepSeek, Qwen Chat..).
🔹 Прокачивать продуктовое мышление.
🔹 Развивать soft skills.

2️⃣ Адаптироваться.
🔹 Мониторить реально востребованные навыки.
🔹 Развиваться до более высоких и незаменимых позиций.


💡 Вывод:
Рынок вовсе не умер, он повзрослел. Зарабатывать будут те, кто создаёт ценность, а не красивые отчёты.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Dependency Injection: как правильно внедрять зависимости в SwiftUI.

Сегодня поговорим о Dependency Injection (DI) — мощный подход, который делает ваш код чище, тестируемым и гибким.


⚠️ Что такое Dependency Injection?

Это способ передачи зависимостей извне, вместо создания их внутри класса.

Без использования DI:

class MyViewModel {
  private let service = MyService()  // Зависимость создаётся внутри
}

С использованием DI:

class MyViewModel {
  private let service: MyService

  init(service: MyService) { // Зависимость передаётся извне
    self.service = service
  }
}

🤔 Зачем это нужно?

🔸 Тестируемость: можно подменять зависимости на моки.
🔸 Гибкость: легко менять реализации (например, для разных сборок).
🔸 Чистая архитектура: сущности не знают, как создаются их зависимости.
🔸 Масштабирование: удобное расширение функционала благодаря добавлению зависимостей.


✅ Три способа внедрения зависимостей в SwiftUI:

1️⃣ Через инициализатор (Constructor Injection).

struct MyContentView: View {
  let service: MyNetworkService

  var body: some View {
    Text(service.fetchText())
  }
}

MyContentView(
  service: MyNetworkService()
)

2️⃣ Через свойства (Property Injection).

class MyViewModel: ObservableObject {
  var analytics: MyAnalyticsService?  // Можно задать позже
}

let myViewModel = MyViewModel()
myViewModel.analytics = MyAnalyticsService()

3️⃣ Через .environmentObject (Environment).

@main
struct MyApp: App {
  let service = MyNetworkService()

  var body: some Scene {
    WindowGroup {
      MyContentView()
        .environmentObject(service)
    }
  }
}

struct MyContentView: View {
  @EnvironmentObject var service: MyNetworkService

  var body: some View {
    Text(service.fetchText())
  }
}

💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик