71–80 of 116 posts
Earlier quoted context omitted.
Flutter too: https://docs.flutter.dev/get-started/install/macos/mobile-io...
Flutter has moved to Swift Package Manager, it’s just not enabled by default iirc
Earlier quoted context omitted.
I will never start another Apple platform application without Tuist. If I start work on one I will do my best to get buy-in to switch.
It is also the only good way to use LLMs to manage projects/workspaces You can use it for non-Apple platforms btw. Swift on Linux, Android, Windows, WASM. Projects like https://swiftcrossui.dev (with major contribution from Miguel de Icaza recently) and https://skip.tools for instance make this all the more productive
For my Swift backends running on Linux I have just been using SPM and when working on macOS open the manifest directly. I haven't really done anything with a non-web UI with Swift outside of blessed platforms.
Earlier quoted context omitted.
I am going to start sounding like a dinosaur but I really hate this dev tendency to trash the old way as soon as the new way comes out. I am seeing it with all the devs advocating for mise over asdf, and a year ago they were all singing asdf’s praises. I think we can advocate for better while still thanking those we are building upon. Long winded way of saying: thanks to the cocoapods maintainers, you made iOS dev be…
> and a year ago they were all singing asdf’s praises. This can't be true, many people recognized all the deficiencies contemporaneously and even complained about them publicly?
Earlier quoted context omitted.
Yes. There's no ambiguity, no other project uses the name
It was not at all obvious to people that haven’t heard of tuist (presumably the intended audience of your post) that tuist is a product. I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)
That is on you, though.
Earlier quoted context omitted.
> superior solutions Superior includes actual state of being better. Differences could just be differences. Maybe it’s just homoplastic.
Open source superior just means newer, even if it comes with less features and more bugs
It was useful, but way too delicate. I didn't like the way that it rewrote my project structure. Once Swift Package Manager matured, I stopped using CocoaPods.
As someone with no direct love of CocoaPods... Is there a way to use SPM for mixed ObjC and Swift projects? I'd love to know if I have options :)
There was a Swift Evolution proposal at one point to go all the way and bring in support for mixed Obj-C and Swift targets [1] but it was returned for revision. It talks about the multiple target workarounds:
> Distribute binary frameworks via binary targets. Drawbacks include that the package will be less portable as it can only support platforms that the binaries support, binary dependencies are only available on Apple platforms, customers cannot view or easily debug the source in their project workspace, and tooling is required to generate the binaries for release.
> Separate a target’s implementation into sub-targets based on language type, adding dependencies where necessary. For example, a target Foo may have Swift-only sources that can call into an underlying target FooObjc that contains Clang-only sources. Drawbacks include needing to depend on the public API surfaces between the targets, increasing the complexity of the package’s manifest and organization for both maintainers and clients, and preventing package developers from incrementally migrating internal implementation from one language to another (e.g. Objective-C to Swift) since there is still a separation across targets based on language.
The upshot is that SPM has a better interoperability story with Swift and C++ [2] and maybe that can serve as a foundation for getting to the same level of interop for Obj-C.
[1]: https://github.com/swiftlang/swift-evolution/blob/main/propo...
The end of an era! Goodbye xcworkspace. For most of my use cases SPM is now much easier to use and causes less issues but a great effort from all the Cocoapods maintainers over the years. I wonder how interoperable SPM is though with non-Xcode build pipelines (e.g. Unity projects, ReactNative, Flutter, etc)?
The interesting question is what happens to the ~100k+ pods that never migrated to SPM. There's probably a lot of useful but abandoned code that smaller projects still depend on. This creates a bifurcation where legacy projects get stuck on older toolchains.
And this, kids, is why you should always vendorize your dependencies