🔨 Xcode 26 ускоряет сборки: появилось кеширование компиляции!

В Xcode 26 RC добавили ручное включение кеширования компиляции и это может серьезно ускорить вашу разработку.


⚠️ Как это работает?

Теперь можно закешировать результаты компиляции Swift и C-подобных языков. При повторной сборке тех же файлов Xcode будет брать их из кеша, а не пересобирать с нуля.


🔗 Xcode 26 RC Release Notes


👨‍💻 Мое мнение:

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


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

👨‍💻 Эффективный рост в IT: как развиваться быстрее других.

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

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


1️⃣ Стратегия роста: осознанный шаг, а не прыжок в пустоту.

Смена специализации или поиск новой работы это не «попробую, что предложат». Это точечный расчет.

Пример:
Вы backend-разработчик и хотите уйти в Data Engineering. Ваш план:

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

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


2️⃣ ИИ ваш партнер в апгрейде, а не угроза.

Да, ИИ пишет код. Но он не может выстроить архитектуру, прочувствовать продукт или понять бизнес-логику. Его сила в скорости рутины. Ваша в экспертизе.

Как использовать ИИ для роста:

🔹 Поручите ему рутинные задачи: генерация тестов, шаблонного-кода, документации.
🔹 Используйте для изучения нового: «Объясни разницу между Grand Central Dispatch и OperationQueues», получите выжимку, углубляйтесь сами.
🔹 Декомпозируйте сложные задачи: «Как перейти от MVC к VIPER?», получите от ИИ план внедрения, проанализируйте предложенную архитектуру, найдите слабые места и адаптируйте под конкретные нужды вашего проекта.


3️⃣ Кризис = время для переговоров.

Компании сокращают дорогих специалистов, но паника делает рынок подвижным. Те, кто уверен в своей ценности, могут найти даже лучшие условия.

Но есть нюансы:

🔹 Не меняйте работу случайным образом. Изучите стек и боли нового работодателя.
🔹 Готовьтесь к сложным техническим собеседованиям, на них стали глубже спрашивать про архитектуру и принятие решений.
🔹 Используйте нетворкинг: 70% крутых вакансий не публикуются, их занимают по рекомендациям.


4️⃣ Рост это всегда практика, а не сертификаты.

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

Ваш план роста:

🔹 Если хотите сменить специализацию, то начните с внутреннего перехода в компании. Так безопаснее.
🔹 Участвуйте в опенсорсе или создайте свой проект на новом стеке. Это лучше любого резюме.
🔹 Просите фидбек у коллег и менторов, без него вы не увидите слепых зон.


5️⃣ Менторство и комьюнити — лифт для карьеры.

Самостоятельно расти можно, но медленно и с ошибками. Окружение ускоряет рост.

Что делать:

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


6️⃣ Фокус на качестве, а не на количестве технологий.

Распыление это главный враг роста. Лучше быть экспертом в одном, чем поверхностным во всем.

Как проверить, туда ли вы растете:

🔹 Сравните свой стек с вакансиями мечты. Уберите лишнее, добавьте недостающее.
🔹 Спросите себя: «Что я сделал за последние 3 месяца, чтобы стать ближе к цели?» Если ответа нет, меняйте тактику.
🔹 Не бойтесь отказываться от проектов или задач, которые не ведут к цели.


💡 Вывод:

2025-2026 год станет временем настоящих профессионалов, а не универсальных специалистов широкого профиля. Успеха добьются те, кто делает ставку на глубокую экспертизу, а не поверхностное знакомство с технологиями. Умение эффективно использовать ИИ для рутинных задач и строить сильное профессиональное сообщество вокруг себя станет ключевым преимуществом.


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

🔢 Как запустить поток в Swift: основные способы.

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

1️⃣ Grand Central Dispatch (GCD) — DispatchQueue.

Позволяет легко выполнять код в фоне или на главном потоке.

// Фоновый поток
DispatchQueue.global().async {
  // Тяжелые вычисления или сетевые запросы
  DispatchQueue.main.async {
    // Обновляем UI (только в главном потоке!)
  }
}

2️⃣ Swift Concurrency (Task, async/await).

Современный способ для асинхронного кода.

Task {
  // Асинхронная работа
  let result = await networkRequest()

  await MainActor.run {
    // Обновляем UI (только в главном потоке!)
    updateUI(with: result)
  }
}

...

@MainActor
private func updateUI(with result: String) {
}

3️⃣ OperationQueue.

Для сложных зависимостей между задачами.

let queue = OperationQueue()
queue.addOperation {
  // Фоновая задача
}

⚠️ Важные правила:

🔸 UI-обновления: только в главном потоке (DispatchQueue.main), @MainActor.
🔸 Глобальные очереди (global()): для CPU-интенсивных задач.
🔸 Асинхронность (async): чтобы не блокировать текущий поток.


🤔 Когда что использовать?

🔹 DispatchQueue: для простых фоновых задач.
🔹 Task: для современного асинхронного кода (с async/await).
🔹 OperationQueue: для сложных цепочек операций.


💡 Вывод:

Выбирайте инструмент под задачу, но всегда помните о потокобезопасности!

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

🔢 Что изменилось в поиске на iOS 26: разбор новых возможностей SwiftUI.

Всем привет! Если вы обновляете свое приложение под iOS 26, то обратили внимание на поиск. Apple серьезно переработала не только визуал, но и логику размещения поисковых интерфейсов.

Рассказываю, как это работает теперь, с живыми примерами и кодом.


1️⃣ Поиск в toolbar.

Раньше поиск в NavigationSplitView автоматически размещался в сайдбаре на iPad и вверху экрана на iPhone. Теперь система сама выбирает оптимальное расположение:

