Потом проект вырос, в команду пришли ещё люди, и стало понятно: этот красивый монолит пора разделять.

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

Половина нужна только Android, другая только iOS. Но метод один. Потому что так более по программистцки, как написано в каждой второй статье про архитектуру автотестов.

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

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

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

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

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

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

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

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

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

Теперь разработчики могут использовать автономных кодовых ассистентов прямо внутри Xcode, без сторонних плагинов и костылей. То есть теперь ИИ сможет получать цель и самостоятельно решать, как к ней прийти. И все это прямо внутри IDE от Apple.

Claude и Codex — прямо в IDE

В Xcode 26.3 встроена нативная поддержка Anthropic Claude Agent и OpenAI Codex. Эти агенты могут работать на протяжении всего цикла разработки, а не только писать код по запросу.

Они умеют:

• изучать структуру проекта и файлы,
• искать информацию в документации,
• менять настройки проекта,
• запускать сборки и чинить ошибки,
• проверять результат через Xcode Previews.

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

Продолжение курса на «умный» Xcode

В Apple подчеркнули, что это логичное развитие функций ИИ, появившихся в Xcode 26. Напомним, что тогда IDE получила нового ассистента для Swift. Теперь же ИИ получил доступ к куда большему количеству внутренних возможностей Xcode.

По словам вице-президента Apple по работе с разработчиками Сьюзан Прескотт, цель компании — дать разработчикам инструменты, которые «ускоряют работу и освобождают время для настоящей инженерии и идей, а не рутины».

Не только Claude и Codex

Помимо встроенных интеграций, Apple открыла Xcode для других агентов через Model Context Protocol (MCP) — открытый стандарт взаимодействия инструментов и ИИ-моделей.

Это значит, что в будущем разработчики смогут подключать любые совместимые модели и агентные системы, а не только решения от Anthropic и OpenAI.

Компания представила официальный Swift SDK для Android, позволяющий писать нативные Android-приложения на фирменном языке, изначально созданном для iOS и macOS.

От iPhone до Android

Swift появился в 2014 году как альтернатива Objective-C — более безопасный, современный и лаконичный язык для экосистемы Apple.

За 11 лет он вырос из «внутреннего» инструмента в многофункциональную платформу, на которой создают облачные сервисы, десктопные приложения для Windows и даже прошивки для микроконтроллеров.

Теперь Swift впервые официально выходит за пределы «яблочной экосистемы. Превью-версия SDK для Android доступна уже сегодня — в составе Swift-инсталлятора для Windows или отдельно для macOS и Linux.

Как это работает

Новый SDK — результат многомесячной работы Swift Android Workgroup, открытого сообщества, куда может присоединиться любой разработчик. С его помощью можно:

• собирать нативные Android-приложения на Swift;
• переносить существующие Swift-пакеты — более 25% уже совместимы с Android;
• интегрировать Swift-код с Java через проект swift-java, автоматически генерирующий безопасные биндинги между языками.

Apple опубликовала подробное руководство «Getting Started» и примеры кода, демонстрирующие полный цикл разработки Android-приложений на Swift.

Что это значит для экосистемы

Релиз открывает дорогу к кроссплатформенным приложениям без использования Flutter, Kotlin Multiplatform или React Native.

Теперь компании смогут писать бизнес-логику один раз на Swift и использовать ее и в iOS-, и в Android-версиях.

Эксперты отмечают, что шаг Apple может снизить барьеры между мобильными экосистемами и ускорить развитие open-source сообщества Swift.

Что дальше

По словам участников проекта, впереди — создание полноценного Android-Toolchain, улучшение совместимости со средами разработки и официальное внедрение CI-сборок.

Разработчики уже готовят документ с видением будущего Swift на Android, который определит приоритеты и стратегию развития.

«Swift вырос из языка для iOS в универсальный инструмент для всего программного мира. Теперь он будет жить и в Android-экосистеме», — говорится в сообщении разработчиков.

Смотреть подкаст на YouTube, в VK.

Анна Жаркова пишет нативные приложения под iOS и Android и кросс-платформенные приложения на Xamarin, Xamarin.Forms и Kotlin Multiplatform. Написала книгу о Kotlin Multiplatform, которая выходит в сентябре. Пишет статьи, выступает на конференциях и митапах. Член программного комитета Mobius, CodeFest, «Стачка». Увлекается живописью и участвует в выставках.

Поговорили о безумных проджект-менеджерах, войне Android и iOS, о том, почему ИИ не заменит программистов, и что делать, если вам позарез нужно установить ВСЕ приложения из магазина. Добро пожаловать в абсурдный и увлекательный мир мобильных разработчиков!

О смысле мобильных приложений

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

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

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

Ну да, взять то же банковское приложение, оплату с телефона… Ребята, с компьютером не походишь, чтобы это всё делать. Давай поедем к следующему. Можно делать так, чтобы приложение ставилось не из App Store?

Конечно. Если это приложение под Android, оно будет ставиться через Google Play, а также есть специальные магазины, например, AppGallery для Huawei или RuStore. Также у некоторых вендоров есть свои маркеты, например, у Samsung.

Если же говорить про iOS, то тут всё строго с App Store. Но кто знает, возможно, в будущем появятся и кастомные магазины для iOS. Хотелось бы, чтобы поскорее.

А скажи, пожалуйста, насколько широкий ассортимент приложений в этих альтернативных магазинах? У меня всё на яблоках, я не особо разбираюсь, что там происходит, особенно с Huawei, с RuStore. Можешь рассказать, насколько там всё хорошо или плохо?

Я думаю, если говорить про приложения, которые имеют ограничения в загрузке в App Store, они, в принципе, есть и в Google Play, но свободно грузятся в остальные магазины. Особых ограничений нет. Конечно, бывают ситуации, когда приложение пропадает из магазина по чьей-то жалобе. Но выбор приложений довольно большой. Например, в компании, где я работаю, мы свободно загружаем наши приложения в разные магазины, и всё в порядке.

Супер. А насколько вообще отличается разработка для, скажем, Huawei от классической Android? Там есть какая-то своя специфика, или всё тоже самое? Может, свой стэк?

Плюс-минус как Android, но есть определённые различия. У них своя среда разработки, свои сервисы, дополнительные технологии. Тема довольно обширная, но в принципе, всё это плюс-минус то же самое, и Android-разработчику освоить это несложно. Главное — поставить нужную IDE (Интегрированную среду разработки) и взять устройство для отладки.

А какие там специфические IDE?

Да, там есть, по-моему, собственная IDE, но я скажу честно, я с ней особо не работала. Я сейчас копаю немножко в другом направлении.

О фантастическом девайсе

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

Что ж, ну, возникает вопрос: наверное, у этого пользователя очень много денег, он может позволить себе все платные приложения. Порадуемся за него!

Но если говорить про аппарат, то это должен быть какой-то супермощный с параметрами из серии «Чёрная дыра». Современное приложение, тот же самый «суперап», который объединяет кучу сервисов, может занимать сотни мегабайт. Обычное банковское приложение — тоже несколько сотен мегабайт.

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

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

Да, вот у меня даже на айфоне он сгружает в облако всё, что не нужно. И у меня стоит довольно много приложений, в том числе детские, с ИИ, чтобы звёзды смотреть, цветы диагностировать… Куча странных приложений, которые я использую очень ситуативно. Я не представляю, сколько надо времени, чтобы скачать себе даже десятую часть всех существующих приложений в Store. Ну, это невозможно.

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

О разработке на мобильном телефоне

«Раз для компов проги пишут на компах, разве не уместнее для мобилок писать на мобилках?»

Кстати, очень хороший вопрос. На заре энтузиазма, когда только появлялись смартфоны, все считали: «Сейчас они будут настолько мощные, что не понадобится настоящий комп, чтобы писать программы».

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

Конечно, на мобильном устройстве можно скомпилировать какие-то простые, легковесные приложения, например, на скриптовых языках. Есть такие технологии. И в том числе можно использовать мобильные устройства как инструмент для разработки. У того же GitHub такое было.

Но честно говоря, если есть желание что-то писать на мобильном аппарате, то лучше работать с облачными средами разработки. Потому что даже на компе та же Android Studio может кушать очень много памяти и сохранять много кэша. Облачная среда, конечно, в какой-то степени небезопасна, потому что вы что-то загружаете на сторонние сервера. Но если это ваше собственное, настроенное место, то вполне можно по удалёнке получать доступ. Другой вопрос, что вам тогда необходим хороший интернет.

Ну, ты знаешь, у меня вот был странный опыт. Когда я училась на Python-разработчика, у меня был старый макбук. Он у меня сдох через полгода, просто потому что не вывез: ты ставишь все эти библиотеки, прописываешь команды, подгружаешь версии… В общем, у меня просто сдох жесткий диск. Поэтому да, хороший вопрос. Не всякий даже ноут это выдержит, как выяснилось.

Более того, даже для сборки мощных мобильных приложений на Mac сейчас часто требуется 32, а то и 64 ГБ памяти. Были бы, конечно, такие крутые мобильные устройства, полноценные мини-компьютеры… Но это уже из области фантазии наших зрителей.

О Keycloak и мобильной безопасности

Так, следующий вопрос. «Подскажите, кто-нибудь пользуется Keycloak для SSO (стандарт единого входа)?»

Интересный, конечно, вопрос про Keycloak. Я слышала такое слово от бэкендеров — это механизм, который используют для безопасности на бэкенд-части. Но что примечательно, с вопросом про Keycloak часто приходят именно к нам, мобильным разработчикам.

Тебе говорят слово «Keycloak», и ты думаешь: «Хорошо, а я тут причём?» Так что да, это довольно часто задаваемый не по адресу вопрос. Ответ — спросите у аналитика или у бэкенд-разработчика.

А как ты думаешь, почему к мобильным разработчикам приходят с этим вопросом?

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

Keycloak — это система идентификации и управления доступом с единой точкой входа. Мобильное приложение — это фронтенд-клиент, который обращается к API вашего сервера. Поэтому вся система должна быть реализована на бэкенде. Мобильщик будет лишь использовать готовое API. Если вам говорят, что вы должны это сделать сами на мобилке, ну тогда вы, получается, не мобильщик, а фуллстэк. Я вас поздравляю!

О выборе технологии: натив vs Flutter

Так, переходим к следующему вопросу. «Стоит ли погружаться в нативную разработку или сразу учить Flutter?»

Очень хороший вопрос. Flutter — это отдельная технология со своим языком Dart. Но тут есть маленький нюанс. Да, Flutter — технология отличная, но вы разрабатываете под Android и iOS, и поэтому вам необходимы знания нативной разработки, хотя бы в минимальном объёме. Есть проекты, где пишут код Flutter-разработчики, но от них требуют хороших, крепких знаний по нативу хотя бы одной платформы.

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

То есть, сначала учим какую-то одну платформу как базу, а потом уже идём во всякие Flutter’ы с ними.

Безусловно. Вы исходите из того, что пишете под Android (или iOS). И уже смотрите: как я могу это делать? Я могу писать на нативе, а могу на Flutter’е. Но Flutter всё равно будет опираться на натив, поэтому получается такая ступень по изучению технологий.

О роли ИИ в мобильной разработке

Что сейчас можно сделать с помощью ИИ в мобильной разработке?

Довольно много. Но тут возникает уточняющий вопрос: использовать ИИ как инструмент или внедрять ИИ в приложение? Есть возможности по внедрению ИИ, чтобы оно что-то генерировало в вашем приложении: умные ассистенты, генерация изображений и т.д.

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

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

Вопрос от этого же задавателя вопросов. «Используют ли Kotlin Multiplatform React Native (технологии для кроссплатформенной разработки) и так далее? Если да, бывают ли задачи с адаптацией под мобильный веб?»

Хм, хороший вопрос. Если говорить про работу с искусственным интеллектом в контексте этих технологий… Вы можете попробовать сгенерировать код под любую платформу. Для этого нужно писать много промтов и иметь много ресурсов для обучения модели.

Но если говорить о продакшене, то тут имеет смысл использовать только то, что безопасно. Есть компании, которые разрабатывают свои инструменты на основе LLM-моделей, как, например, Яндекс. Есть те, кто берут открытые модели, разворачивают их и используют.

А вот публичные сервисы вроде ChatGPT я не рекомендую использовать для продакшена. Они могут залогировать ваш код и потом выдать его кому-то. Это крайне небезопасно. В прошлом или позапрошлом году был скандал, когда ChatGPT выдавал куски кода одной компании, вплоть до креденшиалов. Так что в продакшене — только собственные решения.

О сегментации рынков Android и iOS

Насколько реально сегментированы рынки Android и iOS?

Если говорить про iOS, то тут всё просто: один вендор — Apple. Вся экосистема: iOS, iPadOS, watchOS, специальная OS для авто. Минимальная сегментация. А вот с Android вендоров много. Это и гиганты типа Samsung, большой кусок рынка у Xiaomi и её суббрендов вроде Poco или Redmi.

Но стоит не забывать, что есть страны Латинской Америки, Африки, Юго-Восточной Азии, где ситуация с разработкой и устройствами совершенно другая, чем в Штатах, Европе или СНГ. Там до сих пор используют такие технологии, как Cordova, PhoneGap, потому что это дёшево, а iPhone там очень непопулярны — банально не по карману.

О самых сложных задачах

Какие задачи в мобильной разработке самые сложные?

Всё зависит от того, что считать задачами. Есть интересные фичевые задачи, которые дают возможность разрабатывать что-то новое. Есть рутинные, неинтересные, но простые задачи, которые просто отнимают много времени.

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

Но многие скажут, что самая сложная задача — это работа с заказчиком, с ТЗ, работа между командами. То есть, есть элемент технического челленджа, а есть — психологического. Разработчику надо уметь преодолевать и те, и другие, потому что это позволяет потом работать проще и интереснее.

Об ассемблере в 2025 году

«Какое место в Android и, видимо, iOS-разработке занимает ассемблер в 2025 году?» Вообще ассемблер и мобильная разработка, мне кажется, две немножко разные сущности.

Честно говоря, я не пользовалась ассемблером для мобильной разработки. Если у того, кто это задал, есть наработки, пусть пришлёт, посмотрим. Или придёт на Mobius и расскажет про это — у нас ещё открыт CFP. Если это будет супер-хардовый доклад, это будет здорово!

Например, пару лет назад у нас был человек, который встроил Doom (а он написан на ассемблере) в SwiftUI. То есть низкоуровневое что-то встраивается через C, C++ (например, через NDK для Android). Всё это можно сделать.

Но возникает вопрос: зачем? Потому что есть решение «потому что могу» — и это круто. А есть принцип разумной достаточности: не надо усложнять решение там, где это не нужно. Мы экономим и делаем оптимальной не только архитектуру приложения, но и время разработчика. Так что, отвечая на вопрос: есть Doom UI. Можете посмотреть: где только Doom не запускали.

О дизайне под Android и iOS

«Почему менеджеры и дизайнеры всегда хотят, чтобы на Android всё выглядело точно так же, как на iOS?»

Я думаю, потому что это красиво. У iOS долгое время очень много вкладывалось в визуал, в неповторимые жесты и систему. Это было просто супер. Затем Google решил догнать. Сначала появился Material Design, потом более продвинутый. И теперь, если посмотреть на доклады Google и Apple, можно заметить, что в какой-то момент предложения инженеров Google превращают Android в iOS, а у iOS есть тенденция становиться визуально похожим на Android.

Основная причина, почему хочется использовать iOS-подобный дизайн на Android, — «потому что красиво». Но Android не повезло: красивые вещи довольно затратны. Изначально Android затачивался под аппараты для всех, включая страны с дешёвыми устройствами малой мощности. Тащить туда всю красоту — вредить пользователям. Там действует принцип «максимум возможностей при минимальных затратах».

Ну да, Apple всегда стремились делать очень красиво. Так, скоро же выйдут новые модели Apple, они там всё выкатят в сентябре. Там какие-то изменения по разработке будут под iOS?

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

Были у них такие периоды, но это было связано скорее с языками (Swift у Apple, Jetpack Compose у Google), которые сильно менялись. Но кардинальной смены инструментов или парадигмы в ближайшее время не планируется.

Крик души мобильного разработчика

Так, ещё у нас остался один большой вопрос, прямо крик души. Цитирую: «Почему на симуляторе всё работает, а на телефоне нет? Телефон тупее? Если отключу фоновые процессы, батарейка начнёт заряжаться в обратную сторону? А можно сделать так, чтобы приложение работало одинаково на всех 19 тысячах моделей телефонов? Почему я должна платить 99 долларов в год, чтобы тестировать на своем же телефоне? Почему пуши приходят только тогда, когда я уже сама все проверила вручную? Почему SwiftUI делает все проще, но я все равно страдаю?»

Я так понимаю, это крик души. Мы пойдём по частям. Судя по желанию, «чтобы оно работало везде одинаково», — это PM или Product Owner detected. «Нехорошо, неправильно не делайте, делайте правильно». Вот такой тезис.

Давай пройдёмся по частям.

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

Про 99 долларов. Вы платите не мне, а компании Apple. А компания Apple считает, что вы должны платить, «потому что они красивые». Вот. Такова жизнь.

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

С пушами отдельная история. Доставка пуш-уведомлений — вещь негарантированная. Многое зависит от сервиса, который вы используете (Firebase часто капризничает, try RuStore, они стабильнее), от территориальных особенностей, от того, как настроена рассылка. На Android и iOS разные политики работы с пушами. Иногда, если понизить приоритет пушам, они дойдут гарантированнее, чем с высоким приоритетом. Всё индивидуально.

А по SwiftUI... Я очень сочувствую вашему опыту. Если вы посмотрите WWDC последних двух лет, особенно этот год, они даже не прикладывают исходники тех примеров, которые показывают. То есть покажут сниппет, а целиком приложение не дают. Так что, возможно, это всё на их совести. Пусть они спят плохо.

О собеседованиях и офферах

«Почему для получения оффера недостаточно, что в своём телефоне я разработчик?»

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

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

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

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

Ох, на самом деле да. Бывает, людей вводят в заблуждение разные кураторы, и они считают, что если суперуверенно рассказать что-то HR, то он уже прошёл. Вот эти кейсы, где предлагается подумать и рассказать, как бы ты это делал, — довольно показательны.

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

Если человек говорит: «Это всё гуглится», — возникает вопрос: «Зачем ты тогда тут?» Кейсы экономят время, не у всех может открыться среда для лайвкодинга, и они помогают понять, как человек мыслит и насколько он адекватен.

Об автомобильной разработке

Так, и вот последний странненький, на мой взгляд, вопрос. «Зачем нужны специалисты по мобильной разработке, если есть уже автомобильная?»

Хороший вопрос. Можно обыграть, что автомобильная — это разработка на vibe-кодинге, just for fun. Если говорить серьёзно, то автомобильную разработку тоже делают мобильные разработчики! Так что можно быть автомобильным разработчиком, но не сужайте себе поле, попробуйте другие девайсы, вам тоже понравится.

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

Зачем разработчику Swift изучать ассемблер

Ассемблер — это не просто низкоуровневое программирование, а способ понять, как код на Swift или Objective-C преобразуется в инструкции процессора. Он помогает разобраться в движении данных, оптимизировать производительность и отлаживать сложные ошибки. Изучение ассемблера не требует писать целые приложения на нем, но дает уверенность и глубокое понимание работы системы. К тому же, умение работать на уровне процессора добавляет разработчику уникальности и открывает новые карьерные перспективы.

Регистры: основа работы процессора

Регистры — это быстрые ячейки памяти процессора, своего рода «рабочий стол» для данных. На архитектуре Apple Silicon (ARM64) они выполняют следующие роли:

• x0–x7: передача аргументов и возвращаемых значений.
• x8: регистр косвенных результатов (используется редко).
• x9–x15: временные регистры для промежуточных вычислений.
• x16–x17: для системных вызовов (например, указание номера вызова).
• x18: регистр платформы, сохраняемый между вызовами.
• x19–x28: регистры, которые нужно сохранять при вызове функций.
• sp (x31): указатель стека, хранящий локальные данные.
• pc: счетчик программы, указывающий на следующую инструкцию.

При выполнении системного вызова (например, для вывода текста в консоль) аргументы загружаются в регистры x0, x1 и далее, номер вызова — в x16, а команда svc 0 передает управление ядру системы.

Настройка Xcode для работы с ассемблером

Чтобы начать писать код на ассемблере, нужно настроить проект в Xcode:

1. Откройте Xcode и создайте новый проект: File → New → Project….
2. Выберите Command Line Tool в разделе macOS, затем нажмите Next.
3. Назовите проект, например, HelloAsm, выберите язык C (его позже заменим) и нажмите Create.
4. В Project Navigator удалите файл main.c.
5. Добавьте новый пустой файл: File → New → File… → Other → Empty, назовите его main.s и нажмите Create.
6. В настройках проекта откройте Build Phases и убедитесь, что main.s добавлен в Compile Sources.

Теперь Xcode будет компилировать файл main.s как точку входа для программы на ассемблере.

Первая программа: «Hello, Assembly!»

Рассмотрим минимальную программу, которая выводит «Hello, Assembly!» в терминал. Вот ее структура с пояснениями:

• .section __TEXT,__text & .global _main: указывает, что это исполняемый код, а _main — точка входа.
• mov x0, 1: задает 1 (stdout) как первый аргумент системного вызова.
• adrp/add: загружает адрес строки msg в регистр x1 (с учетом разбиения на страницы).
• mov x2, #0x11: задает длину сообщения (включая символ новой строки и нулевой терминатор).
• mov x16, #0x4: указывает номер системного вызова для записи в macOS.
• svc 0: выполняет системный вызов, передавая управление ядру.
• Повторение для вызова выхода.

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

