😤 Сильный сотрудник начал сдавать? 8 реальных причин.

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

🔸 Талантливый специалист ≠ хороший руководитель. Если сотрудника повысили, но не научили управленческим навыкам, он может тонуть в задачах, которые раньше решал за час.
🔸 Сильные сотрудники часто берут на себя слишком много — особенно если им не говорят «стоп». Со временем это приводит к ошибкам и апатии.
🔸 Даже топовые специалисты — живые люди. Развод, болезнь, уход за родственником снижают концентрацию.
🔸 Если сотрудник не чувствует поддержки коллег или борется с токсичным окружением, его мотивация падает.
🔸 Рутина убивает амбиции. Если человек не видит развития, он начинает работать «на минимуме».
🔸 Хронический стресс, депрессия, недосып или синдром самозванца снижают продуктивность.
🔸 Если компания резко меняет курс (например, с качества на скорость), принципиальные сотрудники теряют мотивацию.
🔸 Плохое согласование может привести к неэффективной работе сотрудников.

Прежде чем ругать сотрудника, разберитесь в причинах. Часто проблема не в нём, а в системе.

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

🔢 Swift 6: Typed Throws — точечная обработка ошибок.

С выходом Swift 6 работа с ошибками стала точнее. Теперь вместо простого throws можно указывать конкретный тип или даже вариант ошибки, что делает код безопаснее и понятнее.

♣️ Раньше функция могла выбросить любую ошибку, и компилятор не проверял её тип:

func readFile(at path: String) throws -> String {
}  

♣️ Теперь можно явно указать, какую именно ошибку ожидать:

func readFile(at path: String) throws(FileNotFoundError) -> String {
}

Если функция попытается выбросить другой вариант FileNotFoundError (например FileNotFoundError.whileSearchingFile), компилятор заранее сообщит об ошибке.

🤔 Зачем это нужно?
🔹 Безопасность: компилятор проверяет, что вы ловите именно те ошибки, которые задекларированы.
🔹 Читаемость: из сигнатуры функции сразу видно, что может пойти не так.
🔹 Упрощение кода: больше не нужен «универсальный» catch для всех неизвестных ошибок:

do {
  let content = try readFile(at: "path")
} catch FileNotFoundError.whileReadingFile {
  print("Файл поврежден")
} catch FileNotFoundError.whileSearchingFile {
  print("Ошибка при поиске файла")
}

⚠️ Важно:
🔸 Тип ошибки должен соответствовать протоколу Error.
🔸 Можно указать как общий catch (как было ранее), так и конкретный case из enum.

💡 Вывод:
Typed Throws в Swift 6 — это шаг к предсказуемому и самодокументируемому коду. Меньше скрытых багов, проще отладка!

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

🔨 Новый инструмент для оптимизации приложений на SwiftUI.

На WWDC25 Apple представила крупное обновление Xcode 26 и новые инструменты для оптимизации SwiftUI приложений.

Команда Apple Music и разработчики Instruments показали, какие проблемы теперь можно отследить в SwiftUI:
🔹 Лишние обновления View (которые вызывают лаги анимации и скролла).
🔹 Подвисания интерфейса (Hitches).
🔹 Медленные списки (теперь обновляются в 16 раз быстрее).

🤔 Как это работает?
Новый SwiftUI Instrument в Xcode 26 детально показывает:
🔸 Какие View обновляются и почему.
🔸 Как часто происходят ререндеры.
🔸 Time Profiler + Hitches Tool помогают находить узкие места.

Пример из сессии WWDC25:

Мы нашли View, которая обновлялась 300 раз в секунду без причины. После фикса FPS вырос с 40 до 60.

🔗 Подробнее на сайте Apple

💡 Зачем это нужно?
🔹 Ускорение разработки (меньше ждёте загрузку Xcode).
🔹 Энергоэффективность (Power Profiler спасёт батарею пользователей).
🔹 Плавный интерфейс (SwiftUI Instrument избавит от лагов).

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

🔢 Structured Concurrency в Swift: последовательное vs параллельное выполнение задач.