// Раньше: поиск всегда в сайдбаре
NavigationSplitView {
  List(notes, selection: $selectedNote) { note in
    NavigationLink(note.title, value: note)
  }
  .navigationTitle("Notes")
} detail: {
  NoteDetailView(note: selectedNote)
}
.searchable(text: $searchText) // Новый стиль по умолчанию

В iOS 26 тот же код дает совершенно другой результат:

🔹На iPad: поиск в стеклянном контейнере в правом верхнем углу.
🔹На iPhone: поиск внизу экрана (удобно для больших экранов).

Хотите вернуть старое поведение? Укажи явное размещение:

.searchable(text: $searchText, placement: .sidebar)

2️⃣ Поиск в detail view.

Если поиск нужен только в детальном представлении, то модификатор применяется к нему:

NavigationSplitView {
  // Список без поиска
} detail: {
  NoteDetailView(note: selectedNote)
  .searchable(text: $searchText) // Только для детального просмотра
}

Здесь тоже работает новое позиционирование: сверху на iPad, снизу на iPhone.


3️⃣ Поиск в tabBar.

Для приложений с табБаром появился отдельный сценарий. Создаем вкладку с ролью .search:

TabView {
  Tab("Library", systemImage: "books.vertical") {
    LibraryView()
  }

  Tab(role: .search) { // Важно: роль search
    NavigationStack { // Обязательно в NavigationStack
      SearchView()
      .navigationTitle("Search")
    }
  }
}
.searchable(text: $searchText)

В iOS 26 такая вкладка:

🔹 Визуально отделена от других.
🔹 Превращается в поисковое поле при выборе.
🔹 На iPad размещается по центру сверху.


⚠️ Новые toolbar-компоненты.

Самое интересное — кастомизация нижнего toolbar. Добавлены два новых типа контента:

.toolbar {
  if #available(iOS 26.0, *) {
    DefaultToolbarItem(kind: .search, placement: .bottomBar) // Новый!
    ToolbarSpacer(.flexible, placement: .bottomBar) // И этот новый
  }

  ToolbarItem(placement: .bottomBar) {
    NewNoteButton() // Ваша кастомная кнопка
  }
}

Так поиск и другие элементы toolbar правильно распределят пространство.


✅ Минимизация поиска.

Если поиск не основная функция, можно свернуть его в кнопку:

// Создаем extension для удобства
extension View {
  @ViewBuilder func minimizedSearch() -> some View {
    if #available(iOS 26.0, *) {
      self.searchToolbarBehavior(.minimize)
    } else {
      self
    }
  }
}

// Использование
.searchable(text: $searchText)
.minimizedSearch() // Теперь это кнопка поиска!

Система может применить это поведение автоматически, в зависимости от размера экрана или количества элементов toolbar.


💡 Вывод:

Большинство изменений в поиске iOS 26 работают автоматически, достаточно обновить приложение до новых API. Новый дизайн обеспечивает единый стиль и улучшенный UX, особенно для больших экранов, при этом сохраняя гибкость кастомизации.


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

📱 Вайбкодеры vs Разработчики: почему холивар бесполезен, а ИИ это просто новый инструмент.

Все чаще в интернете возникают споры: одни ребята в восторге от того, как ИИ (тот же Cursor) генерит за них код. Другие, классические разработчики, смотрят на это скептически и даже свысока. Мол, «настоящие программисты так не делают», а вайбкодеры просто копипастят код без понимания. Давайте разбираться.


⚠️ Что такое «вайбкодинг»?

Если коротко, это когда ты не пишешь код вручную, а объясняешь задачу ИИ «человеческими» словами. А он тебе выдает готовый кусок программы. Это как давать задание умному стажеру, который мгновенно его выполняет.

Идею популяризировал Андрей Карпати (экс-Tesla AI). Его подход: «Я вижу что-то, говорю что-то, запускаю, копирую и это в основном работает». Звучит знакомо, правда?


✅ Мой опыт работы с Cursor.

Недавно мне понадобилось собрать прототип мобильного приложения под iOS с базовым экраном профиля, настройками и простой авторизацией. По старинке я бы потратил день только на то, чтобы прописать основные View, настроить навигацию между экранами и организовать простые сетевые запросы. Но с тем же Cursor я получил готовый каркас на SwiftUI буквально за полчаса. Да, потом я ещё правил логику, допиливал интерфейс и адаптировал под свои нужды. Но самое утомительное, создание базовой структуры, верстка стандартных элементов — всё это за меня сделал ИИ.

И это круто не потому, что я «разленился» или забыл, как пишется код. А потому, что вместо часов кропотливой рутины я сразу смог заняться тем, что действительно важно: проектированием пользовательского опыта, анимациями и продумыванием того, как всё будет работать вместе. ИИ взял на себя черную работу, а я сосредоточился на творческой.


👨‍💻 О скептическом отношении опытных разработчиков.

Их скепсис мне понятен. Вот пару аргументов, с которыми я сталкивался:

🔸 «Это код низкого качества». ИИ часто выдает работающее, но неоптимальное или небезопасное решение. Без глубоких знаний это не проверить.
🔸 «Таких джунов не возьмут на работу». CEO одной студии прямо заявил, что не стал бы нанимать человека, который просто копипастит код из ИИ без понимания.

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

Но вот важный нюанс: многие стартапы уже генерируют по 80-90% кода через ИИ. Но делают это как раз технически сильные основатели, которые могли бы написать всё сами, но теперь экономят время.


🤔 Так в чём же суть?

Для меня вайбкодинг это не про лень и не про «халяву». Это про эффективность.

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

Да, ответственность никуда не делась. Код всё так же нужно тестировать, ревьюить и продумывать архитектуру. ИИ не отменяет need-to-know. Но он автоматизирует рутину.


💡 Вывод:

Спор «вайбкодеры vs разработчики» бесполезен. Настоящий прорыв происходит не на этих баррикадах, а у тех, кто использует ИИ как мощный инструмент для усиления своих возможностей.

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


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

