Comments 17
Я вам написал в личку по поводу "в производстве", но вот я продолжаю читать статью дальше, и это... ужасно. Попросите кого-нибудь вычитать её, пожалуйста.
> которые окончательно не связаны с Xcode 14.
> that aren't definitively attributable to Xcode 14.
"которые не могут быть однозначно связанны с Xcode 14."
Потому что современное ПО -- поделки. Важно побыстрее, с меньшими усилиями и минимальным порогом вхождения для программистов.
А когда профессиональный программист пишет взрослый код они плачут с фразами: "Сложна! Почему так сложна!?". И всё ради снижения порога вхождения в профессию. Думать о размере кода и памяти? -- Слишком сложно! Даёшь автоматическую кучу! Давайте ещё больше кода для упрощения работы с памятью и "рисования" кода! Вот -- доупрощались. Зато программу может сляпать любой ребенок!
P.S. Извините, наболело..
Да нет, когда профессиональный программист пишет взрослый код – напротив, это не сложно, он значительно легче читается, чем наплывы кода, созданные неопытными программистами или просто в спешке, без планирования.
Какой-то странный у вас "взрослый код", который непонятен людям. Взрослый код по определению понятен и доступен всем (не путать со знанием API, который этот код использует)
Касательно конкретно iOS, как правило принцип "всё своё ношу с собой". На iOS, Swift runtime до определённого момента даже не был частью системы, например. Каждое приложение включало себя рантайм. Так же "fat binaries", которые включают себя код для нескольких архитектур сразу.
На данный момент Apple перепаковывает приложение на своей стороне и отдаёт только нужные бинарники, но в свете этой статьи не факт, что он будет делать это дальше.
Приложение для андроида, которым я сейчас занимаюсь, в релизной сборке весит 3 (три) мегабайта. Гугл плей ещё дополнительно скукоживает, убирая ресурсы вроде ненужных этому конкретному пользователю локализаций. Люди удивляются, по большей части в хорошем смысле.
Нет ни одной хорошей причины, почему приложение производителя обуви может весить 300 грёбаных мегабайт. Ни одной.
Потому что используют готовые пакеты в огромном количестве, зато софт можно выпускать очень быстро
Не понял, за что вас минусанули, но это действительно основная причина. При чем зачастую продиктованная бизнесом - нужна определенная аналитическая тулза, или тот же Facebook SDK, которые весят больше, чем само приложение.
Еще есть Elektron и подобные ему монстры, которые тащат с собой весь JS мир (привет PayPal для iOS).
«Удалить связанный продукт» на «Да»
«Дополнительные флаги полосы» на -rSTx
Все остальные настройки зачистки на значения по умолчанию
А это не вы случайно подрабатываете русским переводом у китайцев для Алиэкспресса?
Я так понял статья Copy-Past из переводчика в Safari.
Василий, было бы хорошо делать вычитку статьи перед публикацией.
А что настройки Xcode - русифицировали???
"Deployment Postprocessing" = "Yes"
"Strip Linked Product" to "Yes"
"Additional Strip Flags" to
-rSTxAll other stripping settings to their defaults
1. XCode14 теперь не удаляет отладочную информацию из release (которой раньше там и не было).
2. Увеличение приложений за счет мусора, вызывают только положительные эмоции. По крайней мере это называют: улучшением. Но тут же зачем-то пристраивают костыли.
Попробовал поймать проблему на Xcode 14.2 и не смог воспроизвести, пробовал разные комбинации, ipa-шка всегда получается мелкого обычного размера как и на Xcode 13 (на нашем проекте размер ipa файла 25 мб), но xcarchive отличается размерами в несколько раз, но после упаковки в ipa размер становится обычным. Возможно в ранних версиях Xcode 14 не работала вырезка символов перед упаковкой в апкашку. В проекте стоят дефолтные значения для "Deployment Postprocessing" = "No", "Additional Strip Flags" = "", "Strip Linked Product" to "Yes". Но в целом у нас в проекте и так выключен bitcode с недавних пор (как-то случайно пролезла), но даже если включить то всё ок как на Xcode 13, так и на Xcode 14.2.
Как Xcode 14 непреднамеренно увеличивает размер приложения