Сборка и запуск

Соберите и запустите проект в Xcode. При успешной компиляции в терминале появится:

Hello, Assembly!

Если вывод не появился, проверьте:

• Файл main.s добавлен в Compile Sources.
• Нет лишних C-файлов, которые могут переопределить main.
• Архитектура проекта соответствует вашему оборудованию (Intel или Apple Silicon).

Что дальше

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

Журналисты с сайта 9to5Mac выяснили, что Apple добавила в IDE встроенную авторизацию через Anthropic-аккаунт, а также нашли упоминания моделей Claude Sonnet 4.0 и Claude Opus 4, выпущенной 14 мая 2025 года.

Что это значит для разработчиков

Хотя официально в Xcode пока представлена только интеграция с ChatGPT от OpenAI, свежая находка указывает на то, что Anthropic получит такой же уровень встроенной поддержки — без необходимости подключать API вручную. Это может стать значимым шагом для разработчиков, использующих Claude как основную LLM.

Напомним, что ранее Claude можно было подключить только через внешний API (как и другие сторонние модели). Теперь же Apple, по сути, приближает Anthropic к статусу, который до этого был лишь у OpenAI.

Эволюция Swift Assist

Функция Swift Assist была анонсирована ещё на WWDC 2024 как альтернатива GitHub Copilot. Идея заключалась в создании встроенного ИИ-помощника, который помогает писать код, разбираться в API Apple и работать с фреймворками.

Однако Swift Assist так и не был запущен в оригинальном виде. Вместо этого в Xcode 26 появляется более гибкий механизм под общим названием Intelligence с поддержкой:

• моделей Apple;
• встроенного ChatGPT (с ограничением по количеству запросов, если не авторизован);
• сторонних моделей по API;
• и теперь — Anthropic с полноценной нативной интеграцией.

Что нашли в Xcode 26 beta 7

По данным 9to5Mac, в последней бете IDE обнаружены:

• внутренние ссылки на Anthropic-аккаунты;
• параметры выбора между Claude Sonnet и Opus;
• конфигурационные файлы, намекающие на более глубокую интеграцию Claude в системы Apple, включая Siri и Writing Tools.

Это может означать, что Claude появится не только в Xcode, но и в других частях экосистемы — в качестве альтернативы ChatGPT.

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

Claude — один из наиболее точных и аккуратных LLM, ориентированных на безопасность и детальность в генерации кода. Многие разработчики считают Opus и Sonnet лучшими ассистентами на рынке.

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

Apple пока не делала официальных заявлений о Claude в Xcode, но по текущим данным это лишь вопрос времени. Интеграция может быть активирована уже в ближайших обновлениях Xcode 26.

Что такое Cangjie

Cangjie — язык общего назначения, разработанный для HarmonyOS Next. Это та самая операционная система, созданная на замену Android после американских санкций.

По словам HUAWEI, язык подходит для разработки «во всех сценариях», включая мобильные приложения, распределённые системы и ИИ-сервисы.

Особенности Cangjie:

• Нативная поддержка ИИ
• Фокус на безопасности
• Поддержка приложений не только на HarmonyOS, но и на Android с iOS

Таким образом, Cangjie позиционируется как альтернатива Java (в экосистеме Android) и Swift (в iOS).

Как развивается экосистема

Язык разрабатывался почти пять лет и впервые был представлен в июне 2023 года. За несколько недель он привлёк свыше 10 000 заявок на участие в тестировании.

Уже в октябре прошлого года Cangjie стал доступен всем разработчикам HarmonyOS, а к июлю 2025 его используют крупные игроки:

• Meituan — пишет на Cangjie приложение для доставки, релиз которого ожидается в III квартале;
• JD.com — использует язык в мобильных решениях для собственной платформы.

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

Cangjie — ещё один шаг в сторону технологического суверенитета Китая. Под американскими санкциями HUAWEI активно выстраивает собственную экосистему — от ОС и чипов до языков программирования и облачных сервисов.

Что дальше

С 30 июля исходный код Cangjie будет доступен всем. HUAWEI рассчитывает, что открытие языка ускорит его адаптацию и создаст альтернативу западным технологиям — в первую очередь в Китае, а затем и за его пределами.

Посмотреть документацию языка можно по ссылке.

С 2022 года российские компании столкнулись с проблемами в работе на иностранных заказчиков. Как отметил партнер инвестиционной компании KAMA FLOW Павел Охонин, сложности начались еще в 2018, но в 2022 ситуация ужесточилась, и особенно пострадал IT-сектор, который исторически выполнял большой объем работы на аутсорсе или в формате аутстаффинга для зарубежного бизнеса.

Появился ли просвет

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

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

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

Чтобы лучше понять, какова сегодня практика работы с иностранными заказчиками, что нужно учитывать и какие шаги придется совершать, мы опросили управляющего партнера Адвокатского бюро Солларс Людмилу Соболевскую и старшего юриста Адвокатского бюро Солларс Веру Наумову.

Захотят ли с вами работать

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

Например, в июне-2024 власти США запретили предоставлять услуги в сфере IT и программного обеспечения на территории России, а также перестали контактировать с россиянами как с поставщиками. В Новосибирске был случай, когда оборонное ведомство США, обнаружив, что часть их софта поставляет/обслуживает ИТ-компания из Новосибирска, разорвала с ней сотрудничество. В 2023 в официальные санкционные списки США попала новосибирская IT-компания «ОМП», не относящаяся к ВПК. Причины, тем не менее, во всех случаях — прямо или косвенно — политические.

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

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

Как принимать оплату и что с налогами

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

Даже для России SWIFT еще жив, но ненадежен. Некоторые российские банки до сих пор подключены к платежной системе SWIFT (федеральные Райффайзенбанк, ЮниКредит Банк, Газпромбанк и некоторые региональные). Но санкционные списки постоянно обновляются, и если разово оплату еще можно провести через доступный банк, то для стабильных расчетов придется искать другие решения.

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

Например, Китай с 2015 г. развивает собственную систему для расчетов в юанях — CIPS (Cross-Border Interbank Payment System), которая на март-2025 насчитывает 150 прямых участников и почти 1500 косвенных. Иностранный заказчик должен иметь счет в банке, который выступает прямым или косвенным участником CIPS (ICBC, Citibank, BNP Paribas и пр.), и отправить перевод в юанях. Для исполнителя в России есть выбор более чем из 23 банков. CIPS использует RTGS (расчеты в режиме реального времени) — часто такие платежи проходят даже быстрее SWIFT, в течение нескольких минут или в тот же день, даже с косвенными участниками.

Можно использовать Систему передачи финансовых сообщений Банка России (СПФС), разработанную в качестве альтернативы SWIFT. СПФС участвует в платежах между Россией, странами СНГ и другими дружественными государствами (Турцией, Таджикистаном, Кубой).

Можно рассмотреть специальные платежные инструменты, «фриланс-площадки», то есть посредников. Но стоит учесть, что зачастую такие сервисы доступны только ИП или юрлицам и могут брать дополнительную комиссию.

Как вариант — открыть юрлицо за рубежом. Один из трендов сейчас — зарегистрировать компанию в дружественной юрисдикции, например, в ОАЭ, и принимать на нее оплату за услуги. Если правильно выстроить структуру и соблюдать требования комплаенса, иностранная компания сможет переводить оплату в Россию. При этом юрисдикции с льготным налогообложением часто позволяют применять нулевую или сниженную ставку налога на прибыль.

ИТ-специалисты же могут открыть зарубежный счет. Как правило, фрилансеры выбирают дружественные или нейтральные страны (ОАЭ, Казахстан, Грузия и пр.). В некоторых случаях все еще возможно завести карту удаленно через различные сервисы. Но с 2024 г. все больше юрисдикций требуют личного присутствия, кроме стандартного набора из загранпаспорта, подтверждения адреса и иногда — местных SIM-карты и ИНН.

Последние два подхода остаются популярными среди российских IT-компаний и фрилансеров. Они позволяют не просто получать деньги от иностранного заказчика, но и масштабировать бизнес, иметь зарубежные банковские счета. Для таких расчетов нужно учесть, что наличие компании за рубежом требует отчитываться в ФНС об участии в иностранной компании, о контролируемой иностранной компании (КИК), а также уведомить налоговую службу об открытии счета и ежегодно предоставлять отчет о движении денежных средств и 3-НДФЛ (для физлиц).

Налоговые вопросы не отличаются специфичностью при работе с зарубежным заказчиком. Граждане-резиденты РФ платят НДФЛ с доходов от иностранных заказчиков по прогрессивной ставке так же, как и от российских. Даже если вы получаете оплату на зарубежный счет, декларация 3-НДФЛ обязательна.

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

Как подстраховаться

• Заранее продумайте и обсудите с контрагентом возможный и удобный способ оплаты: CIPS, СПФС, SWIFT через дружественную юрисдикцию.
• Помните, что вы все еще остаетесь под контролем ФНС — включите налоговое планирование в свою структуру и не забудьте о своевременной отчетности.
• Учтите, что инструменты за границей (счета и компания) — это не только получение оплаты, но и способ масштабирования бизнеса, который требует тщательного планирования с самого старта.

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

Больше инфоповодов — в нашем тг-канале Представляешь.

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

Как все начиналось

Sandpolis задумывался как универсальный инструмент для системных администраторов. Идея пришла в университете, энтузиазма хватало. Уже в 2019 году у проекта была рабочая Java-серверная часть (~50 000 строк кода) и небольшой iOS-клиент на Swift (~10 000 строк).

Но затем случился «переписон» — автор решил, что все нужно перевести на Rust, «язык будущего». Так началась вторая жизнь проекта. К сожалению, безрезультатная.

Почему за 7 лет не получилось даже MVP

Вот как сам автор описывает главные причины провала:

• Переписывание ради языка. Rust стал увлечением, и проект превратился в площадку для экспериментов, а не развития продукта.
• Фокус на «интересном», а не важном. Вместо ключевых проблем (например, проработки модели данных) автор занимался второстепенными деталями: паролями, мелкой оптимизацией.
• Дыры вместо структуры. Поскольку сложные задачи откладывались, проект обрастал кусками кода, которые не складывались в единую систему.
• Отсутствие дисциплины. Основной диагноз: нежелание делать трудное и скучное. Работа велась по принципу «где интересней» — но не «где нужней».

Что автор понял спустя 7 лет

Дисциплина — это то, чего в инженерии сегодня не хватает так же сильно, как хорошего вкуса.

Основные выводы:

• Делай приоритетное — даже если оно скучное. Не отвлекайся, пока не решишь главную задачу.
• Чем дольше код сломан — тем сложнее его починить. Правки должны возвращать проект в рабочее состояние как можно быстрее.
• Не переписывай без причин. Переписка кода на новом языке может уничтожить весь прогресс.
• Ранние ошибки становятся дорогими. Лучше «заплатить» временем сразу, чем страдать потом.
• Идеи без реализации — это просто мечты. Рабочий код важнее красивых концептов.

Что дальше

Разработчик пообещал, что в 2025 году он сосредоточится только на одной вещи: идеальной модели данных для Sandpolis. А уже после — будет строить вокруг нее приложение.

Правда, много времени у них это не заняло — уже летом 2019 году компания представила собственную систему HarmonyOS. Сейчас Huawei активно ее развивает и релизит мощные фичи, а сама ОС ориентирована на на широкий спектр устройств — от смартфонов до IoT-устройств. В статье рассказываем, сможет ли HarmonyOS составить серьезную конкуренцию iOS, Android и Linux.

А мы возьмем и сами сделаем: что из себя представляет HarmonyOS

HarmonyOS часто сравнивают с Android, но это не совсем правильно. Первые версии HarmonyOS, использовавшиеся на смартфонах, были тесно связаны с Android — по сути, они форк Android AOSP, в который встроили новые модули Huawei. Однако с версией HarmonyOS 4 (выпущена в 2023 году) началось постепенное отдаление от Android-ядра. Тогда Huawei пообещал, что следующая итерация, HarmonyOS Next, будет полностью независимой, без возможности запуска Android-приложений. Так и получилось.

При чем здесь OpenHarmony

Как и Android Open Source Project (AOSP), Harmony OS написана на проекте с открытым исходным кодом. И Huawei — главный разработчик, но не единственный. За развитием OpenHarmony стоит Open Atom Foundation — некоммерческая организация с открытым исходным кодом, в которую входят такие крупные игроки, как Alibaba, Baidu, Huawei, Inspur, Qihoo 360, Tencent и China Merchants Bank.

Несмотря на то, что OpenHarmony — полноценная операционная система, она изначально не создавалась как готовый продукт для конечных пользователей. Аналогично AOSP, OpenHarmony скорее представляет собой фундамент, на основе которого другие компании или разработчики могут создавать собственные продукты. Поэтому потребительских устройств на «чистом» OpenHarmony вы не встретите — как и устройств на «чистом» AOSP.

Исходный код OpenHarmony лежит на Gitee (китайском аналоге GitHub), подобном Github, базирующемся в Китае). Текущая стабильная версия OpenHarmony — 5.0, вышла в сентябре 2024.

Окончательная независимость — HarmonyOS Next

В 2024 году Huawei анонсировал HarmonyOS Next, который стал первым релизом без поддержки Android-приложений. Это значит, что разработчикам придётся создавать приложения с нуля или портировать их на новую платформу. Чтобы стимулировать переход, Huawei предлагает разработчикам SDK, IDE и денежные субсидии. Компания заявляет, что уже более 4000 китайских разработчиков начали адаптировать свои приложения.

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

Об архитектуре

Huawei отказались от Linux и Android в пользу собственного микроядра. Это распределенная ОС, где каждый компонент выполняет конкретную узкую функцию, а вся система легко масштабируется и адаптируется под разные устройства. По словам Huawei, 15 000 приложений уже стали частью их экосистемы.

Вот основные компоненты HarmonyOS:

• Микроядро. Главная особенность архитектуры HarmonyOS — полностью собственное микроядро, не основанное на Linux. Оно выполняет только базовые функции: управление памятью, планирование задач, межпроцессное взаимодействие и безопасность. Все остальное, включая драйверы и файловые системы, вынесено в пользовательское пространство — это повышает надёжность и защищённость системы. За безопасность ядра отвечает архитектура StarShield. IPC работает через шифрованные каналы, а само ядро поддерживает разные архитектуры, включая ARM, x86 и RISC-V.
• API и SDK для разработки приложений. Он включает модули для интерфейса, мультимедиа, управления и взаимодействия между устройствами. Все работает через среду DevEco Studio. Поддерживает «мультискрин» — например, перетаскивание видео с телефона на телевизор или передачу вызова на часы. Под HarmonyOS приложения пишутся на двух языках — ArkTS (прокаченная версия TypeScript) и Cangjie (подробнее об этом языке можно почитать здесь).
• Ark Compiler. Ark Runtime — аналог Android Runtime, но адаптированный под HarmonyOS. Запускает приложения, созданные на ArkTS и Ark UI. Главное преимущество — можно один раз написать приложение, и оно будет работать на любом устройстве HarmonyOS. По словам Huawei, с помощью компилятора устройства могут работать до 30% быстрее и тратить на 20% меньше энергии.
• ArkUI + ArkTS. ArkUI — фреймворк, чем-то похожий на SwiftUI. Он декларативный и работает на языке ArkTS. Если вы писали на TS, то до 97% кода можно сохранить без изменений.

HarmonyOS Next — это попытка Huawei создать «всё в одном»: одну операционку для ноутбуков, часов, ТВ и бытовой техники (чайники, берегитесь). Вместо тяжёлой системы с кучей костылей, микроядро и интерфейс ArkUI, благодаря которым приложения легко адаптируются под любой экран. Это особенно важно, потому что Система должна заменить целый набор западных сервисов, недоступных в Китае. Правда, есть нюанс. HarmonyOS Next все-таки может запускать Android-приложения, но не нативно. Для этого она использует эмулятор EasyAbroad (处境), который позволяет запускать популярные аппы типа YouTube, Gmail, Google Maps и другие. Интерфейс напоминает магазин приложений, все работает адекватно, но пока нет пушей.

Конечно, куда же без ИИ: в системе встроена собственная языковая модель PanGu-Σ и платформа глубокого обучения MindSpore. Huawei хочет, чтобы ИИ отвечал на команды, помогал управлять техникой и делал устройства умнее без подключения к облаку. Такой подход дает шанс создать замкнутую экосистему без Google и OpenAI — и это реальная альтернатива для китайского рынка.

Конкуренция с Западом — это реально?

В октябре 2024 года HarmonyOS поддерживалась на 1 млрд устройств (но вопрос в том, сколькими из них пользуются), а количество зарегистрированных разработчиков сейчас уже явно перевалило за 6,8 млн. Но здесь нужно учитывать, что почти все из них сосредоточены внутри Китая. Да, это делает HarmonyOS самой популярной операционкой в пределах одной страны, но ее глобальное влияние пока невелико.

Если говорить о Linux, то, конечно, ее доля на мировом рынке невелика — всего 4%, но при этом это доминирующая ОС на серверах, встраиваемых системах и среди энтузиастов. Что касается мобилок, Android пользуются более 72% юзеров, iOS — 27,5%, и чуть меньше одного процента уходит Самсунгу.

Какие у HarmonyOS могут быть проблемы:

1. Без глобальной поддержки разработчиков HarmonyOS будет сложно конкурировать с Play Store и App Store.
2. В других странах HarmonyOS практически не распространен.
3. Хотя Huawei обещает открыть HarmonyOS, на деле исходные коды доступны лишь частично.
4. HarmonyOS — часть китайской технологической независимости. Ну, лицо запада представляете.

Однако Huawei делает ставку на «национализацию» ОС: если HarmonyOS будет использоваться во всех госучреждениях, школах, армии и госсекторе, это может создать внутренний рынок в сотни миллионов устройств. Кроме того, Huawei активно развивает партнерства с китайскими брендами: электромобилями (например, Aito, Avatr), бытовой техникой, носимыми устройствами. Другими словами, экосистема, которую мы заслужили.

Если Huawei удастся доказать, что HarmonyOS действительно надёжнее, быстрее и безопаснее, чем Android или Linux (а может, даже Windows или MacOS), это может привлечь интерес и в развивающихся странах, особенно в Азии и Африке.

Сейчас на глобальном уровне китайцам вряд ли удастся подвинуть западные технологии: Android и Linux обладают колоссальной инерцией и экосистемами, выстроенными десятилетиями. Хотя ставка на искусственный интеллект действительно может сыграть. Главное сейчас для Huawei — привлекать как можно больше разработчиков в HarmonyOS и доказывать, что оно того стоит. Может быть, через несколько лет мы увидим альтернативный цифровый мир через границу (или даже окажемся в нем…).

iOS или Android? React Native или Flutter? Собираем все новости и гайды по мобильной разработке тут.

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

Немного базы

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

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

Создаём мобильное приложение с нуля: от идеи до публикации в App Store и Google Play — Делимся полным циклом создания: дизайн, разработка, тестирование, релиз.

Введение в мобильную разработку для Android: с каких языков начать изучение? — Рассматриваем, с каких языков программирования начать путь в Android-разработке и почему.

8 языков программирования для Android-разработчика — Перечисляем восемь языков программирования, которые стоит рассмотреть Android-разработчику. Изучаем плюсы, минусы, области применения, особенности.

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

Основы SwiftUI для iOS-разработчиков — Изучаем базовые возможности SwiftUI: декларативная верстка интерфейсов, примеры кода и сокращение сроков разработки.

Начало работы в Android Studio и первый простой проект — Пошаговое руководство по началу работы в Android Studio и созданию первого простого проекта. Учимся пользоваться инструментом с нуля.

Практика, инструменты и тонкости

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

Работа с анимацией в Android: разбираем MotionLayout — Рассказываем, как использовать MotionLayout для создания сложных анимаций в Android-приложениях. С примерами!

Jetpack Compose и Kotlin: как разрабатывать современные UI — Показываем, как разрабатывать современные пользовательские интерфейсы с помощью Jetpack Compose и языка Kotlin. Делимся, как использовать в проектах.

Java vs Kotlin для Android-разработки: ответы «за» и «против» — Сравниваем Java и Kotlin для Android-разработки: плюсы, минусы и рекомендации по выбору.

Бойлерплейт Fastlane для быстрого обновления Android-приложений — Показываем, как использовать Fastlane для автоматизации обновлений Android-приложений, даем рекомендации по применению.

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

Про рост, релиз и продвижение

Когда всё работает — пора думать про рост, релиз и продвижение:

Как добавить приложение в Google Play — Объясняем, как подготовить и опубликовать приложение в Google Play: от регистрации до релиза.

5 главных ошибок в ASO — App Store Optimization — Разбираем пять распространенных ошибок в App Store Optimization и как их избежать. Что нужно делать, чтобы не слить продвижение.

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

Не забудьте сохранить, чтобы не искать потом по всему интернету!

Большая подборка по React — уже на сайте.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Определяем цель

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

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

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

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

Выбираем платформу и инструменты

Сегодня на российском рынке доминируют две мобильные операционные системы: Android (около 70% пользователей) и iOS (около 30%). Оптимальным решением будет разработка приложения для обеих платформ, особенно если вы ориентируетесь на крупные города, где доля пользователей iOS существенно выше.

Приложения под Android большинство разработчиков пишет на Kotlin, хотя Java до сих пор остается одним из вариантов из-за обширной базы готовых решений и библиотек. Основной средой выступает Android Studio — в ней есть весь необходимый инструментарий для создания, отладки и тестирования приложений. Современные разработчики активно используют Jetpack Compose для построения пользовательского интерфейса, Room для работы с базами данных, Retrofit для сетевых запросов и Dagger или Hilt для внедрения зависимостей.

