Objective-C - Swift bridging performance for existent codebase

Question

A performance question for developers who have experience with adding swift into existent Objective-C codebase.

My premise is: eventually Bridging-Header.h might become really big (it might end up containing all 1.5k existent Objective-C classes (give or take classes those that won't be accessed from Swift)) and vice versa for PRODUCT-Swift.h generated header.

I fear the compilation performance might decrease dramatically: every time any of the included .h classes has changed it will have to recompile all .swift files.

Is this the case? If so, is there any way to optimise performance?

Clarification: Imagine that you included your entire project classes into .pch file, now every class change will trigger recompilation of the entire project. Is it similar to the way Bridging-Header.h works?

Apparel

Answer 1

If you expect a lot of churn in the header files, I would recommend modules. By splitting your Swift code into modules, each with its own bridging header, you should dramatically reduce the Swift rebuild time. You'll also likely get improvements in Swift rebuild times if it doesn't have to contemplate every internal function across the entire system.

Modules seems to be where Swift wants to go for program organization. I'm not saying they're very strong yet; they still seem pretty messy. But they're likely the best tool for this job. The good news is that you should be able to migrate piecemeal as you encounter problems. You shouldn't have to massively rework your entire project all at once. I definitely wouldn't recommend running out and creating 100 different modules on day one. Look for just a few large ones that might segment your program well.

Riggins