🔢 SwiftUI WebView: работаем с веб-контентом.

На WWDC 2025 компания Apple представила долгожданный нативный WebView для SwiftUI.


⚠️ Базовое использование:

// Инициализация WebPage
@State private var page = WebPage()

// Загрузка контента
WebView(page: page)
.onAppear {
  let request = URLRequest(url: URL(string: "https://apple.com")!)
  page.load(request)
}

⚙️ Ключевые возможности:


1️⃣ Загрузка локального контента.

let htmlString = "<h1>Локальный контент</h1>"
page.load(html: htmlString, baseURL: Bundle.main.resourceURL)

2️⃣ Отслеживание загрузки.

VStack {
  // Индикатор прогресса
  if page.isLoading {
    ProgressView(value: page.estimatedProgress)
  }
}

3️⃣ Кастомные схемы URL.

Регистрация обработчика для собственных URL-схем:

let scheme = URLScheme("myapp")!
var config = WebPage.Configuration()
config.urlSchemeHandlers[scheme] = CustomSchemeHandler()
page = WebPage(configuration: config)

4️⃣ Управление навигацией.

Контроль перехода по ссылкам через NavigationDecider:

class CustomNavigationDecider: WebPage.NavigationDeciding {
  func decidePolicy(for action: WebPage.NavigationAction) async -> WKNavigationActionPolicy {
    // Ваша логика обработки переходов
    return .allow
  }
}

...

let config = WebPage.Configuration()
let decider = CustomNavigationDecider()

WebPage(
  configuration: config,
  navigationDecider: decider
)

5️⃣ JavaScript-взаимодействие.

let result = try await page.callJavaScript("document.title")
print("Заголовок страницы: \(result)")

✅ Важные особенности:

🔹 Требует iOS 18+ / macOS Sequoia+.
🔹 Для сложной навигации обязателен NavigationStack.
🔹 Поиск по странице: .findNavigator(isPresented: $showSearch).
🔹 История посещений: page.backForwardList.items.


💡 Вывод:

Новый WebView это мощное решение для интеграции веб-контента в SwiftUI-приложения. Он предлагает современный API и полноценную функциональность.


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

🛡 Certificate Pinning на iOS: как защитить приложение от перехвата данных.

Друзья, привет! Сегодня разберем важную тему — защиту сетевых запросов с помощью certificate pinning. Это обязательная защита для любого приложения, которое работает с пользовательскими данными.


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

Основная цель — защита от атак «человек посередине» (Man-in-the-Middle). Злоумышленники могут перехватывать ваши запросы, тестировать уязвимости API и даже подменять данные. Проверить уязвимость просто: достаточно запустить Charles или Proxyman и посмотреть, проходит ли трафик вашего приложения через прокси.


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

При HTTPS-соединении сервер предъявляет цепочку сертификатов:

🔸 Корневой сертификат (доверенный, уже есть в системе).
🔸 Промежуточный сертификат.
🔸 Листовой сертификат (конечный, именно его мы будем «пиннить»).


💎 Что пиннить?

🔸 Весь сертификат (просто, но негибко).
🔸 Отпечаток (хеш) сертификата.
🔸 Публичный ключ (самый гибкий вариант).


♣️ Практическая реализация:

1️⃣ Достаем сертификат сервера:

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | awk '/-----BEGIN CERTIFICATE-----/{i++} i==1 {print}' > leaf.pem

2️⃣ Добавляем сертификат в проект как ресурс:

Например, в папку Certificates/example.com/leaf.der


3️⃣ Реализуем проверку в URLSessionDelegate:

func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge) async -> (URLSession.AuthChallengeDisposition, URLCredential?) {
  let host = challenge.protectionSpace.host
  let trustedCertificates = loadCertificates(for: host) // Ваш метод загрузки

  guard let serverTrust = challenge.protectionSpace.serverTrust,
        let serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0),
        trustedCertificates.contains(where: { SecCertificateEqual($0, serverCertificate) })
    else {
      return (.cancelAuthenticationChallenge, nil) // Блокируем соединение
    }

  return (.useCredential, URLCredential(trust: serverTrust))
}

❌ Основная проблема:

Сертификаты имеют срок действия (обычно 1 год). Когда вы его обновляете, приложение с пиннингом перестанет работать! Решения:

🔸 Пиннить публичный ключ (если он не меняется).
🔸 Удаленное обновление сертификатов через CloudKit или APNS.
🔸 Использовать несколько сертификатов «про запас».


✅ Советы:

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


💡 Вывод:

Certificate pinning — это must-have для безопасности приложения. Да, это добавляет сложности, но защита пользовательских данных того стоит.


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

👨‍💻 Жесткая правда об IT: почему айтишники выгорают быстрее всех.

Если вы до сих пор верите, что IT это только кожаные кресла, креатив и зарплаты как в Кремниевой долине, приготовьтесь к жесткому разочарованию. Реальность куда прозаичнее.

За последние годы я наблюдал всю эволюцию IT-карьеры — от восторженных новичков, мечтающих изменить мир, до выгоревших senior'ов, считающих минуты до дедлайна. И сейчас готов рассказать, почему IT это не мечта, а работа со своими правилами, подводными камнями и… возможностями.


1️⃣ «Программист только пишет код».

На самом деле, код это лишь 30% работы. Остальное:

🔹 Созвоны с заказчиками, которые сами не знают, чего хотят.
🔹 Разбор чужих багов и легаси-кода, который страшнее кошмара.
🔹 Чтение документации и бесконечные митинги.
🔹 Общение с ИИ (да, теперь и это часть работы!).


2️⃣ «В IT платят бешеные деньги».

Да, зарплаты выше среднего, но:

🔹 Junior'ы часто получают меньше офис-менеджера.
🔹 Зарплата senior'а в регионах ≈ 230к — это достойно, но не роскошно.
🔹 В аутсорсе клиент платит $50/час, а ты получаешь максимум $25, остальное идет на менеджмент, аренду и прибыль компании.