В мире iOS основным языком программирования стал Swift — современный и безопасный инструмент для нативных приложений. Разработка ведется в среде Xcode, официальной IDE от Apple. Для построения интерфейсов все чаще используется SwiftUI, для управления данными — Core Data, а для сетевого взаимодействия — фреймворк Alamofire. Работа с асинхронными событиями упрощается с помощью фреймворка Combine.

При ограниченных ресурсах можно рассмотреть кросс-платформенную разработку. Так, Flutter использует язык программирования Dart и позволяет создавать производительные приложения с нативным внешним видом. React Native дает возможность применять веб-технологии для мобильной разработки, а Xamarin ориентирован на разработчиков, привыкших к экосистеме Microsoft и языку C#.

Выбор платформы и инструментов должен основываться на характеристиках вашей ЦА, требованиях к функционалу и имеющихся ресурсах. Учитывайте также, что для разных магазинов приложений (RuStore, App Store, Google Play) могут потребоваться специфические оптимизации и настройки.

Продумываем функционал

При разработке функционала важно следовать концепции MVP (Minimum Viable Product) — минимально жизнеспособного продукта. Это позволит быстрее выйти на рынок, получить обратную связь и итеративно улучшить приложение.

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

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

Важно уделить внимание и техническим аспектам функционала:

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

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

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

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

• MVVM — рекомендуемый Google подход с разделением UI и бизнес-логики
• MVI — однонаправленный поток данных, хорошо сочетается с реактивным программированием
• MVP — классическая архитектура. Популярна благодаря простоте реализации
• Clean Architecture — многослойный подход с упором на тестируемость и гибкость
• VIPER (iOS) — расширенный MVC со строгим разделением ответственности

Важное значение имеет также выбор технологий для хранения и передачи данных. Для локальной работы подойдут SQLite + Room, Realm или DataStore; для сетевого взаимодействия на Android чаще всего используют Retrofit + OkHttp, а в реактивных сценариях — Ktor Client.

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

Создаем удобный интерфейс

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

Эффективный UI/UX строится на пяти ключевых принципах:

1. Очевидность (интуитивное понимание интерфейса);
2. Экономия внимания (минимум шагов для достижения цели);
3. Консистентность (единообразие элементов с одинаковой функциональностью);
4. Обратная связь (видимый результат каждого действия);
5. Прощение ошибок (возможность отмены операций).

Современные инструменты значительно ускоряют создание качественных интерфейсов. Дизайнеры используют Figma, Adobe XD и Sketch для прототипирования. Android-разработчики предпочитают Jetpack Compose и Material Design Components. Для iOS актуальны SwiftUI, UIKit и Human Interface Guidelines от Apple.

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

Проводим тестирование

Юзабилити-тесты с фокус-группами, A/B-тестирование элементов и аналитика пользовательского поведения дают объективную картину взаимодействия клиентов с приложением.

Комплексное тестирование включает два основных направления:

1. Автоматизированное тестирование: unit-тесты (JUnit, XCTest) для проверки отдельных компонентов; интеграционные тесты для проверки взаимодействия между модулями; UI-тесты (Espresso, XCUITest) для проверки интерфейса; end-to-end тесты для имитации полного пользовательского сценария.
2. Ручное тестирование: функциональное (соответствие требованиям), тестирование производительности (работа под нагрузкой), юзабилити (оценка удобства), кросс-платформенное тестирование (проверка на разных устройствах) и тестирование подключений (поведение при различном качестве интернет-соединения).

Для этого используют специализированные инструменты: Firebase Test Lab для запуска тестов на множестве устройств, Crashlytics для мониторинга сбоев, Android Profiler и Xcode Instruments для анализа производительности. А Accessibility Scanner помогает адаптировать интерфейс для людей с ограниченными возможностями, расширяя потенциальную аудиторию.

Публикуем приложение

После тестирования и исправления проблем наступает ответственный момент публикации. Каждый магазин приложений имеет свои особенности процесса:

• Google Play: создание аккаунта разработчика ($25 единоразово); подготовка материалов (иконка, скриншоты, видео, описание); загрузка APK/App Bundle; заполнение формы оценки контента; настройка дистрибуции и ценообразования; ожидание проверки (до 2 дней).
• App Store: регистрация в Apple Developer Program ($99/год); создание записи в App Store Connect; подготовка маркетинговых материалов; загрузка сборки из Xcode; заполнение информации о возрастных ограничениях; ожидание рассмотрения (1-7 дней).
• RuStore: бесплатное создание аккаунта; подготовка материалов; загрузка APK; заполнение метаданных; быстрая модерация (до часа).

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

Поддерживаем и обновляем

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

Для эффективного мониторинга используют комплексные аналитические инструменты: Firebase Crashlytics для отслеживания сбоев, Firebase Analytics/Google Analytics для анализа пользовательского поведения, RuStore Remote Config — бесплатный аналог Firebase, Mixpanel для углубленного анализа пользовательских путей, AppMetrica от Яндекса как комплексное решение для российского рынка.

Автоматизация процессов разработки критически важна для регулярных релизов. CI/CD-системы (GitHub Actions, GitLab CI, Bitrise, Fastlane) позволяют автоматизировать сборку, тестирование и публикацию обновлений, значительно сокращая время выхода новых версий.

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

Продвигаем приложение

На рынке огромная конкуренция, и без активного продвижения ваш продукт просто затеряется среди тысяч других программ. Важную роль здесь играет ASO (App Store Optimization) — оптимизация для магазина приложений. В некоторых случаях был зафиксирован рост установок до 70% благодаря сильным ASO-стратегиям.

Для Android-приложений это означает настройку страницы так, чтобы пользователи легко находили ваш продукт. Здесь важно правильно подобрать ключевые слова для описания, создать привлекательную иконку и подготовить качественные скриншоты. Чтобы понять, какое оформление работает лучше, разработчики всё чаще используют A/B-тесты — такая возможность есть, например, в RuStore. Она позволяет сравнить разные версии карточки приложения и выбрать ту, которая эффективнее привлекает пользователей.

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

Еще один инструмент для продвижения приложений — социальные сети. Здесь можно показывать функционал программы, общаться с пользователями, отвечать на их вопросы и рассказывать о новых опциях. Это помогает создать активное сообщество вокруг продукта. Так, к примеру, В 2023 году компания Geozilla, разработчик приложения для отслеживания местоположения близких, провела кампанию по продвижению с инфлюенсерами в социальных сетях. В рамках сотрудничества удалось собрать более 1 миллиона просмотров, а коэффициент конверсии из кликов в установки приложения составил 24%.

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

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

Подводим итоги

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

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

iOS или Android? React Native или Flutter? Собираем все новости и гайды по мобильной разработке тут.

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

Что такое вайб-кодинг

Термин «вайб-кодинг» впервые использовал AI-инженер из Tesla и Open AI Andrej Karpathy на своей страничке в Твиттере:

Если кратко, то суть примерно такая:

«Вайб-кодинг» — это когда просто говоришь ИИ, что делать, и почти не трогаешь код. Жму «Принять все», ошибки просто копирую обратно в ИИ — обычно он сам чинит. Даже прошу сделать его что-то максимально глупое и простое типа «уменьши отступ у боковой панели в два раза». Иногда баги не исправляются, тогда прошу менять что-то, пока не заработает. Отлично для небольших проектов. По сути, я не кодю — просто говорю, запускаю и копирую, а оно как-то работает.

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

Вот, например, еще один твиттерский сделал Candy Crush всего одним промптом:

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

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

Что говорят айтишники

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

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

В комментах ему ответили, что вайб-кодинг очень помогает, если хочешь научиться чему-то новому:

Автор согласился и сказал, что это действительно так: люди переоценивают возможности ИИ, и без знаний программирования все рухнет. А еще в комментах было предположение, что SwiftUI — довольно узкая тема, поэтому нейронки не могут работать с ним в полном объеме. А вот простой React — совсем другое дело.

Есть ли польза от вайб-кодинга

На самом деле, да. Особенно это касается владельцев бизнеса, диджатальщиков и в целом тех, кто работает с контентом. Например, если редакции журнала нужно создать пример какого-то интерфейса, сайта или мини-игры, то они могут не нанимать специального кодера и не тратить время собственной команды разработки. Или, например, бизнесу нужно создать простой лендинг или приложение с минимальным UI — здесь тоже на помощь приходит вайб-кодинг.

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

Недавно эксперты посчитали, что к 2027 году количество строк кода, написанных ИИ, увеличится на 25%. Уже сейчас нейросети закрывают 5-10% рутинных задач, а в будущем этот процент станет еще выше.

А вот Дарио Амадей — CEO Anthropic и создатель ClaudeAI — и вовсе заявил, что программисты закончатся всего через год. По его словам, через полгода нейронки будут писать до 90% кода, а через год — и вовсе весь. В США, кстати, уже упал спрос на прогеров. Но здесь важно сделать ремарку от редакции: пока нет нейронок, которые могут написать полностью безопасное приложение. Его нужно тестировать и проверять на ошибки.

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

Наш совет — не пытайтесь создавать действительно крупные и важные проекты, например, банковские приложения, ПО и так далее. Если что-то пойдет не так и у юзера, например, по ошибке спишется больше денег с карты или злоумышленники получат доступ, кого винить — ИИ, вас или компанию?

А теперь — делаем свой простой сайт

Сейчас мы попробуем создать классный сайт с приглашением на вечеринку и простой формой пожеланий по еде. Использовать будем Grok. Вот первый промпт:

А вот первый результат. Кажется, очень неплохо! Grok создал HTML-код и дал подробную инструкцию, как прикрутить гугл-таблицы и залить сайт на Гитхаб, чтобы он открывался по ссылке. А еще доступен предпросмотр прямо в интерфейсе — очень удобно.

Единственное, кажется, что приглашение немного пустовато. Напишем еще один промт:

Теперь сайт выглядит вот так:

Все еще не идеальный вариант. Давайте попробуем доработать форму и сделать тайминг в виде таймлайна:

Кажется, получилось:

А еще давайте попробуем доработать вишлист. Например, добавить иконки рядом с «подарками» и изменить шрифт на рукописный.

Ожидание:

Реальность:

Что ж, попробуем исправить:

Ну, допустим:

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

А вы — обязательно попробуйте вайб-кодинг и делитесь своими творениями в комментах.

Императивный подход:

«Встань. Подойди к выключателю. Нажми на нижнюю часть клавиши. Возвращайся обратно и садись».

Декларативный подход:

«Выключи свет».

Вот так фреймворк сокращает сроки разработки под iOS.

До SwiftUI использовали набор UIKit. Он устраивал разработчиков, но создание UI-элементов занимало много времени. В новых проектах на SwiftUI продолжают обращаться к набору компонентов — фреймворк пока не покрывает всех возможностей UIKit.

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

Начало работы со SwiftUI

Приложения под iOS пишут в IDE Xcode.

Создаем новый проект для платформы iOS, выбираем приложение «App». На следующей странице нужно придумать название проекта, ввести идентификатор (в качестве «заглушки» можно написать com.example).

Далее убедимся, что в поле «Interface» выбран SwiftUI и язык программирования — Swift.

После заполнения информации о проекте Xcode создаст базовую структуру приложения.

Основной файл проекта, с которым будем работать, называется ContentView.swift. По умолчанию Xcode создает в нем шаблон приложения «Hello, world!».

Чтобы изменить текст, нужно обновить строку внутри Text, и в превью справа отобразится обновленный экран. Симулятор iOS-устройства запускать не обязательно.

Компоненты в SwiftUI должны соответствовать протоколу View. Он определяет, как выглядят и ведут себя элементы интерфейса.

По правилам протокола View, разработчик должен реализовать одно обязательное свойство — body. Оно описывает содержимое и иерархию представления на экране.

Компонентный подход

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

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

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

Основные компоненты iOS SwiftUI

Чтобы добавить на экран приложения текст, нужно создать компонент Text, для картинки — Image, для кнопки — Button и т. д.

Текст

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

Картинки

Изображения в SwiftUI подключаются из ассетов проекта или системных иконок SF Symbols:

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

Кнопки

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

Поле ввода и переключатели

Требуют привязки текста свойством @State:

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

Переключатели тоже работают через привязку к @State:

Списки

Бывают статическими и динамическими.

Если планируете добавлять новые элементы в список, выбирайте динамическую структуру:

Создание пользовательского интерфейса

Чтобы расставлять элементы по своим местам, в SwiftUI применяют контейнеры:

• HStack,
• VStack,
• ZStack.

HStack располагает элементы горизонтально, VStack — вертикально, а ZStack накладывает компоненты друг на друга.

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

Работа с состоянием

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

Локальное состояние хранится в @State. На первом экране для отображения и изменения счетчика его достаточно:

Передадим значение переменной count во вложенное представление с помощью @Binding. Теперь дочерний экран сможет напрямую менять состояние основного:

Если функция с более сложной логикой нужна на нескольких экранах, лучше использовать @StateObject.

Глобальное состояние, доступное любому экрану, нужно прописывать в @EnvironmentObject. Например, настройку темы:

Анимации и взаимодействие

Первым рассмотрим метод withAnimation на примере простой задачи: нужно скрывать и показывать элемент. С анимацией это выглядит так:

Плавное появление и исчезновение элементов удобнее реализовывать через модификатор .transition. Еще можно применять встроенные анимации через .animation. Они автоматически привязываются к изменениям состояния.

Поведение компонентов SwiftUI можно настроить на жесты пользователя. Например, перемещение объекта через DragGesture и реакции на нажатия через TapGesture.

Работа с навигацией

Переходы между экранами в приложении реализуют через NavigationView и NavigationLink.

Контейнер NavigationView добавляет кнопку для перехода и навигационный заголовок:

Здесь каждая строка в списке — это интерактивная ссылка, а destination — содержимое следующего экрана.

Если нужно переключаться между вкладками, то лучше использовать TabView. Это как папки на рабочем столе: каждая вкладка ведет к отдельному разделу:

Каждая вкладка содержит свой экран. TabItem задает иконку из библиотеки SF Symbols и текст для таба.

Интеграция с UIKit

SwiftUI отлично справляется с созданием интерфейсов, но иногда возникает ситуация, когда нужного элемента в нем просто нет. Тогда разработчики обращаются к UIViewRepresentable. Он «оборачивает» UIKit-компонент и делает его частью SwiftUI-интерфейса.

Например, так можно добавить индикатор активности из набора UIKit:

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

Обратная задача: внедрить SwiftUI в существующий UIKit-проект. Здесь поможет класс UIHostingController. Он берет View из SwiftUI и превращает его в контроллер, который можно добавить в UIKit. Класс UIHostingController используют, чтобы постепенно адаптировать старый код.

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

Если хотите узнать, какие фреймворки и библиотеки учить, чтобы быстрее найти первую работу, читайте ответы middle и senior разработчиков.

В этой статье мы разберемся со Swift Grand Central Dispatch (GCD) раз и навсегда. Несмотря на то, что GCD может казаться устаревшим в условиях существования Swift Modern Concurrency, код с использованием этого фреймворка будет встречаться еще долгие годы как в проде, так и на собеседованиях.

Сегодня сосредоточимся только на фундаментальном понимании GCD. Мы в деталях рассмотрим самые ключевые концепции в многопоточности, включая взаимодействие потоков и очередей. С осознанием этих основ легко будет самостоятельно разобраться с другими темами: DispatchGroup, DispatchBarrier, семафоры, мьютексы и так далее.

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

P.s. Это первая часть материала. В следующей рассмотрим реальные задачи, которые пригодятся вам на собеседованиях

Основные понятия: поток, многопоточность, GCD, задача, очередь

Поток — фактически, контейнер, в который кладется и выполняется какой-то набор инструкций для системы. На самом деле, весь исполняемый код исполняется в каком-то потоке. Различают main (основной, главный) и worker потоки.

Многопоточность — возможность системы выполнять несколько потоков параллельно (одновременно).

Grand Central Dispatch (GCD) — фреймворк для удобной работы с потоками (использования преимуществ многопоточности). Основные примитивы — задача, очередь. GCD — инструмент, позволяющий легко писать параллельно исполняющийся код. Простой пример: вынос тяжелых вычислений в отдельный поток, чтобы не мешать обновлению UI на основном (main) потоке.

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

Очередь (queue) — основной примитив GCD. Это место, куда разработчик помещает задачи для выполнения. Очередь берет на себя задачу по распределению по потокам (каждая очередь имеет доступ к thread pool — пулу потоков системы).

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

Типы очередей

Основная очередь (main) — выполняется только в основном потоке. Она последовательная (об этом чуть позже).

Глобальные очереди (global) — 5 очередей (на каждый уровень приоритетности), предоставляемых системой. Они параллельные.

Пользовательские очереди (custom) — создаются пользователем. Разработчик сам выбирает один из 5 приоритетов и тип: последовательная или параллельная (по умолчанию — последовательные).

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

Приоритеты очередей

Quality of Service (QoS, дословно — качество обслуживания) — система приоритетов очередей. Чем выше приоритет очереди, в которой находится задача, тем больше ресурсов на нее будет выделено. Всего есть 5 QoS:

.userInteractive

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

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

.userInitiated

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

.default

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

.utility

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

.background

Для задач с самым низким приоритетом. Пример — очистка кэша.

Последовательные и параллельные очереди

Все очереди делятся на 2 типа: последовательные (serial) и параллельные (concurrent).

Последовательные (serial) очереди — когда следующая задача начинает выполняться только после окончания текущей.

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

Способы выполнения задач

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

Асинхронно (async)

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

В этом примере мы асинхронно добавляем задачу на print из главного потока (так как мы пишем этот код, не находясь ни в какой очереди, стандартно он исполняется в главном потоке) в основную очередь. Ставим print(“A”) в основную очередь и сразу же идем дальше, не ожидая ее исполнения — выполняем print(“B”).

Поскольку главный поток занят выполнением текущего кода, а задачи из main очереди могут выполняться только в главном потоке, сначала завершается текущая задача — print(“B”), а только потом, после освобождения главного потока, выполняется задача из основной очереди — print(“A”). Таким образом, вывод — BA.

Логика выполнения:

1. Добавляем задачу в глобальную очередь с приоритетом .default из основного потока асинхронно — в вызывающем потоке сразу идем дальше и вызываем indicateLoading().

2. Через какой-то промежуток времени система выделяет ресурсы для исполнения задачи в глобальной очереди и начинает ее выполнение в свободном потоке из thread pool. Вызывается метод updateData().

3. Задача с updateInterface() добавляется в основную очередь асинхронно — в вызывающем потоке не ждем ее исполнения и идем дальше.

4. Когда добавляем задачи асинхронно, не можем точно сказать, когда на них будут выделены ресурсы. В конкретном случае неизвестно, что произойдет раньше: выполнение updateInterface() в основном потоке или Logger.log(.success) в одном из worker потоков из thread pool (как не можем и в шагах 1-2: первым выполнится indicateLoading() в основном или updateData() в worker). Основной поток хоть и не стоит без дела (в нем выполняется обновление интерфейса, обработка жестов и другие подкапотные задачи), но он работает всегда и на него выделено максимальное количество системных ресурсов. С другой стороны, выделение ресурсов для выполнения в workerthread может произойти почти мгновенно.

Заметьте, что в этом видео глобальная очередь выполняет свои задачи в каких-то свободных worker потоках.

Синхронно (sync)

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

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

Заметьте, что в этой анимации пользовательская очередь выполняет свои задачи в каких-то свободных worker потоках.

Deadlock

Deadlock возникает, когда поток бесконечно ждет сам себя или другой поток для продолжения работы. Классический пример — вызов DispatchQueue.main.sync {} из главного потока.

В этом случае:

• Главный поток выполняет printing().
• DispatchQueue.main.sync { print("B") } пытается выполнить код синхронно, но main-очередь может выполняться только в главном потоке.
• Главный поток уже заблокирован и ждет завершения print("B"), но эта задача не может начаться, так как поток занят.

В итоге возникает deadlock — выполнение программы зависает.

Заметьте, как print(“B”) из основной очереди не может выполниться, поскольку задача из main очереди может выполняться только на main потоке, но он заблокирован.

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

Надеюсь, Вы нашли для себя что-то полезное в этой статье. Если какие-то вещи остались непонятными, я могу бесплатно помочь с разбором: telegram @kfamyn.

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

В июне 2024 года вышла новая версия языка — узнаем, какие функции появились в этом релизе, в чем преимущества Swift 6, каковы отличия этого продукта от С++.

Обзор Swift: путь к версии 6

Согласно официальным данным, Swift создан разработчиками компании Apple в 2014 году. Однако алгоритмы, которые лежат в основе этого языка, использовались еще в 90-х годах прошлого века при создании платформы NeXT — основы для будущих систем iOS и macOS.

Сотрудники Apple занимались разработкой языка несколько лет, при этом у Свифт нет конкретного прародителя, поскольку при создании использовались наработки сразу нескольких продуктов — Objective-C, Haskell, Python, C++ и других.

В 2014 году на официальной презентации был представлен пакет документов по языку Swift на 500 страницах. Уже в следующем году вышла обновленная, более производительная версия Swift 2.0.

В 2015 вышла модификация 3.0, которая отменила прошлые версии. Следующее масштабное обновление вышло в 2017 году — версия Swift 4.0 несколько раз модифицировалась. В 2019 вышла пятая версия, в которой содержалось множество нововведений. 11 июня 2024 — дата релиза Swift 6, последней на текущий момент версии языка.

Особенности и преимущества Swift 6

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

В отличие от Objective-C — языка, который корпорация Эппл использовала ранее, синтаксис у Swift более понятный и лаконичный. Программистам требуется меньше времени на написание кода.