В Swift современный подход к многопоточности: Structured Concurrency — позволяет легко управлять асинхронными операциями, сохраняя читаемость кода. Рассмотрим два ключевых сценария: последовательное и параллельное выполнение.

1️⃣ Последовательное выполнение.
Когда задачи зависят друг от друга или должны выполняться по очереди:

func fetchData() async {
  // Сначала загружаем аккаунты, затем задачи
  let accounts = await fetchAccounts()
  let tasks = await fetchTasks(accounts: accounts)

  print("Аккаунты: \(accounts)")
  print("Задачи: \(tasks)")
}

⚠️ Особенности:
🔸 Выполняется пошагово: fetchAccounts() → fetchTasks()
🔸 Подходит, если второй запрос требует данных из первого.
🔸 Простота отладки (очевидный порядок выполнения).

2️⃣ Параллельное выполнение.
Когда задачи независимы и можно сэкономить время, выполняя их одновременно:

func fetchData() async {
  // Параллельный запуск
  async let accountsRequest = await fetchAccounts()
  async let tasksRequest = await fetchTasks()

  // Ожидаем результаты
  let (accounts, tasks) = await (accountsRequest, tasksRequest)

  print("Аккаунты: \(accounts)")
  print("Задачи: \(tasks)")
}

⚠️ Особенности:
🔸 Обе функции запускаются одновременно.
🔸 Общее время выполнения ≈ времени самой долгой задачи.
🔸 async let создает параллельное подзадачи.
🔸 Результаты доступны только после await.

✅ Ключевые принципы Structured Concurrency:

Иерархия задач:
🔹 Родительская задача ждет завершения дочерних (async let).
🔹 Отмена родительской отменяет и дочерние.

Безопасность:
🔹 Компилятор контролирует await, предотвращая deadlock.
🔹 Ошибки распространяются корректно.

Эффективность:
🔹 Система сама решает, сколько потоков использовать.
🔹 Нет ручного управления (DispatchQueue не нужен).

💡 Вывод:
🔸 await — для последовательного кода.
🔸 async let — для параллельных операций.
🔸 Structured Concurrency делает асинхронный код предсказуемым

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

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

🇷🇺 🍏 Россия требует от Apple открыть iPhone для RuStore.

Владимир Путин сегодня подписал закон, который обязывает Apple разрешить установку российского магазина приложений RuStore на iPhone.

Теперь производителям запрещено блокировать его загрузку на устройства, продаваемые в России. Если RuStore установлен (даже если вы скачали его сами), Apple не может замедлять его работу, мешать обновлять приложения, ограничивать платежи или ухудшать работу смартфона из-за российского магазина приложений.

Несоблюдение этих правил будет считаться нарушением прав потребителей — это грозит серьезными штрафами.
Закон вступает в силу 1 сентября 2025 года.

📱 Но главное: согласится ли Apple?
Компания всегда строго охраняла свою экосистему, и неизвестно, как она отреагирует на требование открыть iPhone для стороннего магазина.

👨‍💻 Что я думаю?
Лично мне кажется, что Apple всё же разрешит RuStore. Россия — важный рынок, и компания вряд ли захочет рисковать штрафами или уходом с него. Да, их система всегда была закрытой, но ради бизнеса они могут пойти на уступки — как уже делали в других странах.

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

🔢 NavigationView в SwiftUI: навигация в iOS приложениях.

NavigationView — это основной компонент для организации навигации в SwiftUI приложениях. Он позволяет создавать иерархические переходы между экранами, похожие на стандартные UINavigationController в UIKit.

✅ Основные возможности:
🔹 Стековая навигация (push/pop).
🔹 Автоматическая кнопка "Назад".
🔹 Поддержка заголовков и панелей инструментов.

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

struct MenuView: View {
  var body: some View {
    NavigationView {
      List {
        NavigationLink("Первый экран", destination: FirstScreen())
        NavigationLink("Второй экран", destination: SecondScreen())
      }
      .navigationTitle("Главное меню")
    }
  }
}

⚠️ Ключевые модификаторы:
🔸 navigationTitle - задает заголовок экрана.
🔸 navigationBarItems - добавляет кнопки в панель навигации.
🔸 navigationBarHidden- скрывает панель навигации.