3️⃣ «Работа в крупной компании — предел мечтаний».

Мечтать о карьере в IT-гигантах — естественно. Но реальность крупных корпораций часто отличается от ожиданий:

🔹 Технологическая лотерея: вас могут перебросить с привычного стека на абсолютно чужую технологию без согласования. Сегодня вы пишете на Swift, завтра поддерживаете legacy-проект на Objective-C.
🔹 Винтик в системе: ваша индивидуальность и амбиции часто не имеют значения. Вы часть огромного механизма, где важнее процессы, чем люди.
🔹 Бессмысленный труд: можно годами работать над проектом, который внезапно закроют «по стратегическим причинам». Ваш код может никогда не увидеть пользователей.


💼 Карьера: рост или иллюзия?

Грейд junior/middle/senior часто зависят не от навыков, а от:

🔹 Политики компании (в продукте растут медленнее, в аутсорсе быстрее).
🔹 Умения продавать себя на собеседованиях.
🔹 Везучести.

Можно быть junior’ом с 3 годами опыта или senior’ом с 2. Все решает компания, а не объективные критерии.


❌ Фриланс: свобода или ловушка?

Мечтать о работе «на себя» естественно, но фриланс в IT это:

🔹 Быть одновременно разработчиком, менеджером и продажником.
🔹 Тратить до 70% времени на поиск клиентов и переговоры.
🔹 Конфликт ролей: то, что вы продали, потом придется делать самим.

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


⚠️ Так что же делать? Как выжить в IT?

🔹 Принять реальность: IT не рай, а работа с плюсами и минусами. Как и любая другая.
🔹 Прокачивать софт-скиллы: умение договариваться, объяснять и продавать идеи важнее знания фреймворков.
🔹 Следить за здоровьем: спорт не опция, а необходимость. Сидячий образ жизни убивает быстрее дедлайнов.
🔹 Не гнаться за грейдом: senior в одной компании ≠ senior в другой. Цените знания, а не звания.
🔹 Рассматривать смежные области: devOps, data engineering, AI.. Там, где больше денег и меньше конкуренции.


💡 Вывод:

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


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

🔢 Swift 6.2 вышел: интересные фичи для практической разработки.

Swift 6.2 — самое значимое обновление языка за последние годы. Рассказываю о самых интересных изменениях и как это повлияет на вашу ежедневную разработку.


🚀 Concurrency: теперь проще и безопаснее.

Главное изменение: больше не нужно постоянно ставить @MainActor. Теперь можно включить режим, где весь код по умолчанию работает на главном потоке:

// Раньше:
@MainActor
func updateUI() {
}

// Теперь:
func updateUI() {
  // Автоматически на главном потоке
}

Для тяжелых задач появился @concurrent:

@concurrent
func processImage(_ image: UIImage) async -> UIImage {
  // Выполняется в фоне, не блокируя интерфейс
  return applyFilters(image)
}

🔒 Безопасность памяти на максимум.

Новые типы для системного программирования:

🔹 InlineArray — массив фиксированного размера в стеке:

struct GameLevel {
  var enemies: [100 of Enemy] // Фиксированный размер
}

🔹 Span — безопасный срез данных:

let data = [1, 2, 3, 4, 5]
let slice = Span(data, start: 1, count: 3) // [2, 3, 4]

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


⚡️ Улучшения для разработки.

🔹 VS Code теперь официально поддерживается:

🔸 Фоновая индексация.
🔸 Встроенный отладчик LLDB.
🔸 Live-превью документации.

🔹 Быстрая сборка макросов: время clean build уменьшилось в разы.

🔹 Умные предупреждения: можно тонко настраивать:

.target(
  name: "MyApp",
  swiftSettings: [
    .treatAllWarnings(as: .error),
    .treatWarning("Deprecated", as: .warning)
  ]
)

✅ Testing 2.0

🔹 Тестирование крашей:

@Test func appCrashesOnInvalidInput() {
  #expect(exitCode: .failure, when: app.processInvalidInput())
}

🔹 Вложения в тестах: добавляйте логи, скриншоты, данные:

@Test func userLogin() {
  attach(loginRequestData, name: "Request")
  attach(screenshot(), name: "UI State")
}

🌐 Поддержка WebAssembly.

Теперь можно компилировать Swift в Wasm и запускать в браузере:

swift build --target wasm32-unknown-wasip1

🔗 Остальные изменения


💡 Вывод:

Swift 6.2 — это фундаментальный шаг в развитии языка, делающий его безопаснее, быстрее и удобнее для разработчиков.


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

🌐 Wasm и Swift: мост между нативными и веб-приложениями.

Если вы еще не слышали о WebAssembly (Wasm) — это технология, позволяющая запускать код на любых платформах: в браузере, на сервере, в мобильных приложениях. Think of it as universal bytecode для веба и не только.


🤔 Зачем Wasm Swift-разработчику?

🔸 Кроссплатформенность: один код для iOS, Android, Web и серверов.
🔸 Производительность: скорость выполнения, близкая к нативному коду.
🔸 Безопасность: песочница и изоляция по умолчанию.
🔸 Интероперабельность: работа с JavaScript, C++, Rust.

Как и писал ранее про добавление поддержки Wasm в Swift 6.2 — за лето, с момента анонса, экосистема сделала огромный рывок.


⚙️ Embedded Concurrency:

Работает в двух средах:

# CLI-приложения
swift run --target wasm32-unknown-wasip1

# Браузер через JavaScriptKit
import JavaScriptEventLoop // Для асинхронности в браузере

🗃 CI и пакеты:

Автосборка для основных пакетов Swift:

🔸 swift-algorithms
🔸 swift-collections
🔸 swift-nio
🔸 swift-foundation (теперь входит в SDK)


