Objective-c, или почему не Swift
Разработка

Objective-c, или почему не Swift

Команда «Иностудио»

Создаём сервисы в сферах HR-Tech, образования, девелопмента.

Посмотреть кейсы Посмотреть кейсы

В качестве основного языка для разработки мобильных приложений мы используем Objective-С. С появлением Swift, стал возникать вопрос: «А почему, собственно, мы пишем на Objective-C, а не на Swift?». Хочу описать свой взгляд и пояснить, почему все-таки мой выбор — это Objective-C. В рассуждениях старался не становиться на сторону ни одного из языков и быть максимально объективным (насколько это возможно, конечно), опираясь на свой опыт и знания.


Сомнений в том, что за Swift будущее, у меня нет, но это будущее не сегодня. Язык сильно изменяется от релиза к релизу: нет ABI совместимости, сильная завязка на Objective-C, баги, недоработки и просто не очень удобные решения (access control с отсутствием protected — очень спорное утверждение, что это идеальное решение).

Почему будущее за Swift?

Судя по многочисленным отзывам и дискуссиям разработчиков, верится, что Apple настроены очень серьезно. Они делают огромную работу и создают Swift таким, каким его хочет видеть сообщество, и это несомненный плюс. Большинство Open Source проектов перешли на Swift, из-за чего найти актуальную и поддерживаемую библиотеку на Objective-C становится все сложнее (особенно, если это новая технология). Все примеры к iOS SDK, WWDC — все это Swift, обойтись хотя бы без понимания его становится сложно. В свою очередь, Objective-C как был, так и остается без изменений (не будем считать изменения для совместимости со Swift), что хорошо и плохо одновременно. В свою очередь уже сейчас понятно, что язык будет востребован, это просто вопрос времени.

Пройдемся по основным тезисам за и против, которые возникали в процессе подобных споров:

Сильные изменения от версии к версии

Это адаптация своего кода к новой версии. Конечно, Apple говорит, что все будет хорошо, у нас есть Migration Tools и он может все. Опыт говорит обратное (stackoverflow подтверждает): Swift позиционируется как Open Source, и я думаю, что день, когда в него не будут вноситься глобальные изменения, наступит не скоро. В нашем проекте я смог полностью перевести библиотеки только спустя 2 месяца после выхода Swift 3, при этом только 2 из 3-х используемых библиотек получилось перевести, третью было решено заменить на аналог, написанный на Objective-C (конечно, всегда можно внести свой вклад в Open Source и сделать хорошее дело). В результате все это требует времени, которого может и не быть, и чем больше проект, тем больше времени понадобится. Хорошо, если время есть, но как показывает практика, это больше роскошь, чем норма.

Сильная завязка на окружении iOS 

UIKit, Foundation и другие стандартные библиотеки — все это Objective-C, большая часть любого приложения — взаимодействие с ними, и в итоге это делает Swift не таким и привлекательным. Взаимодействие с Objective-C происходит динамически, что отлично сводит плюсы быстродействия на нет, как и красивый синтаксис. Откровенно говоря, это ужасно: мы хотим писать на Swift, но все еще завязаны на Objective-C. Мы легко можем стрелять себе в ногу, также используя KVO, KVC, Swizzling и все, что нужно — унаследоваться от NSObject, и вперед. Синтаксис Swift для большинства будет приятнее, но он теряет всю красоту, когда мы сталкиваемся со стандартным апи iOS. 

Кроссплатформенность

Кроссплатформенность — сильный аргумент за. Ходят слухи, что Google планирует сделать Swift базовым языком для разработки под Android. К сожалению, сегодня это разбивается о стандартное окружение iOS (UIKit, Foundation и другие), да и поработать придется много. Есть cocos2d-swift, есть люди, которые считают, что он годится для написания обычных приложений (не игр)… В чем-то, конечно, они правы, учитывая, что интерфейс будет построен не UIKit, а на OpenGl, еще плюс время на приведение его к более-менее стандартному стилю для iOS (а может и вообще к material design). Думаю, это того не стоит.

Порог вхождения в Swift меньше чем в Objective-C