NavigationLink - основной способ перехода между экранами:

NavigationLink(destination: FirstScreen()) {
  Text("Первый экран")
}

💡 Советы по использованию:
🔹 Не вкладывайте несколько NavigationView друг в друга.
🔹 Для сложной навигации используйте NavigationStack.
🔹 Помните, что стиль навигации может отличаться на разных платформах (iOS, macOS).

NavigationView значительно упрощает реализацию навигации по сравнению с UIKit, сохраняя при этом привычный пользователям iOS интерфейс.

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

🔢 Автоматическое отслеживание изменений с помощью @Observable: магия SwiftUI теперь доступна в UIKit.

С iOS 18 и macOS 15 UIKit получил скрытую фичу, которая меняет правила игры — автоматическое отслеживание изменений данных через @Observable. Больше не нужны ручные вызовы setNeedsLayout() — интерфейс теперь обновляется сам!

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

Помечаем модель макросом @Observable:

import Observation

@Observable
class User {
  var name = "Иван"
  var unreadMessages = 0
}

Читаем данные в стандартных методах ViewController:

class ProfileVC: UIViewController {
  let user = User()

  override func viewWillLayoutSubviews() {
    super.viewWillLayoutSubviews()

    // UIKit автоматически отследит эти изменения
    nameLabel.text = user.name
    messagesCountLabel.text = "\(user.unreadMessages)"
  }
}

Изменяем данные — интерфейс обновится автоматически:

@objc func buttonDidTap() {
  // Значение messagesCountLabel обновится автоматически
  user.unreadMessages += 1
}

Включаем отслеживание @Observable в Info.plist:

<key>UIObservationTrackingEnabled</key>
<true/>

В iOS 26 это работает из коробки без настройки.

⚠️ Важные нюансы:
🔸 Автоматическое отслеживание изменений работает в viewWillLayoutSubviews(), layoutSubviews() и новом методе updateProperties(), который вызывается перед layoutSubviews для оптимизации.
🔸 Обновление интерфейса после обновления данных возможно только в main thread.
🔸 Важно не забывать про retain cycles, при работе с @Observable.
🔸 Рекомендуется избегать обновление данных без необходимости, так как частое обновление интерфейса может сказаться на производительности приложения.

💡 Вывод:
Теперь UIKit умеет так же удобно обновлять интерфейс, как SwiftUI. Главное — правильно использовать @Observable и не забывать про потокобезопасность.

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

✌️ Продажу iPhone могут запретить в России, если Apple не пропустит RuStore.

Буквально недавно обсуждали, что никаких запретов в сторону Apple не ожидается, а вот вам и здравствуйте. В Госдуме сообщили, что в случае отказа Apple содействовать работе российского магазина приложений RuStore на своих устройствах, в отношении компании могут ввести санкции, вплоть до полного запрета продаж iPhone на территории России.

Хотя в текущем году таких мер не планируется, ограничения могут начать действовать уже в следующем году, если компания не изменит свою позицию. На данный момент Apple не прокомментировала новый закон и возможные последствия.

Переобулись уж очень быстро 😅

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

🔨 Xcode 26: как ИИ помощник изменит разработку под Apple.

На WWDC25 компания Apple представила Xcode 26 с революционным ИИ ассистентом, который переосмысливает процесс создания приложений. Вот что ждет разработчиков.


ИИ помощник: код как диалог.

1️⃣ Умное автодополнение:
🔹 Анализирует стиль кода и предлагает персонализированные варианты.
🔹 Генерирует шаблонный код (делегаты, сетевые запросы).

2️⃣ Предсказание ошибок:
🔹 Находит синтаксические и логические баги до запуска.
🔹 Подсказывает оптимизации для Swift / Objective-C.

3️⃣ Контекстные советы:

// Вы начинаете печатать:  
@State private var isLoading = false

// ИИ сразу предлагает:
.onChange(of: isLoading) { newValue in
  print("Loading state changed: \(newValue)")
}

