iOS *

Привет, я Антон, iOS-разработчик в inDriver. Год назад я присоединился к компании и стал одним из первых разработчиков в новой платформенной команде. Перед платформенными командами, в отличии от продуктовых, стоят задачи по разработке, а не по продукту как таковому. Мы выделили основные направления: создание общих компонент и стандартов разработки, а также развитие и поддержка архитектуры проекта. В этой статье остановимся на архитектуре. Разберем, с какими проблемами столкнулись в процессе ее масштабирования, какие ошибки допустили и как исправили. Обо всем по порядку.

UPD: технические детали подробнее рассказаны во второй части.

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

Как и множество других компаний, мы в hh.ru с интересом приглядываемся к Kotlin Mobile Multiplatform. Особенно нас заинтересовал вопрос, связанный с удобством работы iOS-разработчиков с общим SDK. Наши iOS-инженеры пишут на Swift, поэтому нам важно было убедиться: то публичное API, которое мы сформируем, будет выглядеть на Swift так же удобно и классно, как и в Kotlin. Мы провели объёмный ресёрч, в рамках которого подготовили специальный репозиторий "Kotlin-Swift-Interopedia", которым и хотим поделиться с сообществом.

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

Как поведут себя abstract-классы? Что будет с sealed-интерфейсами? Удобно ли мне будет работать с лямбдами в качестве аргументов функций? Enum-ы превратятся в Swift-овые enum-ы?

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

Относительно недавно на Хабре анонсировали специальный инструмент, который может немного улучшить опыт iOS-разработчиков — плагин moko-kswift от компании IceRock. Но даже с его помощью не все боли могут быть исправлены прямо сейчас.

Всем привет! Меня зовут Илья, и я провожу собеседования *хлоп-хлоп-хлоп*. Сейчас работаю на позиции Principal iOS Engineer в inDriver, и мой фокус смещен в сторону технических собеседований. До этого руководил мобильной разработкой в в «Альфа-Банке» и был кем-то вроде нанимающего менеджера. Это тот человек, который говорит финальное слово по кандидату и определяет, какую циферку написать в оффере. Помимо «рабочих» собеседований, я иногда собеседую на аутсорсе, а также помогаю разработчикам к ним готовиться. 

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

Всем привет!

Меня зовут Илья и я являюсь одним из разработчиков в команде in3D - мы делаем технологию по созданию 3D модели человека с помощью телефона. Мы начали еще в далеком 2019 году и с тех пор мы сильно продвинулись вперед. Давайте вместе посмотрим на прогресс нашей технологии и на основные шаги улучшения.

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

Создание нового проекта на Flutter - это благословение - свежая кодовая база, никакого легаси кода (пока что), null safety, самые последние версии ваших любимых библиотек и так далее. Однако, в то же время, необходимо принять критические решения в самом начале, которые будут лежать в основании для будущего, такие как инструменты, пакеты, файловая структура, решение для менеджмента состояния, тестирование и планирование. В противном случае, в итоге, проект превратится в еще одну чашу спагетти с фрикадельками. Чтобы избежать этого, я подготовил список наиболее важных, по моему мнению, частей проекта, которые должны быть решены как можно раньше. Я надеюсь, что это поможет вам. Приятного чтения!

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

Изучая тему мобильной разработки обнаружил, что руководство компании Apple по дизайну и разработке приложений Human Interface Guidelines не переведено на русский язык.

Потратив некоторое количество времени, совладал с переводом этого материала.

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

Если увидите, что в каких-то местах текст переведен некорректно или плохо, и у вас есть идея о более правильном варианте, прошу написать на почту hamvestor@gmail.com, указав в теме письма "HIG - перевод".

Перевод размещен здесь: Human Interface Guidelines for iOS.

Из этой статьи вы узнаете о возможностях работы геолокации, когда приложение свёрнуто или закрыто; о тонкостях работы с авторизацией; о нововведениях в iOS 15, затрагивающих геолокацию.

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

Типичный день мобильного разработчика: получил json, распарсил, отрисовал на UI ячейки, PROFIT.

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

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

За последний год в нашем мире так много изменилось, и React Native не исключение. Мы приветствовали новых членов в нашей команде (с которыми мы очень рады встретиться лично!), наши проекты созрели, и появились новые возможности. Мы рады поделиться всем этим с вами в этой публикации!

В Facebook наша команда работает полугодиями. Каждое полугодие мы пересматриваем нашу стратегию, устанавливаем планы и делимся ими внутри компании. Сегодня мы хотим поделиться с вами, нашим комьюнити, нашими планами на второе полугодие 2021 года.

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

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

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

War Robots всегда была игрой, насыщенной контентом, а потому места в памяти девайсов занимала немало. Раньше эти цифры колебались в районе 800 МБ, но масштабная переработка графики в ремастере игры, как бы ни хотелось, не смогла бы оставаться в тех же пределах и наверняка бы привела к увеличению размера приложения в несколько раз. Что и случилось в нашем случае: вес клиента достиг 2,3 ГБ — в три раза больше «ванильной» версии. В то же время мы понимали, что HD-пресет потянет далеко не каждый мобильный телефон, а значит — нет смысла заставлять игроков качать ненужные гигабайты и тем самым ломать себе воронку конверсий.

Выход? Базовое качество скачивать по умолчанию и выбирать при первом запуске, а HD-пресет предлагать пользователю позже — и только если устройство его поддерживает. 

Все это подстегнуло нас на активное внедрение такой технологии в нашу игру.

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

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

1. iOS in-app purchases часть 1: конфигурация и добавление в проект.

2. iOS in-app purchases часть 2: инициализация и обработка покупок.

3. iOS in-app purchases часть 3: серверная валидация покупок.

4. iOS in-app purchases часть 4: локальное тестирование покупок в XCode.

5. iOS in-app purchases часть 5: обработка ошибок SKErrors. - Вы тут.

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

Привет! На связи Влад, iOS-разработчик из Ozon. Сегодня я поделюсь с вами, возможно, не самым очевидным способом использования propertyWrappers. Обёртки позволяют добавлять дополнительную логику свойствам. В одну из них мы спрятали описание безопасного декодинга массивов, и теперь нам достаточно пометить свойство как @SafeDecode — и всё начинает работает автоматически. О том, как они работают и как их завести у себя, читайте дальше.