Давайте мыслить логически: Objective-C прост дальше некуда, в нем нет ничего (да, да есть мозговыносящий синтаксис). В Swift есть, наверное, все: замыкания, шаблоны, модификаторы доступа и это далеко не все. Нет смысла говорить, что синтаксис у него приятнее и фич больше — это и так очевидно, он вышел позже и впитал в себя все самое лучшее из того, что есть. Неправильно сравнивать два языка разного возраста, приводя в аргументы только фичи/сахар, и на основании этого судить о смерти одного из них. Вспомните Си, который все еще неплохо себя чувствует, и С++ с его ужасным порогом вхождения и ужасающими конструкциями (и, конечно, как без «неопределенного поведения»).

Найти нового сотрудника со знанием Objective-C с каждым днем сложнее

Это отлично видно, в том числе и по нашим кандидатам, которые сначала присылают Swift, и только по запросу — Objective-C. Если смотреть, ориентируясь на будущее, я бы не стал сегодня учить Objective-C, Swift популярнее, он у всех на слуху, и, естественно, изучать стоит его.

Смерть Objective-C — вероятное событие

Но оно не произойдет внезапно, и, думаю, никто не пострадает (смерть не в том, что его все забудут, а в соотношении количества разработчиков Swift/Objective-C). Думаю, смерть будет естественной: все новые/старые Open Source проекты перейдут на Swift, со временем не останется другого выбора, кроме как начать использовать их совместно с Objective-C кодом (конечно, мы можем использовать библиотеки, написанные на Swift и из Objective-C). Отчасти это уже так. Дальше все придет к тому, что большая часть библиотек будет на Swift, и необходимость в Objective-C со временем отпадет. Почему я не думаю, что Apple просто возьмет и скажет: «все, не будет больше никакого Objective-C?» Да потому, что база существующего на нем кода (приложений) бесконечно огромна, взять и убить это все, думаю, даже Apple не под силу.

KVC и KVO работает только для наследников от NSObject

Часто можно слышать упрек в сторону Swift, что KVC и KVO работает только для наследников от NSObject. В контексте: «а почему только так и это недоработка, требую справедливости!» Мое понимание таково — это нельзя отнести к ошибкам, багам, недоработкам языка. Философия Swift (и всех новых языков программирования) — свести к минимуму случаи, когда программист может прострелить себе ногу и не понять случившегося. С NSObject это работает только из-за совместимости с Objective-C. И описанный механизм в Swift в таком виде, как есть сейчас, недопустим.

Вывод

В заключение, можно сказать, что сегодня итоговый счет Objective-C vs Swift: 1 к 1, и в перспективе Objective-C начинает проигрывать. Использовать Swift для реальных проектов, особенно больших, еще рано, нужна стабильность, тогда — да, можно. Думаю, еще год-полтора и можно его использовать в серьезных проектах, а сегодня стоит попробовать в рамках развития или на небольшом проекте. В целом, это вопрос выбора между стабильностью/качеством vs идти в ногу со временем/модой и использовать только новейшие технологии, пусть с багами! недоработками? но! новейшими! Плюсы и минусы каждого вектора развития, надеюсь, очевидны и в пояснениях не нуждаются. А что выбрать? Сегодня, я за Objective-C. Swift, можно, даже более — нужно, попробовать хотя бы для большего понимания того, что там действительно происходит. Конечное решение, что использовать, каждый должен принять сам для себя. Буду рад замечаниям, и давайте будем слушать себя, а не маркетологов :-)

Список источников, которые будут полезны:

1. Swift 3.0, много шума, а что на деле?
2. ABI Compatibility: Whoopdty Do, What Does It All Mean?
3. Getting to Swift 3
4. Access Control and protected
5. Swift Needs Protected Access Level
6. Android переходит на Swift
7. RobBoluga/cocos2d-swift

Оцените эту статью

0 0
Спасибо за оценку!

Оставьте заявку

Расскажите о проекте — мы его реализуем

Мы свяжемся с вами в течение 4 рабочих часов: обсудим цели проекта, требования к нему и составим план сотрудничества

* – поля обязательные для заполнения