❓ Что такое дженерики

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

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

Именно здесь вы можете использовать дженерики.

Например, вы можете создать общий тип для параметров (для представления любого типа), используя букву, например T, следующим образом:

struct Vec3D<T> {
    let x, y, z: T
    init(x: T, y: T, z: T) {
        self.x = x
        self.y = y
        self.z = z
    }
}
let intVector = Vec3D(x: 1, y: 2, z: 5)
let floatVector = Vec3D(x: 1.0, y: 2.0, z: 5.0)

🐸 Библиотека мобильного разработчика

#буст #JuniorKit #Swift

🐸 Библиотека мобильного разработчика

#КодКрашТест #MiddlePath #Swift

🐸 Библиотека мобильного разработчика

#междусобойчик #JuniorKit #Swift

❓ Предложите небольшую доработку для следующего кода

if age >= 18 {
    driveCar()
} else {
    doNotDrive()
}

Этот код хорошо работает - но можете ли вы предложить небольшое улучшение рефакторинга, чтобы сделать его еще лучше?

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

age >= 18 ? driveCar() : doNotDrive()

🐸 Библиотека мобильного разработчика

#буст #JuniorKit #Swift

🎮 «Чистая» структура View-компонентов в SwiftUI

В проектах на SwiftUI тело View может быстро разрастись: десятки вложенных VStack/HStack, логика отображения, стили — всё в одном месте.

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

1️⃣ Извлечение отдельных View

Если часть интерфейса имеет собственное назначение — вынеси её в отдельный struct-View:

struct ArticleRow: View {
    let article: Article
    var body: some View {
        HStack { … }
    }
}

Затем:

ForEach(articles, id: \.url) { article in
    ArticleRow(article: article)
}

Это делает главный View более “обзорным” и облегчает повторное использование.


2️⃣ Использование ViewModifiers для стилей

Когда видишь дублирования стилей, вынеси их:

struct CardStyle: ViewModifier {
    func body(content: Content) -> some View {
        content
            .padding()
            .background(Color(.secondarySystemBackground))
            .cornerRadius(8)
    }
}
extension View {
    func cardStyle() -> some View {
        modifier(CardStyle())
    }
}

Теперь:

ArticleRow(article: article)
    .cardStyle()

Так ты централизуешь “язык дизайна” и можешь менять стиль в одном месте.

3️⃣ Создание универсальных расширений для просмотра

Если повторяются шаблоны (например, “заголовок секции”), можно сделать расширение:

extension View {
    func sectionHeader(_ title: String) -> some View {
        VStack(alignment: .leading, spacing: 4) {
            Text(title)
                .font(.title3)
                .bold()
            self
        }
    }
}

Пример:

VStack {
    ForEach(articles, id: \.url) { article in
        ArticleRow(article: article)
    }
}
.sectionHeader("Articles")

Такие расширения уменьшают вложенность и делают код декларативнее.

📌 Практическое руководство по созданию хорошей архитектуры SwiftUI

Если вы не уверены, стоит ли что-то извлекать, спросите:

Есть ли у этого элемента пользовательского интерфейса чёткое назначение и возможность повторного использования?

🔘 Если да → создайте новый View или ViewModifier.

🔘 Если нет → оставьте его локальным или используйте вычисляемое свойство.

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

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #SeniorView #Swift

❓ Что такое полиморфизм

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

class Person{
    var name: String
    var age: Int
            
    init(name: String, age: Int){
        self.name = name
        self.age = age
    }
    func display(){
        print("Имя: \(name)  Возраст: \(age)")
    }
}
        
class Employee : Person{
    var company: String
    init(name: String, age: Int, company: String) {
        self.company = company
        super.init(name:name, age: age)
    }
    override func display(){
        print("Имя: \(name)  Возраст: \(age)  Сотрудник компании: \(company)")
    }
}
        
class Manager : Employee{    
    override func display(){
        print("Имя: \(name)  Возраст: \(age)  Менеджер компании: \(company)")
    }
}

В данном случае класс Manager (менеджер компании) наследуется от класса Employee (сотрудник компании), а класс Employee - от класса Person (человек). Тем самым класс Manager ненапрямую тоже наследуется от Person.

Поскольку и сотрудник компании и менеджер компании в то же время являются людьми, то есть объектами класса Person, то мы можем написать следующим образом:

let tom: Person = Person(name:"Tom", age: 23)
let bob: Person = Employee(name: "Bob", age: 28, company: "Apple")
let alice: Person = Manager(name: "Alice", age: 31, company: "Microsoft")

Все три константы представляют тип Person, однако первая хранит ссылку на объект Person, вторая - на объект Employee, а третья - на объект Manager. Таким образом, переменная или константа одного типа может принимать многообразные формы в зависимости от конкретного объекта, на который она указывает.

Но что будет, если мы вызовем метод display() для всех трех объектов:

let tom: Person = Person(name:"Tom", age: 23)
let bob: Person = Employee(name: "Bob", age: 28, company: "Apple")
let alice: Person = Manager(name: "Alice", age: 31, company: "Microsoft")
        
tom.display()       // Имя: Tom  Возраст: 23
bob.display()       // Имя: Bob  Возраст: 28  Сотрудник компании: Apple
alice.display()     // Имя: Alice  Возраст: 31  Менеджер компании: Microsoft

Несмотря на то, что все три константы представляют тип Person, при вызове метода display будет вызываться реализация метода именно того класса, ссылку на объект которого хранит константа. Данный примем называется динамической диспетчеризацией - во время выполнения программы на основании типа объекта система решает, какую именно реализацию метода вызывать.

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

🐸 Библиотека мобильного разработчика

#буст #JuniorKit #Swift

🔍 Архитектура Clean Swift

В Clean Swift приложение состоит из сцен, т.е. каждый экран приложения — это одна сцена. Основное взаимодействие в сцене идет через последовательный цикл между компонентами ViewController -> Interactor -> Presenter. Это называется VIP цикл.

Мостом между компонентами выступает файл Models, который хранит в себе передаваемые данные. Так же есть Router, отвечающий за переход и передачу данных между сценами, и Worker, который берет часть логики Interactor’a на себя.

🔹 View

Storyboard’ы, XIB’ы или UI элементы, написанные через код.

🔹 ViewController

Отвечает только за конфигурацию и взаимодействие с View. В контроллере не должно находиться никакой бизнес логики, взаимодействия с сетью, вычислений и так далее.
Его задача обрабатывать события с View, отображать или отправлять данные (без обработки и проверок) в Interactor.

🔹 Interactor

Содержит в себе бизнес логику сцены.

Он работает с сетью, базой данных и модулями устройства.

Interactor получает запрос из ViewController’a (с данными или пустой), обрабатывает его и, если это требуется, передает новые данные в Presenter.

🔹 Presenter

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

Как пример, добавить маску на номер телефона или сделать первую букву в названии заглавной.
Обрабатывает данные, получение из Interactor’a, после чего отправляет их обратно во ViewController.

🔹 Models

Набор структур для передачи данных между компонентами VIP цикла. Каждый круг цикла имеет в себе 3 вида структур:

🔘 Request — Структура с данными (текст из TextField и т.д.) для передачи из ViewController'a в Interactor
🔘 Response — Структура с данными (загруженными из сети и т.д.) для передачи из Interactor в Presenter
🔘 ViewModel — Структура с обработанными данными (форматирование текста и т.д.) в Presenter’e для передачи обратно во ViewController

🔹 Worker

Разгружает Interactor, забирая на себя часть бизнес логики приложения, если Interactor стремительно разрастается.

Так же можно создавать общие для всех сцен Worker’ы, если их функционал используется в нескольких сценах.

Как пример, в Worker можно выносить логику работы с сетью или базой данных.

🔹 Router

В Router выносится вся логика, отвечающая за переходы и передачу данных между сценами.

____________________

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

1. Пользователь ввел свой логин и пароль, нажал на кнопку авторизации

2. У ViewController срабатывает IBAction, после чего создается структура с введенными, в TextField’ы, данными пользователя (Models -> Request)

3. Созданная структура передается в метод fetchUser в Interactor’e

4. Interactor отправляет запрос в сеть и получает ответ об успешности авторизации

5. На основе полученных данных, создает структуру с результатом (Models -> Response) и передается в метод presentUser в Presenter’e

6. Presenter форматирует данные по необходимости и возвращает их (Models -> ViewModel) в метод displayUser в ViewController’e

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

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

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #SeniorView #Swift

🐸 Библиотека мобильного разработчика

#КодКрашТест #JuniorKit #Swift

