Вы открываете приложение, чтобы быстро проверить баланс или забронировать стол, и тут же получаете в лицо: «Вам нравится наше приложение? Оцените нас!». Ваша реакция? В лучшем случае - машинальное нажатие на крестик, в худшем - удаление. Моя личная боль - открываешь банковское приложение для оплаты на кассе по СБП и получаешь аж три баннера один за другим на экран. Я не хочу прямо сейчас оформить кредит, не хочу оценивать ваши продукты. Я только открыл приложение, я покупки оплатить хочу. И такое поведение если уж не каждый запуск, то каждый второй точно.

В 2026 году Apple и Google стали еще жестче фильтровать накрутки, а пользователи - еще чувствительнее к прерыванию их «флоу». Тем не менее, рейтинг 4.9 - это не магия, а математика, психология и вовремя вызванный системный метод.

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

Помните времена, когда пуш-уведомление реально что-то значило? Телефон вибрировал, и ты точно знал: случилось что-то важное. Такси подъехало. Деньги списались. Начальник написал что-то срочное (ладно, обычно не срочное, но хотя бы по делу).

Это был 2016 год.

На дворе 2026-й. Шторка уведомлений среднего пользователя превратилась в мусорный бак, куда маркетологи сбрасывают свои KPI с маниакальным упорством.

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

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

Если вы разрабатываете iOS-приложение с виджетом, Watch-компаньоном (это приложение для Apple Watch, которое работает в паре с основным приложением на iPhone) или Share Extension - рано или поздно вам придётся передавать данные между процессами. App Groups - стандартный механизм для этого, и на первый взгляд он прост: добавил capability, написал UserDefaults(suiteName:), поехали. Но именно эта кажущаяся простота и создаёт проблемы. Данные лежат в незашифрованном контейнере, любое приложение из вашей команды может их прочитать, а валидация входящих данных почти никогда не делается. Давайте же рассмотрим, как правильно настроить App Groups, что реально можно туда класть, какие риски существуют и как организовать безопасный обмен (в том числе с примером передачи токена авторизации между приложением и виджетом).

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

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

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

Давайте же разберем как делать переходы в iOS-приложениях так, чтобы они не раздражали, не ломали флоу и не заставляли пользователя думать "что-то пошло не так". Выясним почему 60 FPS - это не всегда гладко, как избежать типичных багов вроде джанка и мигания, правильно использовать matchedGeometryEffect, писать кастомные переходы без костылей и отлаживать всё это дело до идеального состояния. В конце разберём реальный кейс - переход от списка к детальной странице без единого моргания экрана.

Вы узнаете, как на самом деле работает магия приложения Локатор (Find My в англоязычной версии): от аппаратных хитростей контроллера питания до пост-квантовых алгоритмов шифрования. Мы разберем, почему «выключенный» iPhone - это лишь иллюзия для пользователя, как математика защищает ваши координаты от самой Apple и почему ваш смартфон превращается в криптографический маяк, когда гаснет экран. Статья будет интересна разработчикам, специалистам по безопасности и всем, кто хочет понимать реальные возможности (и ограничения) современной электроники.

Часто можно увидеть такую картину: разработчик влюбляется в концепт из Dribbble, тратит два дня на реализацию сложнейшей цепочки переходов, а потом удивляется, почему его iPhone 15 Pro начинает греться через пять минут использования приложения. Анимация - это всегда сделка с дьяволом (железом). Вопрос лишь в том, насколько выгодный курс обмена вы сможете выторговать.

Когда на WWDC представили iPhone Mirroring, многие скептично хмыкнули: «Ну, очередной VNC/AirPlay, что мы, трансляций экрана не видели?». Однако за окошком iOS на рабочем столе вашего макбука скрывается сложнейший инженерный стек. Это не просто стриминг картинки - это полноценная виртуализация управления, работающая в условиях жестких ограничений по питанию и безопасности. Сегодня мы препарируем iPhone Mirroring и узнаем, как Apple заставила задержку (latency) исчезнуть, а безопасность - не пострадать.

Разбираться во внутренностях AirDrop - это как препарировать фокус иллюзиониста: на сцене всё бесшовно, а за кулисами - вспотевшие инженеры пытаются заставить два разных радиомодуля не конфликтовать за общую антенну. Прочитав этот текст, вы поймете, как Apple фактически создала свой стек протоколов на базе стандартного железа, почему Bluetooth Low Energy - это «швейцар», а Wi-Fi - «грузчик», и как индустрия наконец-то пришла к единому стандарту передачи данных, который не заставляет владельцев Android чувствовать себя лишними на этом празднике жизни.