Еще одна ключевая особенность Свифта — его повышенная производительность. Несмотря на простоту и быстрое освоение, эффективность языка довольно высока. Эксперты утверждают, что Swift втрое быстрее Objective-C и в 8 раз опережает по скорости Python. В новой версии разработчики попытались превзойти по этому параметру C++.

Другие преимущества:

• Наличие современных библиотек и фреймворков, которые существенно упрощают написание кода для программистов. В распоряжении разработчиков — множество готовых функциональных блоков.
• У Swift открытый исходный код, что делает язык доступным для всех пользователей. Это может показаться странным для Apple, но в данном случае такой ход корпорации полностью оправдан. Профессиональное коммьюнити занимается исправлением багов и предлагает полезные нововведения.
• К сильным сторонам языка относится его безопасность. По этому показателю Свифт превосходит Objective-C. Благодаря улучшениям при работе с памятью разработчики минимизировали риск стороннего доступа к данным.
• Более эффективная работа со сценариями снижает вероятность критических ошибок при разработке программ.
• Возможность визуализации результата программирования. С помощью специальной песочницы можно наглядно оценить результаты работы конкретной программы. Такой метод позволяет быстро обнаружить ошибки в коде и тем самым сократить время на разработку.
• Динамические библиотеки. Благодаря такому формату пользователи быстрее вносят изменения и обновления в готовые коды, не дожидаясь релиза новых версий iOS.

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

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

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

Что касается перспектив Swift, то они вполне определены. Разработчики, владеющие этим языком, постоянно востребованы. Количество пользователей, приложений и возможностей систем macOS и iOS постоянно растет, а значит, растут и запросы на разработку нового софта.

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

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

Что нового в Swift 6

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

Обратите внимание, что рассматриваемые нами изменения актуальны на момент официального релиза Swift 6, то есть в будущем наверняка появятся дополнительные обновления.

Полный параллелизм

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

В Свифт 6 проверка параллелизма улучшена — устранены ложные сообщения о гонках данных, распространенные в версии 5.10. Многие целевые изменения сделали параллелизм более простым для освоения.

Примером значимого нововведения можно назвать SE-0414 — эта опция позволяет компилятору привести доказательства, что разные части кода могут выполняться одновременно. Изменение основано на концепции sendability (отправляемости) — то есть базируется типах данных, которые возможно в безопасном режиме отправлять в параллельной среде.

Некопируемые типы данных

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

Интеграция с С++

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

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

Поиск ошибок

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

Замена функций

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

Итерация пакета

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

Анализ нововведений: как Swift 6 меняет разработку

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

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

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

В Swift 6 задействованы механизмы изоляции данных, опции для защиты изменений кода и безопасного обмена информацией. Безопасность data-race здесь достигается по умолчанию.

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

Сравнение Swift 6 и C++

На презентации Swift 6 представители Apple заявили, что в новой версии язык стал еще более скоростным и безопасным, а по эффективности, возможно, превзошел С++. В свое время Свифт создавался именно в качестве потенциальной замены языка С++, у которого есть есть определенные уязвимости.

Рассмотрим основные параметры Swift 6 и сравним их с показателями С++:

• Скорость. С английского слово Swift переводится как «стремительный». Разработчики изначально намеревались сделать высокоскоростной язык. По скорости он однозначно превосходит последнюю версию Python, а по некоторым алгоритмам опережает и С++.
• Производительность. Скорость исполнения кода неизбежно повышает производительность приложений, которые работают на Свифт. При этом софт, в отличие от аналогичных программ, написанных на С++ и других языках, не перегружает до критических значений вычислительные мощности устройств.
• Код. Свифт изначально создавался как язык с максимально простым, неперегруженным синтаксисом. Это делает работу с инструментом понятной и доступной. В новой версии громоздких конструкций и лишних элементов стало еще меньше. Swift все больше становится похожим на естественный язык, оставаясь ясным и чистым даже при создании сложного года. Неочевидных ошибок здесь встречается на порядок меньше, чем в С++.
• Память. Инновационная система автоматического управления памятью ARC следит за расходованием и очисткой нужного количества ресурсов. Программисту можно не отслеживать этот параметр.
• Безопасность. Еще один аспект, в котором эксперты отдают предпочтение Swift 6. В новой версии несанкционированный доступ к важным данным минимизирован. При этом язык точнее отслеживает баги разработчика, снижая риск малозаметных, но критичных ошибок. При этом Свифт более предсказуем, что важно для процессов тестирования и отладки.

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

Apple уделяет время и ресурсы на продвижение и развитие языка. Компания следит не только за обновлением версий, но и постоянно предоставляет пользователям актуальные обучающие материалы. В macOS есть встроенная среда разработки, которая поддерживает Свифт, что называется «из коробки». В Apple Swift Playgrounds можно создавать пробные версии приложений и тут же тестировать их. Официальный подробный учебник по языку доступен в открытом хранилище Apple Books.

Есть ли позиции, по которым C++ опережает Swift? Да, такие моменты присутствуют, поскольку ничего совершенного в природе, даже если это цифровая среда, не существует.

Один из главных недостатков Swift 6, как и предыдущих версий, это узкая специализация. Свифт применяется только для разработки программ на устройства Apple, никакого другого назначения у него нет. Приложения в теории могут работать на Windows и Linux, но это будет неудобное решение.

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

Относительным недостатком можно считать неразрывную связь Swift 6 и старых версий с Objective-C. Свифт без проблем встраивается в продукты, написанные на Objective-C, что обеспечивает разработке гибкость. Однако новичкам, желающим освоить программирование для Apple, придется освоить оба языка, иначе работать с приложениями будет сложно.

Итоги

Очевидно, что при разработке продуктов для Apple язык Swift 6 будет предпочтительным выбором. Однако по причине узкой специализации Свифт не получится использовать для написания программ на других ОС. В этом отношении C++ более функционален и практичен, поскольку относится к универсальным языкам программирования.

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

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

Стоит отметить, что импортозамещение обычно подразумевает создание аналога продукта, который больше не доступен в России. В случае Zenly, это приложение не просто ушло из России — оно полностью прекратило свою деятельность. Поэтому мы не выступаем импортозаместителями в прямом смысле этого слова. Наше приложение — самостоятельное решение, разработанное с нуля.

Какие основные функции и возможности предлагает Blink пользователям? Можем ли мы «бампнуться» по-старинке или отправить смайлик другу на весь экран?

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

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

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

Еще одна интересная особенность Blink — функция «трях», аналогичная «бампу» из Zenly. Теперь, чтобы сообщить друзьям о встрече, достаточно просто потрясти телефонами. Вообще, термин «бамп» в английском языке имеет сексуальный подтекст, поэтому для англоговорящей аудитории звучит так же странно, как «трях» для русскоязычной.

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

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

Помимо Golang, в стек входит ряд других ключевых инструментов. Для обработки потоков данных в режиме реального времени используется Apache Kafka, надежный и производительный брокер, с которым уже была знакома команда разработчиков и DevOps/SRE. Выбор Kafka обусловлен необходимостью надежной маршрутизации гигабайтов геопакетов в секунду.

В качестве основной базы данных выбран PostgreSQL, известный своей надежностью, производительностью и возможностью масштабироваться. Для кэширования данных используется Redis, а ClickHouse – для аналитики и обработки больших объемов данных, в том числе для пост-процессинга геокоординат. На данный момент объем данных в кластере приближается к 30 ТБ, и ClickHouse справляется с этой нагрузкой.

Для мобильных платформ мы используем Swift для iOS и Kotlin для Android.

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

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

В основе нашей работы лежит сбор данных с устройств пользователей и применение технологий геофенсинга. Хотя мы не изобретаем революционных решений, поскольку действуем в рамках закрытых операционных систем (iOS и Android), тщательно обрабатываем полученные данные, чтобы обеспечить их точность и надежность. Как происходит процесс?

Все начинается с получения координат от пользователя. Эти данные проходят несколько этапов проверки. Мы анализируем, не произошел ли резкий скачок местоположения, например, перемещение из России в Австралию за короткий промежуток времени. Фильтр Калмана помогает сглаживать координаты, удаляя аномальные значения и улучшая точность.

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

Мы также проверяем, находится ли пользователь в знакомом окружении, например, в домашней сети Wi-Fi. Если данные указывают на аномальное перемещение, корректируем местоположение.

Стоит отметить, что в последнее время мы все чаще сталкиваемся с проблемами навигационных систем и GPS-глушилок. Поэтому разработали целый ряд фильтров и механизмов для обеспечения высокой точности геолокации. Кроме того, работаем над улучшением клиентской части, оптимизируя работу приложения для минимального потребления заряда аккумулятора. Blink в среднем потребляет всего 1% заряда в сутки, что является отличным показателем. Мы потратили много времени на это улучшение, и теперь приложение практически не тратит заряд, хотя работает в фоновом режиме.

Как реализована система хранения и обработки больших объемов геоданных в приложении? Какие технологии и подходы задействованы?

Мы внедрили два ключевых решения: Apache Kafka и ClickHouse.

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

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

Стоит отметить, что объем накопленных нами данных уже превышает 30 терабайт. Это огромный массив информации, который требует применения современных Big Data решений, таких как Kafka и ClickHouse. Благодаря этому мы можем эффективно управлять и анализировать все эти данные, извлекая ценные инсайты и предоставляя полезный сервис нашим пользователям.

А что насчет самих пользователей? Как вы подходите к вопросам безопасности и конфиденциальности данных в Blink? Какие меры предприняты для защиты личной информации?

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

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

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

Какие методы и инструменты применяются для анализа поведения пользователей, их передвижений и активности в приложении? Как вы используете эти данные для улучшения сервиса?

У нас есть два основных направления аналитики: клиентская и серверная.

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

В части серверной аналитики:

• Все события, связанные с действиями пользователей, собираются и отправляются на наш сервер, где хранятся в базе данных ClickHouse. Это касается как клиентских, так и серверных событий.

• Собранные данные затем передаются в BI-системы, такие как Redash и Superset, для визуализации и построения дашбордов.

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

Один из последних кейсов:

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

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

С какими основными трудностями и вызовами вы сталкивались в процессе разработки и масштабирования Blink? Как вы их преодолевали?

Несмотря на стремительный рост, мы столкнулись с несколькими серьезными техническими вызовами:

1. Изначально, с нагрузкой в 10 тысяч онлайн-пользователей, наши го и легковесные горутины, а также оптимизированные веб-фреймворки справлялись с нагрузкой. Однако с ростом аудитории до 100 тысяч возникли проблемы на сетевом уровне, которые нашим инженерам удалось решить за счет переконфигурирования балансеров (nginx + sysctl).
2. Для хранения географических данных мы выбрали PostgreSQL, но со временем объем этих данных превысил 1 ТБ, что привело к существенному падению производительности. Попытки горизонтально масштабировать PostgreSQL оказались малоэффективными, и в итоге мы перешли на Clickhouse, который гораздо лучше справился с этой задачей. Перевод на Clickhouse занял около недели, но куда больше времени потребовалось на миграцию данных из PostgreSQL.
3. Недостаток мониторинга приводил к тому, что о проблемах мы узнавали уже тогда, когда они становились критическими и вызывали простои сервиса. Несколько бессонных ночей наглядно продемонстрировали важность использования инструментов вроде Grafana.

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

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

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

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

Кроме того, мы разрабатываем собственную карту Blink Maps, которая будет интегрирована в приложение уже через несколько месяцев для некоторых устройств на Android. Это наша собственная 3D-карта, позволяющая решить технические ограничения, с которыми мы сталкиваемся при использовании платформенных карт, по типу Google Maps. Например, сможем более эффективно отображать больше пинов без задержек и сбоев. Карта будет регулярно обновляться, что позволит избегать проблем с устаревшей информацией. У нас свой движок, построенный на видеопроцессоре GPU, который на основе данных OpenStreetMap делает магию. Основу мы берем из OSM и поверх накручиваем все свои изменения.

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

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

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

Однако, в свете этих тенденций, стоит учитывать, что Apple и Google, например, продолжают усложнять работу с геолокацией для сторонних разработчиков. Несмотря на наличие встроенных решений, таких как Find My Friends у Apple, ограничения и новые требования для работы с геоданными становятся все более жесткими. Это создает дополнительные вызовы для разработчиков, которые должны адаптироваться к меняющимся условиям и искать альтернативные пути стабильной работы своих приложений.

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

Уязвимости и их последствия

Исследователи из EVA Information Security выявили три ключевые уязвимости:

• CVE-2024-38367: Уязвимость, связанная с манипуляцией URL в механизме проверки электронной почты, позволяла хакерам перенаправлять ссылки на свои серверы.
• CVE-2024-38368: Возможность захвата управления над «осиротевшими» кодовыми пакетами, которые продолжают использоваться в приложениях, но оставлены их разработчиками.
  
• CVE-2024-38366: Уязвимость, позволяющая выполнить код на сервере CocoaPods через инъекцию команд в процессе проверки адресов электронной почты.
  

Пример уязвимости

Одна из уязвимостей позволяла изменить URL для перенаправления пользователей на вредоносный сайт. Например, вместо обычного URL, который ведет на сервер CocoaPods:

Хакеры могли изменить его на:

Рекомендации по безопасности

Разработчикам, использующим CocoaPods, рекомендуют следующее:

• Синхронизировать файл podfile.lock со всеми разработчиками, чтобы избежать автоматического обновления до потенциально опасных версий.
• Выполнять проверку CRC (контрольной суммы) для внутренне разработанных подов.
  
• Проводить тщательный обзор безопасности любого стороннего кода.
  
• Проверять зависимости CocoaPods и избегать использования «осиротевших» подов.
  
• Использовать сторонние зависимости, которые активно поддерживаются.
  
• Проводить периодические проверки безопасности кода для выявления секретов и вредоносного кода.
  

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

В этом году решили выбрать тот же путь и оценили языки программирования:

— по рейтингам TIOBE и RedMonk (базируются на данных GitHub и активности обсуждений на Stack Overflow)

— порогу вхождения

— размеру зарплат разработчиков

В статье рассматриваем:

• Python
• JavaScript
• Java
• TypeScript
• Golang
• Ruby
• Swift

Python

Популярность

Язык находится на 1-м месте TIOBE. Несмотря на популярность, за год язык потерял в рейтинге 2,39%. Вот динамика изменения позиции Python с 2002 года.

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

Уровень зарплат

По данным Хабр Карьеры, медианная зарплата программистов на Python составляет 184 000 ₽. Минимальная заработная плата — 74 000 ₽ (джун), максимальная — 350 000 ₽ (лид).

Порог вхождения и перспективы

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

На Python можно писать как относительно несложные проекты, так и корпоративные системы с комплексной архитектурой. А библиотеки Python (TensorFlow и Keras) сделали его популярным среди специалистов для создания нейронных сетей и моделей машинного обучения.

JavaScript

Популярность

В рейтинге TIOBE JavaScript находится на 6-м месте, потеряв за год 0,11% (особой динамики нет). Это может означать только одно: JavaScript стабильно популярен у разработчиков.

В рейтинге RedMonk JavaScript на 1-м месте — он не сходит с этой позиции с 2012 года. Только один раз, в 2013 году, JavaScript уступил Java, но уже в 2014-м вернул место лидера.

Уровень зарплат

Согласно Хабр Карьере, медианная заработная плата составляет 176 000 ₽. Минимальная зарплата у джунов — 70 000 ₽, а максимальная, у сеньоров — 199 000 ₽ (данных по лидам у сервиса нет).

Порог вхождения и перспективы

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

Чтобы познакомиться с основами языка (синтаксис, типы данных, операторы), новичку достаточно 1-2 месяцев. Ещё месяц уйдёт на изучение работы с DOM-деревом и событиями. После этого человек сможет писать несложные скрипты для сайтов: для валидации форм, слайдеров, обработки кликов пользователя и т. д. Ну а дальше нужно осваивать асинхронное программирование и фреймворки — на это уйдёт от 2 до 5 месяцев.

В ближайшее время JavaScript вряд ли потеряет популярность, ведь с его помощью можно разрабатывать сайты (как фронтенд, так и бэкенд), приложения для смартфонов и даже игры. На JavaScript написан весь фронтенд Gmail и другие известные на весь мир приложения.

Java

Популярность

В рейтинге TIOBE Java находится на 4-м месте, язык потерял за год 4,34%. Сильнее сократился показатель лишь у языка С# — он упал на 4,81% за год. Тем не менее это не критическое падение.

Во втором рейтинге Java на 3-м месте — там он находится уже три года подряд. В RedMonk Java весьма стабилен: с 2012 года язык то падает до 3-го места, то поднимается на второе.

Уровень зарплат

По информации Хабр Карьеры, медианная зарплата специалистов по Java составляет 212 000 ₽. Джуны зарабатывают около 95 000 ₽, а лиды — 326 000 ₽. В целом, всё неплохо — компании предлагают разработчикам достойное вознаграждение.

Порог вхождения и перспективы

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

Java — объектно ориентированный язык. Помимо обычной базы в виде синтаксиса, структур данных и операторов придётся освоить концепции ООП: классы, объекты, наследование и полиморфизм.

В среднем у новичков это занимает от 2 до 6 месяцев. После вы сможете создавать несложные приложения для десктопов, смартфонов и веба: калькуляторы, todo-листы, игры.

Программисты на Java пользуются большой популярностью на рынке труда. На этом языке разрабатывают мобильные приложения под Android, большие корпоративные системы и игры. Так, на Java написаны Assassin’s Creed и Minecraft, серверная часть Pokemon Go, портала «Госуслуги» и приложений для интернета вещей, а также сервисы доставки еды и продуктов.

TypeScript

Популярность

У этого языка 35-е место в рейтинге TIOBE. За год TypeScript набрал примерно 0,39%, т. е. почти ничего не изменилось. Тем не менее разработчики советуют изучать TypeScript, в другом рейтинге он занимает более высокое положение.

По мнению RedMonk, TypeScript находится на 8-м месте, поднимаясь из «подвала» с 2016 года. В прошлом году он занимал то же место, из чего можно сделать вывод, что TypeScript явно востребован среди специалистов.

Уровень зарплат

На Хабр Карьере нет данных по зарплате разработчиков этой специальности. По информации сервиса Zarplan (сайт прекратил работу с 1 февраля 2024 года), медианная заработная плата программиста TypeScript составляет 201 000 ₽.

Порог вхождения и перспективы

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

Стоит ли учить TypeScript как первый язык программирования? Без знания JavaScript вам будет довольно сложно понять концепции и синтаксис TypeScript, обучение может затянуться на несколько месяцев. В описаниях стажировок и вакансий TypeScript обычно требуется в связке с JS или его фреймворками, поэтому начинать свой путь в программировании с TS не стоит.

TypeScript используют для создания пользовательских интерфейсов, frontend- и backend-частей веб-сайтов, а ещё больших бизнес-приложений, где требуется стабильность. Соответственно, популярность TypeScript вряд ли будет сильно снижаться.

Golang

Популярность

По рейтингу TIOBE язык Go находится на 11-м месте. Это один из немногих языков программирования, который за год стал популярнее: Golang набрал 1,38% рейтинга.

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

По RedMonk Go находится на 15-м месте. К слову, он занимал эту позицию ещё в 2018 году, затем несколько опустился в рейтинге и снова стал расти с 2021 года.

Уровень зарплат

Хабр Карьера сообщает, что медианная зарплата Golang-разработчика составляет 255 000 ₽. Джуны в среднем получают 125 000 ₽, а лиды — 424 000 ₽. Это один из лучших показателей среди языков программирования, о которых мы говорили выше.

Порог вхождения и перспективы

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

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

На Go разработаны инструменты для контейнеризации Kubernetes и Docker, консольное приложение GitHub CLI, а также база данных для работы с метками Prometheus. Пишут на Go в крупнейших компаниях России и мира, так что перспективы у языка хорошие.

Ruby

Популярность

В рейтинге TIOBE Ruby занимает 18-ю позицию. При этом за год он практически ничего не потерял, но и не набрал. Так что Ruby остаётся стабильно востребованным языком программирования.

А вот c RedMonk иная ситуация: в этом рейтинге у Ruby 9-е место. Но у языка неровная динамика: он то поднимается в рейтинге, то снова падает. Например, в 2012 году он занимал 5-ю позицию.

Уровень зарплат

Согласно Хабр Карьере, медианная зарплата специалистов составляет 223 000 ₽. По лидам данных нет. Зато известно, сколько получают джуны (в среднем 101 000 ₽) и сеньоры (350 000 ₽).

Порог вхождения и перспективы

С нуля учить этот язык вряд ли получится, уже практикующие кодеры рекомендуют освоить базовые концепции программирования (переменные, операторы, типы данных, циклы, функции, ООП) и только потом переходить к изучению этого языка. Чаще всего разработчики приходят в Ruby после нескольких лет работы на любых других языках.

Тем не менее этот язык стоит изучить, поскольку Ruby — современный, постоянно развивающийся язык программирования.

Ruby применяют в веб-разработке (фреймворк Ruby on Rails), создании скриптов для администрирования, DevOps и тестирования, научных вычислений и обработки данных. С использованием Ruby on Rails написаны серверные части веб-приложений Twitter, GitHub, Airbnb и Shopify, поэтому язык имеет хорошие перспективы в будущем.

Swift

Популярность

В рейтинге TIOBE язык занимает 16-е место. За год Swift потерял одну позицию, оставаясь тем не менее востребованным и популярным.

Вот его динамика.

По RedMonk видим, что Swift резко поднялся из «подвала» в 2016 году. После чего, начиная с 2018 года, стабильно занимает 11-е место.

Уровень зарплат

Медианный показатель здесь — 263 000 ₽, джуны получают около 110 000 ₽, а лиды — 430 000 ₽. Если верить Хабр Карьере, специалисты по Swift явно одни из самых высокооплачиваемых на рынке.

