Блог Артёма Болотова

Россификация RedCalendar

2026-10-20T00:00:00+00:00

Думал, что просто меняю сервер. Оказалось — пишу новое приложение, спецификацию на 2 500 строк и согласие на обработку персональных данных.

RedCalendar — облачный календарь женского цикла для iPhone. На днях вышло большое обновление: всё тот же календарь, но внутри от старого приложения не осталось ничего. Данные теперь хранятся в России, входить нужно по почте, а само приложение написано заново.

Загрузка изображений...

0/6

Почему пришлось уезжать

Раньше всё держалось на Firebase — это сервис Google для разработчиков приложений, где база данных, вход и уведомления идут готовыми кирпичиками. Удобно, быстро и почти бесплатно. Только серверы Firebase стоят в США.

Главная причина переезда — закон о персональных данных (152-ФЗ). Данные россиян нужно хранить на серверах в России, а сведения о здоровье, к которым относится и менструальный цикл, — это отдельная, особо охраняемая категория. Хранить их у Google в американском дата-центре для российского приложения становилось всё менее разумно.

Свой сервер в России

Сервер RedCalendar живёт у российского облачного хостинга NetAngels — я давно пользуюсь им в других проектах. Он хранит записи, рассылает уведомления и отправляет письма с кодом входа. Сервер я намеренно сделал скучным: только проверенные временем технологии и минимум сторонних библиотек.

Что чем заменилось:

Что	Было	Стало
Сервер и база данных	Firebase, США	Свой сервер в NetAngels, Россия
Вход по номеру	Через Firebase	Звонок: код — последние 4 цифры номера, который звонит
Вход по почте	Не было	Код в письме через Yandex Cloud Postbox
Уведомления	Сервис Google	Свой сервер напрямую через Apple
Аналитика	Google	AppMetrica

Письма с кодом отправляет Yandex Cloud Postbox. Летом я писал про закон об иностранной почте и почему считаю, что своя система входа по почте лучше кнопок «Войти через…». Вот это она и есть.

Postbox я выбрал как самый надёжный сервис с подходящим тарифом. Чтобы письма не попадали в спам, ещё настроил для домена строгие правила DMARC — по ним почтовые сервисы проверяют, что письмо действительно отправил я, — и зарегистрировал домен в Postmaster Mail.ru. В общем, сделал всё, что мог.

Но и самый надёжный сервис может подвести. Когда дата-центры Яндекса вывели из строя, Postbox продолжал считать, что отправляет письма, а на деле они не приходили. Я поймал это на тестировании и задержал выход обновления.

Загрузка изображений...

0/3

Как перевезти людей, не заставив их ничего делать

Главное правило переезда: никто не должен ничего переносить вручную, заново входить в аккаунт или делать что-то ещё. Обновил приложение — и все записи на месте.

Готовиться к этому я начал больше чем за год. Летом 2025 года, в версии 2.2.2, старый RedCalendar стал при каждом запуске тихо оставлять себе записку: идентификатор аккаунта в Keychain — защищённом хранилище iPhone, которое переживает обновления, в секторе, доступном только для RedCalendar. Новое приложение вышло в App Store под тем же именем (то есть идентификатором), то есть пришло обычным обновлением. При первом запуске оно находит записку и узнаёт человека без всякого входа. От человека нужно только одно — дать согласие на обработку данных.

Сами записи телефон не перевозит: главная копия хранилась в Firebase, поэтому за ними идёт сервер. Он выгружает историю, приводит её к новому формату, проверяет по тем же правилам, что и любые правки с телефона, и складывает в свою базу. Пока это происходит, вместо пустого календаря крутится значок синхронизации. Когда всё готово, история приезжает целиком.

Сломать переезд на полпути нельзя. Записка стирается только после того, как сервер выдал телефону новый ключ входа: пропала сеть или приложение закрыли — при следующем запуске всё начнётся заново. А записи для каждого аккаунта переносятся один раз, поэтому второй телефон или повторный вход ничего не скопируют дважды и не вернут то, что уже удалено.

Если записки нет — например, старую версию не открывали с лета 2025 года, — можно войти по номеру телефона, как раньше. Новый сервер сохранил идентификаторы аккаунтов из Firebase, так что по номеру находится тот же самый аккаунт, и дальше всё идёт точно так же.

Закон: согласие и удаление

Переезд — это не только про серверы, но и про документы.

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

Удаление аккаунта. По закону на уничтожение данных есть 30 дней. Резервные копии у хостинга хранятся около трёх недель. Поэтому аккаунт удаляется через 7 дней после запроса: 7 дней плюс примерно 23 дня жизни копий как раз дают 30. Передумали в течение недели — просто войдите снова, и удаление отменится.

Загрузка изображений...

0/2

Новое приложение с нуля

Старый RedCalendar был написан на UIKit — прежнем способе делать интерфейсы для iPhone. Новый написан на SwiftUI, современном инструменте Apple. Переносить старый код не стал: проще и надёжнее было начать заново.

Главное, что хотелось получить, — предсказуемость. Всё, что знает приложение — какой день открыт, что в нём отмечено, выполнен ли вход, — лежит в одном месте. Экраны ничего не меняют сами: они только показывают это состояние и отправляют заявки вроде «отмечено начало месячных», а заявки выполняются строго по очереди. Поэтому, если на экране что-то не так, причину не нужно искать по всему приложению. Программисты узнают в этом схему Redux и, на мой взгляд, она идеальна для SwiftUI.

Самая сложная часть нового приложения глазами не видна — это синхронизация. Все записи хранятся прямо на телефоне, поэтому календарь работает и без интернета, а изменения уходят на сервер, как только появится связь. Звучит просто, пока не начинаешь задавать вопросы. Что делать, если интернет пропал посреди отправки? Как не дать удалённой записи «воскреснуть» на другом телефоне? Чья правка победит, если одну и ту же запись поменяли на двух устройствах? Ответы я сначала записал в документ на 2 500 строк и только потом начал писать код.

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

Теги и комментарий показываются прямо в карточке дня. Открытый день, как и раньше, можно листать свайпом, но теперь можно и просто нажать на другой день в календаре — сразу откроется его карточка. В старой версии на UIKit сделать так у меня не получилось: нажатие на календарь закрывало карточку, и чтобы выбрать другой день, приходилось нажимать ещё раз. А акцентный цвет приложения можно выбрать в настройках.

Так выглядел старый RedCalendar:

Загрузка изображений...

0/4

А так — новый:

Загрузка изображений...

0/4

Была задача освежить приложение, но оставить узнаваемым.

Что дальше

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

Сама идея входа по номеру мне нравилась больше, но стала плохо работать. Дело не только в деньгах: SMS с кодом теперь стоит очень дорого, а приходит не обязательно SMS (звонок робота, сообщение в Telegram, WhatsApp или, упаси Господи, в Max). А может и не прийти вооьще. Вход по звонку — хорошая штука, но заботливые операторы теперь блокируют такие звонки, а человек думает, что это приложение кривое, и может поставить одну звезду:

Загрузка изображений...

0/1

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

Firebase тоже пока работает: в нём остаются аккаунты и записи тех, кто ещё не открыл новую версию. Когда переезжать станет некому, старый проект можно будет удалить. После этого RedCalendar окончательно станет российским — от сервера до последней резервной копии.

От git push до сайта

2026-08-24T00:00:00+00:00

Любой проект — это много мелких правок, часть которых можно делать «между делом». Но мы часто их откладываем, ведь в классическом варианте эти правки нужно не только внести, но и как-то применить. Поэтому они копятся, забываются, а потом просто становится не до них. Как, к примеру, выглядит работа с сайтом? Есть у вас на компьютере локальная версия, в ней вы и «играетесь», а потом публикуете. Физически нужен доступ к этой версии, компьютер. Короче, это неудобно, поэтому давайте попробуем другой способ. Пусть код сайта хранится где-то в облаке, а изменения заливаются на хостинг автоматически. Быстро, без ноутбука, без каких-то программ для загрузки файлов, без «доеду до дома — поправлю».

Называется это автоматической публикацией — вы отправляете изменения в специальное хранилище кода, а дальше сервис сам берёт свежую версию сайта и выкладывает её на хостинг в соответствии с правилами, которые вы определили. Я хочу показать, как это устроено, на примере реального проекта на PHP. А в следующих статьях разберём, как быть с сервисом на Node.js и как автоматически собирать нативные мобильные приложения без компьютера и посторонних сервисов. Начнём с сайта, потому что это просто.

Как обычно выкладывают сайт

Классический способ — зайти на хостинг по FTP или SFTP каким-нибудь файловым клиентом (например, FileZilla), найти на компьютере изменённые файлы и перетащить их на сервер поверх старых.

Работает это до поры до времени, а потом начинаются мелкие неприятности. Забыли залить один из изменённых файлов — и часть сайта работает по-старому. Не помните, какая версия файла сейчас на сервере — та, что вы правили вчера, или ещё более старая. Два человека работают над одним проектом — и рискуют затереть правки друг друга, просто перезалив файлы поверх. А если что-то сломалось после заливки — вернуть как было можно только если у вас случайно осталась резервная копия старых файлов.

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

Репозиторий — это надёжнее

Есть другой подход: хранить код сайта не просто как папку с файлами на компьютере, а в системе контроля версий — например, в git. Такое хранилище называется репозиторием, а сервисов, которые их у себя размещают, много — самый известный GitHub.

Если совсем просто: репозиторий запоминает каждое изменение файлов как отдельный шаг с датой, автором и описанием. Захотели узнать, что изменилось за последний месяц, — посмотрели историю. Что-то сломали — вернулись на шаг назад одной командой. Работаете вдвоём — правки не затираются, а аккуратно складываются друг на друга.

Но главное для нашей темы — другое. Раз весь сайт целиком лежит в репозитории, то у вас появляется однозначный ответ на вопрос «а что сейчас на сайте?»: то, что лежит в репозитории в основной ветке (обычно она называется main), — то и должно быть на сайте. И никакой путаницы.

Можно работать откуда угодно

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

А ещё с репозиториями хорошо работают помощники вроде Claude Code — им можно описать задачу («поправь вёрстку карточки на мобильных» или «добавь новую страницу с прайсом»), и они сами напишут код и отправят изменение в репозиторий. То есть можно между делом, буквально с телефона, попросить что-то поправить или попробовать новую идею на сайте — и не нужно вообще садиться за компьютер.

Что такое GitHub Actions

GitHub Actions — это встроенный в GitHub робот, который умеет что-то делать автоматически при разных событиях в репозитории. Самое частое событие — отправка изменений (это и называется словом push, «отправить»): вы отправили правки в основную ветку — робот заметил это и запустил заранее описанный набор шагов.

Набор шагов описывается в обычном текстовом файле в формате YAML, который лежит прямо в репозитории по пути .github/workflows/имя-файла.yml. В этом файле написано человеческим языком (ну, почти): «при отправке изменений в ветку main — скачай свежий код и отправь его на хостинг по такому-то адресу».

Готовим SSH-ключ

Чтобы робот GitHub Actions мог зайти на хостинг и оставить там файлы, ему нужен способ авторизоваться — представиться и доказать, что он действительно имеет право туда заходить. Самый надёжный вариант — SSH-ключ.

SSH-ключ — это пара файлов: закрытый (приватный) и открытый (публичный). Работает это так: открытый ключ кладётся на сервер и говорит «пускай того, у кого есть парный закрытый ключ». Закрытый ключ никому не показывается и остаётся только у вас — точнее, в нашем случае, только у GitHub, в специальном защищённом хранилище, о котором дальше.

Создать пару ключей можно одной командой в терминале (на Mac и Linux — обычный терминал, на Windows — например, PowerShell или Git Bash):

ssh-keygen -t ed25519 -C "deploy-key"

На вопросы, где сохранить файл и нужен ли пароль на сам ключ, можно просто нажимать Enter, соглашаясь со значениями по умолчанию (для ключа, который будет использовать робот, а не вы лично, пароль на сам ключ не нужен — иначе его некому будет вводить). В результате появятся два файла: например, id_ed25519 (закрытый ключ) и id_ed25519.pub (открытый).

Кладём ключ на хостинг и в настройки репозитория

Дальше открытый ключ (файл с окончанием .pub) нужно положить на хостинг, а закрытый — спрятать в настройках репозитория на GitHub, откуда его сможет достать только сам GitHub Actions.

Я показываю на примере хостинга NetAngels — пользуюсь им давно, но подойдёт в целом любой хостинг с поддержкой SSH, шаги будут примерно такими же.

В личном кабинете NetAngels заходим в нужный контейнер сайта и открываем вкладку «SSH». Там же будут видны логин (что-то вроде c123456), адрес сервера (h60.netangels.ru) и порт (обычно 22) — эти данные понадобятся чуть позже.

