Comments 49
Мне кажется вы забыли упомянуть, насколько дольше разрабатывать, сложнее поддерживать obj-c проекты и насколько труднее искать специалистов.
Почему вы считаете, что Objective-C проекты сложнее поддерживать?
2) Приходится писать больше кода, код менее читаем.
3) Много новых библиотек написаны на swift (например всякие аналитики от facebook). Там куча предупреждений от компилятора, которые разработчики не сильно то хотят и фиксить. Директивы игнорирования предупреждений периодически ломаются, причем на ровном месте, что мешает использовать флаг — treat warnings as errors.
4) Обобщения кастрированные.
5) Синтаксис замыканий вырвиглазный, приходится лазить на сайт fuckingblocksyntax.com
6) Количество файлов в проекте x2
Я могу ещё что-нибудь выделить, но пожалуй мне уже хватит.
В конечном счете разработчик идет на компромисс: продолжить писать на Objective-C или насладиться преимуществами Swift. И в том и в другом случае придется «танцевать с бубном». Для Objective-C нужно следовать строгому стилю кодирования и доработать инструментарий: в том числе, написать много страниц макросов, использовать кодогенерацию и, возможно, доработать тулчейн. Для Swift нужно разбивать проект на много подпроектов, чтобы как-то контролировать время компиляции, смириться с +5–10Mb образа в сторе и описанными во введении проблемами, и, возможно, тоже доработать тулчейн.
Было бы интересно узнать, если кто-то смог настроить сборку Swift-проектов на удаленной мощной машине (как это делают, например, разработчики на Kotlin, сталкивающиеся с теми же проблемами долгой сборки).
судя по вашему работодателю это онлайн стор, что там долго компилится?
я разработчик другого онлайн стора LeBoutique, он полностью написан на свифт
и что-то я на своем мак про 13 8 гиг оперативки 2017 года не вижу трудностей с компиляцией
У меня есть огромные проекты на objectice-c и на swift который начинался с swift 2 плавно мигрировал на swift 4 и могу сказать что только архивация проекта для appstore занимает время, а компиляция на симулятор или девайс вообще без дискомфорта.
И самое важное на свифте приложение магазина имеет crash free 99.9% и разработка прошла на много быстрее чем я привык писать на objective c,
так что я очень давоболен свифтом и у меян уже отторжение objective c
Если не секрет, какие свои проекты вы упоминаете как огромные?
Wardrobe Assistant на Objective c (старое) готовлю обсолютно новое приложение уже на Swift
Я говорю о проектах куда большего масштаба: с экспериментами (A/B тестами), большим количеством экранов, и т.д.
Доклад называется «Ellie Shin, Uber Putting Your App on a Diet»
Лежит здесь
я помню как ужимал свои PNG через чтоб влезло в эти 100 мегабайт, а проект был написан на Objective C
так что тетенька высосала тему из пальца, ну как многие здесь делают и делятся не существуюшим опытом и откровено дизенформацией.
вот пруф
9to5mac.com/2017/09/19/app-store-cellular-download-limit
посмотрите LeBoutique это приложение онлайн стора ( большого ) с количеством пользователей более 4 миллионов, приложение написано на Swift полностью и вес его 28 мегабайт и в приложении все асеты в PDF
даже на онбординг видео лежит в бандл
В Facebook вообще всё разрабатывают на Objective-C++ и не планируют переходить на Swift.
Во-вторых предупреждения «Block implicitly retains 'self'; explicitly mention 'self' to indicate this is intended behavior» же вообще выдаёт фэйсбуковская objective-c библиотека Bolts, которая является зависимостью objective-c библиотеки FBSDKCoreKit.
большой проект на Swift после очистки собирается за 5 минут на среднем компе
что в этом проекте происходит с pods? какое колличество левых на каждый чих фреймворков нагруженно?
Xcode в развернутом состоянии занимает меньше чем 6 без симуляторов
facebook 312MB
Airbnb 165MB
Uber 220MB
сори с таким выхлопом не может быть 5-10 гигов никак
Мой проект на Objective c который в сторе 120MB на диске он 1.2GB с имеджами
Прошу прощения, не удержался
Реализация Swift для Linux вроде есть (правда я не знаю, самая последняя или нет).
Какой-то ObjC входит в состав GCC, но вроде бы там нечто весьма древнее, и фичи, описываемые в данной статье, там скорее всего недоступны.
Что касается реализации 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:
- POSAllocationTracker. Автоматическая детекция утечек объектов. Используется в юнит-тестах на утечки и в дебажной сборке для обнаружения утечек важных с точки зрения бизнес-логики объектов. Например, IoC-контейнер может не просто вернуть некий объект со скопом Singleton, но и перед созданием проверить, реально ли этого объекта не существует в памяти из-за допущенной утечки.
- 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 г.
а вот когда начинаешь использовать UIKit вот где засело долгое мучительное обучение и нарабатывание опыта через года практики
Использование кучи вырвиглазных вложенных макросов, тоже не прибавляет к порогу входа. Воспользуется какой-нибудь товарищ макросной магией, и в pch файле объявит макрос, который будет иметь тоже название, как и функция стандартной библиотеки (например, NSLog), которую вы, не подозревая надвигающегося краха, используете, начнёт вести себя не так. И вот макросы уже не кажутся таким прекрасным инструментом. А логи, которые пишут вам матерное слово, вместо того, чтобы логировать (это ещё хорошо, если все обойдется этим, а не записью на диск в главном потоке).
И как раз в основном сейчас это смешенные проекты objc и swift
скорость работы приложения отличная даже на пристарелых устройствах типа 5S поддерживаемость операционных систем сейчас у меня в приожении >=10.0
так что целесообразность использования только Swift оправдана полностью
Никто не говорил что Swift — будет испытывать больший краш рейт или то что скорость приложения упадет. Скорость исполнения некоторых операций даже выше в Swift чем в Objective C.
Основные проблемы с swift performance — это cold start time и время сборки проекта. А также — отсутствие как таковой стабильности в API языка.
Когда время сборки проекта даже в Objective-C занимает больше часа — перенос его на Swift будет критичной потерей времени, и это основной аргумент для больших компаний и больших проектов все еще использовать Objective-C
Поэтому может LeBoutique и не замечает всего этого, но это только пока что. Эти проблемы появляются с ростом и решаются очень болезненно.
в чем различие в 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, поэтому он по определению не может дергатся
а спорить о том кто и как написал — нет смысла
Так я и не знаю зачем вы начали этот спор. Вы же сказали, при этом не приведя ни одного аргумента: «его вставили в проект из чужой либы как есть
его не написали сами». Я лишь указал вам, что это далеко не так.
вот примеры из док
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, динамическом выделении плэйсхолдеров.
Как писать на Objective-C в 2018 году. Часть 1