Тесная интеграция с экосистемой Apple.
🔹 Swift Playgrounds: ИИ помогает экспериментировать с кодом в реальном времени.
🔹 TestFlight: автоматически анализирует краши и предлагает фиксы.
🔹 Core ML: упрощает внедрение ML-моделей (подсказывает код для обработки данных).


Мультиязыковая поддержка.

ИИ работает с:
🔹 Swift (приоритет).
🔹 Objective-C.
🔹 C++.
🔹 SwiftUI / UIKit.


Отладка нового уровня.

1️⃣ ИИ анализ крашей:
🔹 Определяет корневую причину падений.
🔹 Предлагает готовые решения.

2️⃣ Визуализация данных:
🔹 Показывает графики потребления CPU / памяти.
🔹 Выявляет утечки без Instruments.


🤔 Как это изменит разработку?
🔸 Скорость: на 30-50% меньше рутинных задач.
🔸 Качество: меньше багов в продакшене.
🔸 Доступность: новым разработчикам проще входить в экосистему.


⚠️ Требования:
🔸 Mac на Apple Silicon (M1+).
🔸 Xcode 26 (минимум).


💡 Вывод:
Xcode 26 — это не просто обновление, а смена парадигмы. Теперь ИИ берет на себя шаблонные задачи, оставляя вам творческую часть — архитектуру и инновации.


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

🔢 SwiftUI: отступы для секций в List для iOS 26+.

В SwiftUI появился долгожданный инструмент для точного контроля отступов в секциях List — модификатор listSectionMargins(). Теперь можно гибко настраивать отступы для отдельных секций, не прибегая к костылям.

🤔 Как это работает?
Модификатор принимает:
🔸 edges — стороны для отступов (по умолчанию .all).
🔸 length — величина отступа в точках.

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

List {
  Section("Новости") {
    Text("Свежие обновления")
  }
  .listSectionMargins(.horizontal, 20) // Отступы по бокам
    
  Section("Профиль") {
    Text("Настройки")
  }
  .listSectionMargins(.top, 10) // Отступ сверху
}

✅ Ключевые особенности:
🔹 Переопределяет стандартные отступы: заменяет дефолтные отступы, заданные стилем списка.
🔹 Работает с заголовками/подвалами: отступы применяются вокруг header и footer секции.
🔹 Гибкость: можно задавать для конкретных сторон (.horizontal, .vertical, .top и т.д.) или для всех сторон сразу (.all).
🔹 Не влияет на отступы между ячейками (для этого по-прежнему используем listRowSpacing).

⚠️ До iOS 26 приходилось использовать:
🔸 Неочевидные комбинации padding() + listRowInsets().
🔸 Кастомные разделители.
🔸 Костыли с GeometryReader.

Теперь всё решается одним модификатором!

listSectionMargins() — это отличное дополнение для тонкой настройки списков!

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

🔢 Class vs Actor в Swift: ключевые отличия.

В Swift и классы, и actor используются для создания ссылочных типов, но с разными целями. Главное отличие — в потокобезопасности. Actor появились в Swift 5.5 как часть Concurrency.

1️⃣ Классы (class):
🔹 Не потокобезопасны: доступ к свойствам и методам из разных потоков может привести к гонкам данных.
🔹 Поддерживают наследование: можно создавать подклассы.
🔹 Используются для общего состояния: подходят для объектов, которые не требуют синхронизации.

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

class Counter {
  var value = 0

  func increment() {
    value += 1 // Опасность при вызове из разных потоков
  }
}

2️⃣ Actor:
🔹 Потокобезопасны: Swift автоматически сериализует доступ к свойствам и методам (очередь задач).
🔹 Нет наследования: нельзя наследовать от actor.
🔹 Для изолированного состояния: идеальны для данных, которые изменяются из разных потоков.

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

actor SafeCounter {
  private var value = 0

  func increment() {
    value += 1 // Безопасно (автоматическая синхронизация)
  }

  func currentValue() -> Int {
    return value
  }
}

♣️ Пример работы с Actor:

let counter = SafeCounter()

Task {
  await counter.increment()
  let value = await counter.currentValue()
  print(value) // 1
}