Нажимаем «Добавить ключ», в выпадающем списке выбираем «Создать новый ключ», указываем любое понятное название (например, «GitHub Actions») и вставляем в поле «Ключ» содержимое файла id_ed25519.pub — того самого, открытого. Нажимаем «Добавить ключ».

Теперь идём в репозиторий на GitHub, в раздел Settings → Secrets and variables → Actions. Там два похожих, но разных списка:

Secrets — для по-настоящему секретных данных, вроде паролей и ключей. Значение можно один раз задать, но потом нигде, даже вам самим, посмотреть его снова не получится — только заменить.
Variables — для данных, которые не секрет, а просто настройка, например путь к папке на сервере.

Добавляем секреты (кнопка «New repository secret»):

SSH_HOST — адрес сервера (h60.netangels.ru)
SSH_USERNAME — логин с той же вкладки «SSH»
SSH_PORT — порт (обычно 22)
SSH_KEY — содержимое закрытого ключа целиком, файла id_ed25519 (не .pub!)

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

И одну переменную (кнопка «New repository variable», на отдельной вкладке «Variables» рядом с «Secrets»):

DESTINATION_PATH — путь до папки на сервере, куда нужно класть файлы сайта (включая конечную папку www, если она есть), например /home/c123456/my-cool-website.ru/www

Сам файл: разбираем построчно

Ниже файл .github/workflows/deploy.yml, которым я пользуюсь у себя в одном из PHP-проектов:

name: Deploy to NetAngels

on:
  push:
    branches: [ main, master ]
  workflow_dispatch:

jobs:
  deploy:
    name: Deploy to NetAngels hosting
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v7

    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: '8.5'

    - name: Validate PHP syntax
      run: |
        echo "🔍 Checking PHP syntax..."
        find www -name "*.php" -exec php -l {} \; | tee php_check.log
        if grep -q "Parse error\|Fatal error\|Syntax error" php_check.log; then
          echo "❌ PHP syntax errors found!"
          exit 1
        fi
        echo "✅ PHP syntax validation passed"
        rm php_check.log

    - name: 🚀 Deploy via rsync
      uses: burnett01/rsync-deployments@v9
      with:
        switches: -avzr --delete --exclude-from=.rsyncignore
        path: ./www/
        remote_path: ${{ vars.DESTINATION_PATH }}
        remote_host: ${{ secrets.SSH_HOST }}
        remote_user: ${{ secrets.SSH_USERNAME }}
        remote_key: ${{ secrets.SSH_KEY }}
        remote_port: ${{ secrets.SSH_PORT }}

    - name: Verify deployment
      run: |
        echo "🔍 Verifying deployment..."
        echo "✅ Deployment completed successfully!"
        echo "📊 Deployment summary:"
        echo "   - Server: ${{ secrets.SSH_HOST }}"
        echo "   - Directory: ${{ vars.DESTINATION_PATH }}"
        echo "   - Branch: ${{ github.ref_name }}"
        echo "   - Commit: ${{ github.sha }}"
        echo "   - Time: $(date)"

    - name: Notify on failure
      if: failure()
      run: |
        echo "❌ Deployment failed!"
        echo "Please check the logs above for details."
        echo "Common issues:"
        echo "  - SSH key not added to server"
        echo "  - SSH username incorrect"
        echo "  - Server directory doesn't exist"
        echo "  - Permission issues"
        echo "  - PHP syntax errors"

Разберём по частям:

on: push: branches: [ main, master ] плюс workflow_dispatch: — запускать сценарий при отправке изменений сразу в обе ветки (у старых проектов основная ветка иногда называется master, а не main), а workflow_dispatch добавляет в интерфейсе GitHub кнопку «Run workflow» — можно запустить публикацию вручную, без нового изменения, если, например, просто хочется выложить то же самое ещё раз.
runs-on: ubuntu-latest — GitHub на минуту-другую выделяет под задачу временный компьютер с Linux. Он появляется, выполняет шаги и после этого исчезает — никаких следов не остаётся, кроме журнала выполнения.
Шаг Checkout code — скачивает на этот временный компьютер код репозитория.
Шаг Setup PHP — на временном компьютере по умолчанию нет PHP, поэтому его ставит отдельным шагом, той же версии, что и на хостинге (8.5), чтобы дальнейшая проверка была честной.
Шаг Validate PHP syntax — прогоняет каждый .php-файл в папке www через встроенную проверку синтаксиса PHP (php -l, l — от «lint»), собирает результат в файл-журнал и ищет там слова вроде «Parse error». Если находит — сценарий останавливается с ошибкой (exit 1) и до следующего шага, самой отправки на сервер, дело просто не доходит. Опечатка в коде так и остаётся опечаткой в репозитории, а не превращается в сломанный сайт. Эмодзи в echo — просто украшение для журнала выполнения, чтобы результат было проще пробежать глазами.
Шаг 🚀 Deploy via rsync — тот самый burnett01/rsync-deployments, который копирует файлы на сервер по SSH программой rsync. path: ./www/ — на сервер уходит содержимое только папки www, где лежит собственно сайт, а не весь репозиторий целиком (там ведь есть ещё и сам файл deploy.yml, и служебные файлы, которым на сервере делать нечего). --exclude-from=.rsyncignore подключает список исключений — отдельный файл, о котором дальше.
Шаги Verify deployment и Notify on failure не делают ничего технического — это просто аккуратный вывод в журнал: что именно и когда было выложено, а если что-то из предыдущих шагов сломалось (if: failure()) — подсказка, в какую сторону смотреть. Настоящего отката к прошлой версии тут нет, но и без него, если ошибка — на этапе проверки синтаксиса сайт просто не тронут, а не сломан наполовину.

Ключ ${{ secrets.SSH_KEY }} — это то место, где GitHub подставляет ваш закрытый ключ в момент выполнения, никому его не показывая: ни в журнале выполнения, ни в самом файле настроек, который лежит в открытом репозитории.

Флаги -avzr --delete у rsync означают: скопировать файлы рекурсивно, со сжатием, сохраняя даты изменения, и удалить на сервере то, чего больше нет в репозитории — чтобы сервер всегда точно повторял содержимое ветки, а не постепенно обрастал забытым старьём.

Раз уж мы здесь: обратите внимание на цифры версий у сторонних actions в файле — actions/checkout@v7, burnett01/rsync-deployments@v9. Их стоит время от времени проверять на актуальность: выходят более новые версии с исправлениями, а совсем старые рано или поздно перестают нормально работать. Сделать это просто: берём часть до @ (например, burnett01/rsync-deployments) и открываем в браузере github.com/burnett01/rsync-deployments — это и есть страница репозитория того action’а на GitHub, а на ней видно, какая версия сейчас самая свежая.

Что кладём в .rsyncignore

В корне репозитория лежит ещё один файл — .rsyncignore. Это простой список того, что не нужно отправлять на сервер, даже если оно случайно оказалось в папке www:

.git
.github
.gitignore
.gitattributes
.vscode
.idea
.editorconfig
.envrc
.env*
vendor
*.log
logs
tmp
*.tmp
*.bak
*cookies*.txt
config.php
debug.php
phpinfo.php
test.php
bin
README.md
.DS_Store
Thumbs.db

Сочинять надо под себя. Важный нюанс: --exclude-from работает вместе с --delete по правилу «не трогать». Если такой файл случайно уже лежит на сервере — --delete его не удалит просто потому, что он подходит под исключение. Список работает только в одну сторону: не давать таким файлам попасть на сервер через эту отправку, а не выковыривать их оттуда, если они там уже были.

Пробуем

Сохраняем файл deploy.yml, отправляем это изменение в репозиторий — и дальше можно зайти на GitHub, во вкладку Actions, и увидеть, как запустился и выполняется наш сценарий: шаг за шагом, с журналом всего происходящего. Через несколько секунд напротив всех шагов появятся зелёные галочки, а обновлённый сайт уже будет на хостинге.

Шаг «Notify on failure» остался серым — он выполняется только при ошибке

Дальше это работает само: любое изменение, отправленное в main — хоть с ноутбука, хоть из приложения GitHub на телефоне, хоть руками того же Claude Code, — само доедет до сайта за считаные секунды, без каких-либо действий с вашей стороны.

Что дальше

Мы разобрались, как сайт может публиковаться сам, при каждой отправке изменений в репозиторий. В следующих статьях посмотрим на вещи чуть сложнее: как таким же способом работать с проектом на Node.js, автоматически собрать мобильное приложение под Android или iOS и отправить его на тестирование — тоже без единого лишнего действия с компьютера.

Закон об иностранной почте

2026-07-11T00:00:00+00:00

С 7 июля 2026 года действует статья 13.55 КоАП — штрафы за нарушение правил авторизации на сайтах и в приложениях. В ней предусмотрены и штрафы для физических лиц. Если не читать подробнее, можно подумать, что теперь вход с Google или Apple стал «платным» (для физлиц от 10 000 рублей). На самом деле, это касается только владельцев сайтов и сервисов.

Что теперь нельзя?

Точнее, что можно:

Российский номер мобильного телефона (звонок/смс-код через оператора связи)
ЕСИА — «Госуслуги»
ЕБС — единая биометрическая система
«Иная информационная система», принадлежащая гражданину РФ или российскому юрлицу и соответствующая требованиям к защите информации по ст. 16 149-ФЗ. Формально подойдёт любая система с такими признаками — хоть VK ID, Яндекс ID или Сбер ID, хоть самописная

Остальное нельзя. По мнению людей, придумавших эту инициативу, авторизация через Google опаснее, чем «иная информационная система», которую мамкин вайбкодер сделал с помощью гигачата. Спасибо, что думаете о нас, но, может, мы сами как-нибудь разберёмся?

Кого это касается

Почему-то эту новость иногда выдают за запрет иностранной почты для входа. Некоторые сервисы заранее запретили почту gmail, предложив привязать учётку яндекса или мейл.ру «пока не стало поздно». Хотя я ничего подобного в тексте не нашёл, желание выслужиться или перестраховаться иногда сильнее здравого смысла.

Почему «национальность» почты — бессмысленное понятие

Возможно, депутаты не знают, что такое электронная почта и как она работает. Я готовлю серию статей «Внутри интернета», где в десятой мы будем разбираться, как работает email и чем vasya@yandex.ru отличается от petya@gmail.com, а заодно узнаем, что misha@mishin.site может обслуживаться хоть в яндексе, хоть в mail.ru, хоть в gmail, хоть вообще на своём личном сервере. И смена «местожительства» почты доступна любому владельцу домена. Поэтому сегодня он русский, завтра эстонский или финский.

Что дальше

Я сам старался не пользоваться этими кнопками «Вход с Apple» и «Вход с Google». Мне удобнее просто ввести почту, установить пароль, а потом, когда через год вернусь на этот сайт, менеджер паролей сразу предложит войти, без гаданий, какую из кнопок авторизации я нажимал. Поэтому сейчас, когда нам навязывают вход через Госуслуги или Сбер ID, я всё равно выбрал бы почту. Своя система авторизации всё равно лучше: даже рассылку писем можно настроить самому, например через Yandex Postbox. Да, с этим придётся повозиться — разобраться с отправкой писем, настроить домен, — но по итогу можно убрать лишние кнопки и сделать ресурс одинаково удобным для пользователей из любой страны.

Судя по всему, примерно так авторы закона видят идеальную авторизацию:

Загрузка изображений...

0/1

Как вернуть push-уведомления в Макс на iPhone?

2026-06-17T00:00:00+00:00

Заходите на web.max.ru, нажимайте Поделиться → Добавить на экран «Домой».

Загрузка изображений...

0/1

Потом запускайте с этого ярлыка PWA-версию Макса (которая раньше была категорически запрещена, ведь в ней вас не получится отслеживать), входите по коду из смс (и, надеюсь, паролю) и разрешайте уведомления.

Конечно, в идеальном мире ~~это приложение должно быть установлено на отдельном телефоне~~ этого приложения существовать не должно вообще.

appreach.ru: какой регион App Store выбрать после отключения мобильного платежа

2026-06-04T00:00:00+00:00

Проверка на «патриотизм»?

После отключения возможности пополнять баланс аккаунта Apple каждый россиянин вынужден принять решение: оставаться с «красным» и нерабочим айклаудом и терпеть или поменять регион и получить новые возможности. Выбор, на мой взгляд, очевиден. Но какой регион выбрать? Вопрос относится к категории религиозных и подход может быть разным:

«В Турции дешевле!»
«У меня есть карта Казахстана!»
«Хочу все приложения!»