⚙️ Превращение меню SwiftUI в мини-панель настроек

Меню в SwiftUI часто используются для быстрых одноразовых команд: выберите пункт, выполните действие — и всё готово. Но что, если вы хотите, чтобы меню функционировало не как простой селектор, а как мини-панель настроек, где пользователи могут последовательно переключать несколько пунктов, прежде чем сделать окончательный выбор? По умолчанию меню закрывается, как только пользователь нажимает на пункт, но с помощью подходящего API это поведение можно изменить.

➖ Переосмысление меню

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

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

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

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

➖ Настройка поведения закрытия

SwiftUI расширяет меню с помощью модификатора menuActionDismissBehavior(_:). Это даёт вам возможность точно контролировать, должно ли касание внутри меню приводить к его закрытию или оставаться открытым.

Модификатор принимает один параметр типа MenuActionDismissBehavior, который представляет собой перечисление, определяемое примерно следующим образом:

public enum MenuActionDismissBehavior {
    case automatic   // system-default behaviour
    case enabled     // explicitly force dismissal on each tap
    case disabled    // keep the menu open after taps
}

Применение модификатора выглядит так:

Menu("Options") {
    Button("Toggle A") { /* … */ }
    Button("Toggle B") { /* … */ }
    Divider()
    Button("Done") { /* … */ }
}
.menuActionDismissBehavior(.disabled)

При использовании .disabled меню остаётся открытым после каждого действия, позволяя пользователю выполнить несколько действий, прежде чем решить закрыть его.

➖ Наглядный пример: пакетное переключение

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

struct FeatureToggleMenu: View {
    @State private var featureA = false
    @State private var featureB = false
    @State private var featureC = false
​
    var body: some View {
        Menu {
            Section {
                Toggle("Feature A", isOn: $featureA)
                Toggle("Feature B", isOn: $featureB)
                Toggle("Feature C", isOn: $featureC)
            }
            .menuActionDismissBehavior(.disabled)
            
            Button("Apply Changes") {
                // commit logic here
            }
        } label: {
            Label("Settings", systemImage: "gearshape")
        }
    }
}

В этом макете:

🔘 Пользователь открывает «Настройки» и переключает различные функции, не закрывая меню при каждом нажатии переключателя.
🔘 После выбора он нажимает «Применить изменения», а затем может закрыть меню (в зависимости от реализации).
🔘 Вы даже можете вручную принудительно закрыть меню, используя специальную кнопку «Готово».

➖ Заключение

Модификатор menuActionDismissBehavior(_:) — это удобный API для преобразования типичных меню SwiftUI в более надежные мини-интерфейсы для настроек, переключателей и многошаговых рабочих процессов. Продуманное использование этого может привести к более понятному и интуитивно понятному пользовательскому интерфейсу, когда вам нужно больше, чем простое взаимодействие «выбрать и применить».

🐸 Библиотека мобильного разработчика

#буст #MiddlePath #Swift

🐸 Библиотека мобильного разработчика

#междусобойчик #MiddlePath #Swift

✨ Организация представлений SwiftUI с помощью ToolbarContent и @ToolbarContentBuilder

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

🔹 Разбираем крупные реализации body

Когда body растягивается на десятки строк, страдает читаемость. Лучше разбивать большие представления SwiftUI на мелкие подпредставления или выделять повторно используемые части в вычисляемые свойства или функции. Это сохраняет лаконичность и упрощает понимание, тестирование и повторное использование.

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

🔹 Проблема с панелями инструментов

Модификатор .toolbar позволяет создавать кнопки, меню и элементы управления, адаптируемые под разные платформы. Но если элементов становится много, код внутри .toolbar { ... } быстро теряет читаемость.
Перенести логику в вычисляемое свойство нельзя — .toolbar ожидает содержимое, соответствующее ToolbarContent.

🔹 ToolbarContent и @ToolbarContentBuilder

SwiftUI решает это с помощью:

• ToolbarContent — протокола для элементов панели инструментов;
• @ToolbarContentBuilder — билдера, создающего набор элементов панели.

Объединив их, можно вынести содержимое панели инструментов в отдельный блок, сделав body чище и понятнее.

Пример

struct DemoView: View {
    @State private var message = "Hello, world!"

    var body: some View {
        NavigationStack {
            Text(message)
                .font(.title2)
                .padding()
                .navigationTitle("Home")
                .toolbar { toolbarContent }
        }
    }