Порог вхождения и перспективы

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

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

Что выбрать?

Новичку для старта карьеры в IT лучше выбрать язык с максимально низким порогом входа, например Python, Go, JavaScript.

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

В любом случае главное, чтобы процесс затягивал, а работа нравилась. И конечно, не стоит бросать освоение языка на полпути, если что-то не заладилось. Чтобы поддержать мотивацию, рекомендуем к прочтению «Как войти в IT и не слиться по дороге».

Желаем удачи!

Какой контент там представлен?

На канале уже выложены записи сессий с прошлогодней конференции WWDC 2023. Видео рассортированы по плейлистам, охватывающим разные темы: App Store, Swift, дополненная реальность, Safari и другие. Это даёт представление о том, чего ждать от грядущего мероприятия.

Как канал связан с WWDC 2024?

Наполнение канала — лишь первый шаг в подготовке к главному событию года для разработчиков Apple. Сама конференция WWDC 2024 будет транслироваться на YouTube, наряду с другими платформами компании.

Благодаря этому создатели приложений смогут следить за всеми сессиями и докладами в прямом эфире.

Что ждать от грядущей конференции?

На WWDC 2024, которая пройдёт с 10 июня, Apple традиционно представит новые версии своих операционных систем: iOS 18, iPadOS 18, macOS 15 и другие. Но главным подарком для разработчиков станут именно обучающие видео, которые помогут им освоить все новшества максимально быстро и эффективно.

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

Вот о чем говорится в ролике:

1. Компании, такие как Сбербанк, пытаются обойти удаление, выкладывая приложения под другими названиями или устанавливая их через специальные точки.
2. Модераторы App Store иногда пропускают такие приложения, но они быстро удаляются после жалоб.
   
3. Сбербанк и другие компании ищут способы сохранить iOS-приложения, несмотря на проблемы с обновлением пользовательской базы и безопасностью.
   
4. Компании могут переходить на кроссплатформенные технологии или развивать PWA (Progressive Web Apps) вместо нативных iOS-приложений.
   
5. Спрос на iOS-разработчиков может снизиться из-за перехода на кроссплатформенные решения или PWA.
   
6. Несмотря на сложности, iOS-разработка остается востребованной в некоторых компаниях и секторах.
   
7. Слухи о том, что в iOS 17 можно будет устанавливать сторонние приложения, пока не подтвердились. Но если это произойдет, то ситуация для iOS-разработчиков изменится.
   
8. iOS-разработчикам рекомендуется изучать смежные области и технологии для расширения своих навыков и возможностей.
   
9. Ситуация с iOS-разработкой в России остается неопределенной, но есть надежда на улучшение условий для разработчиков и пользователей.
   

Ниже — транскрибация ролика.

Что теперь делать iOS-никам? Закрывают приложение, удаляют из App Store. Непонятно. Ужас, смерть, трагедия. Неужели придется учить Kotlin? Или еще, не дай бог, ужас C++ какой-нибудь. Ужас обуял некоторых iOS-ников. Они лихорадочно спрашивают, что делать. Сегодня без паники. Мы с вами разберемся. И выясним, какие вообще дела сейчас у iOS-разработчиков в России. Ну а вы наливайте себе чай, кофе, устраивайтесь поудобнее и поехали.

Проблема с распространением iOS-приложений

Итак, собственно, все началось как раз-таки с удаления приложения с App Store. Я бы хотел здесь на самом деле рассмотреть несколько вещей. Как поступают компании, то есть как они действуют [когда их приложения удаляют из стора]. И как реагирует iOS-разработчик, как реагирует на этот рынок. Собственно, вот две таких вещи мы сегодня и попытаемся рассмотреть. И начнем мы как раз с компаний.

Вот, допустим, есть компания Сбербанк. У нее удалили приложение одно из самых первых, по-моему, если не считать там ВТБ и так далее. Что они сделали? И, в принципе, до сих пор продолжают делать.

Они попытались выложить приложение в App Store под, ну там, другим каким-то названием, типа «Сбол», еще я не помню, какие-то названия были у ВТБ, как-то по-другому приложение называется. Альфа, по-моему, тоже пыталась выложить. Почему они это делают? Почему бы не оставить приложение как есть, да? Ну, потому что, во-первых, есть новые пользователи, а во-вторых, есть такое понятие, как дырки в безопасности. Дырки в безопасности периодически находятся, их надо фиксить, чтобы они были пофикшены, надо, чтобы все это выливалось в сторы, да, соответственно, нам нужно обновление.

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

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

Офис Сбербанка есть практически везде, соответственно, там можно наладить выпуск оборудования через iMazing, через специальный софт, установить все это на телефон. Что общего в этих двух вещах? Общего в них то, что Сбербанк не вышел и не сказал, так, iOS-приложения идут нахер, мы больше их не разрабатываем, да, и на iOS вот теперь у вас есть PWA (Progressive Web App, веб-приложение или сайт). Пользуйтесь им, в Иране все пользуются, и вы привыкаете жить, как в Иране, собственно. Нет. Сбербанк так не делает. Он пытается найти какие-то пути. И, собственно, ВТБ пытается найти какие-то пути, и другие компании какие-то пути пытаются найти. То есть, iOS-приложения, они не исчезли.

При этом, такие вот действия говорят нам о том, что, ну, допустим, тому же Сберу нет смысла вкладываться в iOS вот прям так же ретиво, как они вкладывались раньше, или как они сейчас вкладываются в Android. Потому что пользовательская база не обновляется, да, либо очень медленно обновляется. Соответственно, выхлопа свечей уже не так много. Люди тоже постепенно переходят на Android. Интересно, кстати, будет посмотреть в каком-нибудь 2024 году статистику использования айфонов. Я уверен, что она просядет. И новые фичи уже нет смысла так часто выпускать. Поэтому, возможно, в каких-то компаниях, я во всех компаниях не могу сказать, в каких-то я точно знаю, что найм не закрыт, а в каких-то компаниях найм так подсократили.

У топов, естественно, есть опасения про то, что мы сейчас будем вкладываться в iOS, это огромные деньги. Если, допустим, взять какой-нибудь Сбер, то там, наверное, разработчиков под 800, может, даже 1000 или больше, работает над iOS, это просто умножьте в среднем на 200к, например. Это огромный ФОТ, плюс ещё налоги и всё остальное, который они тратят каждый месяц.

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

Но при этом совсем тоже iOS-аудиторию терять не хочется, потому что она все-таки по-прежнему есть, есть люди, которые не переходят и так далее.

Как действуют компании?

Ну, первый путь это вот такой же, там, периодически пытаться залить какой-то «Сбол», вставить во всяких офисах и так далее, то есть, ну, вот, так, тихо, медленно развиваться. Что в таком случае, с точки зрения компании, сделать выгодно? С точки зрения компании, в таком случае, выгодно перейти на кроссплатформенную технологию.

Ну, то есть, мы, допустим, пилим на том же KMM новые фичи, они как бы идут в Android, но плюсом мы захватываем iOS еще дополнительно и что-то тоже туда контрибьютим. Не сильно при этом туда вкладываясь. Это долго, дорого и не факт, что туда люди пойдут. Особенно, например, с Flutter'ом это еще и рискованно очень сильно. Поэтому и этот вариант я оцениваю, ну, так. То есть, грубо говоря, если там Apple срочно в iOS 17 не сделает возможность нам в России тут ставить приложение, тогда все прекрасно. Тогда вот просто все, что я говорю сейчас, да, это единственный лучик надежды, но мы про это еще чуть позже поговорим.

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

Соответственно, второй путь — это запилить PWA, то есть вообще отказаться от iOS, сказать, вот у нас есть полностью PWA веб-приложение, такое же как приложение, на самом деле, конечно, не такое же, да, и вот, пожалуйста, им пользуйтесь, там даже веб-пуши есть. Тут тоже есть некоторые нюансы. Во-первых, вот те самые сертификаты, которые нужно поставить, чтобы у вас все работало. С этим могут быть проблемы. Во-вторых, в PWA, в iOS недоступны большинство функций. Я думаю, что они станут доступны, больше доступны со временем, потому что Apple очень сильно хочет закрепиться в Индии. А в Индии, ну, много чего еще до сих пор на вебе сделано. И поэтому, соответственно, ПВА будет очень кстати. Это тоже вариант.

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

Потому что, как ни крути, многое здесь остается субъективным. Типа, оно более look-and-feel нативно выглядит. Ну, типа это же такая оценка, непонятно, как ее систематизировать, да? Ну, кому-то пофиг, кому-то не пофиг. Посчитать невозможно.

То же самое, да? Там оно более плавно работает. Что значит более плавно? 60 FPS выдает и там, и там? Выдает, да. Ну, опять же, не нативный look-and-feel, да кого это парит? Вот отсутствие каких-то фичей, например, в PWA, оно может сыграть свою роль в том, чтобы не выбрать по агрессии фейпап. Ну, тоже такое.

Если большую часть функционала можно реализовывать, то почему бы и нет? И вот почему-то мне кажется, что очень много СТО в итоге выберет путь PWA. То есть они задолбаются бодаться с Apple и выберут путь веб-приложений.

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

Как это влияет на разработчиков

И тот, и другой путь, они для iOS-разработчиков чреваты тем, что спрос на них резко упадет. Четыре года назад, когда мы открывали вакансию, было примерно такое соотношение. Было где-то 90% андроид-разработчиков, где-то 10% iOS. То есть iOS-ников надо было еще так поискать.

То теперь где-то 50 на 50. То есть 50% iOS-ников, 50% андроид. И вообще во многих компаниях я стал замечать, что андроид сложнее стало найти, потому что они вдруг резко стали нужны аудитории. Ну, база выросла, надо поддерживать, да, то есть iOS-приложения, с ними непонятно что, с андроид-приложениями есть Рустор и все остальное. Тут, наверное, трудно отрицать то, что для айосников действительно наступили трудные времена. Означает ли это, что ну все, конец, расходимся и так далее? Нет, не означает, потому что есть огромное количество компаний, где айосники все еще нужны и востребованы.

Есть другие компании, есть компании, там вот 2GIS, кстати, недавно в App Store вернули, то есть там айосники нужны. ВК, Яндекс, например, и так далее. То есть, есть компании, в которых iOS-ники все еще востребованы. Труднее стало? Да, труднее. Можно попасть? Можно.

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

Ситуация тяжелая, но есть лучик, так сказать, свет в конце тоннеля, да. Это новость, которая недавно прошла. Во-первых, это слух, да, то есть это не какая-то официальная позиция Apple. Что Apple разрешит в iOS 17 устанавливать приложение, вот эти IP, да, IPA на телефоны. Тут, конечно, как обычно, ничего не известно. Ну, одни говорят, что только для Евросоюза. То есть вообще, давайте так, откуда растут корни? Корни растут из специального закона, который называется Digital Markets Act, который регламентирует то, что Apple должна дать доступ ко всем своим драйверам, то есть там не только установка приложений, там и возможность Mirpay, грубо говоря, запилить на основе NFC, то есть ко всем своим вот таким базовым функциям системы, дать возможность ставить альтернативные сторы, устанавливают приложения из этих сторов, и так далее, и так далее. Тут не исключено, что Apple начнет, ну, естественно, выеживаться.

Например, вы поставите себе какой-нибудь Deutsch Store, там, да, в Германии, они себе сами вам поставят из коробки. Короче, как это будет реализовано, вообще непонятно. Очень много сплетен и тенденций на этот счет, что, типа, это будет только в Европе работать, в России не будет работать, или в других странах не будет работать. Мое мнение такое, что Apple, если они умная компания, то они уже перестраивают экономику, потому что как только Евросоюз расчехлил такое оружие, будьте уверены, все остальные страны захотят того же самого. И даже если Россия, ну, типа, с ней не будут никак считаться, да, там, или с Беларусью, да, то за счет того, что все остальные страны все равно потребуют того же, им придется открыть, сделать свою систему более открытой. Поэтому, да, в iOS 17 они могут экспериментально, например, только в Европе как-то ограничить и так далее, но в целом я уверен, что в итоге им систему придется приоткрыть.

В этом плане, конечно, iOS-разработчикам тогда станет раздолье, то есть они станут в этом плане такие же востребованные, как Android, снова все будет по-прежнему, iOS, SwiftUI и все такое. Поэтому лучик света есть, я не советую вам вот сейчас резко все бросать на полпути и менять, например, ваше образование, вы хотели стать iOS-разработчиком, да, вдруг на полпути такие «нет, пойду в другое что-нибудь». Если вы вот, ну, стремитесь войти, только войти, все-таки сохраняйте курс, я так считаю. Такая стратегия самая выгодная. С точки зрения сложившихся iOS-разработчиков, я уже про это много раз говорил, возможно, вам это, ну, типа, вы со мной не согласны, но мне кажется, в принципе, здоровая стратегия для инженера — это постоянно изучать что-то соседнее. То есть вы должны посмотреть в сторону, ну, не должны, окей, я считаю, что вы должны посмотреть в сторону бекэнда, в сторону, не знаю, там, того же Android, Kotlin Multiplatform, какая угодно история, которая поможет вам расширить ваши навыки.

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

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

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

То, что это даст вам, на самом деле, плюс в том числе и в iOS-разработке, в понимании. И вторая вещь, когда такое случится, если вдруг такое случится, то, имея определенные знания, вы просто окажетесь впереди всех своих коллег. С точки зрения, опять же, все той же теории игр, это выгодная стратегия. То есть вам это выгодно. Выгодно оказаться впереди всех остальных и невыгодно оказаться позади. Вроде очевидная мысль, но ее приходится почему-то доносить до всех. Вот, поэтому я бы рекомендовал вот для senior, middle iOS разработчиков примерно где-то придерживаться вот такой стратегии, для джун-стажеров оставаться в iOS, то есть раститься до вот этих вот уровней. Ну и будем надеяться на то, что все будет развиваться хорошо, то есть на то, что Apple нам все-таки разрешит устанавливать IPH, потому что у меня вот у самого iPhone я им пользуюсь.

Видите, у меня вот тут вот есть специальный такой стикер платежный, потому что у меня не работает Apple Pay. Ну, в России не работает, в смысле.

Так вот, как следствие, я бы тоже хотел, чтобы вся эта система продолжала развиваться. Вообще, если так вот удариться в рассуждение, то мне кажется, что Apple выгодно, ну, выгодно развивать. То есть тут вот сейчас, может, картинка появится, если мы ее найдем, о том, что, ну, вот, Market Share, да, Apple, то есть они большая часть денег своих получают с айфонов, с продажи айфонов. И оставшиеся деньги получаются с продажи сервисов. То есть, если у тебя есть возможность ставить любые приложения, да, то ты, конечно, несколько снижаешь продажи сервисов, потому что, ну, можно теперь свои платежки, да, там, лепить и так далее, не платить комиссию 30%. Но, с другой стороны, ты активнее начинаешь продавать сами айфоны, потому что, ну, все, людям, как бы, теперь это свободная платформа, можно ставить, что хочешь, люди более охотно покупают. Потому что у айфонов на самом деле уже давно есть бюджетные модели, можно купить с рук чего-то, да, то есть можно вполне себе за недорогие деньги купить айфон. Это теперь уже не является символом статусности и потребления, хотя у некоторых там он до сих пор таким сохраняется. Ну, понятно, что все цифры есть у компании Apple, и она там уже знает, да, то есть какие деньги она, скорее всего, получит, какие деньги она потеряет, где потеряет конкретно, где получит и так далее.

Ну вот, будем ждать ближайший WWDC, посмотрим, или, как говорят iOSники, DubDubDC, и посмотрим, собственно, что на ней расскажут нам в iOS 17. Но вот, подытоживая, я бы хотел сказать, что, наверное, рано пока еще отчаиваться. IOS-разработка точно не умерла. На выход с вещами пока что еще рано. Но вот, я бы, тем не менее, все равно чисто для страховки посматривал во все остальные стороны. Напишите в комментариях, что вы думаете по этому поводу.

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

Подробнее, что же будет популярно в 2024 году, на какие технологии стоит делать ставку, расскажет Анна Жаркова, руководитель группы разработки компании Usetech, мобильный разработчик с опытом более 10 лет, эксперт Mobile Broadcast и Skillbox, а также член программных комитетов Mobius, Codefest и DevFest (Омск).

Искусственный интеллект

Начнем мы с самого популярного и многообещающего направления, а именно с использования систем Искусственного Интеллекта. McKinsey Global Institute пишут о возможном увеличении прибыли компаний на $4,4 триллиона в год благодаря ИИ. Кроме того, бизнес чаще начинает внедрять генеративный ИИ в повседневные приложения.

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

С конца 2022 года отмечается настоящий всплеск по разработке систем ИИ. На данный момент нейросеть ChatGPT занимает первую строчку в рейтинге технологий генеративного ИИ. В российском сегменте нельзя не отметить мощный аналог от компании Яндекс Yandex GPT. Компании планируют активно встраивать решения на основе нейросетей в свои приложения. Это может быть не только сбор и обработка информации для улучшения пользовательского опыта. Например, сбор и анализ информации позволит строить модели поведения пользователей, сценарии, на основе которых улучшать подбор рекомендуемого контента и т.п. Также это решение различных генеративных задач. Например, автоматический перевод текста, умное взаимодействие с пользователем.

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

Кроссплатформа, Kotlin Multiplatform, Flutter

Технологии кроссплатформенной мобильной разработки под несколько платформ одновременно популярны уже довольно давно. На текущий момент самыми используемыми являются SDK Kotlin Multiplatform (KMP) от JetBrains и Flutter от Google. Оба решения активно развиваются, и без сомнения, в 2024 году порадуют новыми решениями. Кстати, JetBrains проводит ежегодный опрос по использованию Kotlin, который доступен по ссылке.

Осенью 2023 года произошло то, чего ждали многие разработчики и почитатели технологии KMP. Технология перешла в статус Stable и стала полностью готова к полноценному использованию. Это означает, что многие, актуальные для Alfa и Beta версий SDK проблемы, были решены. Например, улучшили поддержку Kotlin/Native, работу с многопоточностью, памятью и т.п. Одной из целей роадмапа на 2024 год сформулировали реализацию прямого взаимодействия между языками Kotlin и Swift. Несмотря на то, что разработчики Google являются авторами конкурирующего продукта Flutter, компания официально делает большую ставку на KMP. Поддержка кросс-платформы включается во многие решения. Так что советуем присмотреться к данному продукту.

Еще одним трендом связанным с кроссплатформенной разработкой является использование Compose Multiplatform для реализации кросс-платформенного UI. Данный декларативный фреймворк объединяет такие технологии как Compose for Desktop, Compose iOS, Compose for Web, а также Jetpack Compose для Android, и позволяет быстро и относительно просто создавать общий UI для разных платформ. В 2023 году вышла альфа-версия Compose для iOS. В 2024 году ожидается выход Бета-версии, в которую войдут улучшения по работе с нативным UI iOS, а также поддержка кросс-платформенного решения для навигации.

В общемировых тенденциях мобильной разработки сохраняется популярность таких решений, как React Native, гибридной разработки на Cordova и ionic, а также Xamarin. Также сохраняется тренд на PWA разработку,

Российская разработка, импортозамещение

Еще в 2022 году возникла потребность в собственных решениях для импортозамещения, а также развития отечественных технологий. Одним из самых актуальных направлений мобильной разработки становится разработка под Aurora OS. Если сначала попробовать устройства под ее управлением могли в основном участники специальной бета-программы и энтузиасты, помогающие компании OMP в разработке и улучшении продукта, то уже осенью 2023 года смартфоны и планшеты на Aurora OS становятся доступны для приобретения для всех желающих. Готовится к выходу 5 версия OS с поддержкой встроенного магазин приложений на RuStore. Многие российские компании уже работают над своими собственными решениями с поддержкой Aurora OS.

Компания OMP также обновили и улучшили инструменты для разработчиков. Предлагается использовать не только QT/QML/C++, но и специальную версию Flutter для разработки под Aurora. Так что здесь стоит отметить сочетание двух трендов мобильной разработки.

Определенно, стоит уделить внимание платформе Rosa Mobile. Данная ОС была заявлена как замена Android, и освоить разработку приложений под нее, было бы весьма нелишним.

Также актуальным трендом остается переход на отечественные сервисы. Например, решения от Yandex для сбора метрик, карты, погода и другие SDK. Замена сервисов Firebase сервисами RuStore (те же пуш-уведомления).

Нативная разработка

Технологии и фреймворки меняются, нативная разработка остается. Это основа основ, база, которую должен знать каждый разработчик. Использование родных языков и инструментов, как и подхода Native First, будет актуально всегда. К тому же для реализации проектов со сложной логикой, сложным UI, стоит выбирать именно нативную разработку.

Ежегодно разработчики платформ iOS/Android, а также языков Swift и Kotlin, выпускают много новых и интересных решений, про которые рассказывают на тематических конференциях WWDC и Google I/O.

Особое внимание стоит уделить усиливающемуся тренду на декларативную разработку в мобильных приложениях. Фреймворки SwiftUI и Jetpack Compose активно развиваются, стабильно улучшаются, становятся более удобными и надежными в работе. Их все чаще используют в разработке приложений различной сложности. Много библиотек и готовых решений, заточенных под SwiftUI и Jetpack Compose. Можно сказать, что это новый стандарт мобильной разработки под Android и iOS.

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

Виртуальная реальность