✅ Вот что уже работает сегодня:

🔹 Сборка комплексных проектов:

swift build --target wasm32-unknown-wasip1

🔹 Использование Foundation (кроме Embedded Swift):

import Foundation
// Работает с URLSession, JSONDecoder и т.д.

🔹 Интеграция с JavaScript:

// Через JavaScriptKit
let result = JSObject.global.document.createElement("div")

❌ Что еще в работе:

🔸 Полная поддержка Embedded Swift Concurrency.
🔸 WASI Preview 2 (wasip2).
🔸 Стабилизация Foundation для Embedded.


💡 Вывод:

Wasm в Swift переходит из стадии эксперимента в production-ready. Уже сейчас можно собирать реальные проекты — от CLI-утилит до браузерных приложений. Главное преимущество — единая кодобаза для разных платформ.


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

👨‍💻 iOS 26: почему нативная разработка становится must-have.

С выходом iOS 26 разрыв между нативными и кроссплатформенными решениями стал очевиден как никогда. Новый дизайн Liquid Glass, Apple Intelligence и интерактивные виджеты работают на полную мощность только в нативных приложениях. Flutter и другие кросс-платформенные фреймворки сталкиваются с растущими ограничениями: от задержек в поддержке новых функций до сложностей с интеграцией системных возможностей.


⚠️ Ключевые преимущества натива в iOS 26:

1️⃣ Полная интеграция с системой:

// Liquid Glass работает из коробки
struct ContentView: View {
  var body: some View {
    Text("Hello iOS 26!")
      .glassBackgroundEffect() // Нативный эффект
  }
}

2️⃣ Мгновенный доступ к новым API:

🔹 Apple Intelligence.
🔹 Интерактивные виджеты.
🔹 Системные жесты и анимации.
🔹 On-device AI через Core ML.


3️⃣ Высокая производительность:

Нативные приложения работают на 20-30% быстрее Flutter-аналогов благодаря прямому доступу к системным ресурсам.


❌ Ограничения кроссплатформенных решений:

🔸 Задержки обновлений: поддержка новых функций iOS появляется с опозданием на 6-12 месяцев.
🔸 Костыли и обертки: для интеграции с системными API требуются мосты и плагины.
🔸 Визуальные компромиссы: Liquid Glass и кастомные анимации сложно реализовать.
🔸 Рост техдолга: поддержка двух платформ усложняет архитектуру.


✅ Альтернатива — Kotlin Multiplatform, но с нюансами.

Kotlin Multiplatform (KMP) может быть компромиссом для проектов, где критична экономия без полной потери качества:

🔹 Общая бизнес-логика на Kotlin.
🔹 Нативные UI на SwiftUI и Jetpack Compose.
🔹 Снижение затрат на 20-40% без ущерба UX.

НО: даже KMP не даёт 100% преимуществ чистой нативной разработки:

🔸 Задержки с поддержкой новых API iOS: Swift-экосистема обновляется быстрее, чем KMP-компоненты.
🔸 Сложность отладки: бизнес-логика в KMP + нативный UI = два слоя для диагностики проблем.
🔸 Зависимость от JetBrains и Google: в отличие от нативного Swift, который полностью контролируется Apple.
🔸 Ограниченный доступ к iOS-специфичным функциям: особенно в первые месяцы после релиза новой iOS.


💡 Вывод:

iOS 26 сделала нативную разработку не просто выбором, а необходимостью для продуктов, которые хотят оставаться конкурентоспособными. Хотя Flutter остается вариантом для MVP, для долгосрочных проектов с высокими требованиями к UX и производительности нативный стек — самое верное решение.


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

🔨 iOS 26: как отключить Liquid Glass в iOS-приложениях.

С выходом iOS 26 многие разработчики столкнулись с необходимостью адаптации под новый дизайн-систему Liquid Glass. Но что делать, если приложение ещё не готово к переходу? Рассказываю простое решение.


⚙️ Отключение Liquid Glass:

Добавьте в ваш Info.plist параметр UIDesignRequiresCompatibility со значением YES.

Это заставит приложение использовать старую дизайн-систему вместо Liquid Glass, даже на iOS 26.


⚠️ Важные ограничения:

🔸 Это временное решение, Apple планирует убрать эту опцию в iOS 27.
🔸 Не влияет на новые API, только на визуальное оформление.
🔸 Тестирование обязательно, некоторые элементы могут выглядеть иначе.


💡 Вывод:

Временное отключение Liquid Glass — это спасательный круг для приложений, которые не успели адаптироваться к iOS 26, но не стоит воспринимать это как постоянное решение. Начинайте работу над поддержкой новой дизайн-системы, которая уже стала основной.


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

🔢 Generics и Protocols: пишем код на Swift профессионально.

Если вы пишете на Swift, но не используете Generics и Protocols на полную, то вы теряете главные преимущества языка. Эти инструменты превращают код из простого набора инструкций в гибкую и безопасную систему.


1️⃣ Generics: пишем код один раз, используем везде.

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

Простой пример:

func swapValues<T>(_ a: inout T, _ b: inout T) {
  let temp = a
  a = b
  b = temp
}

var x = 10
var y = 20
swapValues(&x, &y) // Работает с Int

var s1 = "Hello"
var s2 = "World" 
swapValues(&s1, &s2) // Работает с String

Ограничения generic-ов:

// Проблема: нельзя складывать любой тип данных
func sum<T>(_ a: T, _ b: T) -> T {
  return a + b // Ошибка: Binary operator '+' cannot be applied
}

// Решение: сообщаем компилятору что T должен быть числом
func sum<T: Numeric>(_ a: T, _ b: T) -> T {
  return a + b // Работает с любыми числами
}

Пример с протоколом:

protocol Identifiable {
  var id: Int { get }
}

struct User: Identifiable {
  let id: Int
  let name: String
}