⚠️ Важно:
🔸 Для вызова методов actor нужен await.
🔸 Свойства actor по умолчанию private.

💡 Вывод:
🔹 Классы — для простых объектов без многопоточности.
🔹 Actor — для данных, изменяемых из разных потоков (счетчики, кеши, состояния).

Если нужно потокобезопасное решение — выбирайте actor. Если важна гибкость и наследование — class.

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

👨‍💻 Чем на самом деле отличается джун от сеньора?
И почему стаж ≠ опыт.

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


1️⃣ Видение контекста.

Джун:
🔹 Фокусируется на своей задаче.
🔹 Пишет код по ТЗ, не всегда понимая, как он влияет на систему.

Сеньор:
🔹 Видит связи между компонентами.
🔹 Спрашивает: как это повлияет на поддержку, бизнес или пользователей?
🔹 Выбирает простые, но надежные решения, даже если они менее модные.


2️⃣ Ответственность за результат.

Джун:
🔹 Исправляет баги, если их явно указали.
🔹 Может переложить проблему: «Это не мой модуль».

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


3️⃣ Работа в команде.

Джун:
🔹 Учится у других, редко делится знаниями.
🔹 В код ревью пишет минорные замечания, без изучения глубокой логики.

Сеньор:
🔹 Находит слабые места в команде и помогает их закрыть.
🔹 Дает тактичные замечания при code review, объясняет почему следует внести исправления с аргументами, а не только указывает на проблемный код.
🔹 Говорит: давай разберем твой подход вместе, вместо ты неправ.


4️⃣ Выбор технологий.

Джун:
🔹 Хочет использовать новейший стек, потому что так круто.
🔹 Пишет на SwiftUI, когда нужен UIKit (и наоборот).

Сеньор:
🔹 Выбирает инструменты под конкретную задачу и бюджет.
🔹 Может выполнить рекомендацию по использованию стабильного стека, если видит в этом больше плюсов, а не использует все самое модное и нестабильное.


5️⃣ Умение НЕ писать код.

Джун:
🔹 Стремится добавить фичу любой ценой.
🔹 Может переписать рабочий код для красоты.

Сеньор:
🔹 Избегает изучение лишней информации, которая никогда не пригодится.
🔹 Говорит: этот легаси работает — не трогаем или автоматизируем в следующем квартале.


6️⃣ Работа с неопределенностью.

Джун:
🔹 Ждет четких ТЗ.
🔹 Паникует, если требования меняются.

Сеньор:
🔹 Самостоятельно уточняет детали у бизнеса.
🔹 Предлагает MVP решения при нехватке данных.


⚠️ Главное отличие.

Сеньор — это не про количество строк кода, а про:
✅ Глубину понимания последствий своих решений.
✅ Ответственность за продукт, а не за таски.
✅ Мягкие навыки (коммуникация, менторство и т.д).

Как говорил один мудрый тимлид: джун думает, как написать. мидл — что написать. сеньор — стоит ли писать.


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

🍏 🏋️ Мое приложение для отказа от вредных привычек.

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

💚 Счетчик дней: вредные привычки.
Конечно, счетчик дней без вредных привычек — не новинка. Но я добавил уникальный функционал, которого не было у конкурентов:

➖ Возможность отслеживать не только вредные, но и полезные привычки.
➖ Поддержка iOS, watchOS, macOS и Android версии приложения.
➖ Удобные виджеты для iOS и macOS.
➖ Синхронизация данных между всеми устройствами пользователя.
➖ Система рейтинга – пользователи могут соревноваться в отказе от курения и алкоголя.
➖ Возможность выбора счетчиков привычек, которые следует отображать на главном экране приложения, на виджетах и на часах Apple Watch.
➖ Отображение мотивирующих цитат по отказу от вредных привычек на главном экране приложения.

Моя цель – помочь людям бросить вредные привычки и заменить их полезными, а соревновательный элемент делает процесс более мотивирующим и увлекательным.

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


👨‍💻 Разработка:
🔹 Приложение «Счетчик дней: вредные привычки» для iOS, watchOS и macOS разработано на SwiftUI.
🔹 Версия для Android разработана на Flutter.
🔹 Серверную часть для приложения разрабатывал самостоятельно на PHP.

