Pull to refresh

Comments 49

«И, что очень важно, проекты на Swift собираются слишком долго.»
Мне кажется вы забыли упомянуть, насколько дольше разрабатывать, сложнее поддерживать obj-c проекты и насколько труднее искать специалистов.
Согласен, что искать специалистов сложнее. Что касается скорости разработки, она скорее зависит от принятых практик.
Почему вы считаете, что Objective-C проекты сложнее поддерживать?
1) Менее строгая типизация из коробки без танцев с бубнами (а то, чем вы занимаетесь в статье — это танцы с бубнами).
2) Приходится писать больше кода, код менее читаем.
3) Много новых библиотек написаны на swift (например всякие аналитики от facebook). Там куча предупреждений от компилятора, которые разработчики не сильно то хотят и фиксить. Директивы игнорирования предупреждений периодически ломаются, причем на ровном месте, что мешает использовать флаг — treat warnings as errors.
4) Обобщения кастрированные.
5) Синтаксис замыканий вырвиглазный, приходится лазить на сайт fuckingblocksyntax.com
6) Количество файлов в проекте x2
Я могу ещё что-нибудь выделить, но пожалуй мне уже хватит.
В начале статьи приведены аргументы, почему имеет смысл остаться на Objective-C и подождать лучшего Swift'а. Недостатки Objective-C большинство разработчиков знают. И, конечно, в статье мы не призываем никого начинать новый проект на Objective-C. Пройдет еще пара лет и, надеюсь, польза от Objective-C в проекте останется только для C++ разработчиков.
В конечном счете разработчик идет на компромисс: продолжить писать на Objective-C или насладиться преимуществами Swift. И в том и в другом случае придется «танцевать с бубном». Для Objective-C нужно следовать строгому стилю кодирования и доработать инструментарий: в том числе, написать много страниц макросов, использовать кодогенерацию и, возможно, доработать тулчейн. Для Swift нужно разбивать проект на много подпроектов, чтобы как-то контролировать время компиляции, смириться с +5–10Mb образа в сторе и описанными во введении проблемами, и, возможно, тоже доработать тулчейн.
Было бы интересно узнать, если кто-то смог настроить сборку Swift-проектов на удаленной мощной машине (как это делают, например, разработчики на Kotlin, сталкивающиеся с теми же проблемами долгой сборки).
а можно узнать, какие проблемы у вас со временем компиляции приложения?
судя по вашему работодателю это онлайн стор, что там долго компилится?
я разработчик другого онлайн стора LeBoutique, он полностью написан на свифт
и что-то я на своем мак про 13 8 гиг оперативки 2017 года не вижу трудностей с компиляцией
Время компиляции зависит от размера проекта. У нас проект уже достаточно большой. На данный момент SLOC 199105 (LOC 294021).
Сори но количество строк не говорит ни о чем, можно наплодить очень много кода, а еще можно использовать то что не рекомендуется в swift и что тормозит компиляцию, но больше всего что objective-c что swift тормозит неправильная архитектура сториборд файлов. Если запихнуть все в один файл то и компа станет мало для комфотрной работы с этим файлов, не говоря уже о компиляции.
У меня есть огромные проекты на objectice-c и на swift который начинался с swift 2 плавно мигрировал на swift 4 и могу сказать что только архивация проекта для appstore занимает время, а компиляция на симулятор или девайс вообще без дискомфорта.
И самое важное на свифте приложение магазина имеет crash free 99.9% и разработка прошла на много быстрее чем я привык писать на objective c,
так что я очень давоболен свифтом и у меян уже отторжение objective c
Не понимаю, к чему вы это написали. Речь шла о зависимости времени сборки проекта от количества кода.
Если не секрет, какие свои проекты вы упоминаете как огромные?
e-commerce LeBoutique на Swift из последних
Wardrobe Assistant на Objective c (старое) готовлю обсолютно новое приложение уже на Swift
У нас разное представление об огромных проектах.
Я говорю о проектах куда большего масштаба: с экспериментами (A/B тестами), большим количеством экранов, и т.д.
Вы думаете что LeBoutique отличаетяс от Joom? все тоже самое и AB тесты и кучи контролеров и состояний
И 3 маркетенговые SDK
и кастомыне push notification
и deep links
но вот из левых стоит только Alamofire и все остальное написано самим
На MBLTDev18 слушал доклад Тимлида Uber — тётенька рассказывала что делать если проект по причине Huge Codebase не влазит в отведённые Эплом максимальные размеры скачиваемого дистирибутива (вроде 60Mb). Одна из первых рекомендаций была «отказ от Swift».
Доклад называется «Ellie Shin, Uber Putting Your App on a Diet»
Лежит здесь
150 мегабайт для скачивания через моб интернет и даже 3 года назад это было 100 мегабайт,
я помню как ужимал свои PNG через чтоб влезло в эти 100 мегабайт, а проект был написан на Objective C
так что тетенька высосала тему из пальца, ну как многие здесь делают и делятся не существуюшим опытом и откровено дизенформацией.
вот пруф
9to5mac.com/2017/09/19/app-store-cellular-download-limit
Вы не поняли. У тётеньки возникли проблемы с тем чтобы уложить кодовую базу в 150 мегабайт. Это я ошибся. И вопрос был не в ресурсах, а именно в кодовой базе — я специально уточнял у неё этот момент.
У меня к тетеньке вопрос ) что там она назасовывала в приложение что ей не хватило 150? видео?
посмотрите LeBoutique это приложение онлайн стора ( большого ) с количеством пользователей более 4 миллионов, приложение написано на Swift полностью и вес его 28 мегабайт и в приложении все асеты в PDF
даже на онбординг видео лежит в бандл

