Hi,
I have pretty complex project with multiple submodules, provided as development Cocoapods. When I change something in that related submodule, xCode correctly recompile changed code. However, when I run the code in simulator, the changes are not there. I have to do Product -> Clean to see the changes.
When I switch to the "Legacy" build system, everything works perfectly. Anybody with similar problems? Any idea, where could be the problem?
Thanks,
Jindrich
It is usually needed to perform a clean Build Folder to have such changes and other effective.
Some call it a bug, other call it "feature" !
This is not feasible - it took 10 minutes to make clean build. If it happens sometimes, I would go through it, but it happen always. And only with new build system enabled.
> I have to do Product -> Clean
Not possible. 'Clean' has been removed from Xcode's menu. Most likely you're thinking of the now standard menu choice to clean build folder.
There are 18 hits when the Xcode 10 beta release notes are searched on: new build system - perhaps there is info there that can help you better get along with the beta.
As well, search on 'clean build folder' to see if there are known issues that apply to your work where it may fail.
>This is not feasible
Seems an odd comment to make concerning beta tools...
Good luck, be sure to file bugs against the beta, and thanks for helping test.
Hi sarsonj2
Exactly the same issu with same context with Xcode 10 Build 10A255 (the official release)
With each new release of Xcode it's always the same with CocoaPods 😠
To hack into the Xcode's project files as CocoaPods do it's normal that we are that kind of problems ✖
I don't understand that Apple is not already integrated SwiftPM into Xcode or even SwiftPM is not compatible with iOS project 😢
With SwiftPM we would have something of clean and we can finally get rid of CocoaPods once and for all!!!! 😉
In the meantime you can try to declare your component not as a pod in development mode but as a subproject in your main project. If you have a repository for this component use git submodule. It can work if your component does not use other components itself via CocoaPods. Otherwise you can try passing on Carthage. With Carthage you can quite have a sub-project that uses other components with Carthage.
I also have this problem. It is rediculous. How can it link if I make an error on a submodule but not link if I make a change with no error. This is fundemental. EXTREMELY DISAPPOINTED in Apple over this.
The new build system has three fundamental flaws that I discovered so far; all three are known to Apple as all my bug reports were closed as duplicates, yet the bugs they duplicate are still open. Please note that I filed these when Xcode 10 was still a beta and now we already have Xcode 10.2.1 and nothing has been done to even try fixing any of these bugs.
1. The build system often fails to detect changes, if these changes are not obvious previous to starting a build. Aparently most of the build is planed prior to starting the build. If something is unmodified during that planing phase, it will be ignored. Yet it will even be ignored if it becomes modified as part of the building process. This used to work correctly with the old build system which apparently was performing less planing in advance or was re-evaluating files after certain steps were performed.
2. The build system cannot deal well with symlinks. If a path or build setting is set by a symlink, the build system will inspect the symlink itself but not the file/folder it links to. Very often a build step is not performed, despite the file the symlink points to having a new last modification date. No matter how often I touch the file, the step is skipped. Yet if I force the system to update the last modifcation date of the symlink file itself (`touch -h`), all of a sudden Xcode does perform this step. Using symlinks always worked correctly before but it can get you a lot of headache with the new build system.
3. The new build system fails to re-sign. If you build an app, have it sign and verify the signature, the signature will be okay. If you now modify a resource file (e.g. a strings file), Xcode will detect the file has changed, it will even copy the file tot he app bundle but it will not update the app bundle signture. If you check the signature again, it will be reported as broken since one of the resource files was modified. Again, this has never been a problem with the old build system. The old bulid system always kept a record that it modified a bundle and always re-signed any bundle it modified. See also http://www.openradar.me/radar?id=4959138173943808
When using Cocoapods, (2) can be an issue (Cocopod uses a lot of symlinks to avoid duplicating files) and if you have a development pod, especially (1) is a problem. In some cases also (3) is an issue if a resource may change between two builds. But (3) can be an issue for any project that requires a correctly signed application and one of our apps has a huge issue becuase of (2).
And again, please understand that this is not a "oh, this cannot be fixed" issue as why would the old system always produce correct results then? If the old system can do it correctly, the new one surely could as well. Especially since it has all the information it needs. It knows when the app bundle was modified and it could also easily dedect that a file was modified as part of the bulid process and then re-generate the dependcy tree, and finally, nothing is more easy than make sure both, the last modification date of a link and the link target are always checked, so I see no excuse whatsoever that this hasn't already been fixed ages ago.
Hi,
I suppose that all bugs still exist in 11.1 or did you get a feedback from Apple that they have been solved?
PS: I experience still the same issues as you have described with 11.0 (at least with that version I tested the new build system as I am too lazy to check all the time if some of the bugs disappeared whenever a new version arises).
PPS: The most annoying part is that Xcode still suggests to use the new build system whenever you get a new Xcode version though the bugs make the new build system unusable.
I have been wrestling with problem #3 for almost a week. I believe it was precipitated by modifying the help book for a macOS project, which I was trying to commit before upgrading to Xcode 11 from Xcode 10.
I initially searched "Command codesign failed with a non-zero exit code". None of the solutions resolved my problem. Despite seemingly endless frustration, I continued to explore the Xcode app and my macOS project. On a whim, I decided to search the "new build system", and I came across the link cited in #3 as well as Apple's own documentation. However, the solutions did not correct my build failure.
Out of desparation, I considered reverting to the legacy build system when I had an inspiration. I reverted to the legacy build system in "File -> Project Settings ...". Instead or using the legacy build system to rebuild my project, I cleaned the project with the legacy build system. Then I changed back to the new build system and issued the build command. It succeeded without a codesign failure.
can verify that the new build system is still troublesome with large pre-existing projects on xcode 12. whenever we try to switch to it, lots of errors. trying to fix them uncovers more errors.