Защита приложений от обратной разработки - сложный процесс, который может отнимать много сил и нервов. Статья расскажет о нескольких подходах защиты приложений под операционную систему iOS с использованием разных методов запутывания кода и сокрытия данных.
Привет! На связи Влад, iOS-разработчик из Ozon. Сегодня я поделюсь с вами, возможно, не самым очевидным способом использования propertyWrappers. Обёртки позволяют добавлять дополнительную логику свойствам. В одну из них мы спрятали описание безопасного декодинга массивов, и теперь нам достаточно пометить свойство как @SafeDecode — и всё начинает работает автоматически. О том, как они работают и как их завести у себя, читайте дальше.
Потоковое вещание с мобильных устройств превратилось из экзотики в надежный рабочий инструмент. В статье мы даём лучшие практики и рекомендации для мобильного вещания на примере нашего приложения Larix Broadcaster.
На iOS есть два варианта тестирования: классический, посредством Sandbox покупок, и новый способ локального тестирования покупок через Xcode (StoreKit local testing).
Sandbox тестирование — процесс несколько муторный и работает только на реальном девайсе. Чтобы тестировать в Sandbox, в самом начале надо завести аккаунт тестировщика на портале, связать его со своим устройством и после этого этого проверить все сценарии.
Тестирование в Xсode Во-первых, тестировать покупки в Xcode можно на раннем этапе, когда приложение не подключено к AppStore Connect. Во-вторых, для Xcode не нужно заводить дополнительных аккаунтов в AppStore, что сильно ускоряет процесс конфигурации тестов, особенно для lifetime non-consumable. В-третьих, локальное тестирование можно автоматизировать, что потенциально снижает шанс появления ошибок в коде.
Познакомьтесь с остальными статьями из цикла:
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. - Вы тут.
Привет, Хабр!
В этом посте, как и всегда, расскажем о новом релизе AppCode. Всем, кому интересно, — добро пожаловать под кат.
Начну с себя. Я и есть тот самый iOS девелопер, работающий в компании Orion Innovation, которому посчастливилось разбирать функционал и придумать универсальный инструмент, применимый в разных кейсах. И у меня есть вопросы. Как часто вам приходится работать с реальными устройствами в мире мобильных девайсов? А что, если ваше приложение отличается от типичных клиент-серверных?
На всё про всё – массив байт. В нем заложены команды, и они отправляются на блютуз девайс. Как же нам конвертировать это в неклассическую модель данных, совсем непохожую на привычный Json? Интересно? Мои идеи и работающие решения в этой статье.
А если серьезно, то продолжительное время мой проект занимается разработкой приложения для управления чипом по протоколу BLE. Отдельная группа инженеров работает непосредственно с железом,занимаясь тем, что готовит API для нас. Сам чип управляет различными девайсами в зависимости от того, с какой платой его сконнектить. Инженеры создали свой функционал, а мы… на стороне клиента должны работать четко по предоставленной ими инструкции.
Современные AAA-тайтлы уже давно стали весить больше 100 ГБ, а их апдейт еще на 20 ГБ считается обычным делом. Тот же тренд разрастания билда постепенно просачивается в мидкорные и хардкорные мобильные игры. Впрочем, к тому, что уже не удивляет ПК- и консольных юзеров, мобильные геймеры все еще довольно чувствительны.
Размер игры на релизе может оказаться гораздо больше необходимого, такое бывает. И даже тогда, когда кажется, что в билде осталось все только нужное, всегда найдется то, что можно оптимизировать и сократить.
Привет, Хабр! Меня зовут Руслан, я — автотестировщик в QA-агентстве «Кавычки». Из этого можно понять, что мы в агентстве занимаемся только тестированием во всех его проявлениях, а меня зовут Руслан. Отлично, идем дальше. Когда какая-то проблема начинает сильно докучать, то даже тестировщики могут что-то создать (ну или сломать это к черту, чтобы не мешало). Это статья как раз про тот случай, когда наша проблема перешла совместимый с жизнью болевой порог, и нам пришлось решить ее с помощью собственной разработки.
Вся наша команда распределена по нескольким странам, поэтому мы не понаслышке знакомы с плюсами и минусами удаленной работы. В какой-то момент минусы начали мешать и соответственно отражаться на качестве тестирования, поэтому мы написали свою мобильную ферму. А из это предложения можно подумать, что мы взяли, сели и написали ее в один прекрасный день, но это не так. Дальше расскажу, как мы к этому пришли, что делали, через что прошли и, конечно, что в итоге получилось. Спойлер: в конце будет ссылка на гит, где лежит наша поделка.
Серверная валидация (server-side receipt validation) — это способ проверить подлинность покупки. В отличие от проверки покупки на устройстве, серверная валидация происходит, внимание, на сервере. Валидация означает, что устройство или сервер обращаются к серверам Apple и спрашивают, действительно ли была покупка и валидная ли она.
Познакомьтесь с остальными статьями по ссылке:
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.
Борясь с рутиной по конфигурации UITableView и UICollectionView, мы создали библиотеку RDDM. В её основе — адаптер, имплементирующий DataSource и Delegate, и генератор, соответствующий ячейке коллекции.
Библиотека дорабатывалась и становилась мощнее. Но чем больше мы вносили улучшений, тем больше понимали, что с архитектурой библиотеки что-то не так. Последней каплей стала попытка подружить RDDM с мощным UITableViewDiffableDataSource, которая завершилась провалом.
Настало время для рефакторинга.
Год назад мы пересмотрели свою реализацию роутинга в iOS-приложениях hh.ru. Тогда она больше походила на простой слой сборки экранов, чем на роутинг как таковой. Смирившись с этим печальным фактом, мы принялись исследовать тему навигации: пересмотрели много подходов в iOS, примерили каждое в песочнице нашего проекта и даже дошли до Cicerone из мира Android.
Взяв лучшее из всех изученных решений, мы переработали всё это дело в собственную реализацию, которая теперь идеально подходит под наши требования к навигации. Недавно мы начали выносить свои наработки в отдельный open-source проект — Nivelir. Эта статья поможет в нём разобраться и покажет, как устроен роутинг в наших проектах.
В жизни хакеры не так всесильны и эффектны, как в голливудских фильмах. Но это не значит, что iOS-разработчик может вообще не думать о безопасности своего приложения. Пусть оно и не хранит тайны Пентагона, взломать его всё равно могут хотя бы для того, чтобы получить платные функции бесплатно.
На нашей конференции Mobius разработчик Мурад Татаев рассказывал о взломе iOS-приложений — и о том, что разработчики могут делать для защиты от него. А теперь мы расшифровали этот доклад (видеозапись также прилагаем). Далее повествование идёт от лица спикера.
На связи Алексей Поддубный, iOS-разработчик AGIMA. Я расскажу, как в iOS работают диплинки, и разберу тонкости настройки популярных сервисов: где создавать ссылки с динамическими параметрами, как настраивать конфигурацию приложений и что делать после настройки. Инструкции основаны на оригинальных туториалах, которые мы перевели и адаптировали.
Что такое эта ваша многопоточность и как с ней жить? Попробуем разобраться что за зверь pthread, зачем нужен RunLoop, какие примитивы синхронизации доступны в iOS разработке, а так же, какие проблемы за собой влечет многопоточность.
Если вы разработчик или автоматизатор, пишете нативные UI-тесты в iOS или думаете начать их писать, эта статья для вас.
Сегодня мы детально погрузимся в мир UI-тестов, потренируемся в их написании, рассмотрим, с какими проблемами разработчик может столкнуться в процессе покрытия приложения тестами, и предложим вам наши решения. Попробуем вместе с вами написать хороший UI-тест! )
Изучение приложений на платформе iOS - это достаточно сложная задача, которая разрешима, если использовать правильный набор инструментов. Основа такого набора - устройство с установленным jailbreak и инструмент frida Frida.
Далее будет рассказано о нескольких способах детектирования инструмента frida из приложения. Заметим, что статья не преследует цели описания всех возможных подходов обнаружения frida, поскольку любая защита может быть снята: всё упирается во время, которое необходимо для анализа.
Kotlin Multiplatform Mobile позволяет компилировать Kotlin код в нативные библиотеки для Android и iOS. И если в случае с Android полученная из Kotlin библиотека будет интегрироваться с приложением написанным на Kotlin, то для iOS интеграция будет с Swift и на стыке Kotlin и Swift, из-за разницы языков, происходит потеря удобства использования. В основном это связано с тем, что компилятор Kotlin/Native (который компилирует Kotlin в iOS framework и является частью Kotlin Multiplatform) генерирует публичное API фреймворка на ObjectiveC, а из Swift мы обращаемся к Kotlin за счет этого сгенерированного ObjectiveC API, так как Swift имеет интероп с ObjectiveC. Далее я покажу примеры ухудшения API на стыке Kotlin-Swift и покажу инструмент, который позволяет получить более удобное API для использования из Swift.
