Tuist поможет избавиться от тыканья добавление зависимостей в самом икскоде, и избавит от конфликтов с pbproject (огромными файлами проекта). Ну и есть всякие удобные генераторы ресурсов что бы к ним обращаться напрямую. Ну и всякие прикольные штуки как кеширование внешних зависимостей, что бы каждый раз не собирать их в икскоде.
2) Вы описали удобные функции в этом Package.swift для DSL, это удобно, но если в будущем понадобиться создать новый Package.swift что бы туда что то перенести, то вам придется код DSL туда опять дублировать.
Поэтому я бы посоветовал просто использовать Tuist для всего этого, и там можете описать DSL свой подход для удобства и спокойно проект создавать. Рекомендую юзать buildableFolders, что бы файлы появлялись автоматически в икскоде, удобно когда с ИИ используешь.
Да с 1к таргетов икскоду тяжело :). Рефакторинг почти не работает.
Добавление / удаление файлов нормально работает у нас. Даже можно спокойно через Finder файлы добавлять и в икскоде они появляются (правда есть шанс поймать ошибку что компилятор этот файл не видит и надо перезапускать икскод).
У нас еще была такая проблема что у нас 1 Impl юзкейс / репозиторий это 1 таргет, поэтому у нас так много таргетов наклепано. Планируем сперва разбить на Package.swift поменьше (а то в одном UseCasesImpl у нас 200-300 таргетов), и потом уже на туист переводить.
Но зато плюс такого подхода в том что внутри таргета ты случайно не заюзаешь какой нибудь экстеншен который уже где то был объявлен.
А и еще одна топ болячка. Это когда ты забыл в таргете A добавить нужную dependencies, то локально может нормально билдить, а уже на CI/CD падать и не собираться. Или наоборот - там и там нормально, но когда новый таргет добавил, икскод опомниться и начнет жаловаться. В xcode 26 добавили warning'и на то что какой то зависимости нет, теперь хоть чутка по проще, но к сожалению нельзя эту ошибку сделать фатальной.
Конечно спасибо за статью, но к сожалению в вашей статье:
Идет изменения дерева SwiftUI, что будет бить очень по производительности и в будущем могут необычные баги возникать. Срочно рекомендую посмотреть WWDC 2021: Demystify SwiftUI презентацию.
AnyView тоже зло, учитывая что можно через @ViewBuilder по красоте сделать (а в идеале он тут вообще не нужен будет)
в SwiftUI очень весело фиксить "новшевста" эпла, которые они привносят с минорной версией iOS. Допустим в 16.0 нормально работала клавиатура на вьюхе, в 16.1 уже поломана... и таких микро моментов полно и фиксить приходится обходными путями... Если в UIKit куда проще эпол моменты починить, то в SwiftUI не так.
Я правильно понял что в данный момент Cilicon запускает только 1 раннер на одном компьютере? Есть ли в планах сделать так, что бы запускалось хотя бы 2 раннера на одном компьютере?
А мне очень удобно юзать эту тулзу на макоси, дружелюбный интерфейс, сразу из одного места можно открыть проект какой тебе нужно. Вообщем, как обычно, каждому своё :).
че то самсунг совсем офигели. А теперь представим, что купив тот же айфон в США, и вжух в России он отказывается работать т.к. «ну тыж в Росси сейчас!»… Да уж самсунг пошел по плохой дорожке…
в ВР играх графика не главное, главное погружение и управление. Какая у Вас гарнитура?
Гарнитуру под конец этого года раскупили как горячие пирожки. В Америке распродали полностью окулус квест и валв индекс. Видимо из-за анонса ХЛ: Алекс.
Завезите SPM для AppCode, а то сейчас только SPM умеет в xcframework. Я пробовал в xcode это всё хозяйство добавлять, но аппкод отказывается компилить такой проект и сборка падает.
Или это завезут в 2020.1?
Tuist поможет избавиться от тыканья добавление зависимостей в самом икскоде, и избавит от конфликтов с pbproject (огромными файлами проекта). Ну и есть всякие удобные генераторы ресурсов что бы к ним обращаться напрямую. Ну и всякие прикольные штуки как кеширование внешних зависимостей, что бы каждый раз не собирать их в икскоде.
Не советую СПМ для более крупных проектов.
1) Если у вас есть Основная аппка и экстеншены, то СПМ будет тупо дублировать ресурсы под каждый экстеншен (https://www.emergetools.com/blog/posts/make-your-ios-app-smaller-with-dynamic-frameworks)
2) Вы описали удобные функции в этом Package.swift для DSL, это удобно, но если в будущем понадобиться создать новый Package.swift что бы туда что то перенести, то вам придется код DSL туда опять дублировать.
3) Если проект будет более большим, то будет бить в икскоде по производительности https://docs.tuist.dev/en/guides/features/projects/adoption/migrate/swift-package
Поэтому я бы посоветовал просто использовать Tuist для всего этого, и там можете описать DSL свой подход для удобства и спокойно проект создавать. Рекомендую юзать buildableFolders, что бы файлы появлялись автоматически в икскоде, удобно когда с ИИ используешь.
А ну и еще один минус.
Допустим есть 1 динамический фреймворк с ресурсами.
Есть 2 таргета - аппка и экстеншен. Они оба используют этот динамический фреймворк.
Ну так вот - Компилятор настолько "умный", что тупо дублирует эти ресурсы и из-за этого размер аппки увеличивается.
Подробнее описано тут: https://www.emergetools.com/blog/posts/make-your-ios-app-smaller-with-dynamic-frameworks
не пофиксили до сих пор.
Да с 1к таргетов икскоду тяжело :). Рефакторинг почти не работает.
Добавление / удаление файлов нормально работает у нас. Даже можно спокойно через Finder файлы добавлять и в икскоде они появляются (правда есть шанс поймать ошибку что компилятор этот файл не видит и надо перезапускать икскод).
У нас еще была такая проблема что у нас 1 Impl юзкейс / репозиторий это 1 таргет, поэтому у нас так много таргетов наклепано. Планируем сперва разбить на Package.swift поменьше (а то в одном UseCasesImpl у нас 200-300 таргетов), и потом уже на туист переводить.
Но зато плюс такого подхода в том что внутри таргета ты случайно не заюзаешь какой нибудь экстеншен который уже где то был объявлен.
А и еще одна топ болячка. Это когда ты забыл в таргете A добавить нужную dependencies, то локально может нормально билдить, а уже на CI/CD падать и не собираться. Или наоборот - там и там нормально, но когда новый таргет добавил, икскод опомниться и начнет жаловаться. В xcode 26 добавили warning'и на то что какой то зависимости нет, теперь хоть чутка по проще, но к сожалению нельзя эту ошибку сделать фатальной.
Немного критики на использование SPM'a локально:
Начиная с Xcode 26 во всем проекте теперь есть ограничение на ~1к таргетов SPM локальных. Иначе будет креш.
Так же если много таргетов, то Clean Code должно отрабатывает (до 1-ой минуты)
Ну и вкусенькое - переименование (через рефакторинг) то работает, то нет.
ироиня в том что даже Firebase с этим не справилась... https://github.com/firebase/firebase-ios-sdk/issues/14459 и из-за этого фича флаги ломаются в аппке
Конечно спасибо за статью, но к сожалению в вашей статье:
Идет изменения дерева SwiftUI, что будет бить очень по производительности и в будущем могут необычные баги возникать. Срочно рекомендую посмотреть WWDC 2021: Demystify SwiftUI презентацию.
AnyView тоже зло, учитывая что можно через @ViewBuilder по красоте сделать (а в идеале он тут вообще не нужен будет)
Удачи в позновании SwiftUI :)!
Вы хотя бы для уважения читающего поправьте форматирование кода и вот эти приколы (я про < и т.д):
Result<MoviesPage, Error>) -> Void)
Сама Apple так заявляет, вот в чем нюанс
в Elite Dangerous с нампадом удобнее, но никто не мешает переназначить клавиши и норм
и походу это грубый перевод через гугл переводчик :( "DispatchQueue.синхронизация"
в SwiftUI очень весело фиксить "новшевста" эпла, которые они привносят с минорной версией iOS. Допустим в 16.0 нормально работала клавиатура на вьюхе, в 16.1 уже поломана... и таких микро моментов полно и фиксить приходится обходными путями... Если в UIKit куда проще эпол моменты починить, то в SwiftUI не так.
А что не так с одним портом? Док станцию купил от того же валв или с алика и готово
пользуюсь гитом встроенный в JetBrains. В данный момент, пока еще живое, пользуюсь AppCode.
Я правильно понял что в данный момент Cilicon запускает только 1 раннер на одном компьютере? Есть ли в планах сделать так, что бы запускалось хотя бы 2 раннера на одном компьютере?
Гарнитуру под конец этого года раскупили как горячие пирожки. В Америке распродали полностью окулус квест и валв индекс. Видимо из-за анонса ХЛ: Алекс.
Или это завезут в 2020.1?