Вы упомянули аналитики от Facebook. Но это неправда: Facebook не пишет библиотеки на Swift. Разве что какой-то open source.
В Facebook вообще всё разрабатывают на Objective-C++ и не планируют переходить на Swift.
Во-первых не все. github.com/facebook/facebook-swift-sdk и github.com/BoltsFramework/Bolts-Swift
Во-вторых предупреждения «Block implicitly retains 'self'; explicitly mention 'self' to indicate this is intended behavior» же вообще выдаёт фэйсбуковская objective-c библиотека Bolts, которая является зависимостью objective-c библиотеки FBSDKCoreKit.
Неважно как быстро вы находите специалистов, если сборка полного проекта занимает несколько часов
Я не понимаю о чем речь вообще, какие несколько часов? как это несколько часов?
большой проект на Swift после очистки собирается за 5 минут на среднем компе
Смотря насколько большой. Если исходники проекта занимают 5-10GB то нет, даже с 128GB оперативки, весь проект даже за 3 часа не собрать.
А можно поинтересоваться, что это за проект с исходниками такими? Это код столько весит?
что в этом проекте происходит с pods? какое колличество левых на каждый чих фреймворков нагруженно?
Xcode в развернутом состоянии занимает меньше чем 6 без симуляторов
Конкретно сейчас Facebook. И нет это не «левые» фреймворки на каждый чих, и нет — мы не используем pods. По опыту могу сказать что исходники других компаний из Big5 будут не особо меньше. Больших стартапов тоже будут не меньше (Uber, Airbnb).

сейчас смотрю в стор
facebook 312MB
Airbnb 165MB
Uber 220MB
сори с таким выхлопом не может быть 5-10 гигов никак
Мой проект на Objective c который в сторе 120MB на диске он 1.2GB с имеджами
Если бы мы зашивали весь код в исходники проекта — приложение никто бы не загружал. То же самое с Uber, Google, Airbnb.

Очень многое догружается в рантайме в зависимости от паттерна использования юзера.

Прошу прощения, не удержался
image


Скрытый текст

image

А можно ли использовать последние версии ObjC не на MacOS?
Реализация Swift для Linux вроде есть (правда я не знаю, самая последняя или нет).
Какой-то ObjC входит в состав GCC, но вроде бы там нечто весьма древнее, и фичи, описываемые в данной статье, там скорее всего недоступны.
Есть разные реализации Objective-C Runtime для Windows. Самая актуальная и стабильная — GNUstep. Есть инструкция сборки GNUstep с Clang. Судя по статье в их wiki, с Clang собирается runtime библиотека gnustep/libobjc2, в которой поддержаны все новые фичи Objective-C. Clang можно собрать самому или попытаться использовать Clang из Visual Studio. В последних Clang поддерживается всё, что описано в статье. Я сам не пробовал использовать GNUstep.
Что касается реализации Core Animation и UIKit, — есть проприетарные реализации, которые не выложены в публичный доступ. Из публичных: мне известен только Windows Bridge for iOS Project. Не смог проверить, как работает — с первой попытки не завелось на моем ноутбуке (пока нет времени, чтобы разобраться в причинах). Но есть обзоры на youtube (например, этот), где всё работает.
Если использовать Windows Bridge for iOS Project, то ничего самому собирать не нужно. Нужно просто следовать их инструкции. И судя по этому issue, в 2016 году они перешли на GNUstep :)
Большой респект автору.

Пару фишечек не знал, в частности про засахаривания боксинга структур.

Добавлю свои 5 капель керосина в холивар Objective-C vs Swift в пользу старого доброго. Когда я после 10-летнего опыта разработки на C++ перешёл в мир Objective-C, для меня этот язык со странным синтаксом стал как глоток свежего воздуха.