Казалось бы, выбираете США и не знаете никаких проблем. Оказалось, это не совсем так.

Регионы в App Store

Конечно, оптимальным вариантом будет выбрать регион, соответствующий вашему проживанию: приложения, которые вам можно использовать, цены в вашей валюте, ~~можно привязать свою карту и без проблем оплачивать iCloud и подписки~~. Кроме того, раньше, если у Apple (Google, любого сервиса) возникали сомнения по поводу его корректности, компания могла запросить подтверждающие документы (выписку из банковского счёта или квитанции за квартиру).

После отмены мобильного платежа Apple разрешила россиянам менять регион, закрывая глаза на фактическое проживание. Возможно, это было самым простым решением, хотя, на мой взгляд, могли разрешить добавлять зарубежные карты или организовать покупку подарочных карт с кодами другим способом. Если вы iOS-разработчик и публикуете приложение, проще выбрать сразу все регионы, вместо того, чтобы выбирать из списка. Если не использовать какое-то особое шифрование, которое может не понравиться Франции, трудностей не будет. Однако некоторые приложения всё же недоступны в определённых регионах. Поэтому — вот мой новый сервис, который поможет быстро это проверить.

Помимо приложений из таблицы можно проверить любое другое — просто вставьте ссылку из App Store и нажмите на кнопку. И это та опция, которая позволила отследить момент, в который из App Store удалили Макс. Таблица обновляется раз в час, а ручная проверка показывает результат «здесь и сейчас». Правда, я до последнего был уверен, что это какая-то ошибка в коде.

Если вы ещё не поменяли регион — в статье меняем регион аккаунта Apple по шагам разобрал этот процесс.

Меняем регион аккаунта Apple

2026-05-24T00:00:00+00:00

После того, как в России отключили мобильный платёж для оплаты подписок Apple, поменять регион — разумное решение. Но люди откладывают это, лишаясь полноценной работы iCloud и других сервисов.

Главный миф: «с семейным аккаунтом поменять регион не получится».

Что мешает

Подписка Apple Music.
Если она активна — сначала отменить, потом менять регион.
Деньги на балансе.
Ноль рублей на счёте — обязательное условие. Вот пример, как потратить. Остаток (до 15 рублей) нужно списать через поддержку Apple по телефону +7 499 951-25-79.
Общие семейные покупки.
Самый неочевидный пункт. Заходим в Настройки → [Ваше имя] → Семья → Общие покупки и отключаем.

Загрузка изображений...

0/2

Какой регион выбрать

Универсального ответа нет: не все приложения доступны во всех регионах. Поэтому перед выбором лучше проверить нужные именно вам приложения на appreach.ru — моём сервисе, который покажет, в каких странах они доступны.

США привлекательны доступностью подарочных карт оплаты и широким выбором приложений и сервисов. Но музыка дорогая!

В приложении Сбера можно купить подарочные карты для США, ОАЭ, Польши и Турции: Платежи → Отдых и развлечения → ищем Apple.

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

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

Меняем регион

Открываем App Store и нажимаем на аватарку в правом верхнем углу — попадаем в аккаунт.

Загрузка изображений...

0/3

Нажимаем на своё имя → Страна/регион — там сейчас стоит Россия. Ищем нужную страну, нажимаем Продолжить и принимаем условия.

Загрузка изображений...

0/3

Следующий экран — способ оплаты. Выбираем Нет и заполняем адрес. Адрес должен соответствовать выбранному региону. Если выбрали США, указывайте штат Монтана: там нет налога с продаж, поэтому итоговая цена в App Store будет ровно такой, как написано, без сюрпризов. Улицу можно писать любую — можно взять мой пример, индекс соответствует городу.

Загрузка изображений...

0/2

Готово — регион изменён.

Если пункта «нет» у вас нет, значит какое-то из обязательных условий не соблюдено. Обычно это общие покупки.

Пополняем баланс

Самый удобный вариант — подарочная карта через Сбер. Как это сделать читайте в статье про аккаунт Apple другого региона.

Не знаете, куда деть деньги? Отдайте мне

2026-05-04T00:00:00+00:00

Не так давно Минцифры ввели очередные санкции против россиян — баланс аккаунта Apple больше нельзя пополнять с Билайна и МТС, стоимость подарочных карт для региона Россия взлетела в космос, поэтому люди стали дружно менять платёжные регионы на США, Казахстан, Турцию и Эмираты, бонусом получая возможность скачивать приложения, которые РКН заставил Apple убрать из российского App Store.

Раньше поменять регион было прямо сложной задачей, особенно, если у вас семейный аккаунт. Сейчас всё стало проще: заходим и меняем, активируем подарочную карту нового региона, купленную в приложении Сбера, заново оформляем подписки. Но это работает только при одном условии: на балансе ноль. Если оплата списывалась напрямую со счёта мобильного, никаких трудностей не возникнет. А если вы заблаговременно пополняли счёт и для следующего платежа денег не хватает, эта статья для вас.

Деньги на балансе

Чтобы узнать остаток средств, зайдите в App Store и нажмите на свою аватарку. Баланс Apple можно тратить только внутри экосистемы: купить приложение, песню, оплатить iCloud. Если деньги «мешают», их можно списать через службу поддержки.

Бесплатной горячей линии Apple в России больше нет — номер 8-800 отключили. Поэтому заполняем форму getsupport.apple.com или сразу звоним +7 499 951-25-79, с 10:00 до 18:45 по московскому времени.

Если сумма небольшая (например, 10 рублей), служба поддержки обнулит ваш баланс и вы сможете поменять регион. Богатым же придётся сначала потратить баланс до минимума.

TwinKey: ступени благодарности

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

По правилам Apple разработчики не могут назначать произвольную сумму за покупку. Минимальная стоимость в App Store России — 29 рублей (по состоянию на 3 мая 2026). Это ограничение самого магазина, не приложений.

29 рублей — это много, поэтому я выбрал базовой страной для варианта Light Нигерию — там минимальный порог ниже российского, а конвертация бережно превратила 100 NGN в 15 рублей.

Так получилось несколько ступеней единоразового платежа: 15, 49, 99 рублей и выше.

Как потратить остаток

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

Заходим в настройки, выбираем «поддержать разработчика».
Выбираем подходящую сумму — такую, чтобы остаток на балансе стал минимальным.
Оплачиваем.
Возвращаемся к шагу 2, если ещё есть, что списать.

Загрузка изображений...

0/2

После этого на балансе остаётся сумма, с которой в App Store уже ничего не купишь. Звоним в поддержку Apple — просим списать остаток.

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

Аккаунт Apple другого региона: проще, чем кажется

2026-04-05T00:00:00+00:00

По инициативе Минцифры мобильный платёж в App Store для российских номеров отключили. Карты пополнения для российского региона подорожали в разы. Некоторых приложений в российском App Store никогда не было, а каталог продолжает сокращаться. Разумнее завести отдельный аккаунт Apple того региона, где приложения не исчезают по велению какого-нибудь пенсионера, и пополнять его через подарочные карты.

Кто-то пишет, что Apple заблокировала регистрацию новых аккаунтов из России. Кто-то советует «чистый» номер телефона, который нигде раньше не использовался. Кто-то учит регистрировать eSIM через зарубежные сервисы. Wylsacom и вовсе предложил покупать готовые аккаунты Apple на Авито. В общем, выглядит всё сложно и делать не хочется.

Поэтому сейчас я вам покажу, ~~откуда готовилось нападение~~ как сделать всё самому, буквально за 5 минут.

Создаём новый аккаунт Apple

Открываем Настройки, листаем вниз до раздела Приложения, заходим в Заметки → Учётные записи Заметок → Добавить учётную запись → iCloud.

Загрузка изображений...

0/4

На экране входа нажимаем Создать новый аккаунт Apple → Нет адреса электронной почты? → Получить e-mail в iCloud — Apple сама создаст адрес вида что-то@icloud.com.

Загрузка изображений...

0/3

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

Загрузка изображений...

0/3

Настраиваем новый аккаунт

У нас теперь два аккаунта Apple на одном устройстве: основной — для iCloud, Сообщений и всего остального, новый — только для App Store. Чтобы они не мешали друг другу, нужно отключить в новом аккаунте всё лишнее.

Учётных записей для заметок стало больше на одну. Заходим в неё, открываем iCloud и выключаем все переключатели — Календарь, Контакты, Напоминания. Учётка будет показана как «Неактивна» — так и должно быть.

Загрузка изображений...

0/4

Переключаем App Store на новый аккаунт

Теперь нужно привязать новый аккаунт Apple к App Store. Это делается через раздел Контент и покупки в настройках основного аккаунта.

Заходим в Настройки → [основной аккаунт Apple] → Контент и покупки и нажимаем Выйти.

Загрузка изображений...

0/3

Рядом с «Контент и покупки» появится надпись Настроить. Нажимаем, появится вопрос — от чьего имени настраивать. Выбираем Не [ваше имя]? и входим в новый аккаунт.

Загрузка изображений...

0/4

Меняем регион на США

Открываем App Store — нас встретит экран приветствия. Нажимаем на аватар в правом верхнем углу и заходим в настройки аккаунта.

Загрузка изображений...

0/3

Нажимаем Страна/регион — там сейчас стоит Россия. Выбираем Соединённые Штаты, читаем предупреждение и принимаем условия использования.

Загрузка изображений...

0/4

Следующий экран — способ оплаты. Выбираем Нет и заполняем адрес. Адрес должен быть американским — я использую штат Монтана: там нет налога с продаж, поэтому цены в App Store будут ровно такими, как указано. Индекс должен соответствовать городу — его можно найти в интернете или берите мой из примера. Улицу пишите любую, хоть Sovetskaya. При следующем открытии App Store попросит принять обновлённые условия — соглашаемся.

Загрузка изображений...

0/3

Регион изменён. Теперь доступен американский App Store со всеми его приложениями.

Пополняем баланс

Чтобы оплачивать подписки, нужно пополнить счёт подарочной картой. Я показываю на примере США, потому что меня устраивают ассортимент и цены. Можно изучить и другие регионы — например, Турцию или ОАЭ, где цены на приложения и подписки могут отличаться. Но у каждого региона свои ограничения: в Казахстане, например, нет подписки Apple One.

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

Достаточно удобно это реализовано в приложении Сбера: Платежи → Отдых и развлечения, в поиске пишем Apple. Сбер предлагает карты для ОАЭ, Польши, США, Турции и Франции. Выбираем Apple Card, США, вводим любой живой email, которым пользуетесь — туда придёт письмо с кодом (не тот, что мы только что создали). Выбираем сумму, оплачиваем рублями. Например, подарочная карта на двадцать долларов (что равно подписке ChatGPT) 5 апреля 2026 года обходилась в 1672,55 рублей. Та же подписка, оформленная через сайт днём раньше, обошлась на 200 рублей дороже.

Загрузка изображений...

0/4

Заходим в App Store, открываем аккаунт, нажимаем Активировать карту → Ввести код вручную и вводим полученный код.

Загрузка изображений...

0/2

Готово — баланс пополнен, можно оплачивать подписки.

Бонус: аккаунт живёт в телефоне

Поскольку новый аккаунт Apple добавлен на устройство в учётных записях заметок, а не просто введён в App Store, он никуда не исчезнет, даже если вы им не пользуетесь.

Если вы будете помогать друзьям устанавливать недоступные приложения — коды двухфакторной аутентификации будут приходить push-уведомлением на ваш телефон. Если бы учётка «жила отдельно», коды приходили по СМС или звонку и, если запрашивать их часто, Apple временно приостановит отправку кодов на номер. «Временно» — понятие растяжимое: я однажды ждал больше двух недель.

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

ГдеЯ? geo-сниппеты для России и мира

2026-03-22T00:00:00+00:00

Давайте зайдём на сайт Министерства иностранных дел.

На странице такой серьёзной организации размещены значки некоторых организаций, признанных в России экстремистскими. Чтобы не травмировать вашу психику, я применил к ним эффект стекла (а заодно и к некоторым другим, потому что не знаю, в каком году вы открыли эту статью).

Размещение некоторых значков считается публичной демонстрацией запрещенной экстремистской символики, а значит может примениться административная ответственность по ст. 20.3 КоАП РФ. А если может, значит уже применяется.

И вот как быть серьёзной организации, которая работает не только для России? Помимо нашей страны есть и другие, в которых тоже есть интернет. И там свои варианты дозволенного.

Самый известный пример — GDPR (General Data Protection Regulation), регламент Евросоюза о защите персональных данных. Если ваш сайт посещает пользователь из ЕС, вы обязаны спросить у него разрешение на сбор cookies и объяснить, зачем они нужны. Именно поэтому при первом заходе на европейские сайты вас встречает баннер «Мы используем cookies» — это не прихоть дизайнера, а юридическое требование. Чтобы показывать этот баннер только нужным людям (и не раздражать им всех остальных), сайты и используют геотаргетинг: определяют страну посетителя по IP-адресу и уже тогда решают, что ему показать.