В 2023 году на конференции WWDC компания Apple представила одну из самых громких новинок — очки виртуальной реальности Vision Pro, работающие на платформе VisionOS. Разумеется, это далеко не самый первый такой девайс в мире, и подобные аппараты уже давно используются в игровой индустрии. Ставка делается на уникальные технологии иммерсивности, улучшенное качество звука и изображения. В рамках создания девайса были проведены масштабные разработки в области пространственных вычислений. Поддержка VisionOS была включена в такие инструменты, как: ARKit, RealityKit, Unity, RealityComposer и т.п. И инструментарий, и документация на данный момент доступны для всех заинтересованных разработчиков. Старт продаж самого устройства намечен на 2024-2025 год.

Недавно создатели Vision Pro сообщили о скором запуске магазина приложений для очков виртуальной реальности. А это значит, что в 2024 году нас ждет бум различных приложений для AR/VR устройств: игры, виртуальные примерочные, приложения для подбора интерьера, иммерсивный просмотр фильмов, прослушивание музыки и т.п. Кроме того, согласно Statista, к 2028 году число пользователей рынка AR и VR в мире достигнет 3674,0 млн пользователей.

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

Не только смартфоны. IoT

Каждый год выпускаются новые различные устройства под управлением ОС Android, iOS. Это не только смартфоны и планшеты, но и часы, смарт-телевизоры, игровые приставки, фитнес-трекеры, компьютеры автомобилей, а также устройства системы “умный дом”. Компании-разработчики ОС заинтересованы не только в поддержке новых возможностей устройств и гаджетов, но и улучшении инструментария для сторонних разработчиков.

Использование NFC, Bluetooth в приложениях по-прежнему остается актуальным. Yahoo Finance прогнозирует рост в области NFC с 2023 по 2030 годы на 33,1 миллиарда долларов США.

Безопасность, улучшенная работа с сетью

Сохранение конфиденциальных сведений было и остается одной из главных задач разработчиков. Об этом свидетельствует прогноз Gartner. Внедрение усиленных мер безопасности (аутентификация по биометрии, использование блокчейн и т.п) весьма актуальны и в 2024 году. Также особое внимание следует уделять стабильной и безопасной работе с сетью, в том числе и работе с облачными сервисами, с NFC, при подключении к другим устройствам. Современные мобильные ОС предлагают широкий спектр нативных средств для реализации и поддержки безопасной работы приложений.

Подведем итог

В 2024 мобильные платформы, языки и инструменты разработки продолжат свое развитие. Основными направлениями, на которые мы рекомендуем обратить внимание, будут являться:

• нативная разработка;
• кроссплатформа;
• разработка под различные мобильные устройства, IoT;
• поддержка и использование российских технологий;
• безопасность, работы с сетью;
• AR/VR.

• Swift против Dart;
• R против Python.

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

Со всеми условиями батла можно ознакомиться в анонсе.

Голосование продлится до завтра, 20 декабря 2023 года, до 11 часов по МСК.

Боитесь пропустить следующие раунды батла? Подпишитесь на тэг Лучший язык 2023. Тогда новые раунды появятся в вашей личной ленте, а вам будут приходить уведомления об их появлении.

Мы уже проводили батл в прошлых 2020, 2021 и 2022 годах: первые два раза в голосовании победил Python, а в прошлом году — C#.

Вот, кто поборется за звание лучшего языка в 2023 году:

Правила батла остаются прежними:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 19 декабря, финал — 26 декабря.

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

1. Первый раунд
2. Второй раунд
3. Третий раунд
4. Четвёртый раунд
5. Пятый раунд
6. Шестой раунд
7. Полуфинал
8. Финал
9. Результаты

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

Старт уже завтра — 19 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

Всем привет, меня зовут Макс Нечаев, я тех-лид и iOS разработчик в крупном фудтех стартапе на арабском рынке (Snoonu).

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

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

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

Всего у нас три типа диспетчеризации

Первая: Static dispatch — статическая.

Вторая: Table dispatch — динамическая, которая делится на две:

– Virtual Table

– Witness Table

Третья: Message dispatch

Далее предлагаю рассмотреть все три более подробно.

Static dispatch

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

Статическая диспетчеризация используется в методах структур (value типов), final классов, а также в extension классов и протоколов. Во всех случаях метод не может быть переопределен никак, и выбор его имплементации всегда однозначен.

Примеры методов со Static dispatch:

Преимущества: самая быстра диспетчеризация.

Недостатки: отсутствие полиморфизма и наследия.

Table dispatch

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

Так как это происходит именно в рантайме, думаю, вы понимаете, что здесь скорость диспетчеризации может повлиять на производительность. Но несмотря на это, есть и явные плюсы Table dispatch. Далее мы рассмотрим два подвида этой диспетчеризации.

Virtual Table

Если говорить про Virtual Table Dispatch, то скорее всего мы имеем ввиду работу с классами, с наследованием и переопределением методов.

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

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

Давайте создадим два класса, отец (Father) и ребенок (Child). Причем ребенок должен быть наследником класса отца. У отца будут методы: есть, гулять, спать, работать.

Смотрите, это очень интересный момент. У каждого класса своя виртуальная таблица. Но при это когда у child мы вызываем метод eat(), вызывается имплементация из класса Father. Почему так? Потому что адреса методов в виртуальной таблице ребенка ведут на те же адреса, что и в виртуальной таблице класса отца.

Вопрос на подумать. Как же сделать так, чтобы у виртуальной таблицы класса Child были свои уникальные адреса на имплементацию этих методов?

А вот как:

Мы переопределяем методы, теперь Virtual Table Dispatch у класса Child будет вызывать именно его имплементацию методов, а не класса Father.

Witness Table

Когда мы говорим про Witness Table Dispatch, то здесь скорее всего мы имеем ввиду работу с протоколами. На уровне теории, для класса, который реализует протокол, а именно для методов этого протокола, создается отдельная таблица. Если класс реализует несколько протоколов, то создается несколько Witness таблиц. Основное отличие от Virtual table, что здесь нет наследования.

Давайте попробуем разобраться на примере. Создадим два класса: брат и сестра (Brother / Sister). Также создадим протокол GameProtocol, который обязует класс реализовать метод func buyGame().

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

Каждый класс имеет свою Witness Table и сам решает, как ему реализовать протокол.

Подведем небольшой итог Table dispatch.

Преимущества: наличие полиморфизма (гибкости), возможность наследования

Недостатки: медленнее, чем статическая диспетчеризация

Message dispatch

Динамичный вид диспетчеризации, самый медленный и связан с Objective-C. Он полностью работает в runtime. Для работы с Message Dispatch методам добавляется модификатор @objc dynamic. Как он работает под капотом? В отличии от табличной диспетчеризации, Message Dispatch ищет реализацию метода в дочернем классе, затем по ссылке переходит в таблицу родительского класса и ищет там, если и там нет реализации, переходит на уровень ниже. Таким образом создается длинная цепочка поиска реализации метода от самого верхнего класса, до самого нижнего класса, именно это и делает данный тип диспатча самым медленным.

Message Dispatch лежит в основе KVO и KVC. Так как Message Dispatch работает в runtime, появляется возможность подменить реализацию методов — это называется Method Swizzling. Method Swizzling позволяет подменить метод другим в runtime, при этом оригинальная имплементация остается доступной.

Преимущества: KVO и KVC, Method Swizzling

Недостатки: самая медленная диспетчеризация

Итог

В конце концов хочется сказать, что данная тема не самая ключевая в работе iOS разработчика, но при этом рекомендуется к пониманию. Более того, на собеседованиях вас часто будут спрашивать и гонять по диспетчеризации. Данных знаний вам должно хватить, чтобы ответить на 95% всех вопросов по теме. Более того, прилагаю вам такую схемку, которую можно держать перед глазами, она помогает очень просто и быстро понять, какая и где диспетчеризация.

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

Языки для программирования браузерных игр

Большинство веб-игр работает на комбинации HTML, CSS и JavaScript. HTML формирует структуру и содержимое веб-страницы, CSS определяет внешний вид и стиль элементов, а JavaScript управляет игровой логикой, анимациями и интерактивными элементами. Если добавить сюда PHP, можно прописать бэкенд, настроить взаимодействие с серверной частью и сделать игру многопользовательской.

Примеры браузерных игр

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

Языки для программирования мобильных игр

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