📊 На данный момент приложение имеет более 80 тысяч скачиваний в магазинах приложений.

📱 📱 Приложение доступно в магазинах приложений


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

🔢 Расширенные текстовые возможности в SwiftUI с AttributedString.

На WWDC25 Apple представила новые API для работы с AttributedString в SwiftUI, позволяющие создавать мощные текстовые редакторы с гибким форматированием.

⚠️ Что нового?

Готовые стили:
🔹 Поддержка жирного текста, курсива, подчеркивания, зачеркивания.
🔹 Изменение размера шрифта и цвета текста.

Кастомные атрибуты:
🔹 Можно добавлять собственные правила форматирования.

Безопасное редактирование:
🔹 AttributedTextValueConstraint ограничивает допустимые атрибуты.
🔹 TextEditor автоматически применяет заданные правила.

Динамическое обновление:
🔹 SwiftUI корректно обрабатывает изменения текста и выделения.

🔗 Подробнее на сайте Apple

💡 Где это пригодится?
🔸 Редакторы статей/рецептов (как в демо WWDC).
🔸 Приложения для заметок с расширенным форматированием.
🔸 Чат-боты с поддержкой стилизованного текста.

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

👨‍💻 ИТ-рынок сжался. Как теперь искать работу?

Ещё недавно компании боролись за разработчиков, а сегодня на одну вакансию — сотни резюме.

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

⚠️ Как пробиться даже в кризис?

1️⃣ Резюме — ваш пропуск на собеседование.
🔹 Важно иметь минимум 3 года коммерческого опыта (фриланс и пет-проекты считаются, но котируются меньше).
🔹 Цифры и факты вместо общих фраз. Не «оптимизировал приложение», а «снизил потребление памяти на 25%».
🔹 Если есть пробелы в опыте работы, лучше их закрыть фрилансом или пет проектами.
🔹 Проверьте резюме через ChatGPT или hh-аналитику — даже мелкие ошибки могут отсеять вас.
🔹 Приложите портфолио к резюме. Примеры ваших работ позволят оценить ваш опыт.

2️⃣ Собеседования — учимся играть по новым правилам.
🔹 Будьте готовы к лайвкодингу. Без умения решать задачи на глазах у интервьюера шансы равны нулю.
🔹 Тренируйте алгоритмы (LeetCode должен решаться на автомате).
🔹 Перед собеседованием обязательно ищите слитые разборы вопросов по компании (телеграм чаты, форумы, статьи в интернете).

3️⃣ Выделяться или проиграть.
Жирные офферы получают специалисты, умеющие продать себя. Разработчиков много, поэтому берут тех, кого видно. Вот несколько советов, как стать заметнее:
🔹 Ведите технический блог (даже 1 статья в месяц — уже очень хорошо).
🔹 Участвуйте в опенсорс-проектах (это новый must-have для middle+).
🔹 Делайте разборы кейсов в LinkedIn (работодатели это проверяют).
🔹 Выступайте публично, на ИТ мероприятиях или онлайн конференциях.

Медийность = доверие. Если о вас знают, шанс получить оффер гораздо выше.

4️⃣ Принять новые правила игры.
🔹 Рынок работодателя: вакансий меньше, чем кандидатов.
🔹 Жалобы не помогут: либо адаптируешься, либо останешься без оффера.
🔹 Компании ищут готовых специалистов: доучиваться за их счет не больше не выйдет.
🔹 Удалёнка для джунов почти умерла: готовьтесь к гибридному формату.
🔹 Зарплаты стабилизировались: зп 400к для мидлов осталась в 2023 году.
🔹 Слабые отсеиваются: но те, кто вкатывает, продолжают брать топовые предложения.

💡 Вывод:
Да, рынок уже не тот, но офферы всё ещё есть — их просто получают те, кто готовится лучше других и вкладывается в свою экспертность.

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

🔢 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. Он идеален для приложений со сложной навигацией, программного управления историей экранов и лубоких ссылок.

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