https://kotlinlang.org logo
#decouple
Title
# decouple
l

Landry Norris

02/23/2023, 4:41 PM
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?
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.
c

CLOVIS

02/23/2023, 5:36 PM
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?
l

Landry Norris

02/23/2023, 5:38 PM
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.
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.
See here for how I typically set up the XCode project.
c

CLOVIS

02/23/2023, 6:14 PM
Is the naming of the directories important? Maybe
demo/ios
and
demo/ios-xcode
to keep it closer to your example?
Or maybe I didn't understand what the question is
l

Landry Norris

02/23/2023, 6:15 PM
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.
c

CLOVIS

02/23/2023, 6:16 PM
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)
l

Landry Norris

02/23/2023, 6:17 PM
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.
demo/ios/iosApp and demo/ios/iosAppXcode perhaps?
c

CLOVIS

02/23/2023, 6:17 PM
That's not an issue, GitLab basically just runs a bash script in the provided container, so we can just
cd
before doing anything
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
4 Views