Comments 8
Разве 7 пункт и 10.4 пункт не одно и то же?
1. Использование финализированных классов (final)
Понятно, что использование модификатора final дает некоторые преимущества, но нужно ли его проставлять явно? Где-то попадалась статья, что компилятор автоматически добавляет этот модификатор к private классам и даже по умолчанию к internal (можно отключить в настройках проекта)
Отличный вопрос Bardakan!
Private классы ограничены областью видимости текущего файла и технически не могут быть переопределены из-за этого, Swift не добавляет автоматически final к таким классам. Использование final в таких случаях может быть избыточным.
Касательно internal классов:
Нет встроенной опции в Swift, позволяющей автоматически считать все internal классы как final. Если класс не объявлен как final, он может быть переопределен в пределах того же модуля.
Нашел ту статью:
https://samwize.com/2023/12/15/should-you-add-final-to-all-your-swift-classes/
The compiler can also infer for the default
internalaccess level, but only if you enable Whole Module Optimization (WMO) under Building Settings > Compilation Mode > Whole Module.
И еще одна интересная статья, из которой следует, что final может автоматически применяться даже для `public`:
https://developer.apple.com/swift/blog/?id=27
Спасибо за Ваш комментарий и ссылки. Первую статью я не могу никак комментировать, чтобы там ни было написано, так как, не могу ее считать достоверным источником информации, так же как Вы мою.
Касательно ресурса с официального блога Apple.
В статье Apple обсуждается, как компилятор Swift может оптимизировать вызовы методов и доступы к свойствам, предполагая, что они не будут переопределены, особенно в контексте Whole Module Optimization. Это несколько отличается от автоматического добавления модификатора final, о чем я писал в своем ответе Вам.
Мой основной поинт заключался в том, что Swift сам по себе не добавляет модификатор final к декларациям в коде. Вместо этого, компилятор может оптимизировать внутренние вызовы так, как если бы они были помечены как final, особенно при использовании опций компиляции, которые позволяют ему видеть более широкий контекст, например, компиляция всего модуля сразу.
Мы говорим о немного разных аспектах работы компилятора и модификаторов в Swift. Важно различать автоматическое добавление модификатора final к классам или методам и оптимизации, которые компилятор может применять на основе анализа видимости и использования классов и методов. Когда компилятор выполняет такие оптимизации, он не изменяет исходный код, а просто оптимизирует сгенерированный машинный код. Надеюсь, это проясняет ситуацию.
Каждый пункт писал руками (часть с помощью опен сорс либ с гитхаба), нудное это дело если честно, если вы еще не небезопасник, а простой девелопер и параллельно пилишь бизнесовые фичи.
Это постоянно нужно обновлять эти либы, на глазах видел пример, либа по детекту джейла добавляет новый вид детекта, либа которая скрывает джейл видит этот код в либе детектора и тут же модифицирует код чтобы ее не нашли, потом это видит либа детектора и снова добавляет новый детект, короче кошки мышки.
Метод objc легко хукается школьниками, сначала нужно проверить, что методы не изменены, а только потом их использовать.
FileManager.default.fileExistsЗа статью спасибо, навеяло настальгией. В итоге безопасники заставили перейти на платное решение (очень дорого как я понял, но бизнес согласился) - просто интегрируешь либу, а она уже сама всё детектит и через сеть обновляет сигнатуры малваря.
Защита iOS-приложений от реверс-инженеринга