class DataService<T: Identifiable> {
  private var storage: [Int: T] = [:]

  func save(_ item: T) {
    storage[item.id] = item
  }
}

Использование where для сложных ограничений:

func process<T>(_ value: T) where T: Identifiable, T: Equatable {
  // value имеет и id, и может сравниваться
}

2️⃣ Protocols: контракты для ваших типов.

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

Простой пример:

protocol Drawable {
  func draw()
}

struct Circle: Drawable {
  func draw() {
    print("Рисуем круг")
  }
}

struct Square: Drawable {
  func draw() {
    print("Рисуем квадрат")
  }
}

let shapes: [Drawable] = [Circle(), Square()]
shapes.forEach { $0.draw() }

Расширения протоколов:

extension Drawable {
  // Теперь можно использовать реализацию по умолчанию
  func draw() {
    print("Рисуем что-то")
  }
}

3️⃣ Associated Types: протоколы как дженерики.

Иногда нужно, чтобы протокол работал с разными типами данных, но мы заранее не знаем, с какими именно. Для этого используют associatedtype — это как заглушка для типа, которую заполнят при реализации.

Простой пример:

protocol Storage {
  associatedtype Item
  var items: [Item] { get set }
  func add(_ item: Item)
}

class StringStorage: Storage {
  typealias Item = String  // Задаем тип
  var items: [String] = []

  func add(_ item: String) {
    items.append(item)
  }
}

class IntStorage: Storage {
  var items: [Int] = []  // Компилятор сам определит тип

  func add(_ item: Int) {
    items.append(item)
  }
}

Пример с ограничениями:

protocol ComparableStorage {
  associatedtype Item: Comparable  // Только сравниваемые типы
  func isFirstItemGreater() -> Bool
}

class NumberStorage: ComparableStorage {
  var items: [Int] = [5, 2, 8]

  func isFirstItemGreater() -> Bool {
    return items[0] > items[1]  // Можем сравнивать
  }
}

Что дает associatedtype:

🔹 Гибкость: один протокол для разных типов.
🔹 Безопасность: компилятор следит за типами.
🔹 Четкость: ясно, какие данные ожидаются.

Главное: associatedtype делает протоколы по-настоящему универсальными, позволяя им работать с любыми типами данных, сохраняя при этом полную типобезопасность.


⚠️ Как начать использовать Generics и Protocols эффективно:

🔸 Найдите повторяющийся код: где вы копируете логику для разных типов.
🔸 Определите общее поведение: что общего у ваших объектов.
🔸 Выносите в протоколы: создайте контракты для похожих объектов.
🔸 Добавляйте generics: делайте код универсальным.


💡 Вывод:

Generics и Protocols это не просто синтаксис, а способ мышления. Они превращают Swift из просто языка в инструмент для создания надежных и масштабируемых систем.


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

👨‍💻 Что на самом деле мотивирует разработчика: три фактора, которые важнее зарплаты.

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


🔹 Люди, с которыми ты проводишь 8 часов в день.

Можно работать над самым прорывным продуктом в мире, но если команда разобщена, а атмосфера токсична, желание творить быстро испарится. Сильная команда это не просто набор талантливых инженеров. Это в первую очередь культура взаимопомощи, доверия и открытости. В такой среде не страшно задавать «глупые» вопросы, предлагать смелые идеи и признаваться в ошибках. Именно это позволяет быстро расти. Я бы предпочел присоединиться к сильной команде со средним продуктом, чем к хаотичной команде с гениальной идеей. Первая научит тебя большему и сбережет ментальное здоровье.


🔹 Руководитель как твой личный навигатор.

Руководитель это человек, который определяет твой повседневный опыт работы. Хороший менеджер не просто ставит задачи. Он видит твой потенциал, помогает строить карьерный путь, дает конструктивную обратную связь и, что немаловажно, прикрывает твой тыл от корпоративных бурь. Он превращает препятствия в задачи, которые можно решить. Для меня совпадение по ценностям и видению с будущим руководителем часто перевешивает дополнительные 20% к окладу. Потому что с плохим менеджером эти деньги будут стоить тебе слишком дорого, в виде стресса и выгорания.


🔹 Продукт, который зажигает, а не просто платит.

Даже в лучшей команде с идеальным менеджером может не хватить мотивации, если продукт сам по себе не вызывает интереса. Речь не только о «спасе мира». Важно, чтобы продукт был качественным, с продуманной архитектурой, а не вечным MVP, который постоянно горит. Когда ты видишь, что твоя работа имеет смысл, что ею пользуются и ценят, это дает совершенно иной уровень энергии. Работа над скучным, нестабильным или бессмысленным продуктом быстро приводит к цинизму и апатии, какую бы зарплату тебе ни платили.


💡 Вывод:

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

А что для вас было главным фактором на последнем месте работы? Делитесь в комментариях!


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

🔢 Swift Concurrency: правильное использование [weak self] в задачах.

Всем привет! Сегодня разберемся с темой, которая вызывает много вопросов при переходе на Swift Concurrency: как правильно использовать [weak self] в Task.

Если вы работали с completion handlers, то у вас уже выработался рефлекс, почти в каждое замыкание добавлять [weak self] и делать классический guard let self. Кажется логичным перенести этот подход и в Task:

Task { [weak self] in
  guard let self else { return }

  let data = await loadData()
  ...
}

Но вот в чем проблема: этот код не предотвращает утечку памяти так, как вы ожидаете.


⚠️ Почему это происходит:

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

Когда вы делаете guard let self, вы создаете сильную ссылку на объект. Теперь Task будет удерживать self до своего завершения, до окончания всех await вызовов. Это эквивалентно тому, если бы вы в старом коде с completion handlers написали просто self.loadData() без всякого [weak self].


🤔 Когда это действительно становится проблемой?

Представьте долгоиграющую задачу, например, загрузку данных постранично:

Task { [weak self] in
  guard let self else { return } // Проблема здесь

  var hasMorePages = true
  while hasMorePages {
    let page = await fetchNextPage()
    hasMorePages = !page.isLastPage
  }
}

Если пользователь уйдет с экрана, self не сможет освободиться, потому что Task продолжит свою работу и удерживает его до окончания цикла.


✅ Правильное решение:

Вместо немедленного разворачивания self, делайте это точечно, непосредственно перед использованием:

Task { [weak self] in
  var hasMorePages = true
  while hasMorePages {
    // Проверяем self на каждой итерации
    guard let self else {
      hasMorePages = false
      break
    }

    let page = await self.fetchNextPage()
    hasMorePages = !page.isLastPage
  }
}

Теперь сильная ссылка на self создается только на время одной итерации цикла. Если self освободится, цикл немедленно завершается.


⚡️ Рекомендации:

🔸 Не всегда нужно [weak self]: для коротких Task это часто избыточно.
🔸 Избегайте guard let self в начале Task: это не дает преимуществ, но может продлить жизнь объекта.
🔸 Разворачивайте self непосредственно перед использованием: минимизируйте время удержания сильной ссылки.
🔸 Рассмотрите захват конкретных свойств: если вам нужен не весь self, а только некоторые его свойства, захватите их отдельно.


💡 Вывод:

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


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

🔢 Что изменилось в работе со строками в Swift 6.2

Всем привет! Swift 6.2 принес нам небольшие, но очень приятные улучшения в работе со строками, которое многие давно ждали.


Какая была проблема?

До Swift 6.2 при интерполяции опциональных значений мы постоянно сталкивались с надоедливым ворнингом:

let age: Int? = nil

print("Your age: \(age)") 
//  String interpolation produces a debug description for an optional value

Компилятор предлагал два неидеальных решения:

🔸 String(describing:) - выводил nil, что некрасиво для пользователя.
🔸 Оператор ?? - требовал значение того же типа, что не всегда удобно.

let age: Int? = nil

// Некрасиво
Text("Your age: \(String(describing: age))") // Your age: nil

// Не всегда уместно
Text("Your age: \(age ?? 0)") // Your age: 0, но 0 может быть некорректным!

Что изменилось в Swift 6.2:

Теперь можно использовать параметр default прямо в интерполяции:

let age: Int? = nil

print("Your age: \(age, default: "not specified")") // Your age: not specified

Особенно удобно в SwiftUI:

struct ProfileView: View {
  let username: String?
  let level: Int?

  var body: some View {
    VStack {
      Text("Username: \(username, default: "Guest")")
      Text("Level: \(level, default: "Unknown")")
    }
  }
}

Что еще важно знать:

🔸 Тип значения не важен: default всегда принимает строку.
🔸 Работает с любыми опционалами: Int?, String?, Bool? и т.д.
🔸 Проверки на этапе компиляции: нет влияния на производительность.


Есть ограничение: к сожалению не работает с LocalizedStringKey.


💡 Мое мнение:

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


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

👨‍💻 Неожиданный тренд 2025 года: некоторые компании заменяют сеньоров на джунов.

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


Парадокс рынка труда.

Если посмотреть на статистику безработицы в США и Европе, становится ясно: молодым специалистам действительно сложно найти работу. Но причина не только в том, что ИИ забирает начинающие позиции. Оказалось, что искусственный интеллект в первую очередь бьет по… опытным разработчикам.


Почему опыт стал проблемой?

Сеньоры и мидлы это сформировавшиеся специалисты с устоявшимися подходами к работе. У них есть:

🔸 Четкое мнение об архитектуре проектов.
🔸 Привычный набор инструментов и технологий.
🔸 Собственные стандарты кодирования.

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


Гибкость vs опыт: что ценнее?

Некоторые компании пришли к выводу: лучше взять джуна, который:

🔸 Не боится экспериментировать с ИИ.
🔸 Готов быстро осваивать новые инструменты.
🔸 Не имеет предубеждений против «новомодных» технологий.
🔸 Обходится компании дешевле.

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


Рекомендации.

Если вы опытный разработчик:

🔹 Не игнорируйте ИИ-инструменты, осваивайте их постепенно.
🔹 Будьте готовы менять рабочие процессы, гибкость стала ключевым навыком.
🔹 Учитесь работать в тандеме с ИИ, а не против него.

Если вы джун:

🔹 Ваше умение быстро обучаться это главное преимущество.
🔹 Осваивайте ИИ-инструменты с самого начала карьеры.
🔹 Не бойтесь предлагать новые подходы, компании это ценят.


💡 Личное наблюдение:

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


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

🔢 Swift Concurrency: как Executors и Actors управляют потоками.

Разберем как на самом деле работают потоки в Swift Concurrency. Если вы думаете, что async/await — это просто синтаксический сахар, приготовьтесь удивляться. Под капотом скрывается мощная система управления задачами через Executors и Actors.


Из чего состоит Swift Concurrency:

🔸 Task: единица асинхронной работы (как поток для синхронных функций).
🔸 Job: часть задачи между точками await (suspension points).
🔸 Executor: планировщик, который распределяет Job по потокам.
🔸 Cooperative Thread Pool: пул потоков (число = числу ядер устройства).


Типы Executors:

🔸 Global Concurrent Executor: дефолтный, распределяет задачи по потокам из пула.
🔸 Serial Executors: для акторов, выполняет задачи последовательно.
🔸 Main Actor Executor: специальный для главного потока.


Пример кастомного Executor:

// Создаем свой планировщик
final class CustomExecutor: TaskExecutor {
  func enqueue(_ job: consuming ExecutorJob) {
    print("Запускаем задачу на потоке: \(Thread.current)")
    job.runSynchronously(on: asUnownedTaskExecutor())
  }

