🔨 3 основные размера экрана iPhone'в

Существуют три основных размера
- SE
- Обычный или Pro
- Pro MAX

Нужно проверять как выглядит верстка на всех трех.

Особенно страдает верстка на SE, вы вроде сделали все по уму, а на SE треть экрана не видна, он короткий.

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

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

📱Создал свой YouTube канал

Самая важная вещь для инди-разработчика, которая может быть у вас - это ни айфон, ни даже макбук, а - 🎙 микрофон!

С тех пор как я создал свой YouTube канал, я увеличил свой доход с 10k$ до 70+k$!

Adam Lyttle - австралийский инди-разработчик

Пока просто создал и залил уроки с курса Angela Yu (без публичного доступа), для перевода с дубляжем, на Udemy - перевод видео не работает ((

😵 Первая цель набрать 1000 подписчиков - это позволит вести прямые трансляции.

Думаю иногда, а может и регулярно устраивать трансляции в формате "code with me".

Подпишись 📱 youtube.com/@isilverdev

📚 Собрал книжную полку

Хз когда это всё читать...

Совет как искать книги в pdf выше 🔼

🗓 Отчёт за неделю - это хорошая идея

Текущий прогресс по курсам Swift

✔️ +1 16/100 - 100 дней SwiftUI
✔️ +0 17/39 - Усов книга 1
✔️ +2 5/29 - Angela Yu

🟩🟩🟩⬜️⬜️⬜️⬜️⬜️⬜️⬜️ - 100 дней
🟩🟩🟩🟩🟩🟩⬜️⬜️⬜️⬜️ - Усов
🟩🟩⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️ - Angela Yu

Проект "iOS по взрослому"
- сделал таск "Верстка 0.1.1 Обычная кнопка"

Это первая задача в проекте, учится приходится многому:
- работать с Git и GitHub
- правильно именовать компоненты в коде
- правильно именовать ветки в Git
- правильно именовать pull-requests

Задания в курсе Angela Yu уже делал с учетом новых знаний работы с git, полученных в проекте iOS по взрослому.

Кстати, вписался в коллективное прохождение курса Angela Yu.

Суть: при выполнении заданий отработать методики работы в команде.

Делить задачу на таски (подзадачи).
Использовать Git и GitHub.
Обоюдный код-ревью.
Координация через YouGile.
И тп.

🗓 Планы на неделю:

"iOS по взрослому"
- доработать таск "Верстка 0.1.1 Обычная кнопка" после код-ревью, исправить замечания.
- выполнить новый таск "Верстка 1.1 Онбординг"

Усов книга 1
- изучить 3 главы: enum, struct, class (44 стр.)

100 дней SwiftUI
- дни 17-18 App "Чек в кафе"
- день 19 App "Конвертер"

Новый Pet-проект (пока секрет)
- подготовить картинки
- начать верстку основного экрана

Ну что ж: погнали!

✔️ §19 Перечисления / enum - Усов Book 1

За 2 дня внес исправления по 24 32 42 замечаниям к коду!

Всего лишь кнопочки делаю...

Некоторые примеры замечаний:

Лучше отказаться от enum в пользу struct, так как расширять enum в случае появления дополнительных стилей будет сложнее, чем дописать extension к struct.

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

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

    private func setupButton(
        style: ButtonStyle,
        title: String,
        icon: ButtonIcon?,
        iconPosition: IconPosition
    ) {
        // some code
    }

НО Если параметр один или два и они влезают в 100 символов по ширине не надо переносить на новую строку.

MainButton непоходящее название.
Что-то вроде CornersButton или как-то так более понятно что это за кнопка.

CornersButtonStyle - вынести в отдельный одноименный файл, создать папку (group) "CornersButton"

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

leftIconImageView.isHidden = position == .right
rightIconImageView.isHidden = position == .left

Как же кайфую от количества полезной инфы на практике!

🔥 🔥 🔥

✔️ §16 Терминал: командная строка
(Курс Angela Yu)

📱 Список основных команд

🎉 Тепер у вас есть доступ к App Store Connect 🎉

✔️ §18 Git, GitHub
(Курс Angela Yu)

Для базового понимания - ок.

Для нормальной работы - надо больше, в тч практики. А практики в Git сейчас у меня навалом в проекте "iOS по взрослому".

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

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

📱 Как писать коммиты, чтобы тебе (и команде) не было больно?

Если ты только начинаешь работать с Git, коммиты могут казаться просто формальностью.

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

Или коллега ищет, где починили баг, а в истории — только “fix” и “123”. Разберёмся, как писать коммиты, которые будут понятны и тебе, и команде.

✏️ Коротко, но по делу

Лаконичный коммит лучше длинного, но "fix bug" или "update" ничего не объясняют. Даже через месяц должно быть понятно, что именно изменилось:

✔️ "fix: исправил баг с расчётом скидки в корзине"

✏️ Один коммит — одна логичная правка

Громоздкие коммиты, в которых и рефакторинг, и баг-фикс, и новая фича, — головная боль для команды. Разделяйте изменения:

❌
"Обновил стили, поправил баг с кнопкой, добавил валидацию формы"

✔️
"fix: исправил баг с кнопкой отправки",
"feat: добавил валидацию формы",
"style: обновил стили формы"

✏️Структура коммита делает его понятнее

Лучше договориться о едином формате.

Например, часто используют:
тип: краткое описание
• feat: новая функциональность
• fix: исправление бага
• refactor: улучшение кода без изменения логики
• style: правки форматирования

✏️ Комментарий может быть полезным

Если фикс сложный или решение неочевидное, добавьте пояснение:

✔️
"fix: исправил баг с расчётом скидки (в 3% случаев неправильно округлялась сумма)"

❗️ А если я только начинаю?

Привычка писать осмысленные коммиты помогает быстрее разобраться в проекте и выработать аккуратный стиль работы.

Команда (и ваше будущее "я") скажет спасибо!

🎉 Йехххуууу!!!