Новый тип в стандартной библиотеке Swift — Vector

Swift добавляет Vector, новый тип в стандартной библиотеке, который представляет собой массив фиксированного размера. Это альтернатива классическим C-массивам: T[N], std::array<T, N> в C++ и [T; N] в Rust.

Почему это важно?

Обычные массивы — это динамические структуры данных, которые выделяются на heap и могут быть излишне затратными для небольших массивов фиксированного размера. Vector, напротив, хранит элементы на stack или inline, что обеспечивает высокую производительность и минимизацию накладных расходов.

Основные преимущества Vector:

- Фиксированный размер: размер массива задаётся при создании.

- Высокая производительность: нет динамического выделения памяти.

- Безопасность: инлайн-инициализация элементов с возможностью индексации и итерации.

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

let numbers: Vector<4, Int> = [1, 2, 3, 4]

for i in numbers.indices {
    print(numbers[i])
}

Vector будет полезен, когда нужен массив фиксированного размера без накладных расходов динамической памяти. Будущий кандидат для собеседований? - Абсолютно. Будет ли применяться на практике? - Поживём, увидем.

Официальный обзор и примеры можно найти в предложении SE-0453.

Pets vs. Cattle — Почему 99% твоего кода отправят в утиль (и это нормально)

Вы когда-нибудь задумывались, сколько нашего кода реально используется в проде через год-другой?

Что если, значительная часть работы делается в стол? Значит ли это, что происходит бесполезная работа?

💡 "Pets vs. Cattle" — концепция из DevOps, которая применима и к разработке.

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

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

🔹 Большинство разработчиков относятся к своему коду как к питомцу: холят, лелеют, бесконечно рефакторят.
🔹 А бизнесу нужны "коровы", которые дают результат здесь и сейчас.

Что если мы можем принять тот факт, что 99% кода не переживет следующий бизнес-цикл. И это нормально. Настоящий профессионал не хранит код, а учится эффективно управлять "фермой". Чтобы разобраться в этом вопросе, можно почитать статью у Вастрика, а своим мнением поделиться в чате.

Для кого актуально установить Сбер на свой iPhone, то вот оффициальный способ сделать это легко и просто.

https://www.sberbank.com/ru/person/dist_services/inner_sbol/verni_sber?chips=macos#steps

Swift 6.1 и новинки в многопоточности

Swift 6.1 (beta) привносит важные изменения для работы с асинхронностью и акторами. Если ты следишь за эволюцией concurrency в Swift, вот что стоит знать:

[Изолированный deinit (будет в будущем)]

Разработчики давно ждали, чтобы deinit мог быть привязан к актору. В будущем можно будет явно указывать isolated deinit, например, для @MainActor классов. Это упростит управление памятью, но принесёт небольшие накладные расходы.
---

[Расширенное использование nonisolated]

Теперь nonisolated можно указывать сразу на всём расширении, а не на каждом методе. Это избавляет от дублирования, особенно при реализации протоколов в @MainActor классах.

💡 Было:

extension MainActorType: NotIsolated {
    nonisolated func doStuff() {}
    nonisolated func doThings() {}
}

💡 Стало:

nonisolated extension MainActorType: NotIsolated {
    func doStuff() {}
    func doThings() {}
}

Меньше кода — больше удобства.

---

[Автоматический вывод типа в TaskGroup]

Раньше в withTaskGroup приходилось вручную указывать тип результатов. Теперь компилятор умеет автоматически определять тип из контекста.

💡 Было:

let messages = await withTaskGroup(of: Message.self) { group in
    // ...
}

💡 Стало:

let messages = await withTaskGroup { group in
    // Swift сам понимает, что тут Message!
}

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

Подробный разбор всех нововведений — читай тут.

#обучение

Сейчас наполняю главу для изучения замыканий, думаю, что лучше этих двух видео и не найти даже:

1. https://www.youtube.com/watch?v=WeT1U9YiFAg
2. https://www.youtube.com/watch?v=410NFC0DYiM

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

А вот capture list, delayed deallocation, autoclosure, проблема @escaping замыканий со SwiftUI, работа с ARC и вложенные замыкания + ARC — это уже на грейды повыше. Всё это можно найти и в ноушене, например вот здесь:

1. Capture list
2. Delayed deallocation
3. Autoclosures
4. Почему не стоит использовать escaping замыкание в SwiftUI
5. Escaping
6. Вложенные замыкания и ARC

#работа #шабашка

Всем привет, наш добрый друг — эйчар Семён поделился таким интересным графиком: https://public.tableau.com/app/profile/alkadarskiy.selim/viz/2021_16595984868110/232020

Актуально и сейчас. Как работать? Откликаться на вакансию либо ДО массовой активности других соискателей либо ПОСЛЕ чтобы ваш отклик был выше.

#полезное #swiftui #observable

lazy var в @Observable – почему не работает? 🤔

Если ты попробуешь использовать lazy var в @Observable классе, то наткнёшься на ошибку:

@Observable class MyClass {
    private(set) lazy var something = "" // ❌ 'lazy' cannot be used on a computed property
}

Но почему так?

Ключевая проблема – @Observable автоматически создаёт "синтезированные" свойства для отслеживания изменений. lazy var же инициализируется при первом доступе, а это конфликтует с механизмом синтеза.

