Xcode 10 copy phase fails on twine output files
silverhammermba opened this issue · comments
Xcode 10's new build system runs build phases in parallel whenever possible. This causes problems with twine because there is a required order: twine has to generate the localization files before they are copied into the app bundle.
This can fail your build when building an iOS app (Xcode will try to copy the files before they are created). Even worse, it can silently fail: if you have old localization files present, it might copy those into the app bundle before twine overwrites them with up-to-date versions causing you to deploy an app with missing/incorrect localization.
Xcode's "solution" to this is making you specify all of the files your scripts can output, so that it knows what other build phases could depend on them. This is not ideal, because the set of localization files is dynamic based on the languages present in twine's input.
I tried to hack around this by running twine in a separate build target that my other localization-needing targets depend on. That works for ensuring twine runs before the copy, but it still fails if the localization files don't exist ahead of time (I guess Xcode checks for file existence in parallel, even when the copy phase is run later).
I realize that this isn't a twine bug, but it also isn't really an Xcode bug. Xcode 10's new build system just doesn't play well with twine. Is there a recommended way to get around this issue? Right now we're using my separate twine target hack plus checking in our localization files so that they always exist. This is messy because now our git diffs have a bunch of redundant localization changes in them, but it works.
I've reported this on the Apple forums but so far I haven't gotten any reaction.
We don't check in our localization files, but we do set the input files and output files for all generated languages in our build phase. Does this help at all?
Also note that while we don't checkin the Localizable.strings files into git, Xcode does know about them and shows red entries for them in the project navigator (red until you build once and the files are generated).
Also, I did investigate if we could make the list of output files dynamic based on which languages are present in the twine file. Unfortunately it does not appear as though Xcode supports this. Which means that if we add a new language to our Twine file, we also have to add a new output file in the above list. It's not ideal, but it's also rare enough that it hasn't been much of a bother.
That doesn't look too bad, but for our app we have 33 different localization files.
I like your idea of dynamically generating the output file list. Even if Xcode doesn't support it you could at least put that in a script somewhere so that you can easily update the list whenever your localization files change.
I think we can classify this as a documentation issue. We should update the README to discuss how to properly integrate Twine with the Xcode 10 build process. PRs welcome. :)
Closing due to inactivity.