Во-первых, в Objective-C идеально соблюден баланс динамической и статической типизации. Мы можем брать лучшее из обоих миров. Выше был справедливый коментарий от Agranatmark, что представленные в статье премы – это с точки зрения Swift костыль для внедрения статики в мир Objective-C. Но есть и контрпримеры. Например, кодогенерация на основе Sourcery – не что иное как костыль с точки зрения Objective-C для внедрения метапрограммирования в Swift. Чтобы не быть слишком абстрактным, приведу в пример пару своих библиотек, которые элегантно делаются на Objective-C и волосато на Swift:

  1. POSAllocationTracker. Автоматическая детекция утечек объектов. Используется в юнит-тестах на утечки и в дебажной сборке для обнаружения утечек важных с точки зрения бизнес-логики объектов. Например, IoC-контейнер может не просто вернуть некий объект со скопом Singleton, но и перед созданием проверить, реально ли этого объекта не существует в памяти из-за допущенной утечки.
  2. POSLens. Обобщенные функциональные линзы в 100 строчек. В противовес лаконичной реализации на Objective-C в этой статье показывается, как их сделать для Swift и порешать бойлерплейт с помощью Sourcery.

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

Во-вторых, Objective-C более прост в освоении, чем Swift. Всего 120 страниц в официальном мануале против официального 2-томника Swift в iBooks. Количество синтаксических нюансов в последнем уже довольно изрядно, и ветерок C++ из прошлого вполне ощущается. Не зря Дейв Абархамс одновременно is a member of the Swift language core team and… also founding member of Boost.org and a former participant in the ISO C++ standards committee. Как любителю метапрограммирования с использованием Boost MPL и Fusion мне понятен и симпатичен этот путь Swift, но шаблоны в C++ сложны, и в плюсовом сообществе отношение к ним неоднозначное. В поддежку мнения о нарастающей сложности Swift приведу также вот этот недавний замечательный тредик в Twitter.

I found ObjC much easier to learn & teach than Swift. The main difference is you really want a formal introduction to ObjC that takes about a week (the BNR book for instance). Swift you can play with and guess the bare basics, but after that, the learning curve is much steeper.

— Rob Napier (@cocoaphony) 14 ноября 2018 г.



Objective-C сам по себе мало значит
а вот когда начинаешь использовать UIKit вот где засело долгое мучительное обучение и нарабатывание опыта через года практики

Это правда. Все мы больше UIKit-программисты, чем Swift или Objective-C.

С пунктом «прост в освоении», можно поспорить хотя-бы с позиции свизлинга. Этот ваш самый динамизм, крайне противная штука в отладке. Можно столкнуться с тем, что уважаемый тов. разработчик потусторонней библиотеки, услужливо засвизлит вам метод, который свизлите вы или разработчик другой библиотеки. Чсх — это может произойти в какой-нибудь крайне важной для вас библиотеке(например, статистике) и вот ваша прекрасная библиотека проверки утечки не работает так, как вы того ожидали.
Использование кучи вырвиглазных вложенных макросов, тоже не прибавляет к порогу входа. Воспользуется какой-нибудь товарищ макросной магией, и в pch файле объявит макрос, который будет иметь тоже название, как и функция стандартной библиотеки (например, NSLog), которую вы, не подозревая надвигающегося краха, используете, начнёт вести себя не так. И вот макросы уже не кажутся таким прекрасным инструментом. А логи, которые пишут вам матерное слово, вместо того, чтобы логировать (это ещё хорошо, если все обойдется этим, а не записью на диск в главном потоке).
Ещё есть «прекрасный» инструмент KVC. И поменяв названия свойства, к которому, кто-нибудь обратится через KVC, мы словим очень «приятное» поведение в проде. А чего стоит эта самая диспетчеризация через посылку сообщений — отдельный разговор. Крч, простите но мне лично этот самый динамизм, ни капли не доставляет.

Опасения понятны и оправданны. У всего есть своя цена, и за динамизм тоже приходится платить. Тут вопрос в том, кому что дороже. Мне лично нравится наличие свободы выбора. Хочу – пишу безопасно, а хочу – срезаю углы. Objective-C более толерантный язык.

UFO just landed and posted this here
objc используется потому, что это legacy и его просто тянут сейчас и естественным путем выживают из проектов.
И как раз в основном сейчас это смешенные проекты objc и swift

Не только поэтому. Многие большие бизнесы не рискуют переходить на Swift из-за его нестабильности, скорости и общей неопределенности Apple в языке. Как показала практика на очень больших проектах, рентабельность Swift — меньше чем рентабельность Objective-C
я разработчик (с 10 летним примерно стажем) как раз комерческого приложения e-commerce LeBoutique и могу сказать что стабильность очень высокая 99.9% крашфри
скорость работы приложения отличная даже на пристарелых устройствах типа 5S поддерживаемость операционных систем сейчас у меня в приожении >=10.0
так что целесообразность использования только Swift оправдана полностью

