I've been folowing this thread hoping for a workaround but unfortunatelly none of the suggested solutions worked reliable. Our team has become unproductive and demotivated due to the time we have to wait compiling our mixed Obj-C and Swift project. We conveinced our management to start using Swift and now we have to keep explaining that our productivity dropped because of Swift. We are almost at the point to start writing new code in Obj-C again. We have stopped writing Unit tests and our Android colleagues are laughing at us.
We hope Apple can tackle this problem so all of us can start enjoying our jobs again.
Let me through my 5 cents in.
Our project is recently moved to Swift 3 entirely. It has containing app and the appex. It links agains several libraries managed by CocoaPods.
The relationships with Xcode 8.2, however, have never been easy...
1. Even after changing one characted, Xcode 8.2 builds more than one object file. The build takes 1+ minute. Every time
2. SourceKit keeps crashing, presumably bumping agains some wrong sintax in the process of wresting the iOS SDK & Swift 3 API. Without SourceKit Xcode becomes Vim, highlighting only symbols it (I think) could resolve via RegExp. It does not suggest the API, of course.
3. Every time it builds Swift libraries, why? Everytime it COPIES those binaries to the device.
4. Every time it copies some stuff to iPhone. Definatelly more than just a binary. In the same time, I am sure, Xcode knows what's alredy installed on the device. So, why waste time copying same files?
Is there a particular toolset you recommend for the VMs?
I use VMware Fusion for running my VMs but that’s more an accident of history than a deliberate choice (back in the day I had some friends working on that team). Unless you have other specific requirements, I suspect that any commercial product that officially supports Mac-on-Mac virtualisation would work fine for tests like this.
Mac-on-Mac virtualisation has worked really well for me. The only gotcha is that you don’t get graphics acceleration. This isn’t an issue for me (I work on low-level stuff, and thus don’t care about graphics) but I could see it being an issue for others.
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
It might be interesting as an expiriment, if you removed from the build one file at a time and see if one file in particular is causing most of the build time. Perhaps, that might give a clue. Do that for release and debug to contrast. I'd suppose whole module optimization etc. would be off in debug. Start each run with a clean work space.
I'd wager the whole module optimization is making all the files one space and then it wants to recompile all the files even if only one file changes? Thus, the gripe. Link time optimization caused issues like this with c. So, there was the partial link time optimization as a work around -- but I'm not sure that option exists for Swift.
Perhaps ( wild guess ) it has something to do with sil? I suppose that is one difference contrasting with c's interaction with llvm? Now there is another step called sil.
Just throwing spaghetti at wall. Maybe something will stick.
Hmm, when I build my workspace with two projects of 91 swift files and 7 Objective-C/C++ files on a mid 2012 MBP with ssd drive, it takes about 2:17 to compile with Xcode 8.2.1. I cleaned before I ran my test. If I build without the clean it takes about 20 seconds with signing taking most of the time.
I do not have find implicit dependencies or parallelize build checked in my schemas. ( mainly because I copy a framework )
All my project files are set to Xcode 8.0 compatible. Deplyment target iOS 10. No enable bitcode and no build active architecture only. Fast whole module optimization is on and legacy swift is off. Not a simulator build.
Hmm, if I generate an ipa archive and rename it to .zip, then you can decompress and get to the bundle. Inside the bundle there is a _CodeSignature folder with a CodeResources file. Its just xml but there is a key for "files". My guess is that would have atleast 450 entries for your pictures. Each item looks like there is a base64 string associated with it. ( I can tell because there is a "=" on the end ... plus its xml ) So maybe there is some over head per file such that it takes 8 minutes generating somekind of signature.
Or perhaps some of those images are big -- like raw? Might just be one of them -- maybe an artist messed up. For kicks, as a test, if you did not include some of them in the project would it speed things up? Or any image file in particular? Having a large number if images should not be out of the ordinary for an app.
It might be interesting if you zipped all those images into one file, then when your app first runs decompress it out into multiple files. Or if they could be downloaded off a server when the app first runs then there would be no code signing for these images -- that might be a more scalable approach and then users could download the app on cell connections.
Random ideas...hope that helps.
I will make some tests with your suggestions, but the "Signing product" time seems not correlated to the number of images.
Just to mention, for a pair of times the compilation time was just 40 seconds or so, without any reason, but in the last 5 compilations, again, 8 minutes and more, just for signing the product.
PS: tried to compile with 10 pictures instead of 450; no differences at all...
When I build my code sign is doing something like:
Signing Identity: "iPhone Developer: XXXXXX (XXXXXX)"
Provisioning Profile: "iOS Team Provisioning Profile: com.XXXXXX.XXXXXX"
/usr/bin/codesign --force --sign ZZZZZZ --entitlements /Users/USER/Library/Developer/Xcode/DerivedData/XXXXX-XXXXX/Build/Intermediates/XXXXX.build/Release-iphoneos/XXXXX.build/XXXXX.app.xcent --timestamp=none /Users/USER/Library/Developer/Xcode/DerivedData/XXXXX-XXXXX/Build/Products/Release-iphoneos/XXXXX.app
So, seems like there are limited options here. But what would bug me is I see timestamp, Intermediates and DerivedData. Maybe something is not being cleaned up from the last sign -- something left in derived data from the last build. In Xcode 8, there was a suspicious change with removing the ability to delete derived data etc. The only influence I can see in this step is cleaning out derived data and or not including files in a project to avoid the sign. But as a user, I should not have to worry about it ... it should just work. I guess it does but takes 8 minutes in your case.