    @ToolbarContentBuilder
    private var toolbarContent: some ToolbarContent {
        ToolbarItem(placement: .navigationBarLeading) {
            Button { message = "Left tapped" } label: {
                Label("Left", systemImage: "line.3.horizontal")
            }
        }
        ToolbarItem(placement: .navigationBarTrailing) {
            Button { message = "Right tapped" } label: {
                Label("Right", systemImage: "star")
            }
        }
    }
}

🔹 Заключение

Использование @ToolbarContentBuilder для отделения содержимого панели инструментов от основного окна имеет ряд преимуществ:

• Улучшена читаемость: Ваш body текст по-прежнему сосредоточен на вёрстке, а логика панели инструментов реализована в другом месте.
• Лучшая организация: Группировка элементов панели инструментов в отдельном блоке позволяет с первого взгляда оценить их структуру и расположение.
• Масштабируемость: Когда на панели инструментов появляется несколько кнопок, меню или условная логика, поддерживать её в рабочем состоянии становится намного проще.

🐸 Библиотека мобильного разработчика

#PixelPerfect #MiddlePath #Swift

🧠 Tachikoma — современный Swift SDK для работы с ИИ-провайдерами

Tachikoma — современный Swift AI SDK, который делает интеграцию с ИИ простой и естественной. Tachikoma предоставляет интеллектуальный, адаптивный интерфейс для ИИ-сервисов с полностью современным API на Swift.

Пример:

import Tachikoma  // Single unified module
​
// Simple text generation
let answer = try await generate("What is 2+2?", using: .openai(.gpt4o))
print(answer) // "4"
​
// With different models
let response1 = try await generate("Hello", using: .anthropic(.opus4))
let response2 = try await generate("Hello", using: .grok(.grok4))
let response3 = try await generate("Hello", using: .ollama(.llama33))

💻 Tachikoma на GitHub

🐸 Библиотека мобильного разработчика

#буст #Swift

🔥 Вышла библиотека Any Language Model

Разработчик Мэтт Тиссен (Matt Thiessen) выпустил библиотеку Any Language Model для Swift. Она полностью совместима со стандартной Foundation Models, и с ней можно использовать любые LLM, а не только решения от Apple.

В 2025 году Apple представила библиотеку Foundation Models. С её помощью в приложения можно интегрировать модели от Apple: локальную LLM с 3 млрд параметров или облачную VLM. Разработчики в сообществе оценили удобный синтаксис адаптера и оптимизацию под устройства экосистемы, но привязка к определённым нейросетями разрушила потенциальную универсальность.

Проблему решил Мэтт Тиссен. В его API-совместимой библиотеке Any Language Model разработчики могут сами выбирать бэкенд для запуска моделей. Например, можно использовать Apple Foundation Models, CoreML, MLX, llama.cpp (GGUF), OpenAI API, Anthropic API или Google Gemini API. При этом не надо создавать отдельный адаптер для каждого LLM-провайдера.

Для установки Any Language Model в файле Package.swift надо указать следующую зависимость:

dependencies: [
    .package(url: "https://github.com/mattt/AnyLanguageModel.git", from: "0.3.0")
]

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

dependencies: [
    .package(
        url: "https://github.com/mattt/AnyLanguageModel.git",
        branch: "main",
        traits: ["CoreML", "MLX"] // Enable CoreML and MLX support
    )
]

Пример использования Any Language Model выглядит следующим образом:

import AnyLanguageModel

struct WeatherTool: Tool {
    let name = "getWeather"
    let description = "Retrieve the latest weather information for a city"

    @Generable
    struct Arguments {
        @Guide(description: "The city to fetch the weather for")
        var city: String
    }

    func call(arguments: Arguments) async throws -> String {
        "The weather in \(arguments.city) is sunny and 72°F / 23°C"
    }
}

let model = SystemLanguageModel.default
let session = LanguageModelSession(model: model, tools: [WeatherTool()])

let response = try await session.respond {
    Prompt("How's the weather in Cupertino?")
}
print(response.content)

➡️ Код библиотеки доступен на GitHub. Для работы нужен Swift 6.1+ и iOS 17.0, macOS 14.0 или visionOS 1.0.

🐸 Библиотека мобильного разработчика

#свежак #iOS #Swift