  func asUnownedTaskExecutor() -> UnownedTaskExecutor {
    UnownedTaskExecutor(ordinary: self)
  }
}

// Использование
Task(executorPreference: CustomExecutor()) {
  print("Выполняем работу")
  try await Task.sleep(for: .seconds(1))
  print("Завершаем работу")
}

Actors: безопасность данных.

Акторы защищают от гонки данных, выполняя методы последовательно:

actor SafeCounter {
  private var count = 0

  func increment() {
    count += 1
    print("Текущее значение: \(count)")
  }
}

// Использование
let counter = SafeCounter()

Task {
  await counter.increment() // Безопасный доступ
}

Как работает последовательность.

Даже при параллельных вызовах актор гарантирует порядок:

await withTaskGroup { group in
  for i in 0..<5 {
    group.addTask { await counter.increment() }
  }
}
// Вывод всегда будет: 1, 2, 3, 4, 5

Global Actors.

@MainActor вы уже знаете, но можно создавать и свои глобальные акторы:

@globalActor
actor NetworkActor {
  static let shared = NetworkActor() // Единый экземпляр на все приложение
}

@NetworkActor
func fetchData() async -> Data {
  // Все вызовы этого метода будут последовательными
  // даже из разных частей приложения!
}

@NetworkActor 
class ApiService {
  // Все методы класса будут автоматически изолированы
  func getUser() async -> User {
  }
}

Зачем это нужно, спросите вы. Чтобы разные функции и классы использовали один общий актор. Например:

🔸 Все сетевые запросы через один NetworkActor
🔸 Все операции с базой данных через DatabaseActor
🔸 Все аналитические события через AnalyticsActor


Важные особенности:

🔸 Потоки не блокируются: await освобождает поток для других задач.
🔸 Автоматическое планирование: система сама выбирает оптимальный поток.
🔸 Безопасность по умолчанию: компилятор следит за изоляцией данных.


Когда использовать:

🔹 Global Concurrent: для независимых задач.
🔹 Serial Executor: когда важен порядок выполнения.
🔹 Main Actor: для работы с UI.
🔹 Custom Executors: для специальных требований к планированию.


💡 Вывод:

Swift Concurrency это не просто async/await, а целая экосистема для безопасной многопоточности. Понимание работы Executors и Actors поможет писать более эффективный и надежный код.


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

📱 Революция в Apple: почему iOS переписывают на Rust.

Всем привет! Пока мы спорим о SwiftUI и async/await, в компании Apple происходит тихая революция. Оказывается, компания постепенно переписывает ключевые компоненты iOS и делает это не на Swift. Все указывает на Rust - язык, который становится новым фундаментом операционной системы.


Что происходит на самом деле?

Если посмотреть на вакансии Apple за последние годы, становится ясно: компания активно ищет инженеров с опытом работы с Rust. Речь идет о системных компонентах:

🔹 Управление памятью.
🔹 Безопасность и криптография.
🔹 Низкоуровневые фреймворки.
🔹 Драйверы и ядро системы.


Почему Swift не подходит для этих задач?

Swift - прекрасный язык для разработки приложений, но у него есть ограничения:

🔹 Не идеален для системного программирования.
🔹 Работа с памятью через C/Obj-C оставляет уязвимости.
🔹 Модель многопоточности уступает Rust в безопасности.


Преимущества Rust для Apple:

🔹 Безопасность памяти: компилятор предотвращает целый класс уязвимостей.
🔹 Производительность: сравнима с C++, но без головной боли.
🔹 Бесстрашная многопоточность: гонки данных обнаруживаются на этапе компиляции.
🔹 Интероперабельность: легко интегрируется с существующим C-кодом.


Что это значит для нас, разработчиков?

В краткосрочной перспективе ничего не изменится:

🔹 SwiftUI и UIKit остаются основными фреймворками.
🔹 Swift продолжит развиваться.
🔹 API для приложений не поменяются.

Но в долгосрочной перспективе:

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


💡 Мое мнение:

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


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

📱 Правда о вайбкодинге: почему быстрые решения убивают ваш профессиональный рост.

Всем привет! Сегодня хочу поговорить об опасной тенденции, которая захватила мир разработки - vibe coding. Это когда ты быстро переключаешься между вкладками, копируешь код из ChatGPT, видишь, что все компилируется, и чувствуешь себя продуктивным. Но на самом деле ты не понимаешь, что происходит.


Что не так с вайбкодингом?

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


Типичная ситуация:

Разработчик за вечер создал несколько приложений с помощью ChatGPT. В одном была сложная логика расчетов. Код работал идеально, но разработчик не мог объяснить, как он работает. Это как собрать мебель по инструкции, не понимая, зачем нужны детали.


Почему это опасно для карьеры:

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


Что важнее: скорость или понимание?

ИИ-инструменты это мощные помощники. Но когда они заменяют ваше мышление, любопытство и желание разбираться - вы перестаете расти.

Настоящий прогресс приходит через:

🔸 Борьбу с сложными ошибками.
🔸 Понимание КАК и ПОЧЕМУ что-то работает.
🔸 Глубокое погружение в проблему.


Правила осознанного использования ИИ:

Джуны, которые осмысленно работают с ИИ, растут быстрее, чем мидлы, просто копирующие код. Разница в подходе: первые используют ИИ как инструмент, вторые как костыль.

🔸 Используйте ChatGPT для рутины и изучения новых подходов.
🔸 Всегда анализируйте сгенерированный код перед использованием.
🔸 Задавайте вопросы «почему это работает?» и «как можно улучшить?».
🔸 Сохраняйте баланс между скоростью и качеством.


💡 Вывод:

Vibe coding хорош для прототипов и MVP, но только при очень вдумчивом использовании. Если вы не понимаете код, который пишете, вы не можете ему доверять. А если не можете доверять, то не можете нести за него ответственность.


А как вы используете ИИ в работе?


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