Да хоть 40 лет.

Никто не говорил что Swift — будет испытывать больший краш рейт или то что скорость приложения упадет. Скорость исполнения некоторых операций даже выше в Swift чем в Objective C.

Основные проблемы с swift performance — это cold start time и время сборки проекта. А также — отсутствие как таковой стабильности в API языка.

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

Поэтому может LeBoutique и не замечает всего этого, но это только пока что. Эти проблемы появляются с ростом и решаются очень болезненно.
Возьмем большую компанию facebook и ее месенджер с весом 135MB и возьмем Телеграм X на свифте с весом 77MB
в чем различие в 70MB?
может что-то не так с приложением фейсбук что такой перегруз, что фейсбук тормоз на устройстве и выжирает ресурс?

В том что телеграмм намного меньше? И то что он содержит намного меньше фич?


Хотите померятся размерами приложений? Посмотрите WhatsApp и Messenger Lite.

Ок, этот спор никуда не приведет
Хотите я укажу одну маленькую штуку которая покажет что разработка Мессенджера далеко не идеальна?
откройте месенджер первый контролер у нас есть три верхних таба
активный Messages и нажмем на Groups и мы увидим как пролетает мимо средний контролер
Теперь возьмем LeBoutique там подобные табы сверху и нажмем последний и мы не увидим как мимо прилетают 2 которые находятся меджу

Вау. Вы же не серйозно сейчас?


Если все таки серйозно то тогда отвечу:


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


2) Поведение UI не всегда имеет зависимость от качества кода, т.к. разработчики не всегда имеют контроль над этим


3) Сравнивать приложение с активной пользовательской базой менее 250к и приложение с пользовательской базой более 1.5млрд просто некорректно. Абсолютно разный подход к выполнению и абсолютно разные задачи


4) Такое ощущение что вы продолжаете дискуссию только для пиара проекта на котором вы работаете

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

я вижу что вы не разработчик

С чего вы взяли, что я не разработчик?

это не родной контрол (такого нет в UIKit)

Не понимаю какая разница родной это контрол из UIKit или нет?

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

Кого вставили в проект из чужой либы? Табы в мессенджере? Вы серьезно думаете что Facebook использует сторонние библиотеки? Вы серйозно думаете что в коде FB есть что-то не написанное разработчиками которые там работают?

а база больше пару миллионов

Не меняет сути. Даже приложения с базой 10-100 миллионов не решают ту проблематику с которой компании из Big4 сталкиваются, соответственно сопоставлять практически неуместно
Я указал что контрол не правильно написан
причина: пролетающий мимо контролер загружает контент в себя а не должен, так как ему нужно отрисовать контент, а это происходит в мейн треде что приводит к дерганию UI

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


Так он не загружает. Если этот контроллер не был выделен — он не загружает ничего и не отрисовывает и анализ показывает стабильную прямую без проседания FPS на любой из этих анимаций.
Более того, UI отрисовывается не в main thread, поэтому он по определению не может дергатся

а спорить о том кто и как написал — нет смысла


Так я и не знаю зачем вы начали этот спор. Вы же сказали, при этом не приведя ни одного аргумента: «его вставили в проект из чужой либы как есть
его не написали сами». Я лишь указал вам, что это далеко не так.
стоп)))начнем с того что UI отрисовывается в main
вот примеры из док
Updating UI from a Completion Handler
let task = URLSession.shared.dataTask(with: url) { (data, response, error) in
if let data = data {
self.label.text = "\(data.count) bytes downloaded"
// Error: label updated on background thread
}
}
task.resume()


вот решение
Solution
Dispatch the call to update the label text to the main thread.
let task = URLSession.shared.dataTask(with: url) { (data, response, error) in
if let data = data {
DispatchQueue.main.async { // Correct
self.label.text = "\(data.count) bytes downloaded"
}
}
}
task.resume()


developer.apple.com/documentation/code_diagnostics/main_thread_checker

Думаю дальше не стоит обсуждать этот вопрос
и еслия. вижу контролер который пролетает и в нем есть контент значит он его загрузил даже если view пустое
контроле инитиализирован
стоп)))начнем с того что UI отрисовывается в main


А закончим на том, что нет, не весь UI отрисовывается в main. Google в помощь — ключевые слова AsyncDisplayKit, Facebook Papers, Pinterest Texture.

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


Как вам угодно, игнорирование знаний и уверенность в своей правоте — это как наркотик, я понимаю.

Гугл в помощь, о манипуляциях иерархий, кастомных иерархий view, динамическом выделении плэйсхолдеров.

Аплодирую стоя вашему терпению при общении с "разработчиком с десятилетним примерно стажем".

Sign up to leave a comment.