moko-resources
moko-resources copied to clipboard
[iOS] FileAlreadyExistsException / FileNotFoundException
Under certain circumstances, I can run into a FileAlreadyExistsException
when building for iOS from Android Studio
Example message:
Execution failed for task ':composeApp:copyResourcesDebugFrameworkIosSimulatorArm64'.
> kotlin.io.FileAlreadyExistsException: /Users/stevenkideckel/Documents/Multiplatform/PathWidgetXplat/composeApp/build/bin/iosSimulatorArm64/debugFramework/ComposeApp.framework/PathWidgetXplat:composeApp.bundle/Contents/Resources/en.lproj/Localizable.strings -> /Users/stevenkideckel/Documents/Multiplatform/PathWidgetXplat/build/ios/Debug-iphonesimulator/widgetExtension.appex/PathWidgetXplat:composeApp.bundle/Contents/Resources/en.lproj/Localizable.strings: The destination file already exists.
It's always been with the en
file. My base locale is English. I have a base/strings.xml
and en/strings.xml
file.
After cleaning and running again I can then hit
Execution failed for task ':composeApp:copyResourcesDebugFrameworkIosSimulatorArm64'.
> java.io.FileNotFoundException: /Users/stevenkideckel/Documents/Multiplatform/PathWidgetXplat/build/ios/Debug-iphonesimulator/widgetExtension.appex/PathWidgetXplat:composeApp.bundle/Contents/Resources/en.lproj/Localizable.strings (No such file or directory)
The situation usually resolves itself with a combination of cleaning in xcode and Android Studio, and running the app from xcode first.
My project is at https://github.com/steviek/PathWidgetXplat
Do you solve this problem .. ? @steviek sometimes its compiled sometimes it suddenly not
Still hitting this sometimes unfortunately. Now it's working for me from AS, but not from Xcode 😬
I wonder if this an issue with using the strings catalog rather than strings file in my xcode project?
I ran into the same issue and since the project linked above also uses a widget target, it could be the same cause:
When I added a widget target to my iOS project, I forgot to also set Build Settings > Build Options > User Script Sandbox to No (ENABLE_USER_SCRIPT_SANDBOXING = NO
in .xcodeproj file).
Therefore the copyFrameworkResourcesToApp
gradle task wasn't allowed to touch the files it needs to interact with. Once I updated that flag (and killed any running gradle daemons), I didn't had the issue anymore.
@ExNDY i think this info should be added in readme
information about ENABLE_USER_SCRIPT_SANDBOXING added in readme