Вы упомянули аналитики от Facebook. Но это неправда: Facebook не пишет библиотеки на Swift. Разве что какой-то open source.
В Facebook вообще всё разрабатывают на Objective-C++ и не планируют переходить на Swift.
У нас разное представление об огромных проектах.
Я говорю о проектах куда большего масштаба: с экспериментами (A/B тестами), большим количеством экранов, и т.д.
Не понимаю, к чему вы это написали. Речь шла о зависимости времени сборки проекта от количества кода.
Если не секрет, какие свои проекты вы упоминаете как огромные?
Есть разные реализации 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 :)
В начале статьи приведены аргументы, почему имеет смысл остаться на Objective-C и подождать лучшего Swift'а. Недостатки Objective-C большинство разработчиков знают. И, конечно, в статье мы не призываем никого начинать новый проект на Objective-C. Пройдет еще пара лет и, надеюсь, польза от Objective-C в проекте останется только для C++ разработчиков.
В конечном счете разработчик идет на компромисс: продолжить писать на Objective-C или насладиться преимуществами Swift. И в том и в другом случае придется «танцевать с бубном». Для Objective-C нужно следовать строгому стилю кодирования и доработать инструментарий: в том числе, написать много страниц макросов, использовать кодогенерацию и, возможно, доработать тулчейн. Для Swift нужно разбивать проект на много подпроектов, чтобы как-то контролировать время компиляции, смириться с +5–10Mb образа в сторе и описанными во введении проблемами, и, возможно, тоже доработать тулчейн.
Было бы интересно узнать, если кто-то смог настроить сборку Swift-проектов на удаленной мощной машине (как это делают, например, разработчики на Kotlin, сталкивающиеся с теми же проблемами долгой сборки).
Согласен, что искать специалистов сложнее. Что касается скорости разработки, она скорее зависит от принятых практик.
Почему вы считаете, что Objective-C проекты сложнее поддерживать?
Часть запасов лития в США может составлять 136% от всех запасов лития в США?
Для таких сообщений есть Ctrl+Enter.
Единственный способ выучить C++ по бесплатным курсам
Очень странное начало статьи без какого-либо вступления о том, что такое Zig.
В Facebook вообще всё разрабатывают на Objective-C++ и не планируют переходить на Swift.
Я говорю о проектах куда большего масштаба: с экспериментами (A/B тестами), большим количеством экранов, и т.д.
Если не секрет, какие свои проекты вы упоминаете как огромные?
Что касается реализации Core Animation и UIKit, — есть проприетарные реализации, которые не выложены в публичный доступ. Из публичных: мне известен только Windows Bridge for iOS Project. Не смог проверить, как работает — с первой попытки не завелось на моем ноутбуке (пока нет времени, чтобы разобраться в причинах). Но есть обзоры на youtube (например, этот), где всё работает.
Если использовать Windows Bridge for iOS Project, то ничего самому собирать не нужно. Нужно просто следовать их инструкции. И судя по этому issue, в 2016 году они перешли на GNUstep :)
В конечном счете разработчик идет на компромисс: продолжить писать на Objective-C или насладиться преимуществами Swift. И в том и в другом случае придется «танцевать с бубном». Для Objective-C нужно следовать строгому стилю кодирования и доработать инструментарий: в том числе, написать много страниц макросов, использовать кодогенерацию и, возможно, доработать тулчейн. Для Swift нужно разбивать проект на много подпроектов, чтобы как-то контролировать время компиляции, смириться с +5–10Mb образа в сторе и описанными во введении проблемами, и, возможно, тоже доработать тулчейн.
Было бы интересно узнать, если кто-то смог настроить сборку Swift-проектов на удаленной мощной машине (как это делают, например, разработчики на Kotlin, сталкивающиеся с теми же проблемами долгой сборки).
Почему вы считаете, что Objective-C проекты сложнее поддерживать?