Add a tool to migrate an xcodeproj to Skip

[dfabulich]

People keep asking about this, and the documentation around this https://skip.dev/docs/project-types/#existing_development basically says "start from scratch, copying over code into a fresh project created with skip init or skip create."

But I can dimly imagine a tool that could at least take a standard Xcode-generated SwiftUI xcodeproj (with no xcworkspace), convert it into an xcodeproj that depends on a SwiftPM module, moving the xcodeproj into a Darwin folder, and generate an Android directory for it.

It could perhaps run in phases. Perhaps the first phase would just SwiftPM-ify the whole thing, and then stop and let the user verify that their iOS app still works as expected. Then, maybe a second command could skip-ify one SwiftPM module, ensuring that it builds on Android.

(Some day, as part of an integration test, we could search Github for open-source pure SwiftUI apps and try to automatically migrate as many of them as we can.)

This would be a lot of work, but I think it could really open doors for Skip.

[marcprux]

Yeah, I too have been "dimly imagine"-ing this for a while. Handling all the possible permutations of Xcode would be a tall order, given the variations in how they handle dependencies (Xcode-specified SwiftPM dependencies, CocoaPods, Carthage, etc.). But even just handling the common case of a wizard-created-SwiftUI project that has no dependencies and a pile of .swift files in a top-level folder would be very useful by itself.

We don't currently have any ability to parse and comprehend the .xcodeproj formats, so we'd need to either offload that to a tool like tuist's XcodeProj or implement the parsing ourselves. That would probably be the major hurdle, and once that is done then we could pull the .swift files out, create a Package.swift, maybe run a quick test to see that everything compiles, and then embed Skip's swiftpm-embedded-in-xcodeproj convention. We'd also need pull out the metadata for the top-level Skip.env and the Darwin/ProjectName.xcconfig. Getting resources right would also be tricky, because we'd need to identify which ones need to be handled by Package.swift's .copy vs. .process.

TBF, I've been hoping to a while a some new Xcode release would have improved support for driving app development from a Package.swift. I had high hopes that the .swiftpm format used by Playground apps (https://developer.apple.com/documentation/swift-playgrounds/add-a-swift-package) would evolve into the ability to create an app without the legacy Xcode baggage, but those efforts seem to have fizzled.

All that is to say: this would be a wonderful feature, but also very ambitious. LLMs would probably help a lot for the grunt work. For starters, I would recommend the first step would be to start with a separate greenfield project (like skip-import), and then once something start to work, consider whether it makes sense to merge it into the skip tool itself.