Если добавить к нему макрос @ObservationIgnored, то система наблюдения будет игнорировать синтез для этого свойства.

@Observable class MyClass {
    @ObservationIgnored
    private(set) lazy var something = "" // 💚 Все ок, теперь можно!
}

#полезное #поиск_работы #линкедин

1. Создать ЛинкедИн;
2. Оформить профиль (можно как у меня, можно как у других людей с оформленным профилем);
3. Еженедельно расходуйте весь максимум на добавление контактов (100-150 шт). Добавляйте инфлюенсеров и рекрутеров и людей с большим количеством контактов - это поможет в будущем при посте: "я в поиске работы"/"я уволился" и т.п.;
4. Попросите знакомых заапрувить навыки на Линке;
5. Комментируйте рандомные посты, поздравляйте с днём бетона всех у кого день бетона, желайте удачи, ставьте лайки, пишите посты и повторюсь "расширяйте сеть контактов" — это гаранты вашего высокого SSI рейтинга. Чем выше эта залупа, тем вы "круче";
→ Ссылка для проверки SSI метрики на LinkedIn
6. Лайфхак: смешной мем в посте добавляет охватов больше, чем полезный "высер" + люди будут хихикать и потом мб вам придут и дадут ваку за хороший смех;
7. Делать всё нужно регулярно↑;
8. После 1000+ контактов можно забить хуй, но не рекомендую))))
9. Плашечка опенТуВорк: честно, холивар на ровном месте. Хотите ставьте, хотите нет);
10. Если вы в поиске работы — укажите ваш тг везде: в шапке, в заголовке, в "о себе", в контактах;
11. Можно заебаться и настроить авто-аутрич, когда к вам в контакт добавляется, чтобы от вас прилетало сообщение: салам аллейкум, одна тут? *Я такое не делал, так что не подскажу*;
12. Как искать ваки: в постах рекрутеров, через булевые запросы в поисковой строке линка, по хештегам, писать в лс рекрутерам и "привет рОдная, есть чем поживиться для пажилого?"

=КрАтЕньКо=

P.S. Я договорился с Семёном и будет гайд для небазовых, где он подробном и четко все сделат, в основном канале сегодня - завтра отпишу.

Indie-разработка жива: $35K за 30 дней

На Reddit всплыл классный пост от разработчика, который в одиночку сделал $35K за последний месяц с iOS-приложением. Без команды, без инвестиций — просто стабильная indie-работа и правильный подход к монетизации.

Из интересного:

- Приложение — “AI Chat”, но не просто обёртка для ChatGPT. Там и оффлайн-модели, и быстрые ответы, и проработанный UX.
- Очень грамотно сделана монетизация — подписка через IAP, пробный период, и чёткое УТП.
- Основной трафик — органика и App Store SEO.

Потратил 3 месяца на MVP.
Сейчас работает над улучшением ретеншна и платящих пользователей.
Делает всё сам: код, UI, маркетинг, support.

Читай полный пост: [ссылка на статью]

A Day in the Life of a SwiftUI View

Chris Eidhof раскрывает mental model SwiftUI, показыя, как наш код превращается в ephemeral view tree и в персистентный render tree — AttributeGraph. Chris подробно объясняет, как @State интегрируется в граф, оптимизирует layout и что происходит при каждом вызове body.

https://www.youtube.com/watch?v=MRY3UCUVv98
https://www.youtube.com/watch?v=MRY3UCUVv98
https://www.youtube.com/watch?v=MRY3UCUVv98

> Текстовая версия доклада
> Похожая статейка в ноушен
> Подробно про AttributeGraph в ноушен

#weak_let #swift #concurrency

Раньше weak можно было только с var, и из-за этого классы и замыкания с такими ссылками не были Sendable, но с принятием этого проползола можно будет объявлять слабые ссылки с let, а не только с var.

Зачем это нужно?
- Убирает лишнюю мутируемость, weak let не мешает проверкам на безопасность в конкурентных контекстах.
- Закрывает брешь в sendability: классы и @Sendable-замыкания с weak let становятся полностью безопасными.

Про мотивацию
1. weak var считался мутируемым, потому что при деинициализации объекта ссылка сбрасывалась в nil.
2. На самом деле это не "мутация" значения, а просто особенность weak ref.
3. Теперь weak let отражает именно эту логику – неизменяемая слабая ссылка, которая по-прежнему может стать nil.

Прочитать подробнее и посмотреть можно здесь: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0481-weak-let.md

final class ContentViewModel: ObservableObject {
    @Published var text = "Hello @StateObject"
    
    init() {
        print("ViewModel init")
    }
    
    deinit {
        print("ViewModel deinit")
    }
}

struct ContentView: View {
    @StateObject private var viewModel: ContentViewModel
    
    init(viewModel: ContentViewModel) {
        _viewModel = StateObject(wrappedValue: viewModel)
        
        print("ContentView init")
    }
    
    var body: some View {
        Text(viewModel.text)
    }
}

struct RootView: View {
    @State private var isOn = false
    
    var body: some View {
        VStack(spacing: 20) {
            ContentView(viewModel: ContentViewModel())
            
            if isOn { Text("is on") }
            
            Button("Trigger") { isOn.toggle() }
        }
    }
}

Есть ли у этого кода проблема связанная с объявлением StateObject? Опрос ниже