Эта статья - финальный аккорд в нашей трилогии об архитектуре. Мы уже научились наводить порядок внутри экрана с помощью MVVM и управлять потоками переходов через Coordinator. Но остался один неудобный вопрос: кто создаст все эти зависимости? Если ваш Координатор превратился в свалку из десятка сервисов, которые он просто пробрасывает дальше, значит, пришло время внедрить Factory. Вы узнаете, как разделить создание объектов и управление ими, почему глобальные DI-контейнеры - это яд замедленного действия, и как построить систему, где каждый компонент получает только то, что ему нужно, не зная лишнего.

Эта статья - логическое продолжение нашего погружения в архитектуру. Если в первой части мы навели порядок внутри «черного ящика» под названием ViewModel, то здесь мы выйдем за его пределы. Вы узнаете, как выпилить логику переходов из ViewControllers и ViewModels, почему вызов navigationController?.pushViewController() прямо в экшене кнопки - это архитектурный тупик, и как построить систему навигации, которая не превратит ваш проект в спагетти при добавлении десятого экрана. Мы разберем концепцию Child Coordinators, решим проблему утечек памяти (спойлер: системная кнопка "Назад" - ваш враг) и обсудим, выжил ли этот паттерн в эпоху SwiftUI.

Если вы когда-нибудь открывали проект, где ViewModel превратилась в свалку логики, навигации и форматирования дат - поздравляю, вы видели MVVM-курильщика. Рассказываю, почему «чистый» MVVM из учебников рассыпается в бою, как превратить ViewModel в машину состояний вместо мусорного ведра, и почему import UIKit в вашей VM - это диагноз. Без воды, с примерами кода и болью. Эта статья - не очередной пересказ документации. Вы научитесь разделять данные и их представление так, чтобы тесты писались сами собой, а ваши коллеги не проклинали вас на код-ревью.

Вы когда-нибудь замечали разницу между просто хорошим приложением и тем, которое ощущается «родным», надежным и дорогим? Часто дело не в дизайне или анимациях, а в мелочах, которые мы воспринимаем как должное, пока они не ломаются. Одна из таких критических мелочей - способность приложения помнить, где вы остановились. Вы читаете длинную статью, сворачиваете приложение, чтобы ответить на сообщение, возвращаетесь через минуту, а вас выбрасывает в самое начало текста. Раздражает, правда? Или пишете заметку, переключаетесь на браузер, возвращаетесь, а клавиатура скрыта и курсор потерян. В этой статье мы разберем, как технически грамотно реализовать сохранение позиции скролла и состояния курсора в iOS-приложениях. Мы уйдем дальше банальных советов и рассмотрим реальные сценарии с навигацией, табами и асинхронной загрузкой данных, чтобы ваши пользователи никогда не чувствовали себя потерянными.

Если вы открыли эту статью, значит, ваш менеджер или заказчик снова пришли с «гениальной» идеей: «А давайте не будем тратить бюджет на нативную iOS-разработку, а сделаем PWA? Это же кроссплатформенно, модно и дешево!». И теперь вам нужно аргументированно объяснить (или понять самому), почему в 2026 году, несмотря на все обещания открытого веба и давление регуляторов, PWA на iPhone всё ещё ощущается как гражданин второго сорта.

В этом тексте не будет маркетинговой шелухи про «единый код для всех». Мы разберем суровую техническую реальность Safari 19, ограничения WebKit, о которых Apple предпочитает молчать, и те немногие лазейки, которые позволяют сделать опыт использования веб-приложений хотя бы терпимым. Вы узнаете, почему localStorage умирает при установке, как заставить работать Deep Links (и почему они все равно ломаются), и в каких редких случаях PWA действительно может заменить App Store. Это гайд по выживанию в экосистеме, которая активно сопротивляется вашему присутствию.

В Android-разработке рано или поздно придётся столкнуться с задачей передачи данных между приложениями. Казалось бы, что тут сложного - отправил intent, получил результат. Но стоит копнуть глубже, и выясняется, что за простым API скрывается целый зоопарк потенциальных дыр в безопасности. Мы разберем три основных механизма обмена данными в Android: intents, URI schemes и shared preferences. Посмотрим, как они работают под капотом, где подстерегают грабли и как защитить своё приложение от любопытных глаз. Если вы пишете на Android и хотите понять, почему «просто передать данные» - это плохая идея, читайте дальше.

Межпроцессное взаимодействие в iOS - штука хитрая. Apple выстроила целую систему песочниц и ограничений, и просто так передать данные из одного приложения в другое не получится. Зато когда разберёшься, открывается масса возможностей: от банальной передачи изображений до выстраивания целых экосистем приложений. Давай разберем все основные способы обмена данными между приложениями (от URL Schemes до App Groups) с акцентом на безопасность и реальные проблемы, которые могут возникнуть. Покажу код, расскажу, где какой метод уместен, и объясню, как не наделать дыр в защите данных пользователя.