Та же задача встала передо мной, когда я делал промо-страницу для своего приложения ScreenLines. Приложение доступно в App Store, а там пользователи со всего мира. На странице я предлагал промокод на премиум-подписку в обмен на видео: нужно было снять, как клеишь защитное стекло на телефон, и выложить в соцсети. Но в какие именно? ВКонтакте понятен российской аудитории и бесполезен для иностранца. Instagram (принадлежит компании Meta, признанной экстремистской организацией и запрещённой в РФ) и X (Twitter) — наоборот, привычны на Западе, но в России заблокированы. Вот тут и пригодился геотаргетинг. Для посетителей из России — одно предложение, для всех остальных — другое.

Первый подход: цепочка сторонних сервисов

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

ip-api.com — попадает в чёрные списки блокировщиков рекламы, лимит 45 запросов в минуту с одного IP
ipinfo.io — лимит 1000 запросов в сутки на бесплатном тарифе (общий на всех с одного IP)
ipapi.co — аналогично в чёрных списках, бесплатный тариф явно запрещён для коммерческого использования
ipgeolocation.io — требует регистрации и API-ключа

Чтобы не зависеть от одного сервиса, я выстроил цепочку: если первый не ответил — пробуем второй, если и второй не сработал — следующий. Если никто не ответил — на всякий случай показываем российский вариант. Логика разумная, но у неё есть цена: каждый запрос ждёт ответа и только после этого передаёт эстафету следующему. В итоге страница могла подвисать на несколько секунд, пока вся цепочка не отработает.

Но главная проблема обнаружилась позже. В России на мобильном интернете действуют белые списки: без ограничений открываются только одобренные ресурсы, особенно хорошо работает виртуальный хостинг — провайдеры этот вопрос решают. А вот обращение к зарубежному геосервису, например ipinfo.io, попадает под шейпинг — это когда доступ не заблокирован, но скорость намеренно урезана до минимума. Нам нужно получить буквально несколько байт с геоданными, но из-за шейпинга даже этот крошечный запрос может тянуться секунды.

Второй подход: свой сервис

Я решил сделать иначе. Если вы когда-то настраивали хостинг, то могли видеть галочку «доступ к сайту только из РФ». На мой взгляд, абсурднейший флажок — особенно сейчас, когда люди запросто «оказываются в другой стране», как только просыпаются. Но именно эта механика мне и нужна.

Идея: разместить на своём хостинге специальный адрес /geo/ru и закрыть к нему доступ для российских IP. Дальше всё просто: скрипт на странице делает один HEAD-запрос на этот адрес — он не скачивает никакого содержимого, только получает код ответа сервера. Если пришёл 403 (или любая другая ошибка) — значит, доступ закрыт, пользователь в России. Если 200 — пользователь за рубежом.

CDN — российский, запрос к нему не шейпится, ответ приходит мгновенно. Никаких цепочек, никаких зависимостей от сторонних сервисов.

Так появился ГдеЯ — инструмент с открытым исходным кодом, который доступен на GitHub. Можно использовать мой сервис или развернуть собственный.

Как этим пользоваться

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

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

При загрузке страницы скрипт определяет местоположение пользователя по одному HEAD-запросу. За пределами России — показывается международный вариант. В остальных случаях (ошибка, таймаут, Россия) — российский.

Вот как выглядит сниппет для строчного элемента — например, ссылки или кнопки:

<span
  data-gdeya-ru="t9G08LCjEOKFt9C1zEzjsuKIR7Taqd8S4I/m37TfqOISUUBCAgkHFg1dRF1A"
  data-gdeya-intl="t9ZDFwNBQAkKBkQNCwRUDRBeExAVClsdH1tYFBAEHhNTXRxVCAlKGBNGVV9UCAgKDQ5EEgzm37TYqODjsuKGt9e0+bGC4I7m0lhKGF8=">
</span>

А вот пункт списка со ссылками на соцсети. Обратите внимание: data-gdeya-ru пустой — для российских пользователей этот элемент просто не появится:

<li
  data-gdeya-ru=""
  data-gdeya-intl="R0RFWUESEBIKBkQGFQBBQw8UDgcKF0MS...">
</li>

Содержимое закодировано — в исходном коде страницы его не прочитать. Это важно, если вы, например, прячете иконки заблокированных в России соцсетей: они не присутствуют в HTML явно, а раскодируются и подставляются скриптом уже в браузере.

Кстати, МИД тоже мог бы воспользоваться ГдеЯ. Показывать российским пользователям одно, иностранным — другое. Но, видимо, пока не в курсе.

Роутинг для белых списков

2026-02-04T00:00:00+00:00

Все по-разному пользуются интернетом. Для кого-то, это что-то базовое: посидеть в ВК, скинуть квитанцию в чат садика в Максе, посмотреть погоду в яндексе и вызвать там же такси. Бывают и другие сценарии: например, мне нужен YouTube, нейронки и доступ к зарубежным исследованиям и статьям. Всё это мало возможно без VPN. Заходя на какой-то сайт, нужно либо включать его, либо выключать (поэтому я вообще назначил команду на физическую кнопку в телефоне). Обычно он всё же включён и, заходя на тот же Кинопоиск или в приложение Сбера, для сервиса мы выглядим как гражданин Нидерландов. И в этом есть минусы, поскольку для нас могут убрать какие-то фильмы, а перевод вообще заблокировать. С введением так называемых белых списков, когда не работает ничего кроме сайтов из этого списка (у нас в Костроме этот режим стал постоянным — скорость к ресурсам не из БС режется до 0,2 Мб/с), всё стало ещё неудобнее.

Решение 1 — роутинг в приложении