Но в этом есть и плюс — простота разработки. Можно использовать один из движков (например, Unity) и за несколько недель собрать свою игру, добавив только спрайты и модели и прописав логику на одном из поддерживаемых языков программирования (для Unity это C#).

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

Тогда для геймдева понадобятся следующие языки:

● Java

Язык для разработки нативных мобильных игр под платформу Android. Программы обычно преобразуются в байт-код, который выполняется на любой виртуальной машине Java (JVM), независимо от характеристик процессора. Для Java также разработаны библиотеки и фреймворки, которые помогают в создании игр, например LibGDX.

● Kotlin

Ещё один язык для геймдева на Java, который появился не так давно. Он полностью совместим с Java, поэтому эти языки можно использовать в проекте одновременно или быстро переписать код с одного на другой. С помощью SDK Kotlin Multiplatform Mobile на этом языке можно создавать кроссплатформенные игры для iOS и Android.

● Objective-C и Swift

Objective-C — первый язык программирования приложений и игр для устройств Apple. Он был создан в 80-х годах XX века как объектно-ориентированное расширение языка C.

Objective-C активно использовался Apple на протяжении многих лет, но всё же с годами его синтаксис и другие особенности устарели. Поэтому в 2014 году в компании создали новый язык программирования Swift. Он имеет более современный и интуитивно понятный синтаксис, обеспечивает статическую типизацию и автоматическое управление памятью, что помогает устранить некоторые ошибки Objective-C и упростить отладку.

Примеры мобильных игр

Коммерческие движки и языки программирования

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

Unity

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

Unity легко освоить даже новичку в геймдеве, но для создания сценариев взаимодействия с сервером понадобится знание C#. Это объектно-ориентированный язык, созданный компанией Microsoft в 2000 году для работы с платформой .NET. Он не такой сложный, как C++, и на нём не нужно писать много шаблонного кода, как на Java.

Примеры игр, созданных на Unity

Unreal Engine

Движок от известной игровой компании Epic Games, выпущенный в 1998 году. Уже больше двух десятков лет его используют в геймдеве для создания сложных игр категории AAA разных жанров — от MMORPG до шутеров от первого лица.

Unreal Engine ценят за шикарные визуальные эффекты, но освоить этот движок сложнее, чем Unity. Для создания сценариев в нём используется C++, правда с определёнными отличиями (без низкоуровневого управления памятью и библиотеки шаблонов).

Это довольно старый и сложный язык, но благодаря визуальному редактору Blueprints создавать скрипты и размещать объекты в Unreal Engine можно и без C++.

Примеры игр, созданных на Unreal Engine

Итоги

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

1. для браузерных игр понадобится знание JavaScript и PHP;
2. мобильных — Java, Kotlin и Swift;
3. консольных и ПК-игр — C++ и C#, а ещё опыт работы с коммерческими движками.

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

Что такое интернет вещей, и из чего он состоит

Интернет вещей — система, которая объединяет с помощью проводных и беспроводных сетей (Wi-Fi, Bluetooth и т. д.) разные устройства, подключённые к интернету.

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

Архитектуру IoT обычно разделяют на несколько уровней:

• датчики, собирающие данные (датчики пульса, температуры в помещении, движения и т. д.);
• локальные шлюзы — устройства, позволяющие датчикам и облаку обмениваться данными;
• граничные серверы, которые собирают всю информацию;
• облачная инфраструктура.

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

Какие языки программирования востребованы в IoT

Каждый год компания Eclipse Foundation организует опрос IoT-разработчиков из разных стран и публикует исследование о трендах интернета вещей. В нём есть блок про языки программирования.

По итогам 2022 года:

• в топ-3 языков для программирования микроконтроллеров и встраиваемых устройств вошли C, C++ и Python;
• самыми популярными языками для создания программного обеспечения облачной инфраструктуры стали Java, C, C++, Python и JavaScript;
• Java, Python, JavaScript и C заняли первые места в топе языков для программирования шлюзов и пограничных узлов.

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

Java

Самый популярный язык программирования в сфере IoT. Причина проста — один раз написав код на Java, вы можете быть уверены, что он будет стабильно работать на любом другом устройстве (от смартфона до одноплатного микрокомпьютера).

Всё это возможно благодаря виртуальной машине Java (JVM), которая позволяет писать код, поддерживаемый любым чипом.

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

При всех плюсах неудивительно, что на Java написан бэкенд нашего приложения для поддержания микроклимата «Цельсиум» и платформы MTS IoT HUB.

Python

Благодаря простому синтаксису и быстроте написания кода Python всё чаще используется в сфере IoT. Так как это интерпретируемый язык, он хорошо совместим с такими парадигмами, как объектно-ориентированное, структурное и функциональное программирование.

Кроме того, под Python создано множество библиотек для решения различных задач, например для машинного обучения и работы с данными. А для программирования микроконтроллеров есть специальный пакет MicroPython, который запускает Python непосредственно на «железе».

C

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

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

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

C++

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

Благодаря возможности создавать абстракции C++ отлично подходит для приложений Linux и программирования встраиваемых устройств.

Мы остановились на С++ для фронтенда приложения NB-IoT-тревожной кнопки Smart Click.

JavaScript

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

Благодаря программной платформе Node.js, расширяющей возможности JavaScript, он также подходит для программирования датчиков, серверов и шлюзов.

Языки программирования для узких задач в сфере IoT

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

LUA

Довольно редкий язык программирования, который тем не менее часто используется в сфере IoT.

LUA — гибкий скриптовый язык, подходящий для создания приложений, ориентированных на портативность, экономию энергии и работу с большими объёмами данных. У него также есть фреймворк Node.lua, аналогичный Node.js.

Swift

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

Go

Golang, или Go, позволяет писать оптимизированный код, подходящий для устройств с низким энергопотреблением и небольшой памятью, поэтому набирает популярность в IoT.

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

Выводы

Нет сомнений, что IoT будет развиваться дальше, охватывая всё больше сфер нашей жизни.

✔ Если вы уже программируете на Python, Java, C или C++, поищите вакансии в компаниях, разрабатывающих устройства для интернета вещей.

✔ Если только планируете делать первые шаги в программировании, советуем освоить Python для решения большинства задач IoT или C/C++ для работы с «железом».

Сейчас насчитывается больше 8 000 разных языков программирования (ЯП), и их количество постоянно растёт. Каждый год, если не месяц, появляются новые, в том числе созданные just for fun, но популярных и востребованных всё же гораздо меньше. На какие из них стоит обратить внимание новичку?

Отвечая на этот вопрос, мы проанализировали несколько самых известных языков и сравнили их популярность по двум рейтингам: TIOBE и Stack Overflow. Также мы изучили уровень зарплат для каждого языка из статьи и проанализировали порог вхождения. В статье рассматриваются JavaScript, Golang, C++, Python, Java, Swift и Kotlin из мобильной разработки.

1. JavaScript
2. Golang
3. C++
4. Python
5. Java
6. Swift
7. Kotlin
8. Так что же выбрать?
   

JavaScript

Популярность

Этот язык находится на 7–ом месте по индексу TIOBE, строящемуся на основе подсчёта результатов поисковых запросов, содержащих название ЯП. В 2022 году рейтинг JavaScript вырос на 0,9%. На графике ниже показана динамика изменения рейтинга языка с 2002 года.

Что касается индекса Stack Overflow, то JavaScript находится на 17–ом месте. Он нравится 61,46% пользователей ресурса (индекс составлен с учётом 22 544 голосов).

Уровень зарплат

По данным Хабр Карьеры, медианный уровень зарплаты программистов на JavaScript — 150 000 рублей. Этот показатель не вырос, но и не снизился с 2021 года, что может говорить о стабильном спросе на разработчиков, специализирующихся на этом ЯП.

Порог вхождения и перспективы

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

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

Golang

Популярность

Golang — относительно молодой ЯП, созданный командой Google. За примерно десять лет он поднялся до 12-го места в индексе TIOBE. В 2021 году он занимал 19–ю позицию. Вот динамика изменения рейтинга ЯП с момента его появления в 2010 году.

В индексе Stack Overflow он занимает 8–е место. С ним предпочитают работать 64,58% пользователей ресурса.

Уровень зарплат

По данным Хабр Карьеры, медианная зарплата разработчиков Golang составляет 205 000 рублей, с ростом на 3% по отношению к 2021 году. Рост зарплат может быть свидетельством увеличения популярности языка от года к году.

Порог вхождения и перспективы

По этому показателю Golang несколько проигрывает JavaScript, поскольку язык изучают в основном профессиональные разработчики, которые программируют и на других языках. Как правило, язык изучают в связке с PHP и Python.

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

С++

Популярность

Согласно индексу TIOBE «плюсы» занимают 3–ю позицию, поднявшись с 4–го места в 2021 году. За год рейтинг языка увеличился на 4,21%. Ниже — динамика популярности с 2002 года.

А вот согласно индексу Stack Overflow язык занимает 25–е место. Он нравится 48,39% пользователей ресурса.

Уровень зарплат

Медианный уровень, по данным Хабр Карьеры, — 150 000 рублей. По сравнению с 2021 годом уровень зарплат вырос на 9%.

Порог вхождения и перспективы

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

Спрос же на разработчиков С++ остаётся стабильно высоким. Их приглашают на работу в компании разного масштаба, включая такие крупные, как Microsoft, Amazon и Google.

Python

Популярность

По данным индекса TIOBE, Python занял в 2022 году 1–е место, его показатель популярности вырос с 2021 года на 3,76%. Судя по динамике изменения рейтинга, востребованность специалистов по этому ЯП постоянно растёт.

В индексе Stack Overflow язык занимает 6–е место. Его выбирают 67,34% пользователей ресурса.

Уровень зарплат

По данным Хабр Карьеры, Python-программисты получают около 140 000 рублей. При этом с 2021 года этот показатель упал на 7%. Падение может быть связано с ростом количества программистов, работающих с этим ЯП, и вследствие этого ростом предложения на рынке.

Порог вхождения и перспективы

Язык считается несложным для изучения. До уровня Junior его могут освоить люди без технического образования. Что касается перспектив Python, то его популярность растёт год от года. Причина — несмотря на относительную простоту, ЯП позволяет разрабатывать серьёзные проекты со сложной архитектурой.

Java

Популярность

В индексе TIOBE Java находится на 4–ом месте, тогда как в 2021 ЯП занимал 3–ю позицию. Язык много лет занимает ведущие позиции рейтинга, перемещаясь в первой пятёрке. Вот динамика изменения рейтинга.

А вот по версии индекса Stack Overflow он находится на 28–ом месте. Язык нравится 45,75% пользователей ресурса.

Уровень зарплат

Согласно данным Хабр Карьеры медианная зарплата Java-разработчика составляет около 200 000 рублей. За год зарплаты в среднем выросли на 13%.

Порог вхождения и перспективы

По мнению ряда разработчиков, порог вхождения в Java средний. Чтобы научиться программировать на языке, нужен технический английский, чтобы разбираться в документации. Требуются общие знания ООП, паттернов проектирования, а также общее хорошее знание Java в объёме Sun’s java tutorial.

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

Swift

Популярность

Согласно индексу TIOBE язык Swift занимает 15–е место по популярности среди разработчиков. Стоит отметить, что за год ЯП опустился сразу на 5 позиций, в прошлом году он занимал 10–е место. Вот динамика изменения популярности языка с 2014 года.

Что касается индекса Stack Overflow, то Swift занимает 12–е место. Язык нравится 62,88% разработчиков.

Уровень зарплат

Хабр Карьеры говорит о том, что Swift-разработчики получают около 200 000 рублей, за год зарплаты остались на прежнем уровне. Это может говорить о стабильном спросе на специалистов по этому ЯП, который остаётся примерно на одном и том же уровне из года в год.

Порог вхождения и перспективы

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

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

Kotlin

Популярность

Согласно индексу TIOBE Kotlin занимает 23–е место. Это относительно новый язык, который ещё просто не успел войти в первую двадцатку или тем более десятку. Тем не менее его популярность постепенно растёт. Так, с прошлого года рейтинг ЯП вырос на 0,58%.

По индексу Stack Overflow язык занимает 11–е место. Он нравится 63,29% разработчиков.

Уровень зарплат

Тезис о росте популярности языка подтверждает и уровень зарплат разработчиков, которые специализируются на Kotlin. По данным Хабр Карьеры, медианная зарплата программиста на Kotlin составляет около 185 000 рублей. За год этот показатель увеличился на 3%.

Порог вхождения и перспективы

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

Интересный факт: в Google считают, что Kotlin открывает больше возможностей, чем Java. Его популярность постепенно растёт — некоторые компании предпочитают переходить на Kotlin с Java. Плюс это универсальный язык, на котором можно написать и Android-приложение, и сервис, и приложение для ПК. В ближайшие лет 5 его популярность будет расти, так что и спрос на Kotlin-разработчиков будет стабильно высоким.

Так что же выбрать?

Мы рекомендуем выбирать тот язык программирования, принципы развития и сфера применения которого ближе к вашим профессиональным интересам. Скажем, если вы собираетесь выбрать своей отраслью Data Science, то вам нужен Python. Если хотите посвятить себя мобильной разработке, то без Java, Swift или Kotlin не обойтись.

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

Не хотите пропустить новые раунды? Подпишитесь на тэг Лучший язык 2022 и следите за обновлениями в личной ленте.

Сегодня между собой соревнуются:

• Ruby и PHP;
• Swift и Kotlin.

Голосование по этим языкам программирования продлится до 16 декабря 2022 года. Опросы будут закрыты в 11:00 по МСК.

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

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 13 декабря, финал — 20 декабря.

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

• Этап 1
• Этап 2
• Этап 3
• Этап 4
• Этап 5
• Этап 6
• Полуфинал
• Финал
• Результаты

Турнирная таблица:

Старт уже завтра — 13 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

Вводные данные

Итак, наше «дано» на момент поиска решения:

• Команда тестирования с опытом написания автотестов для web на Java;
• Талантливые и амбициозные iOS и Android разработчики в непосредственном доступе;
• Довольно сжатые сроки.

Что мы искали в автотестах:

• Поддерживаемость;
• Оптимальный порог вхождения;
• Стабильность;
• Надежность.

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

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

Какие технологии мы выбрали

Из тестовых фреймворков мы выбрали Kaspresso, который сочетал в себе все фичи Espresso и Kakao, обладая целой кучей собственных улучшений и доработок. Буквально за полтора месяца работы процент покрытия приложения автотестами превысил 90%.

За плечами осталась база Kotlin и, на мой взгляд, лучший фреймворк для тестирования на Android — Kaspresso.

В разработке Kotlin и Swift очень похожи, но, к сожалению, все сходства сводятся на нет при написании нативных автотестов.

Обычно тестовые фреймворки рассчитаны на базовый уровень знаний языка, как тот же Kaspresso или Selenide. Но оказалось, что XCTest не хочет нас видеть без должного уровня в iOS разработке, и на помощь были вызваны iOS-разработчики.

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

Со стороны iOS-разработчиков поступило предложение быстро надстроить «что-нибудь красивое» над XCUITest. Мы подготовили список того, что нам нужно делать и с какими элементами.

Выкрутив красноречие и харизму на максимум, и стараясь не произносить фразу «Сделайте как у Android», договорились чтобы сделать тестовые методы похожими на знакомый нам Kaspresso. Наши iOS-разработчики принялись паковать локаторы в более знакомые методы, и уже в первый же день все начало приобретать более изящный вид.

Улучшаем автотесты

Так выглядел локатор по тексту на XCUITest:

Упаковали его в:

Тут самой главной сложностью были типы. Привычка из Kaspresso, если мы в тесте указываем, что ищем кнопку с id «any_id», Kaspresso не будет «прокидывать» ошибку, что он нашел id, но это не кнопка. Он просто скажет «Ну допустим это кнопка, хотите нажмем?». На XCUITest так не получалось, любая ошибка в типе элемента неизменно вела к падению тестов, и приходилось быстро и правильно искать по коду типы элементов.

Вторая проблема была с самими id — для разработки они не нужны и соответственно не проставлялись. Сами модификаторы accessibilityIdentifier или accessibility(identifier:), приходилось проставлять в процессе написания автотестов. А нужно это для того, чтобы максимально использовать более надежные локаторы по id, с которыми мы тоже поработали.

Было:

Сделали:

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

Преобразились в:

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

На момент завершения подготовки тестовых методов и локаторов, мы уже делали расширения для методов без помощи команды разработки. С совсем простыми типа isDisplayed/isNotDisplayed мы расправились сравнительно быстро. Но оказалось, что метод clearText, обычно базовый для большинства тестовых фреймворков, в целом не предусмотрен в XCUITest и, чтобы очистить поле ввода, надо «накодить» что-то типа этого:

В целом мы так и «накодили», а потом запаковали все это в расширение и получили:

Подводя итоги

В итоге нашей совместной работы, за пару дней были написаны дополнительные методы, новые локаторы и расширения. Плюсом — еще около 60% покрытия приложения автотестами за все те же полтора месяца. Стабильными, быстрыми, не привязанными к X-Path и зашитыми прямо в код. Ну и конечно прекрасный тимбилдинг и взлет по скиллам.

А уж когда мы вышли на начало новых проектов, наши возможности вскружили головы всем скептикам. Мы находили уязвимости там, где их практически невозможно было заметить мануально, мы всегда могли подстраховать в плане сборок (собрать/пересобрать локально), а автотесты писались практически параллельно с разработкой.

С появлением новых задач и проектов на Swift UI наш «фреймворк» разрастается и пополняется.

Что мы получили в итоге:

• Простые в написании и с низким порогом вхождения автотесты;
• Стабильность и надежность тестов;
• Большее вовлечение команды тестирования в проект;
• Навыки программирования на Swift (рано или поздно все равно приходится править методы).

Минусы нашего подхода:

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

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

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

Опционалы

По сути, это контейнеры, которые либо имеют значение, либо нет — enum с одним из двух значений: nil или любое другое. Эти состояния обозначаются как Nope и Some соответственно. Соответственно, nil — это валидное значение, а не костыль, как в Objective-C, и при создании опциональной переменной присваивается по умолчанию, если значение не указано. Объявляются они так:

А внутри выглядят таким образом (ссылка на исходный код опционала в открытом репозитории свифта: https://github.com/apple/swift/blob/main/stdlib/public/core/Optional.swift):

Благодаря опционалам у языка Swift есть несколько крутых фишек, которых нет в том же Objective-C:

• Все переменные в любой момент в runtime всегда определены и инициализированы. Просто если вы не пишете прямой инициализатор, переменная (если это Optional тип) определяется как nil, а если не Optional, компилятор не позволит вам собрать приложение, ведь вы забыли инициализировать это и это. Так происходит потому, что nil — это особый вид значения, и вы можете сказать компилятору: «это пустая переменная, поэтому проинициализируй её сам».
• Swift почти никогда не выдаёт nullpointerexception. Единственный случай, когда можно нарваться на подобную ошибку — попытаться force unwrap опционал, в котором лежит nil.

Оператор guard

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

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

Здесь мы пытаемся запросить у API свои данные. В колбеке этого запроса мы проверяем, произошла ли ошибка в процессе: если да, то делаем return, если нет, то передаём полученную data в комплишен дальше.

Wildcard

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

В синтаксисе wildcard будет выглядеть следующим образом: когда вы планируете вызвать функцию, можно не писать имя параметра, а просто поставить значение. Допустим, у нас есть следующая функция:

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

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

И позже вызвать функцию:

Ещё к нижнему подчёркиванию можно обратиться, переприсвоить его или передать куда-нибудь.

Константы

Ещё одной особенностью языка Swift является то, что в нём не предусмотрен атрибут константы, и ключевого слова const просто не существует. Вместо этого используется let:

let означает, что мы можем присвоить значение переменной только один раз. И потом либо что-то поменять внутри неё, если это ссылочный тип, либо передать что-то из неё в другое место. А при попытке что-то переприсвоить, компилятор скажет: «так нельзя, я это собирать не буду».

let часто используется для полей класса и параметров. Если переменная нужна в изменяемом виде, — например, это счётчик функции, — то она объявляется через var. Это иногда путает новичков — особенно тех, кто приходит из JavaScript, потому что там между var и let немного другие отношения.

Функции высшего порядка

Функции высшего порядка похожи на лямбда-выражения в Kotlin (но, строго говоря, ими не являются) и что-то делают для каждого элемента коллекции, к которой применяются.

Например, метод map(_:) используется для преобразования последовательностей (тип Sequence). Он очень лаконичный, можно быстро отсортировать коллекцию или посчитать сумму чисел Фибоначчи:

Читабельно ли это? Не очень. У неподготовленного человека или того, кто пишет в соответствии с императивным подходом, это может вызвать сложности.

Другой метод — reduce(_:_:) — уменьшает все элементы до одного значения:

Иногда reduce(_:_:) используется для очень сложных вещей — например посчитать пересечения множеств. Это удобная штука для мелких задач — посчитать сумму массива, найти подмассив, отсортировать что-то.

Атрибуты доступа

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

• public
• private
• protected
• open
• closed
• fileprivate

open и closed — это про наследование. Возможно ли наследоваться от этого класса и можно ли оверрайдить внутри него какие-то поля или методы. Если файл «открытый», от него может наследоваться кто угодно и оверрайдить внутри него что угодно. Если «закрытый», все знают о его существовании и могут делать то, что вы им разрешите. Но наследоваться от него и оверрайдить в нём что-то — нет.

fileprivate — очень интересная штука. Представим, что у вас есть класс, объявленный в Файле 1. В Файле 2 вы пишете для него расширения: добавляете поля, методы и так далее. И один из методов помечаете атрибутом fileprivate. Теперь он будет доступен только в Файле 2. А в других файлах, в том числе в Файле 1, к нему обратиться не получится.

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

Мы же не останавливаемся и объявляем новых кандидатов на звание лучшего языка программирования 2021:

• Visual Basic vs. Java
• Swift vs. Go

Выбирайте язык, исходя из личных предпочтений. Текущее голосование будет завершено 17 декабря 2021 года в 11:00 по Москве.

Но давайте отвлечёмся от официальной статистики и узнаем, какие языки предпочитаете именно вы! Завтра стартует баттл языков программирования 2021. Правила просты:

1. Всего участвует 16 языков программирования.
2. Каждый день соревнуются две пары.
3. На возможность проголосовать за любимый язык отводится 24 часа.
4. Пары составляются рандомно.
5. Выбирайте тот язык, который субъективно нравится вам больше.
6. В финале мы определим победителей — языки которые заняли первое, второе и третье место.
7. Старт — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

А вот как мы выбирали лучший язык программирования в прошлом году.

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

Результаты баттла можно посмотреть по ссылке.

Codex — одна из моделей, которая используется для работы ИИ-помощника для программистов GitHub Copilot.

Инструмент лучше всего работает с Python, но спокойно справляется и с другими языками: JavaScript, TypeScript, Go, Perl, PHP, Ruby, Shell, Swift и так далее.

Как работает

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

Вот видео, как Codex сделал простую компьютерную игру:

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

Например, если пользователь напишет в специальном окне фразу Print Hello World («напечатай Hello World»), Codex сгенерирует код print(“Hello World”), если выбран язык Python.

Codex печатает Hello World:

Codex — потомок GPT-3

Инструмент Codex — это почти как ИИ-модель на основе GPT-3 от Microsoft, но c несколькими улучшениями.

Codex выделяет память 14 КБ памяти для кода на Python, когда GPT-3 — только 4 КБ. Благодаря этому новый инструмент может учитывать в 3 раза больше контекста.

Где попробовать

OpenAI Codex вчера вышел в бета-тестирование.

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

Когда Codex полноценно запустится, его можно будет бесплатно попробовать в течение пробного периода.

Источник: OpenAI

В автобусе увидел у человека iPad и решил стать iOS-разработчиком

— Максим, где ты учился?

Мне кажется, у выпускников вообще нет понимания, что делать после школы. По крайней мере, у меня не было. Я просто постарался максимально хорошо сдать ЕГЭ и подал документы на факультет, на который сложнее всего пройти по баллам. Это оказалась «Информационная безопасность» в КНИТУ-КАИ им. А.Н.Туполева: чтобы поступить на бюджет, нужно было набрать за ЕГЭ 220 баллов. Я подумал, что раз туда сложно поступить, значит, это перспективная специальность. Но сначала мне там не очень нравилось — было мало программирования.

На первом курсе мы изучали Assembler, низкоуровневый язык программирования, который мало понятен людям. Он мне казался очень странным. С третьего курса мы начали программировать на C# и стало интереснее.

— Как получилось, что ты стал именно iOS-разработчиком? Не легче ли было развиваться в разработке на C#?

Я заинтересовался разработкой под iOS на втором курсе, до С#. Тогда под iOS писали на Objective-C, Swift только появился. Помню, в автобусе увидел у человека iPad и подумал: «Прикольно делать софт для iOS, iPad, iPhone». После этого случая я начал изучать Objective-C по учебнику и видео на YouTube. Потом продал игровой компьютер, купил MacBook и стал практиковаться. Через 7–8 месяцев самообучения решил искать работу. Сначала не клеилось: без опыта никуда не брали. Я прошел 5 собеседований, прежде чем устроился в ИТ-отдел банка.

Спарсил «Википедию», чтобы устроиться в банк

— Помнишь тестовое на собеседовании в банке?

Попросили написать список городов России на Objective-C. Нужно было, чтобы в нем отображались название, герб и небольшое описание. Я справился с заданием за 6-8 часов: подтянул библиотеку парсера страниц и спарсил «Википедию».

— Какие задачи ты решал в банке?

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

Когда увидел Swift, подумал: «Что это за прелесть?!»

— Быстро нашел новую работу?

Да. Я устроился в мультипликационную студию, где делал игровое приложение, по которому дети могли учить алфавит. Там тоже проработал недолго — несколько месяцев. На проекте я был единственным разработчиком и мне не хватало наставника, который бы научил меня хорошей архитектуре. После увольнения был перерыв около года, а потом я вернулся в разработку. Устроился в ИТ-компанию, которая делала мобильные приложения. Там я познакомился со Swift. Помню, увидел его и подумал: «Что это за прелесть?!»

— Почему?

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

— Какие проекты ты делал в ИТ-компании?

У меня было несколько сложных и интересных проектов. Например, мы сделали приложение для Музея русского импрессионизма, в котором можно посмотреть видео или послушать аудио о картинах. Еще запомнилось приложение «Зеномания» для фанатов волейбольного клуба «Зенит». В нем можно почитать новости, посмотреть матчи, купить мерч с символикой команды. А еще там можно «примерить» шарф или кепку и сделать «зеноселфи».

— Тебе нравилось в ИТ-компании?

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

— Что было дальше?

Из ИТ-компании я ушел в стартап — делали социальную сеть наподобие «ВКонтакте» для Арабских Эмиратов. В нем было очень много функционала: чат, фото, видео, посты, группы, внутренняя валюта, видеозвонки.

— С реализацией какого функционала возникли сложности?

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

— Сколько ты проработал в стартапе?

Около года. В один момент прекратилось финансирование и все загнулось. Больше я в стартап не пойду. После этого я полгода работал в интернет-магазине, а после устроился в международную ИТ-компанию Luxoft.

Как вместо Москвы переехал в Питер и устроился в Luxoft

— Как ты вышел на Luxoft?

Я планировал переехать из Казани в Москву и искал работу в столице через hh.ru. Мне позвонила HR-менеджер Luxoft. Мы поговорили, и она уже собиралась назначить собеседование, когда я спросил: «Вы находитесь в Москве?» Она ответила, что нет. Я сказал, что тогда ее предложение мне неинтересно, а HR-менеджер спросила: «А если мы вот такую зарплату предложим?» Так вместо Москвы я переехал в Питер.

— Я слышала, что в Luxoft очень жесткий отбор и сложные собеседования…

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

— Как тебе в Luxoft?

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

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

— Почему ты оттуда ушел? Это крутое место, многие хотят работать в Luxoft.

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

— Одиноко было, наверное?

Ну да. В общем я решил вернуться в Казань и устроиться в Neti.

Как пришел в Neti

— Почему именно в Neti?

Я начал сотрудничать с Neti, еще когда работал в Luxoft. Осенью 2019 года мне написал руководитель проектов и спросил, могу ли я помочь с приложением для застройщика. Клиент хотел загружать в приложение тяжелые документы в формате pdf и оставлять в них замечания. РП вообще не был уверен, что это возможно сделать, а я реализовал функционал нативно, без библиотек. После этого я остался на проекте, а летом 2020 года перешел в штат Neti.

— И как тебе здесь?

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

Советы начинающим разработчикам

— Трудно ли учить языки программирования самостоятельно?

Когда я начал учить Objective-C, у меня еще не было программисткой базы. Она появилась через год, когда на третьем курсе вуза нас познакомили с ООП, SOLID на примере С#, наследованиями, объявлениями классов, объявлениями методов. Это сильно пригодилось. На самом деле, без базы непросто. Поначалу вообще непонятно что происходит. Потом, где-то через полгода, появляются какие-то проблески и становится более-менее ясно. Но вообще тем, кто хочет стать разработчиком, я рекомендую идти на курсы, если есть такая возможность.

При самостоятельном обучении ты, конечно, чему-то научишься, но не факт, что будешь делать хорошо и правильно. Можно научиться так, что потом долго придётся переучиваться. А на курсах изначально закладывают правильную базу.

— У тебя, как у самоучки, была проблема, что ты чему-то неправильно научился и потом пришлось переучиваться?

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

— Что еще ты мог бы посоветовать начинающим программистам?

Я бы посоветовал сразу кодить. Когда кодишь, запоминается лучше. Когда появляется свободная минутка, изучать что-нибудь новое. И, конечно, нужно гореть, тогда обучение будет приносить удовольствие.

— Последний вопрос. Стал ли ты адептом Apple: iPhone, MacBook, Air Pods, iPad? Только Apple и никакого Android.

Я всегда был адептом Apple. У меня всегда был iPhone. Может, это тоже повлияло на то, чем я занимаюсь. Сейчас у меня просто больше разных Apple-устройств, потому что они связаны с работой. Но я не против Android — на самом деле есть крутые «андроиды».

Вопросы для iOS разработчиков

Optional

Что такое optional? Какие способы развернуть optional вы знаете? Что такое неявно развёрнутый optional?

Тип optional в Swift — это enum, который может иметь одно из двух значений: None или Some(T), где T — это любой тип данных. С его помощью можно обезопасить себя от попытки доступа к nil значению.

Существует несколько способов развернуть optional.

1. Проверка на nil:let a: String? = "string"if a != nil { print(a!)} else { print("Error")}Guard let:guard let a = a else { return }If let:if let a = a { print(a)} else { print("Error")Force unwrapping — это небезопасный способ, если значение равно nil, программа завершится:print(a!)Nil coalescing:print(a ?? "Error")Optional chaining:print(a?.uppercased())

Также optional используется в приведении типов:

И в обработке ошибок:

Многопоточность

Об этом можно прочитать в статье про GCD и Dispatch Queues.

Отличия frame и bounds

Это один из любимых вопросов на iOS собеседованиях. Отсчёт координат прямоугольника bounds ведется от его системы координат, а координаты frame считаются от контейнера в котором он находится (superview).

Паттерны программирования

У нас если серия переводов статей о паттернах простым языком.

Отличия структуры от класса

Структуры:

• значимый тип;
• имеют поэлементные инициализаторы.

Классы:

• ссылочный тип;
• могут наследоваться;

Weak ссылки

Когда нужно использовать слабые ссылки? Чем weak отличается от unowned?

Слабые ссылки используют, когда объект, на момент обращения к ссылке может не существовать. Например, при обращении к self из замыкания:

Weak ссылки, как и unowned, не увеличивают счётчик ссылок. Отличие unowned в том, что он не является optional. Weak используется когда известно, что ссылка может быть nil. Unowned — если мы знаем что ссылка никогда не будет nil.

Цикл жизни приложения

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

Жизненный цикл ViewController

• loadView: используется когда контроллер создаётся в коде. loadView вызывается контроллером, когда его текущий view равен nil.
• viewDidLoad: вызывается один раз за жизнь контроллера. Метод отрабатывает когда все view загружены.
• viewDidLayoutSubviews: вызывается когда любой view изменяется.
• viewDidAppear: вызывается когда view появляется на экране.
• viewDidDisappear: вызывается когда view контроллера удален.

Модификаторы доступа

• public и open — open позволяет наследовать и перегружать классы и члены классов внутри и вне модуля. public — только внутри модуля.
• internal — доступ в пределах модуля.
• fileprivate — доступ в пределах файла.
• private — доступ в пределах сущности, где определён объект.

Что работает быстрее — поиск по NSArray или NSSet?

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

Анимация

Гайд по анимации в iOS.

Инструменты XCode

Читайте об инструментах в статье про Time Profiler и Allocations.

Ключевое слово defer

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

Хранение данных в iOS

Статья о том, как хранить данные локально.

Git, merge conflict

В этом вам поможет статья о безболезненном разрешении merge конфликтов.

Алгоритмы

Читайте нашу статью об алгоритмах и сложности алгоритмов.

Задачи для iOS разработчиков

Задачи из списка полезно сделать заранее и выложить на GitHub. Зачастую такие задания предлагают сделать перед iOS собеседованием. Наличие готового варианта сэкономит ваше время.

1. Приложение с авторизацией для любого публичного API.
2. Приложение со списком задач: задания хранятся локально, реализовать редактирование, добавление картинок.
3. Простой Instagram: реализовать получение списка картинок из любого публичного API. Картинки должны загружаться по мере скролла страницы. При нажатии на картинку она открывается на весь экран. Также необходимо использовать кэширование, чтобы при отсутствии интернета картинки продолжали отображаться.

Улучшение читаемости кода

Все знают про кошмарные замыкания в Swift. Из-за особенностей мобильной разработки асинхронные процессы должны вызываться вовремя. Раньше это делали с помощью замыканий. Кто-то из вас может до сих пор использовать для этого замыкания и это нормально.

Но однажды вы столкнётесь с вложенными замыканиями. И начнётся кошмар. Читать и редактировать вложенные замыкания — больно. Все это понимают.

И как же реактивное программирование на Swift помогает уменьшить эту боль?

Вы можете связывать observables в цепочки с помощью функций: map, flatMap и flatMapLatest. Таким образом можно обрабатывать запросы одновременно, не утруждая себя чтением вложенных замыканий.

Также функции merge, combine и zip дают возможность выполнять несколько запросов в более управляемом и читаемом виде. Вот цитата о важности хорошей читаемости:

Конечно, соотношение времени потраченного на чтение кода, ко времени потраченному на его написание — примерно 10 к 1. Мы постоянно перечитываем старый код, ведь это часть процесса написания нового. Следовательно, облегчение понимания кода также облегчает и его написание.

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

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

Помощь с обработкой событий

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

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

Во-первых, реактивное программирование может упростить работу с этими сценариями. Всё, что вам нужно, — это создать observer или subject и подписаться на него. Затем, каждый раз, когда observer порождает объект, все подписчики об этом узнают.

Можно использовать такой синтаксис:

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

Вы можете подписаться на subject из первого контроллера в любом месте программы. А затем использовать myObject для своих целей. Например, пропустить первые два объекта. Для этого можно использовать функцию skip. И как я уже говорил, вы можете комбинировать observable с помощью функций merge и zip.

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

Сделать код более модульным

Одна из моих любых особенностей реактивного программирования — передача observable в качестве переменных. Например можно передать сетевой запрос в другой объект и выполнить его, когда потребуется. Это позволяет сделать код более читаемым и модульным.

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

Я всегда пользуюсь этим, когда мне требуются переиспользуемые контроллеры для отображения данных пользователю. Возьмём приложение, похожее на Instagram, где есть объект поста, и экран, где эти посты отображаются. Вам нужно выводить на одном и том же экране посты одного или другого пользователя. Так как это скорее всего делается с помощью сетевых запросов, вы можете создать запрос как observable и передать его контроллеру. Остальное контроллер сделает сам.

Это фрагмент кода иллюстрирующий мою основную идею:

Таким образом, преимущество здесь заключается в модульности и универсальности. Этот один контроллер можно использовать повторно в любое время, когда вам понадобится отобразить список сообщений. И всё, что вам нужно сделать, — это передать ему observer. Остальное сделает контроллер.

Кроме вышеперечисленных возможностей, реактивное программирование на Swift:

• позволяет эффективно отлаживать код;
• сильно уменьшает количество строк кода;
• при использовании таких библиотек как RxSwift или RxCocoa, даёт возможность использовать traits для лучшего понимания кода;
• хорошо подходит для архитектуры MVVM;
• позволяет выполнять цепочки запросов парой строк кода.

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

Мы поздравляем питонистов с победой и благодарим всех за участие в голосовании!

Голосование закончится ровно через 24 часа — 22 декабря 2020 года в 11:00 по московскому времени.

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

Голосование закончится ровно через 24 часа — 21 декабря 2020 года в 11:00 по московскому времени.

Финальное голосование — здесь.

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

А сегодняшние участники: Swift\Assembler и Java\C++.

Голосование закончится ровно через 24 часа — 19 декабря 2020 года в 11:00 по московскому времени.

Финальное голосование — здесь.

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

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

Голосование закончится ровно через 24 часа — 15 декабря 2020 года в 11:00 по московскому времени.

Финальное голосование — здесь.

Следить за результатами баттла можно подписавшись на уведомления.

Завтра начинается баттл языков программирования 2020. Правила просты:

• В баттле участвуют 16 языков;
• ежедневно соревнуются две пары;
• на каждое голосование отводится 24 часа;
• вы выбираете язык который субъективно нравится вам больше чем его оппонент;
• пары подбираются случайно;
• в результате мы определим победителей, занявших первое, второе и третье места;
• Старт завтра — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

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

Я бы не сказал, что Property Wrappers очень сложны для понимания, но стоит в них разобраться получше, т.к. есть и нюансы. Итак, что такое property wrapper? Из самого названия можно догадаться, что это обертка над свойством, которая добавляет логику к этому свойству.

Возможность добавлять к свойствам обертки в Swift добавили в рамках предложения SE-0258 Property Wrappers. В основном это было сделано для SwiftUI. Чтобы было проще работать с данными, добавили @State, @Binding, @ObservedObject и т.д.

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

1. Перед типом стоит атрибут @propertyWrapper,
2. Тип обязан содержать переменную wrappedValue с уровнем доступа не ниже, чем у самого типа.

Тогда простейший пример будет выглядеть так:

Попробуем применить нашу обертку:

В консоли будет выведено test.

Но если внимательно изучить proposal, то мы обнаружим, как внутри объекта раскрываются property wrapper’ы на самом деле:

За счет приватности снаружи мы не можем получить доступ к wrapper’у — print(simplest._value) выдаст ошибку.

Но изнутри типа мы вполне можем получить доступ к самому wrapper’у напрямую:

Это выведет

что подтверждает, что _value — реальная обертка, а value == _value.wrappedValue == String.

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

В консоли будет

Логику мы поместили в set для wrappedValue; в совокупности с инициализатором, в котором мы присваиваем изначальное значение в свойство wrappedValue, это позволяет нам получить нужное поведение как при инициализации переменной с оберткой, так и при дальнейшем ее изменении, в результате отрицательного числа не может быть в value в принципе. Обращаю внимание: важно, чтобы в инициализаторе первым параметром шел параметр с именем wrappedValue, это дает возможность swift’у под капотом позволять вот такие вот присваивания, когда мы в переменную, помеченную оберткой, можем присвоить значение того типа, который она содержит:

Если мы поменяем, к примеру, на

это уже не будет работать.

Стоит отметить, что т.к. по факту реализуют @propertyWrapper самые обычные типы, мы можем параметризовать обертки.

Например, создадим обертку Uppercased, которая так же принимает на вход число символов, которое необходимо конвертировать в upper case с начала строки.

В консоли будет

Еще я хотел бы обратить внимание на «магию»: этот пример не будет компилироваться, если в TestUppercased мы уберем присваивание строки, т.е. под капотом

вызывает init(wrappedValue: String, count: Int), в качестве wrappedValue как раз передается значение, которое мы присваиваем в value.

Чтобы обойти это ограничение, придется инициализацию проводить в конструкторе:

Если вы успели поработать со SwiftUI, то, думаю, обратили внимание на переменные, предваренные знаком доллара $value: их мы обычно передаем в дочернюю View, у которой переменная определена как @Binding. Proposal поясняет, для чего это нужно. Вспомним, что происходит, если объявить переменную как PropertyWrapper, — снаружи типа невозможно будет получить к ней доступ:

А что, если мы хотим, чтобы пользователи структуры TestSimplest имели доступ к логике обертки ее свойства? Для этого надо в property wrapper определить свойство projectedValue.

Вывод в лог:

Таким образом,

развернется во что-то вроде

Важно отметить, что тип projectedValue может быть любым и не соответствовать типу, в котором определена переменная. Это и позволило для @State при получении projectedValue через $ — получать на выходе не State, а Binding.

Какие основные очевидные варианты применения можно придумать?

• Когда работа со значением на самом деле проксируется, и фактически переменная хранится в базе данных/User Defaults.
• Когда мы хотим как-то преобразовать значение при присваивании; примером этого могут быть приведенные выше Abs, Uppercased, ну или из proposal’а Clamping для обрезания значения по min/max-границам.
• Реализация Copy on Write и т.д.

Отметим, что есть определенные ограничения применения property wrapper’ов:

• в протоколе нельзя указать, что это свойство должно быть объявлено с таким-то Property wrapper’ом;
• свойство с property wrapper’ом нельзя использовать в extension и enum;
• свойство с property wrapper’ом нельзя переопределить в наследнике класса;
• свойство с property wrapper’ом не может быть lazy, @NSCopying, @NSManaged, weak или unowned;
• свойство с property wrapper’ом не может иметь кастомный get/set;
• уровень доступа wrappedValue и уровни доступа для всего нижеперечисленного (если присутствуют) должны быть идентичны уровню доступа типа, в котором они определены: projectedValue, init(wrappedValue:), init().

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

выдаст в лог

а не ожидаемые

На вход в VarWithMemory приходит переменная не типа Int, а типа Abs<Int>. А если бы обертки были не Generic, а принимали, допустим, только строки, то это даже бы не скомпилировалось. Красивого решения нет; как вариант, можно делать специализированные версии оберток, чтобы один тип принимал в конструкторе второй, а внутри уже работать со внутренним типом второго.

Подводя итоги

Какие достоинства у property wrapper’ов? Они позволяют спрятать кастомную логику за простым определением переменной, добавив @<Тип>.

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

Какие альтернативы?

• Для создании логики типа Observer — использовать willSet/didSet у свойств.
• Для добавления логики модификации/места хранения — использовать get/set у свойств.

Playground с исходниками из статьи доступен здесь.

Предок Swift, Objective-C, уже сдаёт позиции и проигрывает в скорости работы. К тому же, код на Swift гораздо лучше читается и его легко изучить даже новичкам.

Плюсы Swift:

• современные синтаксические конструкции: замыкания, дженерики, кортежи;
• безопасность: защита от переполнения, Optional`ы, которые позволяют больше не бояться null;
• отличная читаемость кода.

Мобильные приложения

Swift — единственный современный язык для разработки мобильных приложений в экосистеме Apple. Так же как и XCode — единственная официальная IDE для этого. Что с одной стороны ограничивает в выборе, с другой — вы имеете специализированный инструмент для работы.
С помощью Metal API (официальной библиотеки от Apple) делают игры и 3D графику. А библиотека ARKit позволяет создавать приложения дополненной реальности (AR).

Десктоп

Ещё одно из основных предназначений языка — десктопные приложения для macOS. Разработка также ведется в XCode с использованием множества нативных библиотек для кода и UI. Кроме того, Visual Studio 2019 позволяет писать на Swift под Windows.

Серверные и веб приложения

Этот язык позволяет и такое. Например Vapor — веб-фреймворк, который написан на Swift. Vapor позволяет писать веб-приложения, сайты, API, используя HTTP либо WebSockets. К тому же Vapor значительно быстрее многих фреймворков. Да и использовать один и тот же язык на клиенте и сервере — это удобно.

У меня уже есть блог, он на WordPress, и я устал от всей этой свистопляски с обновлением версии, плагинов, возможности взлома и прочего. Это буквально убивает желание продолжать его развивать. Моя цель — делиться с миром своими мыслями и находками, но при этом иметь полный контроль над своим сайтом. С недавних пор GitHub Pages предоставила возможность хранить простенькие сайты у них. Никаких баз данных и PHP, статический сайт, как в старые добрые. Для блога —идеально. А т.к. процесс деплоя будет проходить через GitHub, будет прозрачная история всех изменений и полный контроль над тем, что реально находится на сайте: трояны и прочая нечисть не пройдут.

Но они предлагают использовать Jekyll, статический генератор сайтов, написанный на Ruby. Все же хочется оттачивать мастерство в том языке, который ты используешь ежедневно, поэтому в качестве альтернативы я взял свежий статический генератор, написанный на Swift, от John Sundell.

Нам предстоит сделать 3 вещи:

1. Создать блог на GitHub Pages.
2. Разобраться, как работать с Publish.
3. Залить свой новый блог на GitHub Pages.

Создадим блог на GitHub Pages

Официальная инструкция доступна по адресу https://pages.github.com.

Основное условие — login блога должен совпадать с вашим логином на GitHub (в моем случае это sparklone). Наши действия:

• логинимся в GitHub;
• идем по адресу https://github.com/new,
• в качестве имени репозитория вводите login.github.io, в моем случае было sparklone.github.io;
• убеждаемся, что он будет Public;
• жмем Create Repository;
• все, наш блог уже доступен по адресу https://login.github.io.

Но пока на сайте нет ни одного файла. Переходим ко второму пункту.

Разберёмся, как работать с Publish

Publish — это статический генератор сайтов, написанный на Swift, что позволяет выстраивать любую логику при генерации сайта: теги, карта сайта, rss, специфическая перелинковка… — все, на что нам хватит фантазии. Одна из моих идей на будущее — попробовать писать статьи на двух языках, и чтобы настроенный шаблон умел это понимать и вставлять переключатель в статью, к примеру. Не знаю, дойдут ли когда-нибудь до этого руки, но как идея — интересно.

Я предпочел установить напрямую через git, создал папку ~/Developer/tools и там выполнил

Далее я создал папку, где планирую хранить свой сайт (точнее, исходники его генератора), в моем случае это ~/Developer/my/blog. Внутри этой папки запускаем команду

publish new

Это создаст новый сайт, а список опций для команды можно узнать, просто запустив в консоли publish.

publish run скомпилирует все исходники и запустит веб-сервер на питоне (если прервать посредством Ctrl+C, веб-сервер не умрет и придется ковыряться в процессах, чтобы убить Python).

Первая сборка занимает какое-то время (подливаются нужные репозитории, все компилируется), при последующих запусках publish run все происходит намного быстрее.

Открываем в браузере http://localhost:8000 и видим, что за сайт получился:

Не густо, но мы еще ничего, собственно, и не сделали, чтобы ожидать чего-то большего.

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

1. Сделать изначальную настройку генератора для нашего сайта.
2. Поменять пути, по которым будут лежать записи, и настроить меню.
3. Добавить подсветку для исходных файлов и создание своей темы.

Изначальная настройка генератора для нашего сайта

Посмотрим, что нам сгенерировал Publish. Внутри папки будет файл Package.swift, его открываем XCode’ом (можно в консоли набрать open Package.swift), и это запускает процесс подтягивания всех нужных библиотек. На скрине видно, что должно получится в итоге.

Тестовая запись лежит в Content/posts/first-post.md. Проверим, что мы можем что-то изменить и это отразится на сайте: подправим текст в first-post.md (можно поменять дату, теги, описания и сам контент).

В Xcode выбираем Mac в качества таргета, для которого надо запускать, и делаем Run проекту.

После этого рефрешим веб-страницу http://localhost:8000.

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

Почему это важно сделать сразу? Если вы решите поменять пути после того, как уже зальете часть постов, входящие ссылки на эти страницы станут невалидными, а т.к. это не свой сервер/VPS, будет довольно проблематично сделать редирект со старых ссылок на новые пути. Не невозможно (вот, к примеру, плагин для Jekyll), но зачем создавать себе головную боль в будущем, если можно ее избежать.

По умолчанию все записи лежат в папке posts. Учитывая, что в дальнейшем хочется бить на категории, а posts — общее название, лучше переименовать папку в articles. Также не помешает добавить страницу about. Но наш генератор пока ничего не знает про это.

В main.swift поменяем на

Добавим файл about.md в папку Content и заполним немного информации о себе.

К слову, эту статью я пишу в XCode, редактируя md-файл и периодически запуская проект, чтобы посмотреть в браузере, как это смотрится.

Я долго колебался, заморачиваться ли с датой у файлов *.md, т.е. называть не my-article.md, а, к примеру, 2020-07-10-my-article.md. И все же решил отказаться от этой идеи: т.к. в самих md-файлах есть метаданные (поле date), это при желании позволит в будущем добавлять дату автоматически. И не придется следить за корректностью даты в имени файла, к тому же это убережет от расхождений, если в имени файла одна дата, а в метаданных внутри — другая. Недостатком такого решения я вижу то, что гипотетически могут в будущем быть коллизии в именах md-файлов, но все-таки это маловероятно, к тому же мы об этом узнаем при создании поста, а не сохранении.

Добавляем подсветку для исходных файлов

Автором генератора Publish так же была написана библиотека Splash, позволяющая делать подсветку исходных кодов. Подключается она как package в Swift Package Manager.

Открываем файл Package.swift и добавляем поддержку, по сути нужно добавить 2 строки. Вот что получилось у меня:

А чтобы подсветка начала применяться при генерации, нужно подключить плагин в main.swift:

try Blog().publish(withTheme: .foundation)

Я поменял на

Не забываем добавить в main.swift импорт плагина import SplashPublishPlugin.

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

Но вот проблема: куда добавлять этот CSS? Если покопаться в исходниках, то станет видно, что все это решается на уровне темы. Тема у нас стандартная: foundation, и она лежит в самом пакете Publish по пути Sources/Publish/API/Theme+Foundation.swift.

Внутри своего проекта (Blog) в папке, где лежит main.swift, я создал подобный файл Theme+Blog.swift. Также внутри папки Resources я создал папку Blog и поместил туда файл styles.css Внутрь файла я поместил содержимое CSS от темы Foundation, ну и CSS от Splash. Да, лучше было бы разделить, а может, вообще темы вынести в отдельный package, но не будем усложнять раньше времени.

Итого у меня в файле темы пришлось поменять таким образом:

Если бы мы добавили еще один css, нам потребовалось бы не только добавить его в resourcePaths, но также добавлять в каждый head страниц, чего мне делать совершенно не хотелось в данный момент.

.head(for: item, on: context.site, stylesheetPaths: ["/styles.css", "/splash.css"]),

В итоге сейчас у меня в проекте файловая структура выглядит как-то так:

Зальём свой новый блог на GitHub Pages

Итак, воспользуемся встроенным инструментом Publish для заливки нашего блога. В main.swift добавим

.deploy(using: .gitHub("login/login.github.io", useSSH: false))

У меня получилось

Проверяем в последний раз, что все работает. Последний штрих — мне кажется, что нет смысла хранить в git нашего репозитория с темплейтами, как строить сайт, содержимое папки Output, для этого у нас будет отдельный репозиторий, как раз таки login.github.io Если вы согласны — исключим эту папку из .gitignore, добавив туда строку /Output в конце. Если все ок, выполняем в консоли (из папки, где мы выполняли publish new)

В течение минуты GitHub Pages подхватит ваши изменения, и все появится онлайн.

Поздравляю! ?

Когда начинаешь исследовать какую-то обширную тему в программировании, количество скачанных проектов и созданных черновиков постепенно превышает все мыслимые и немыслимые пределы. А потом и вовсе всё перемешивается и теряется. Вроде помнил, что ты с этим работал, а где, когда? Я пробовал работать в Playground’ах, но они, на мой взгляд, не такие стабильные, как обычный проект, отваливается подсветка, нет возможности нормально делать Debug. С недавних пор я завел единый проект для исследования SwiftUI, и все небольшие вещи закидываю туда. Это помогает держать все в одном месте, к тому же поиск внутри проекта намного удобней. Хоть SwiftUI и предоставляет Preview для быстрого просмотра View и даже позволяет их отлаживать, все же этого не всегда хватает. Хочется и на устройстве проверить. А если держать все эти View внутри одного проекта, надо при создании новой вьюхи проставлять ее как основную в SceneDelegate, что довольно быстро начинает утомлять. Как было бы круто, если бы мы могли видеть все наши тестовые View при запуске приложения и имели возможность выбрать, с чем работать. Фантастика, скажете вы? Отнюдь ?

Задачу, думаю, можно решить более чем одним путем. Навскидку — прикрутить Sourcery, но интересно было решить ее без вспомогательных инструментов.

Итак, что из себя представляет View и её Preview:

Как мы видим, предпросмотр для View обеспечивается структурой, которая имплементирует PreviewProvider. Если кто не знал, можно даже внутри одного файла создавать сколько угодно структур/классов, которые будут имплементировать PreviewProvider, и все они отобразятся в зоне предпросмотра. Может пригодиться, если захотим разбить наш ContentView_Previews на несколько с разными настройками (хотя можно это же сделать и внутри одной структуры, имплементирующей PreviewProvider, но речь не об этом).

Что из себя представляет PreviewProvider? Это протокол

Главное, что можно извлечь из кода, — это не простой протокол, а PAT: Protocol with Associated Type, что сразу усложняет дело. Я перепробовал много вариантов, как обеспечить нужную функциональность с минимальными усилиями.

Начнем с того, как вообще можно подобные вещи делать в real time? В Objective-C мы могли делать все что угодно с помощью reflection — получать список всех классов, исследовать их свойства. В Swift это все дело сильно ограничили, и Mirror не даст нам всего необходимого. Поэтому пришлось смотреть в сторону objc_getClassList: это метод из рантайма Obj-C, который позволяет получить список всех классов. К сожалению, такого нет для Swift-структур, поэтому оставалось только обходится тем, что дали.

Разберем решение по частям.

Нормально работать с системным протоколом PreviewProvider не получится из-за того, что он PAT, поэтом создадим Erase-версию этого протокола:

1. Как видно, я стер тип у Previews, создав обертку anyPreviews, которая будет возвращать AnyView. Я не очень люблю такие штуки, потенциальная потеря производительности, но т.к. это не production-код, то на это можно закрыть глаза.
2. name — свойство, возвращающее имя нашей View, как оно будет отображатьcя в списке; учитывая, что все Preview имеют автоматом генерируемые имена ViewName_Previews, можно _Previews отрезать.
3. Я добавил свойство starred, т.к. число View будет все увеличиваться, а начиная работать с новым куском кода, хочется увидеть его сверху в списке. Это можно сделать, переопределив у превьюхи для новой View это свойство, возвращая true.

Сам список выглядит довольно просто.

Все View сортируются по имени и разбиваются на 2 списка, starred и обычные. Выглядеть все будет примерно так:

Ну, и в SceneDelegate просто меняем основную вьюху:

let contentView = PreviewsList()

Остался последний момент: как же сделать так, чтобы наши Preview попали в этот список.

• поменять struct на class;
• добавить поддержку PreviewHolder.

Т.е. вместо

станет

Опционально можно переопределять name и starred.

Это решение написано за пару часов, чтобы по-быстрому испытать идею. При желании его можно наворотить по полной, проставляя теги, дату создания для Preview, показывать список не основным, а в Debug-окне, что позволит использовать его даже на боевом проекте (не забываем отключать в Release-сборке). В общем, все зависит от вашей фантазии ?

Скачать проект с базовой реализацией можно здесь: Github

Для разработчиков (Java, Swift, JavaScript)

Призовой фонд — 125 тысяч долларов.

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

Примеры графиков ловите в отдельном Telegram-канале. Там же будут публиковать прочую информацию, относящуюся к конкурсу.

Для UI-дизайнеров

Призовой фонд — 15 тысяч долларов.

Нужно сделать редизайн окна с чатом и меню для прикрепления файлов (акцент на фото и видео) для Android-клиента. PNG с дизайном окна и видео с демонстрацией работы меню присылать боту @design_bot.

О качестве дизайна будут судить по его простоте, удобству использования и полноте представления информации. За новостями следите в отдельном Telegram-канале.

Для дизайнеров UI-анимации

Призовой фонд — 10 тысяч рублей.

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

• что существует настольная версия Telegram;
• что двойная галочка у сообщения означает, что оно прочитано;
• что можно переключиться с записи голосового сообщения на запись видео.

Присылать один или несколько Lottie-совместимых JSON-файлов и соответствующие гифки надо в @design_bot. За новостями следите в Telegram-канале для дизайнеров.