В мобильную разработку приходят различными путями. Некоторые рождаются с девайсом в руках, других ведет извилистая дорога вдоль серверов, майнфреймов, дестопных приложений. Но каждый кто в нее попадает ощущает свою незащищенность с тыла, если нет надежного партнера в лице бэкенд ‑разработчика. И, буквально, каждый мобильщик ожидает, что необходимый API будет готов хотя бы за один спринт, до того, как в нем возникнет необходимость. Конечно же, мир IT разработки редко допускает такую роскошь — за нее требуется бороться с ПМ и бизнес‑аналитиком. К тому же не редки ситуации, когда то, что должно быть сделано «на вчера», будет готово «на послезавтра». Те кто имеют достаточно опыта как в наземном, так и подземном мире — берут инициативу с свои руки, и сами предлагают клиент‑серверный интерфейс.

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

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

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

Использование концепции MVVM порождает еще один философский вопрос: может ли один и тот же экран с одной и той же viewmodel иметь различные типы входных параметров. Конечно, для идеологии чистого кода — ответ однозначен. Но ведь если нет нужды в создании нового вида или новой view model, то подавляющее количество разработчиков предпочтет переиспользовать один и тот же экран и для отображения десериализированного объекта, и для сериализированных параметров, передаваемых строкой в пути навигации.

Для атомарного перемещения внутрь иерархии вложенных вью весьма удобно, и, главное, просто использовать путь в виде строки. К примеру, строка вида «/auth/a//b/c/profile/a/c» открывает экран «c» в иерархии экранов «profile», что позволяет откатываться назад по «back» аж до самого корня, проходя через каждый экран. А легкое изменение строки на «/profile/c» откроет только нужный экран без остальных степеней вложенности.

Использование координатора совместно с NavigationStack является общепризнанной практикой на протяжении последних трех лет -- быстро, удобно, надежно. Однако, в том случае если выбор конечных точек пути описывается перечислением, то по мере роста размеров проекта, начинает разрастаться и класс координатора. Пока количество конечных экранов приложения находится в пределах пяти десятком – это не является проблемой, поскольку Pascal/Camel/Snake нотация легко секционирует группы экранов. Но на долгих проектах количество экранов переваливает за 2-3 сотни, и, в этом случае, перечисления на несколько сот строк становятся проблемой. Особенно, тогда, когда над проектом работает команда разработчиков.

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

Одной из самых замечательных и важных особенностей работы нейронных сетей является способность работы с табличными данным. В принципе, это напрямую вытекает из их природы, однако, в плане использования совместно с  Machine Learning – это свойство не так уж очевидно. Вместе с тем, именно оно раскрывает потенциал использования искусственного интеллекта в мобильных приложениях – натренированная на больших объемах данных нейросеть способна делать весьма близкие к действительности предсказания.

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

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

Не смотря на то, что теоретические основы преподаются к каждом техническом ВУЗе, разработчики не стремились включать их в свои приложения. Это обусловлено тем, что нужно пройти несколько этапов прежде чем со сконструированной  нейронной сетью можно будет взаимодействовать – разработка нейронной сети – трудоемкий процесс, но ее обучение – еще и чрезвычайно ресурсоемкий, а потому довольно затратный при каждом изменении базовых свойств.

На протяжении многих лет традиционным подходом было включение библиотек Alamofire (AFNetworking) в состав iOS приложения для осуществления RESTful запросов к бэкенду. И если в первой половине минувшего десятилетия это объяснялось использованием промышленных стандартов (а, фактически, никто не хотел заморачиваться с наборок сырых поделок, которые предоставила компания Apple из коробки), то в начале нынешнего десятилетия нет никаких аргументированных причин, чтоб ограничивать себя возможностями этой популярной библиотеки. </cut>

А ограничения, во истину, колоссальные – с точки зрения RESTful – его работа – тривиальная и предсказуемая, но вот методы использования, обусловленные Clean архитектурой Боба Мартина – вызывают дикую головную боль почти к любого разработчика, который приходит на проект. Благие намерения отделить роутинг от сериализации / десериализации приводят к невероятному разрастанию классов и зависимостей слоев, не смотря на то, что изначально, Clean архитектура декларировала то, что она предназначена для того, чтоб избегать таких зависимостей. Однажды пришлось столкнуться с ситуацией - для того чтоб добавить Post запрос необходимо было внести изменение в 11 фалов проекта!

Apple тоже заметили эту порочную тенденцию, и вместе с реализацией асинхронности через await преложила свой подход с использованием комбаина. Вот только не учла ригидности человеческой психики – те кто раньше создавали десяток слоев для выполнения сетевых запросов, сейчас сократили их до 3-4, но создали при этом синглтонный менеджер, длинной на несколько десятков тысяч строк кода.

С каждый днем все больше разработчиков IOS стремятся свои новые проекты начинать с использованием SwiftUI. И здесь перед ними возникает проблемы в виде реализации устоявшихся представлений о навигации в iOS. Предлагаемые решения от Apple работают весьма часто довольно криво. Это понимают и в самой Apple. По мере развития SwiftUI основной компонент навигации NavigationView был заменен на NavigationStack. И это не просто переименование. Те кто уже использовал NavigationView не готовы от него отказаться, так как его реализация лежала через боль и слезы. Те же кто только входит в мир SUI либо наталкиваются на рекомендации создавать кастомную навигацию, либо смотрят на статьи как разруливать проблемы NavigationView. Новая альтернатива не всем пришлась по-душе, так как на WWDC не продемонстрировали его с лучшей стороны. А она есть. И это хорошая новость! Apple, наконец, освоила паттерн Navigator, которым конкуренты пользовались более 10 лет!

В далекие – далекие времена, когда iOS была совсем маленькой, разработчики, гордо именуемые iOS-девелоперами, задумались о кастомизации навигационного стека. Не то что навигационный стек был плох – он отлично вписывался в картину мира Apple, но вот навигационная панель часто была «бельмом в глазу» для пользователей и дизайнеров. Поэтому разработчики применяли простой трюк – скрывали панель в приложении, а вместо нее показывали свою собственную панель, со своим собственным дизайном интерфейса, управляющие элементы которого были привязаны все к тем же методам push и pop доступных им из коробки.

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