На телефоне я пользуюсь Streisand, куда добавляю свою конфигурацию c VLESS + Reality. Есть и другие вариации (к примеру, v2RayTune или v2Box. Суть и них примерно одинаковая, думаю, движок тоже один. Но именно Streisand мне нравился больше (не добавляет периодически дубликаты профилей, стабильнее находит интернет при смене WiFi на сотовые данные).

Приложение позволяет создать свой роутинг из правил, которые будут выполняться по очереди, а если не выполнится ничего, трафик пойдёт по стандартному маршруту (через VPN).

Загрузка изображений...

0/4

Меня устраивала такая реализация, но хотелось продублировать такую настройку на телефонах друзей и родственников. К счастью, здесь предусмотрена такая опция и маршрутом можно поделиться

    streisand://aW1wb3J0L3JvdXRlOi8vWW5Cc2FYTjBNRERWQVFJREJBVUdCd2dKQ2xSdVlXMWxWSFYxYVdSZVpHOTRZV2x1VTNSeVlYUmxaM2xkWkc5dFlXbHVUV0YwWTJobGNsVnlkV3hsYzFKU1ZWOFFKRGRCUXpneE1qSXdMVEZGTmtNdE5EUXlPQzFDT0VFekxVWXhNVFJGTVVZd01qZERNbGxKVUU5dVJHVnRZVzVrVm1oNVluSnBaS01MUUZEVEJBd05DUTQvVm1SdmJXRnBibHR2ZFhSaWIzVnVaRlJoWjY4UU1BOFFFUklURkJVV0Z4Z1pHaHNjSFI0ZklDRWlJeVFsSmljb0tTb3JMQzB1THpBeE1qTTBOVFkzT0RrNk96dzlQbGd5WjJsekxtTnZiVmN5WjJsekxuSjFXVFEzYm1WM2N5NXlkVnRoYkdaaFltRnVheTV5ZFZ4aGRYUm9MVzV6WkdrdWNuVlhZWFYwYnk1eWRWaGhkbWwwYnk1eWRWaGhkbWwwYnk1emRGNWpaRzR0ZEdsdWEyOW1aaTV5ZFZsalpHNDRkbXN1Y25WWVkybHJjbVl1Y25WWFpIcGxiaTV5ZFZ4bmIzTjFjMngxWjJrdWNuVldaMjkyTG5KMVdHZDFMWE4wTG5KMVcybDZZbWx5YTI5dExuSjFYR3RwYm05d2IybHpheTV5ZFZ4c1pXMWhibUZ3Y204dWNuVlpiRzE5ZFM1MFpXTm9WMjFoYVd3dWNuVldiV0Y0TG5KMVdXMXlZV1I0TG01bGRGVnZheTV5ZFZkdmEyTmtiaTV5VjI5dVpXMWxMbkpYYjNwdmJpNXlkVmh2ZW05dVpTNXlkVnR5WlhNdGJuTmthUzV5ZFZseWRYUjFZbVV1Y25WZGNuVjBkV0psYkdsemRDNXlkVlp5ZW1RdWNuVlhjMkpsY2k1eWRWdHpZbVZ5WW1GdWF5NXlkVlYwTWk1eWRWaDBZbUZ1YXk1eWRWdDFjMlZ5WVhCcExtTnZiVjEyYXkxd2IzSjBZV3d1Ym1WMFZuWnJMbU52YlZWMmF5NXlkVloyZEdJdWNuVlZkMkl1Y25WZWQybHNaR0psY25KcFpYTXVjblZWZWdFdWNuVmFlV0Z1WkdWNExtTnZiVmg1WVc1a1pYZ3VibVYwV1hsaGJtUmxlQzV5ZFZ4NVlYTjBZWFJwWXk1dVpYUmFZbVZsYkdsdVpTNXlkVlprYVhKbFkzVFVCQXhCRFFsQ1RrOVNhWkZyUjBSRlRVZElTVXBMVEUxYmVXOTFkSFZpWlM1amIyMWJhUzU1ZEdsdFp5NWpiMjFiWjNOMFlYUnBZeTVqYjIxZGVYUXpMbWRuY0doMExtTnZiVjhRRDJkdmIyZHNaWFpwWkdWdkxtTnZiVjhRRldSbGRtVnNiM0JsY25NdVoyOXZaMnhsTG1OdmJWOFFGV2R2YjJkc1pYVnlaVzl1YVhSbGNubFZkR1Z1YzI4dVkyOWs=
  

Это прекрасно работало, пока список из доменов не вырос. Теперь при попытке импорта приложение просто вылетает, записывая EXC_BAD_ACCESS (Thread stack size exceeded due to excessive recursion) в отчёт Panic. Я писал разработчику, подробно описывал ситуацию, скидывал пример, но он так и не понял, что я от него хочу. Поэтому идём дальше.

Решение 2 — роутинг в приложении и файл формата geosite

Уважающие себя VPN клиенты (во всех значениях) умеют строить правила опираясь на файлы geosite.dat и geoip.dat. Суть такая: пишем вместо домена что-то типа geoip:ru и все сайты с русским IP-адресом попадают в наше правило. Либо, добавив geosite:google, получаем набор всех доменов, принадлежащих Google. Конечно, кто-то заботливо собирает эти данные, запаковывает в бинарный формат и выкладывает в открытый доступ. Но поиски такой волшебной geosite:ru-whitelisted ничего не дали. Более того, нет вообще какого-то вменяемого списка этих ресурсов (Минцифры публиковало новости в формате “добавлено …”). Самая полная информация есть у операторов сотовой связи. Вот это и было взято за основу для формирования своего списка с доменами.

Создал репозиторий на GitHub, в папке lists разместил два текстовых файла direct.txt и proxy.txt. При изменении репозитория, они скриптом на Go компилируются в файл custom.dat, который, благодаря GithubPages, доступен по отдельному адресу.

Теперь правила можно упросить, убрав список доменов. Но сначала добавим геофайл в приложение.

Заходим в Streisand → Настройки → Роутинг → Настройки → Геофайлы, удаляем преднастроенные источники (свайпом влево), нажимаем сверху Плюс, вставляем https://geofiles.bolotov.dev/custom.dat, включаем автообновление.

Загрузка изображений...

0/2

Теперь правила можно сделать максимально простыми:

Загрузка изображений...

0/3

Заметьте, вместо стандартных IPifNonMatch (IPOnDemand) мы включили AsIS. Поскольку наш спискок содержит только текстовые домены без IP-адресов, проверять, нужен ли VPN, можно не делая запрос к DNS серверу. Казалось бы милисекунды экономии времени, но если есть проблемы с сетью, это становится критичным.

Разумеется, новый роутинг можно добавить через кнопку Плюс на главном экране приложения, скормив приложению QR-код со скрина ниже или это:

    streisand://aW1wb3J0L3JvdXRlOi8vWW5Cc2FYTjBNRERWQVFJREJBVUdCd2dKQ2xSdVlXMWxWSFYxYVdSZVpHOXRZV2x1VTNSeVlYUmxaM2xkWkc5dFlXbHVUV0YwWTJobGNsVnlkV3hsYzF0WGFHbDBaV3hwYzNSbFpGOFFKRGt5T1VJeE0wUkZMVUZDUWtNdE5EaEJRaTA0TTBKR0xUQTBOVFpFTXpGQ1JqUkVSVlJCYzBselZtaDVZbkpwWktJTEVkTUVEQTBKRGhCV1pHOXRZV2x1VzI5MWRHSnZkVzVrVkdGbm9ROWZFQlJsZUhRNlkzVnpkRzl0TG1SaGREcHdjbTk0ZVZWd2NtOTRlZE1FREEwSkVoU2hFMThRRldWNGREcGpkWE4wYjIwdVpHRjBPbVJwY21WamRGWmthWEpsWTNRSUV4Z2RMRHBBVEhONGY0S0prSnlldGJ2Q3hOd0FBQUFBQUFBQkFRQUFBQUFBQUFBVkFBQUFBQUFBQUFBQUFBQUFBQUFBNHc9PQ==
  

а затем включив в настройках

Загрузка изображений...

0/2

Перезапускаем туннель и видим, что для Гугла и Яндекса мы в России, YouTube работает, нейронки тоже.

Загрузка изображений...

0/3

Что может быть прекраснее этого?

О чём не знает iPhone Air

2025-09-11T00:00:00+00:00

После презентации Apple решил узнать и добавить углы скругления экрана в ScreenLines для новых устройств. Установил XCode RC и начал заполнять таблицу.

Для определения радиуса используем значение скрытой переменной. При публикации в AppStore это нужно убрать, поэтому завернём в #if DEBUG, чтобы всё само сделалось.

extension UIScreen {
    static var current: UIScreen? {
        UIWindow.current?.screen
    }
    
    public var deviceCornerRadius: CGFloat {
        let model = UIDevice.current.type
        let radius = model.screenCornerRadius
        
        #if DEBUG
            let actualRadius = self.value(forKey: "_displayCornerRadius") as? CGFloat ?? 0
            print("Model: \(model), stored: \(radius), actual: \(actualRadius)")
        #endif

        return radius
    }
}

И получаем такие же углы, как и в iPhone 16 Pro

extension Model {
    var screenCornerRadius: CGFloat {
        switch self {
            //...
        case .iPhone16Pro, .iPhone16ProMax: 62.0

        case .iPhone17: 62.0
        case .iPhone17Pro: 62.0
        case .iPhone17ProMax: 62.0
        case .iPhoneAir: 62.0
            //...
        }
    }
    //...
}

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

Проверяем на iPhone 17, 17 Pro и 17 Pro Max — такой проблемы нет. Проблема симулятора? XCode Preview тоже срезает углы. Попробуем новый ConcentricRectangle, представленный в iOS 26, который сам подстраивается под родительский элемент?

Проблема осталась (фон покрасил в зелёный чтобы лучше видеть линию и отличать от рамок устройства). Кстати, для iPhone 17 Pro и других устройств этот ConcentricRectangle работает на четыре с минусом (линия угла режется):

В итоге просто исправил таблицу вручную, проверив на каждом устройстве, а ConcentricRectangle убрал. Исправят ли проблему к официальному релизу iOS 26? Или на реальном iPhone Air всё будет по-другому?

RuStore на iPhone. Был ли прав Билан?

2025-08-31T00:00:00+00:00

Возможно ли невозможное? С 1 сентября 2025 года в России вступает в силу закон, обязывающий производителей предустанавливать RuStore на все продаваемые устройства, включая iPhone. Как это можно реализовать на закрытой платформе iOS? И что будет с критически важными функциями вроде push-уведомлений?

Вода, не теки

Закон, подписанный президентом 7 июля 2025 года, запрещает производителям ограничивать установку приложений российских разработчиков и обязует установить наш отечественный магазин приложений. На бумаге всё выглядит просто: купил iPhone — получил RuStore, скачал спокойно сбербанк и всё остальное. Но в реальности Apple не поставляет технику в Россию с марта 2022 года. Все iPhone в российских магазинах — это параллельный импорт через третьи страны. Возможен ли в таких условиях диалог?

Европейский прецедент

В ЕС похожий закон — Digital Markets Act (DMA) — уже заставил Apple открыть iOS для альтернативных магазинов. С iOS 17.4 европейские пользователи могут устанавливать приложения из сторонних источников, но Apple создала настолько сложную систему ограничений, что CEO Epic Games назвал это «злонамеренным соответствием» (malicious compliance).

Финансовые ловушки Apple

Core Technology Fee — «налог на успех»

Apple ввела систему выбора для разработчиков в ЕС:

Старая модель (App Store only):

Стандартная комиссия 30%
Никаких дополнительных сборов
Только распространение через App Store

Новая модель (альтернативные условия):

Пониженные комиссии, но плата €0.50 за каждую установку свыше 1 млн в год
Доступ к альтернативным магазинам и внешним платежам
Пример: приложение с 2 млн пользователей заплатит €500,000 в год дополнительно

Дополнительные комиссии в новой модели:

2% — за привлечение новых пользователей (первые 6 месяцев)
5-13% — сервисная комиссия магазина
5% — Core Technology Commission за внешние платежи

Итого в новой модели: до 20% комиссий + €500,000 фиксированно. Для популярных приложений дешевле остаться на старых условиях с 30% комиссией App Store!

Барьер входа для магазинов

Чтобы создать альтернативный магазин, нужно ЛИБО:

Депозит €1,000,000 в банке с рейтингом A
ИЛИ 2+ года в Apple Developer Program + 1+ млн установок в прошлом году

Психологические и технические препятствия

Пугающие предупреждения

Apple показывает множественные экраны:

⚠️ «Вы можете потерять защиту данных»
⚠️ «Apple не сможет помочь с возвратами»
⚠️ «Возможны проблемы с безопасностью»

Географические ограничения

Работает только в ЕС — система проверяет геолокацию
Apple ID должен быть зарегистрирован в стране ЕС
При выезде из ЕС функции могут перестать работать

Сложная процедура установки

Пользователь должен:

Скачать файл с сайта разработчика
Подтвердить установку в Настройках
Пройти 3-4 экрана предупреждений
Разрешить установку в системных настройках
Подтвердить каждое приложение из магазина отдельно

Скрытый контроль остаётся

Все альтернативные приложения обязательно проходят проверку Apple (Notarization). Apple может заблокировать любое приложение по своему усмотрению, сохраняя фактический контроль над экосистемой.

Результат: формальное соответствие, практический провал

В апреле 2025 года Еврокомиссия оштрафовала Apple на €500 млн за несоответствие духу DMA, но технически Apple выполняет букву закона. Альтернативные магазины существуют, но их доля рынка остаётся мизерной из-за искусственных препятствий.

RuStore на iPhone: возможные сценарии

Депутат Антон Горелкин утверждает, что российский магазин приложений RuStore может до конца 2025 года стать доступен в App Store и войти в список рекомендуемых к установке приложений при первом запуске устройств компании Apple. Рассмотрим технически возможные варианты:

Сценарий 1: Apple идёт на уступки

RuStore появляется как веб-приложение (PWA) с иконкой на рабочем столе
При первой настройке iPhone предлагает «установить» RuStore
Технически это будет закладка в Safari с расширенными возможностями

Сценарий 2: Принудительная авторизация

Apple создаёт специальный API для российского рынка
RuStore получает те же права, что и App Store
Приложения из RuStore проходят полную нотаризацию Apple

Правда пока Apple никогда не создавала исключения для отдельных стран в архитектуре iOS.

Сценарий 3: Россиянам разрешат скачивать и устанавливать .app-файлы.

Мне кажется, для реализации такого подхода достаточно где-то «снять галочку», поскольку это прекрасно работает на Mac OS.

Push-уведомления

Нативные push-уведомления: монополия Apple

Push-уведомления в нативных iOS-приложениях работают исключительно через Apple Push Notification Service (APNS). Для их отправки нужны:

Сертификат разработчика — привязан к Apple Developer Program аккаунту
Bundle ID приложения — должен совпадать с зарегистрированным в Apple
Действующая подписка Developer Program ($99/год)

Web Push: новые возможности PWA

В марте 2023 года Apple добавила поддержку Web Push Notifications в iOS 16.4, что открыло новые возможности для веб-приложений:

Работает без аккаунта Apple Developer Program
Не привязан к App Store
Используется стандарт W3C, совместимый с другими браузерами
Может работать даже при заблокированном домене в App Store

Ограничения Web Push на iOS:

Требует добавления PWA на домашний экран
Работает только при явном согласии пользователя
Менее надёжная доставка по сравнению с APNS
Нет поддержки rich notifications (изображения, кнопки действий)

В целом приложения в формате PWA могут получать push-уведомления, но с ограничениями по сравнению с нативными приложениями.

Что происходит при блокировке аккаунта?

Вместе с удалением приложения из AppStore, Apple обычно блокирует аккаунт разработчика и отзывает push-сертификаты. Даже если приложение работает, push-уведомления зависят от действующего сертификата в Apple Developer Program. При блокировке аккаунта разработчика:

Останавливается доставка push-уведомлений
Приложение не может обновляться
Новые пользователи не могут его установить

Вот почему авито, которое у вас ещё установлено, больше не получает уведомления.

Технические препятствия для RuStore

1. Архитектура iOS

iOS принципиально построена как закрытая система. Каждое приложение должно пройти подпись Apple, иначе система откажется его запускать. Даже в ЕС альтернативные магазины работают через API, предоставленные самой Apple.

2. Sandboxing и права доступа

Приложения в iOS работают в изолированной среде. RuStore не сможет:

Устанавливать другие приложения без участия системы
Получать доступ к файлам других приложений
Обходить системы безопасности

Последствия для пользователей

Согласно закону, устройства без поддержки RuStore будут считаться технически некачественными, но прямого запрета на продажу iPhone нет. Это означает:

Покупатели смогут вернуть iPhone как бракованный товар
Продавцы рискуют получить претензии от Роспотребнадзора
Но сами устройства продолжат поступать через параллельный импорт

Прогноз: что получится на практике

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

RuStore как PWA — полноценное веб-приложение с возможностью установки на домашний экран
Поддержка Web Push — базовые уведомления доступны, но с ограничениями
Каталог PWA-приложений — российские разработчики смогут публиковать веб-приложения с push-поддержкой
Обход Apple Developer Program — не требуются сертификаты Apple для базовой функциональности

Преимущества такого подхода:

Реальная техническая возможность реализации
Независимость от решений Apple
Кроссплатформенность (работает на Android и iOS)
Возможность push-уведомлений через Web Push API

Недостатки:

Ограниченная интеграция с системой
Менее надёжные push-уведомления
Необходимость переписывания существующих нативных приложений

Техническая реальность vs политические амбиции

История с RuStore на iPhone — яркий пример того, как политические решения сталкиваются с техническими реалиями. Даже в ЕС, где Apple была вынуждена открыть платформу, альтернативные магазины не смогли серьёзно потеснить App Store.

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

Итог: Опыт ЕС показывает, что RuStore на iPhone скорее всего станет PWA-платформой с искусственными ограничениями. Apple создаст формальное соответствие российскому закону, но с системой препятствий (предупреждения, сложная установка, ограниченная функциональность), которая сделает альтернативный магазин малопривлекательным для массового пользователя.

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

Зачем так сложно?

Ну и главный вопрос: почему на той же MacOS можно спокойно скачать и установить *.app файл и пользоваться им, а на iPhone так же сделать не разрешают? Может для России всё же сделают исключение? Я уже зарегистрировал в RuStore аккаунт (за это не просят $99/год). Всё, что нужно для этого — учётная запись VK. В личном кабинете у вас даже не будет возможности редактировать информацию о себе — всё делается через почту поддержки. Но (на удивление) отвечают они моментально: мой вопрос решили минут за 10, в выходной день. И всё же надеюсь, мы вернёмся в мир, где не нужны ни RuStore, ни «Вжух»

ScreenLines: обгоняем Столото и Парковки России. Моё новое приложение

2025-08-10T00:00:00+00:00

4700 скачиваний за три дня. 34 место в топе утилит App Store России. Приложение недели в сообществе Indie iOS Apps. И всё это — приложение, которое просто показывает белую линию на экране.

Загрузка изображений...

0/6

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

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

В сервисных центрах за установку стекла берут от 500 до 2000 рублей, но и там их ставят «на глазок». Некоторые стёкла продаются с аппликаторами. Только зачем платить за одноразовую пластиковую рамку, которая в итоге займёт место в мусорном ведре?

От лайфхака к продукту

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

Проверил идею на друзьях и детях. Даже те, у кого «руки не из того места», смогли наклеить стекло идеально с первого раза. Возможно, главную роль играет скорость — вы сразу видите результат.

Вероника клеит стёкла сама

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

Пошаговую инструкцию с видео-туториалом
Систему оценки результата и статистику
Весёлое конфетти, если человек доволен результатом
Полноценный сайт с калькулятором экономии, политикой конфиденциальности, условиями использования
Поддержку всех iPhone и iPad

Разработка началась в январе 2024 года. Казалось бы, что сложного — нарисовать линию?

Техническая кухня

80 моделей — 80 радиусов

Белая линия должна идеально повторять радиус скругления iPhone. iOS может определить радиус программно, но Apple запрещает использовать приватные методы. Спасибо, что можно получить идентификатор модели: например, iPhone17,1 — это iPhone16 Pro, iPhone17,5 — iPhone 16e. Для 11 дюймового iPad Air на M3 сразу четыре идентификатора: iPad15,3, iPad15,4, iPad15,5, iPad15,6.

Поэтому делаем таблицу радиусов, сопоставляем модели и рисуем. Выглядит она примерно так:

extension Model {
    var screenCornerRadius: CGFloat {
        switch self {    
        // ... 
        case .iPhone12ProMax, .iPhone13ProMax, .iPhone14Plus: 53.33
            
        case .iPhone12Mini, .iPhone13Mini: 44.0
                
        case .iPhone14Pro, .iPhone14ProMax, .iPhone15, .iPhone15Plus,
                .iPhone15Pro, .iPhone15ProMax, .iPhone16, .iPhone16Plus: 55.0
            
        case .iPhone16Pro, .iPhone16ProMax: 62.0
        // ... 

HLS вместо встроенного видео

Одно из ключевых технических решений в ScreenLines — использование HLS (HTTP Live Streaming) для видеоинструкции вместо обычного встроенного файла.

HLS — это протокол потокового видео, разработанный Apple. Вместо одного большого файла видео разбивается на множество коротких сегментов (обычно по 6-10 секунд), которые загружаются по мере необходимости. Каждый сегмент — это обычный .ts файл, а .m3u8 содержит список всех сегментов и метаданные.

Почему не просто файл в приложении?

Размер: 6 МБ вместо 50+
Гибкость: можно обновить видео без релиза
Локализация: разные языки без раздувания

HLS разбивает видео на короткие сегменты по 6-10 секунд. Вместо загрузки всего файла AVPlayer подгружает только нужные части:

Сегментация: Видео нарезается на мелкие кусочки
Адаптация: Плеер автоматически выбирает качество под скорость сети
Кэширование: Просмотренные сегменты остаются в памяти

Некоторые мелочи, недоступные картинке с прямоугольником:

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

Эволюция помощников

Проекту нужен сайт. Использовал ChatGPT, DeepSeek, Qwen, Gemini — все изображали бурную деятельность, но результат был так себе. Claude оказался единственным, кто подходит для работы. Давно купил подписку и сейчас использую везде. Даже на платной версии есть лимиты на количество сообщений, но результат стоит того.

С енотом, кстати, вышло случайно — просил разные нейросети рисовать что-то абсурдное. ChatGPT предложил такую идею.

Загрузка изображений...

0/3

Калькулятор экономии

Claude предложил калькулятор — простую, но интересную штуку. Составили таблицу устройств с ценами и простейшей математикой.

const devices = [
    { "model": "iPhone 16 Pro", "serviceCost": 2000, "selfCost": 700 },
    { "model": "iPhone 16 Pro Max", "serviceCost": 2000, "selfCost": 550 },
    // ... 
]

const totalSavings = totalServiceCost - totalSelfCost

Результаты взлёта

4700 скачиваний за первые 3 дня
34 место в топе утилит русского App Store
Обогнали «Парковки России и «Столото»
География: Россия, Нидерланды, Германия, США
Оценка: 4.9

Приложение попало в топ за три дня. Без затрат на продвижение.

Загрузка изображений...

0/4

А ещё получило звание Indie App of the Week

Загрузка изображений...

0/2

Отзывы

А теперь оценки пользователей:

Загрузка изображений...

0/4

Что дальше?

С MacBook и терпением можно создать продукт, который займёт своё место в App Store и будет доступен во всём мире. Да, вам не обязательны дизайнеры, аудиторы и куча бюрократии. Не нужно согласовывать ни с кем ничего. Просто делайте. ScreenLines показал: в App Store всегда есть место для простых, но полезных решений. Не обязательно создавать сложные платформы — иногда достаточно элегантно решить одну проблему. Но дело не только в этом. Приложение вряд ли так быстро вылезло в топ, если бы о нём не рассказал блогер с аудиторией 788k подписчиков.

Загрузка изображений...

0/4

Если приложение висит в топе, значит его кто-то скачивает. А это результат продвижения и маркетинга. И это то, что мне предстоит освоить.

P.S. Если у вас iPhone — попробуйте ScreenLines. Бесплатно.

P.P.S. Енот передаёт привет 👋

P.P.P.S. Оказывается, Георгий Лямин, главред iGuides, тоже написал про ScreenLines в своём канале. Спасибо!

Ссылки

ServiceLocator и @Injected: как упростить работу с зависимостями в iOS

2025-06-07T00:00:00+00:00

Представьте, что вы строите дом. У вас есть электрик, сантехник, маляр — каждый специалист отвечает за свою часть работы. В программировании похожая ситуация: у нас есть разные сервисы (службы), каждый из которых выполняет свою задачу. Сегодня расскажу, как удобно организовать работу с такими сервисами в iOS-приложении на SwiftUI.

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

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

Сервис для работы с сетью
Сервис для сохранения данных
Сервис аналитики
И так далее…

Без правильной организации код быстро превращается в спагетти, где всё зависит от всего.

Решение: ServiceLocator

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

Вот как это выглядит в коде:

final class ServiceLocator {
    // Singleton instance for the entire app
    static let shared = ServiceLocator()
    
    // Dictionary to store all services
    private lazy var services = [String: Any]()
    
    // Register a new service
    func addService<T>(service: T) {
        let key = String(describing: T.self)
        services[key] = service
    }
    
    // Get a service
    func getService<T>() -> T {
        let key = String(describing: T.self)
        guard let service = services[key] as? T else {
            fatalError("Service of type \(T.self) is not registered!")
        }
        return service
    }
}

Магия @propertyWrapper

Но постоянно писать ServiceLocator.shared.getService() — утомительно. Здесь на помощь приходит возможность Swift создавать собственные «обёртки» для свойств. Это как автоматический дозатор мыла — вы просто подносите руки, а он сам выдаёт нужное количество.

@propertyWrapper
struct Injected<Service> {
    private lazy var service: Service = ServiceLocator.shared.getService()
    
    var wrappedValue: Service {
        mutating get { service }
    }

    public var projectedValue: Injected<Service> {
        get { self }
        set { self = newValue }
    }
}

Важность протоколов: контракт вместо реализации

Представьте, что вы нанимаете водителя. Вам важно, что он умеет водить машину, а не то, какой марки у него права. В программировании протоколы работают так же — они описывают, ЧТО должен уметь делать сервис, а не КАК он это делает.

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

Допустим, вы создали приложение, которое сохраняет данные в iCloud. Но потом решили, что хотите сохранять их локально. Если вы использовали протоколы, то замена будет простой как щелчок выключателя.

Вот пример:

// Protocol describes WHAT the storage service should do
protocol StorageServiceProtocol {
    func save(data: String, key: String)
    func load(key: String) -> String?
    func delete(key: String)
}

// Implementation for iCloud
class CloudStorageService: StorageServiceProtocol {
    func save(data: String, key: String) {
        print("Saving to iCloud: \(data)")
        // Code to work with iCloud
    }
    
    func load(key: String) -> String? {
        print("Loading from iCloud")
        return "data from cloud"
    }
    
    func delete(key: String) {
        print("Deleting from iCloud")
    }
}

// Implementation for local storage
class LocalStorageService: StorageServiceProtocol {
    func save(data: String, key: String) {
        print("Saving locally: \(data)")
        // Code to work with UserDefaults
    }
    
    func load(key: String) -> String? {
        print("Loading locally")
        return "local data"
    }
    
    func delete(key: String) {
        print("Deleting locally")
    }
}

Магия замены

Теперь смотрите, как просто поменять реализацию:

// Choose implementation when app starts
if userHasInternet {
    ServiceLocator.shared.addService(service: CloudStorageService() as StorageServiceProtocol)
} else {
    ServiceLocator.shared.addService(service: LocalStorageService() as StorageServiceProtocol)
}

// No need to change anything in the app code!
struct SettingsView: View {
    @Injected private var storage: StorageServiceProtocol
    @State private var userName = ""
    
    var body: some View {
        VStack {
            TextField("Your name", text: $userName)
            
            Button("Save") {
                storage.save(data: userName, key: "user_name")
            }
        }
        .onAppear {
            userName = storage.load(key: "user_name") ?? ""
        }
    }
}

Как это работает на практике в SwiftUI

Шаг 1: Создаём протокол и реализацию

// Protocol for network operations
protocol NetworkServiceProtocol {
    func loadUserData() async throws -> UserData
    func sendAnalytics(event: String)
}

// Real implementation
class NetworkService: NetworkServiceProtocol {
    func loadUserData() async throws -> UserData {
        // API call code here
        return UserData(name: "Artem", email: "ar@bolotov.dev")
    }
    
    func sendAnalytics(event: String) {
        print("Sending analytics: \(event)")
    }
}

// Mock implementation for development
class MockNetworkService: NetworkServiceProtocol {
    func loadUserData() async throws -> UserData {
        // Return test data without server call
        return UserData(name: "Test User", email: "test@example.com")
    }
    
    func sendAnalytics(event: String) {
        print("TEST: \(event)")
    }
}

// Data model
struct UserData {
    let name: String
    let email: String
}

Шаг 2: Регистрируем сервисы в точке входа

@main
struct MyApp: App {
    init() {
        setupServices()
    }
    
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
    
    private func setupServices() {
        #if DEBUG
        // Use mock services in development
        ServiceLocator.shared.addService(service: MockNetworkService() as NetworkServiceProtocol)
        #else
        // Use real services in production
        ServiceLocator.shared.addService(service: NetworkService() as NetworkServiceProtocol)
        #endif
        
        // Register other services
        ServiceLocator.shared.addService(service: AnalyticsService() as AnalyticsServiceProtocol)
        ServiceLocator.shared.addService(service: KeychainService() as KeychainServiceProtocol)
    }
}

Шаг 3: Используем в SwiftUI Views

struct ProfileView: View {
    @Injected private var network: NetworkServiceProtocol
    @Injected private var analytics: AnalyticsServiceProtocol
    
    @State private var userData: UserData?
    @State private var isLoading = false
    @State private var errorMessage: String?
    
    var body: some View {
        NavigationView {
            VStack {
                if isLoading {
                    ProgressView()
                        .padding()
                } else if let userData = userData {
                    VStack(spacing: 20) {
                        Text("Hello, \(userData.name)!")
                            .font(.title)
                        
                        Text(userData.email)
                            .foregroundColor(.secondary)
                    }
                    .padding()
                } else if let error = errorMessage {
                    Text(error)
                        .foregroundColor(.red)
                        .padding()
                }
                
                Button("Reload") {
                    Task {
                        await loadUserData()
                    }
                }
                .buttonStyle(.borderedProminent)
            }
            .navigationTitle("Profile")
            .onAppear {
                analytics.trackEvent("ProfileView opened")
                Task {
                    await loadUserData()
                }
            }
        }
    }
    
    private func loadUserData() async {
        isLoading = true
        errorMessage = nil
        
        do {
            userData = try await network.loadUserData()
            analytics.trackEvent("User data loaded")
        } catch {
            errorMessage = "Failed to load data: \(error.localizedDescription)"
            analytics.trackEvent("User data load failed")
        }
        
        isLoading = false
    }
}

Продвинутый пример: ObservableObject с сервисами

Часто в SwiftUI нужно использовать сервисы внутри ObservableObject:

// Protocol for authentication
protocol AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User
    func logout()
    var isAuthenticated: Bool { get }
}

// ViewModel using services
class AuthViewModel: ObservableObject {
    @Injected private var authService: AuthServiceProtocol
    @Injected private var analytics: AnalyticsServiceProtocol
    
    @Published var isLoading = false
    @Published var errorMessage: String?
    @Published var isAuthenticated = false
    
    func login(email: String, password: String) async {
        await MainActor.run {
            isLoading = true
            errorMessage = nil
        }
        
        do {
            let user = try await authService.login(email: email, password: password)
            analytics.trackEvent("Login successful", parameters: ["user_id": user.id])
            
            await MainActor.run {
                isAuthenticated = true
                isLoading = false
            }
        } catch {
            analytics.trackEvent("Login failed")
            
            await MainActor.run {
                errorMessage = error.localizedDescription
                isLoading = false
            }
        }
    }
    
    func logout() {
        authService.logout()
        analytics.trackEvent("User logged out")
        isAuthenticated = false
    }
}

// SwiftUI View using ViewModel
struct LoginView: View {
    @StateObject private var viewModel = AuthViewModel()
    @State private var email = ""
    @State private var password = ""
    
    var body: some View {
        Form {
            TextField("Email", text: $email)
                .textContentType(.emailAddress)
                .autocapitalization(.none)
            
            SecureField("Password", text: $password)
                .textContentType(.password)
            
            if let error = viewModel.errorMessage {
                Text(error)
                    .foregroundColor(.red)
                    .font(.caption)
            }
            
            Button(action: {
                Task {
                    await viewModel.login(email: email, password: password)
                }
            }) {
                if viewModel.isLoading {
                    ProgressView()
                } else {
                    Text("Login")
                }
            }
            .disabled(viewModel.isLoading || email.isEmpty || password.isEmpty)
        }
        .navigationTitle("Login")
    }
}

Практический пример: переключение окружений

// Protocol for configuration
protocol ConfigServiceProtocol {
    var apiBaseURL: String { get }
    var environment: Environment { get }
}

enum Environment {
    case development
    case staging
    case production
}

// Different implementations
class DevConfigService: ConfigServiceProtocol {
    var apiBaseURL = "https://dev-api.example.com"
    var environment = Environment.development
}

class ProdConfigService: ConfigServiceProtocol {
    var apiBaseURL = "https://api.example.com"
    var environment = Environment.production
}

// Settings view to switch environments
struct SettingsView: View {
    @Injected private var config: ConfigServiceProtocol
    
    var body: some View {
        List {
            Section("Environment") {
                Label(config.environment.rawValue, systemImage: "server.rack")
                Text(config.apiBaseURL)
                    .font(.caption)
                    .foregroundColor(.secondary)
            }
        }
        .navigationTitle("Settings")
    }
}

Советы для SwiftUI разработчиков

1. Используйте @Injected в View напрямую

struct ContentView: View {
    @Injected private var network: NetworkServiceProtocol
    
    var body: some View {
        // Use service directly in view
    }
}

2. Для StateObject создайте фабричный метод

extension ServiceLocator {
    func makeAuthViewModel() -> AuthViewModel {
        return AuthViewModel()
    }
}

struct RootView: View {
    @StateObject private var authViewModel = ServiceLocator.shared.makeAuthViewModel()
    
    var body: some View {
        // Your view code
    }
}

3. Группируйте регистрацию по смыслу

extension ServiceLocator {
    func registerNetworkServices() {
        addService(service: APIService() as APIServiceProtocol)
        addService(service: ImageLoader() as ImageLoaderProtocol)
    }
    
    func registerStorageServices() {
        addService(service: KeychainService() as KeychainServiceProtocol)
        addService(service: UserDefaultsService() as UserDefaultsServiceProtocol)
    }
}

Заключение

ServiceLocator с @Injected и протоколами отлично работает в SwiftUI приложениях. Вы получаете простоту использования, чистый код и возможность легко менять реализацию сервисов.

Помните: протокол — это контракт между частями вашего приложения. Он говорит «что делать», а реализация решает «как делать». Это даёт свободу менять «как» без изменения «что».

Начните использовать этот подход в своих SwiftUI проектах — и вы удивитесь, насколько проще станет организовывать код и добавлять новые функции!

Как я перешёл с Google Analytics на Яндекс.Метрику

2025-05-30T00:00:00+00:00

С 1 июля 2024 года вступили в силу изменения в законодательстве, которые ограничивают использование Google Analytics для российских сайтов. Расскажу, как перенёс аналитику на Яндекс.Метрику и настроил всё правильно с точки зрения защиты персональных данных.

Почему пришлось уходить

Новые требования ограничивают передачу данных российских пользователей в страны, которые не обеспечивают должный уровень защиты персональных данных. Google Analytics хранит всё на серверах в США, что теперь создаёт правовые риски.

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

Что понадобится

Для миграции нужно:

Аккаунт в Яндексе
Доступ к коду сайта
Понимание, где сейчас установлен Google Analytics

Создание счётчика

Процесс довольно простой:

Заходим на metrika.yandex.ru
Нажимаем «Добавить счётчик»
Указываем адрес сайта
Получаем код

Но не спешите его сразу устанавливать.

Главное правило — счётчик должен запускаться только после явного согласия пользователя на использование cookies.

Базовый код

<!-- Yandex.Metrika counter -->
<script type="text/javascript">
   (function(m,e,t,r,i,k,a){
      m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)};
      m[i].l=1*new Date();
      for (var j = 0; j < document.scripts.length; j++) {
         if (document.scripts[j].src === r) { return; }
      }
      k=e.createElement(t),a=e.getElementsByTagName(t)[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)
   })(window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym");

   window.yaCounterInit = false;
</script>
<!-- /Yandex.Metrika counter -->

Логика запуска

const initYandexMetrika = function() {
    if (typeof ym !== 'undefined' && !window.yaCounterInit) {
        ym(12345678, "init", {
            clickmap: true,
            trackLinks: true,
            accurateTrackBounce: true,
            webvisor: true
        });
        window.yaCounterInit = true;
    }
}

// Проверяем сохранённое согласие
if (localStorage.getItem('cookies_accepted')) {
    initYandexMetrika();
} else {
    document.getElementById('cookie-banner').style.display = 'block';
}

// Обработка согласия
document.getElementById('accept-cookies').addEventListener('click', function() {
    localStorage.setItem('cookies_accepted', 'true');
    document.getElementById('cookie-banner').style.display = 'none';
    initYandexMetrika();
});

Простой баннер внизу экрана

Важный момент про noscript

Яндекс.Метрика предлагает добавить такой код для пользователей без JavaScript:

<!-- Не используйте это -->
<noscript>
  <div><img src="https://mc.yandex.ru/watch/12345678" style="position:absolute; left:-9999px;" alt="" /></div>
</noscript>

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

Настройка параметров

Рекомендуемые настройки:

ym(12345678, "init", {
    clickmap: true,           // Карта кликов
    trackLinks: true,         // Отслеживание внешних ссылок
    accurateTrackBounce: true,// Точный показатель отказов
    webvisor: false,          // Лучше отключить для соблюдения GDPR
    ecommerce: "dataLayer"    // Для интернет-магазинов
});

Частые проблемы

Данные не поступают

Блокировщики рекламы. AdBlock и подобные расширения блокируют счётчики. Для тестирования временно отключите их.

Проблемы с геолокацией. Если ваш трафик идёт через зарубежные серверы (корпоративная сеть, спутниковый интернет), Метрика может некорректно определять местоположение.

Режим инкогнито. В приватном режиме localStorage работает только до закрытия окна.

Проверка работы

Откройте консоль разработчика (F12)
Перейдите на вкладку Network
Введите в фильтр mc.yandex
Обновите страницу и дайте согласие
Проверьте, что запросы отправляются

Перенос целей

Если использовали цели в Google Analytics, их нужно адаптировать:

// Google Analytics
gtag('event', 'purchase', {
    value: 1000,
    currency: 'RUB'
});

// Яндекс.Метрика
ym(12345678, 'reachGoal', 'purchase', {
    order_price: 1000,
    currency: 'RUB'
});

Чек-лист после миграции

Удалён код Google Analytics
Установлена Яндекс.Метрика
Настроен запуск после согласия
Удалён noscript-код
Проверена работа в разных браузерах
Обновлена политика конфиденциальности
Перенесены важные цели

Итог

Переход на Яндекс.Метрику — вынужденная, но не такая уж страшная мера. Основной функционал похож, есть свои интересные возможности вроде карты скроллинга и аналитики форм. Главное — правильно настроить с учётом требований о защите персональных данных.

Как я пытался зарегистрировать iOS-приложение в реестре российского ПО

2025-05-28T00:00:00+00:00

С чего всё началось

У меня есть приложение TwinKey — это такой российский аналог Google Authenticator для двухфакторной аутентификации. И вот подумал я: раз уж все говорят про импортозамещение, почему бы не зарегистрировать своё детище в официальном реестре отечественного ПО?

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

Заходя на подобные ресурсы, испытываю особую гордость за Страну

Авторизация через Госуслуги (но это не точно)

Начинается всё вроде бы логично — вход через Госуслуги. Думаю: «Отлично! Все мои данные там есть, сейчас всё само подтянется».

Ага, как же! После успешного входа система радостно предлагает заполнить:

ФИО (которое только что взяла с Госуслуг)
Паспорт (тоже оттуда)
Адрес (и он там есть!)
СНИЛС, ИНН и всё остальное (зачем вообще, если уже связали заявление и мой профиль?)

Получается, Госуслуги нужны просто чтобы убедиться, что ты — это ты и как аналог дорогой капчи. А потом всё равно перепиши всё руками. Логика уровня «покажи паспорт, а теперь перепиши его от руки в эту тетрадочку».

Техническая документация для гуманитариев

Дальше начинается самое интересное. Система просит описать техническую архитектуру. Звучит разумно, да? Но когда читаешь примеры и подсказки, понимаешь — форму составляли люди, которые последний раз видели код в фильме «Матрица».

Где живёт твой код?

Мой любимый пункт: «Адрес нахождения технических средств хранения исходного текста».

Ребята, это 2025 год! Мой код живёт:

На MacBook (который ездит со мной везде)
На GitHub (это где-то в облаках)
В iCloud (ещё выше в облаках)

Что писать? «Россия, переносное устройство»? Или честно: «Сегодня код уехал вместе со мной на ТО в Ярославль, завтра будет дома, послезавтра — на природе отдохнёт»?

И главное — нужен документ, подтверждающий этот адрес! Может, справку у дилера взять? «Подтверждаем, что Артём действительно сидел у нас с ноутбуком».

Про хранение кода

Ещё просят «документацию с описанием технических средств хранения».

Представляю, как пишу:

Для хранения исходного кода программного обеспечения TwinKey используется персональный компьютер MacBook Pro 14″ 2021 года выпуска серийный номер XXX, оборудованный твердотельным накопителем емкостью 512 ГБ производства Samsung, файловая система APFS с включенным шифрованием FileVault 2 на базе алгоритма AES-256… Ещё есть GitHub — это такой сайт в интернете, где тоже можно код хранить. Он там хранится, наверное, на дисках, но уже не моих.

Дайте нам ваше приложение!

Следующий квест: предоставить «экземпляр программного обеспечения для проверки».

Друзья, это iOS-приложение! Оно в App Store лежит! Хотите проверить — берите iPhone и качайте. Но нет, нужна инструкция по установке.

Пришлось писать пошаговое руководство уровня:

Возьмите iPhone (это такой прямоугольник с яблоком сзади)
Найдите иконку App Store (синяя такая, с буквой А)
Нажмите на неё пальцем
В поиске наберите TwinKey
Нажмите «Загрузить»
Поздравляю, вы великолепны!

Один в поле воин

Особенно повеселил раздел про персонал и организационную структуру. У них там, видимо, представление, что любое ПО делает минимум отдел из 20 человек.

А у меня структура простая:

CEO/CTO/Разработчик/Тестировщик/Дизайнер/Менеджер: я
Отдел поддержки: тоже я
Служба безопасности: опять я
Отдел контроля качества: и это я
Юридический департамент: ChatGPT (шутка, но только отчасти)

Пришлось креативить с формулировками. Вместо «делаю всё сам» писал что-то вроде «централизованная модель управления с полным циклом ответственности».

ЭЦП — привет из прошлого

Чтобы отправить все эти документы, нужна электронная подпись. Не просто подпись, а квалифицированная!

Это значит:

Найти удостоверяющий центр (звучит как что-то из шпионского фильма)
Прийти туда лично с паспортом
Заплатить пару тысяч рублей
Получить флешку (в 2025 году)
Обнаружить, что у флешки разъём USB-A, а у твоего MacBook только USB-C
Искать переходник или хаб (ладно, есть у меня)
Установить программы с интерфейсом из Windows 98
Помолиться, чтобы всё заработало

И всё это чтобы подписать PDF-файл, который можно было бы отправить обычным email’ом. Но нет, нужна квалифицированная подпись! Потому что… потому что так надо!

А зачем вообще?

Пока разбирался со всеми этими требованиями, начал искать — а какие вообще плюсы даёт регистрация? Что получу, когда пройду все круги этого квеста?

Внятного ответа так и не нашёл. Вроде как при госзакупках отечественное ПО в приоритете. Но мой аутентификатор вряд ли будут закупать министерства пачками.

Может, какие-то льготы? Тоже непонятно. Продвижение? Сомнительно.

Получается, регистрация нужна… чтобы быть зарегистрированным? Глубоко.

Что в итоге?

Посмотрел я на всю эту красоту и решил: а давайте-ка пока подождём. Поставил регистрацию на паузу по нескольким причинам:

Время. Чтобы собрать все документы и правильно заполнить формы, нужно потратить кучу времени. А его лучше потратить на улучшение приложения.
Деньги. ЭЦП стоит денег, продлевать её каждый год — тоже. И ради чего?
Неопределённость. Когда непонятно, какие преимущества получишь, сложно мотивировать себя проходить через все эти испытания.
Здравый смысл. Иногда полезно остановиться и подумать: а оно мне надо?

Мораль

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

Знаете, система регистрации явно создавалась людьми, которые представляют разработку ПО как производство танков на заводе в Туле. У них в голове есть цеха с компьютерами, на которых висят инвентарные номера, есть журналы учёта исходного кода, и каждый файл проштампован печатью ОТК.

Представьте, как было бы круто:

Зашёл через госуслуги — все данные подтянулись
Указал ссылку на GitHub — система сама всё проверила
Дал ссылку на App Store — не нужно писать инструкции
Подписал прямо в браузере — без флешек и КриптоПро
Получил сертификат и чёткий список преимуществ

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

А пока — качайте TwinKey! Он хоть и не в реестре, но работает отлично. И для установки не нужна инструкция на 20 страниц 😊

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

Где разместить сайт: простые решения для разработчиков

2025-04-30T00:00:00+00:00

Каждый iOS-разработчик (и не только) рано или поздно сталкивается с необходимостью создания сайта для своего приложения. Это не просто дань моде — при публикации в App Store вы обязательно должны указать ссылку на политику конфиденциальности. К тому же сайт делает ваш проект более доступным для поисковых систем и потенциальных пользователей.

Но что делать, если основная сфера ваших интересов — это само приложение, а сайт нужен лишь как дополнение? Тратить время на изучение тонкостей хостинга, настройку серверов и мониторинг нагрузки совсем не хочется. Особенно когда речь идёт о простом сайте с описанием, парой красивых скриншотов и, возможно, небольшим промо-видео. App Store требует обязательную ссылку на политику конфиденциальности. И пусть она ведёт на ваш сайт.

Загрузка изображений...

0/2

Домен и хостинг — разные вещи

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

Домен (например, twinkey.app или calendar.red) вы можете приобрести в любом удобном регистраторе: timeweb, REG.RU, namecheap, spaceship и других. А вот где будет физически размещён ваш сайт — это уже вопрос выбора хостинга.

Хорошая новость — для простых проектов есть отличные бесплатные решения.

GitHub Pages: просто по-гиковски

Если вы уже пользуетесь Git для хранения кода своих проектов, то GitHub Pages — идеальное решение. Именно на нём размещён и этот блог, который вы сейчас читаете.

Принцип работы:

Создаёте репозиторий на GitHub с названием username.github.io
Загружаете туда HTML, CSS и JavaScript файлы (или используете генератор статических сайтов вроде Jekyll)
GitHub автоматически публикует ваш сайт по адресу username.github.io

Бесплатный хостинг, правда с регистрацией и смс

Если хотите использовать свой домен, это тоже не проблема — достаточно настроить DNS-записи и указать его в настройках репозитория.

А если прописать A и CNAME DNS записи по инструкции, можно и свой домен подключить

Преимущества GitHub Pages:

Абсолютно бесплатно для публичных репозиториев
Неограниченный трафик
Поддержка HTTPS из коробки
Интеграция с системой контроля версий
Автоматическое обновление сайта при изменении файлов

Есть и ограничения: сайт должен быть статическим (никакого PHP или других серверных языков), а размер репозитория не должен превышать 1 ГБ.

Firebase Hosting: когда нужно чуть больше

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

Особенности Firebase Hosting:

Интеграция с другими сервисами Firebase
Глобальная CDN от Google
HTTPS по умолчанию
Удобный CLI-интерфейс для деплоя
Возможность создания динамических приложений с Firebase Functions

Настройка тоже предельно проста:

# Install Firebase CLI
npm install -g firebase-tools

# Login to your account
firebase login

# Initialize project
firebase init hosting

# Deploy your site
firebase deploy --only hosting

Что по-настоящему выделяет Firebase — возможность создания интерактивных сайтов без необходимости настройки бэкенда. Вы можете подключиться к Firestore прямо из JavaScript, добавить аутентификацию и даже использовать серверные функции для более сложной логики.

Яндекс.Облако и его аналоги

Стоит упомянуть и отечественные решения. Яндекс.Облако предлагает сервис Object Storage, который можно настроить для хостинга статических сайтов. Принцип похож на Amazon S3 — вы загружаете файлы в бакет и настраиваете его как веб-сайт.

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

Сам не пользовался, но рассказать про это нужно.

Что выбрать?

Мой опыт показывает, что:

GitHub Pages отлично подходит для личных сайтов, резюме, блогов и небольших проектов. Особенно если вы уже используете GitHub и знакомы с Markdown.
Firebase Hosting — лучший выбор, если вы используете другие сервисы Firebase в своём приложении или планируете добавить интерактивность на сайт.
Яндекс.Облако стоит рассмотреть, если важна скорость доступа в России и соответствие ФЗ-152.

Заключение

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

Мой TwinKey использует Firebase, а этот блог работает на GitHub Pages — оба решения отлично справляются со своими задачами и не требуют практически никакого обслуживания. Это позволяет сосредоточиться на том, что действительно важно — разработке качественных приложений.

Личный блог: испытание свободой

2025-04-29T00:00:00+00:00

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

Это не ностальгия по «старым добрым временам» (хотя куда без неё 😊). Просто хочется иметь место, где можно спокойно делиться чем-то без ограничений формата и алгоритмов социальных платформ.

Свобода творчества без рамок

Я пробовал писать статьи на Медиуме, Яндекс.Дзене, vc.ru и в телеграме. И всегда раздражал жёсткий формат. Особенно в телеграме, где каждый пост — это либо текст, либо картинка с подписью, либо видео, либо каша.

А здесь, на сайте, можно делать всё, что захочется:

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

О видео и чтении

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

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

Кроме того, у текста есть особая магия времени. Помните это чувство, когда находишь свои старые записи — школьные тетради, письма, заметки в блокноте? Перечитываешь и будто возвращаешься в тот момент, вспоминаешь, о чём думал тогда.

И ещё один практический момент: по тексту работает поиск. В видео придётся перематывать туда-сюда, пытаясь вспомнить, на какой минуте была нужная информация.

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

Машина времени в действии

В соцсетях всё привязано к конкретному моменту: пост от вчерашнего дня уже считается «старым». На своём сайте можно:

Написать статью с любой датой — хоть из прошлого, хоть из будущего
Поделиться воспоминаниями о событиях прошлых лет, когда блога ещё не было
Обновить старую публикацию, добавив новые мысли или исправив устаревшие данные

Классно же? Своя небольшая машина времени!

Гугл тебя найдёт

Пока что это больше теория, чем практика. Блог только запустился, и посетителей из поиска ещё нет. Но я верю в долгосрочную перспективу.

В телеграм-канале всё работало просто: написал пост, поделился ссылкой — люди прочитали. Через пару дней пост теряется, и шансов, что его кто-то найдёт, практически нет.

С блогом должно быть иначе. Хорошая статья про SwiftUI или решение какой-то технической проблемы может приводить читателей месяцами и даже годами. Конечно, для этого нужно время и хорошие статьи: пока поисковики проиндексируют, пока статьи начнут ранжироваться… Но это как раз тот случай, когда попробуем играть вдолгую.

Посмотрим, что получится. Надеюсь, этот раздел не придётся переписывать 😊

Сам себе хозяин

На большинстве платформ мы всегда зависим от чужих правил и алгоритмов.

А здесь полностью контролируем процесс:

Статья может быть любой длины
Никто не заблокирует контент из-за «нарушения правил»
Дизайн и оформление — только по вашему вкусу
Никаких внезапных глобальных обновлений, которые всё могут поломать!

И напоследок…

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

Как стать iOS-разработчиком

2025-04-26T00:00:00+00:00

Привет! Не знаю, как вы здесь оказались, но раз уж читаете эту статью, значит, вас заинтересовала нативная разработка приложений для iPhone и iPad. Отличный выбор!

С чего всё началось у меня

В 2014 году я случайно наткнулся на видео Алексея Скутаренко — русскоговорящего iOS разработчика, который, освоив эту профессию, уехал жить и работать в США. Это был один из тех моментов, когда сразу понимаешь: «вот оно!»

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

Удовольствие дорогое, но оно того стоит

iOS-разработка — не самое дешёвое увлечение. И дело не только в технике.

1. Компьютер

Вам обязательно понадобится Mac. Нет, не Windows с эмулятором, не хакинтош, не виртуалка. Настоящий Mac на чипе Apple Silicon.

Помню, как покупал свой первый Macbook Air в 2014 году. Думал о хакинтошах, но решил не издеваться над собой и купил слабенький, но настоящий Mac. Разумеется, ни разу не пожалел.

И чек до сих пор ношу с собой в паспорте.

Сейчас мне максимально комфортно работать на MacBook Pro 14”. Не нужны широкие мониторы или несколько экранов. Куда приятнее быть мобильным: писать код в парке, кафе или на природе. Лучше быть готовым взять ноутбук с собой, чем иметь мощную, но стационарную станцию, к которой не захочется возвращаться.

2. Устройства для тестирования

Симулятор в Xcode работает лучше, чем аналоги для Android, но он не заменит настоящее устройство. Идеально иметь хотя бы один iPhone или iPad для тестирования. И лучше не самый новый — так вы сможете проверить, как ваше приложение работает на устройствах с меньшей производительностью.

Я начинал с тестирования на своем личном iPhone, потом появился iPad. Сейчас у нас несколько устройств разных поколений — это помогает убедиться, что всё работает везде.

3. Аккаунт разработчика

Apple Developer Program стоит $99 в год. Без него вы не сможете:

Публиковать приложения в App Store
Полноценно тестировать их на физических устройствах
Использовать Push-уведомления
Работать с iCloud, In-App Purchase и другими API

Сейчас оплата происходит так же просто, как подписка на iCloud.

Обучение

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

100 Days of SwiftUI — отличный старт для новичков. Paul Hudson очень структурировано ведёт от основ к более сложным темам.
CS193p - Developing Apps for iOS — университетский курс от Стэнфорда. Каждый год обновляется, сейчас полностью на SwiftUI. Тут уже поглубже и поакадемичнее.
Big Mountain Studio — отличный выбор когда уже есть основы. «SwiftUI Views Mastery» и «Core Data Mastery in SwiftUI» — их я прочитал от корки до корки (если так говорят про электронные книги).

Почему это всё-таки стоит начать

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

Качественная экосистема. Apple создаёт хорошие инструменты, которые постоянно улучшаются. SwiftUI сейчас развивается невероятными темпами (и уже не сырой фреймворк).
Монетизация. Пользователи iOS больше платят за приложения. Даже небольшое приложение может приносить стабильный доход.
Удовлетворение. Когда видишь своё приложение в App Store и получаешь первый отзыв — это непередаваемые ощущения.
Востребованность. iOS-разработчики будут нужны всегда, пока существуют iPhone.

Что дальше?

Если эта статья не отпугнула вас, а наоборот — зажгла интерес, то вот мой совет: просто начните. Скачайте Xcode, создайте первый проект, посмотрите первые уроки из курса.

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

P.S. И да, начинайте сразу с SwiftUI.

Мнимая безопасность: усложняем простое

2025-04-19T00:00:00+00:00

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

Ситуация из жизни

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

Но системный администратор решил пойти другим путём. Вместо настройки встроенного в регистратор удалённого доступа, он развернул VPN-подключение. Идея заключалась в том, чтобы директор мог «виртуально оказаться» в локальной сети предприятия и получать доступ к видеорегистратору как к обычному внутреннему ресурсу.

Почему это проблема?

На первый взгляд, решение может показаться даже более надёжным — VPN же защищённое соединение, верно? Но на практике возникает как минимум две серьёзные проблемы:

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

Почему так происходит?

«Усложнение простого» обычно случается по нескольким причинам:

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

Баланс между безопасностью и удобством

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

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

Выводы

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