Where would the best place be to put an iOS demo i...

# decouple

[Landry Norris]

Where would the best place be to put an iOS demo in the project structure? I could create demo/ios, but I’ve found XCode projects that consume a cocoapod to be more reliable than the gradle ways of building an iOS app. This leads to two folders: a gradle project for the pod and an XCode project for the app. Would this mess up the current build infrastructure in any way?

[Landry Norris]

I believe that once I fix the commit message names for https://gitlab.com/opensavvy/decouple/-/merge_requests/52 and https://gitlab.com/opensavvy/pedestal/-/merge_requests/47 so they can be merged, it should be possible to add iOS support to the core and material using Compose for iOS.

[CLOVIS]

My understanding is that XCode only needs access to the final executable, right? It doesn't need access to all modules?

What about something like
• demo/ios-pod ← Gradle module, same pattern as the android and web modules
• demo/ios-app ← XCode stuff

I assume it's easy to change in the future if we decide another layout is better?

[Landry Norris]

The pod module will output a framework and a podspec. That’s all the XCode project needs (The XCode project is often just a basic Swift entrypoint that calls into a Kotlin main function. It’s really just needed because XCode can package everything correctly). It should be pretty easy to change later.

[Landry Norris]

There was a gradle plugin that shipped with AppCode that could package everything without an XCode project, but with the sunsetting of AppCode, I’m not too confident in setting it up for something new, and besides I could never get it working without AppCode to begin with.

[Landry Norris]

See here for how I typically set up the XCode project.

[CLOVIS]

Is the naming of the directories important? Maybe demo/ios and demo/ios-xcode to keep it closer to your example?

[CLOVIS]

Or maybe I didn't understand what the question is

[Landry Norris]

Naming of directories isn’t important to the xcode build. We can name them whatever is best. We could even do demo/ios/xcode and demo/ios/gradle or something like that to not clutter the root.

[CLOVIS]

The problem is that then, the Gradle module would be named :gradle, which is going to be very inconvenient if we push it to a maven repository or similar (though it's the demo, so maybe we won't)

[Landry Norris]

the question would mainly be how this affects the CI builds. Gradle has the modules and submodules to handle this. XCode doesn’t so we’d have to cd around.

[Landry Norris]

demo/ios/iosApp and demo/ios/iosAppXcode perhaps?

[CLOVIS]

That's not an issue, GitLab basically just runs a bash script in the provided container, so we can just cd before doing anything

[CLOVIS]

That seems a bit long? Well, as long as it's in the demo directory and is easy to change later, I don't really have a strong opinion