Handling very large numbers of high-speed classes

Question

Targeting iOS 9+, with Swift 3

My application uses hundreds (and potentially thousands) of Swift classes.

Each class is responsible for drawing a certain part of the vector work. Jobs are created in Sketch and exported as a Swift class using the PaintCode plugin. Each class can be quite complex and lengthy, with lots of data. The class file is then loaded into an automatic command-line tool that writes application functionality to the file, allowing art to become interactive and flexible. The resulting Swift file is added to the application Xcode project.

Since Swift does not allow dynamic loading of the Objective-C style / creating classes by name (feel free to fix it), my application adds the processed Swift class to the drawing class lookup table. When an application needs to draw a specific piece of a work, the class lookup table is read, the corresponding class is returned, and then used to draw art.

I am concerned that this approach may not be feasible after the project has reached full production and hundreds or thousands of classes will be created at that point. Possible problems:

• compilation time
• code size
• application load time
• Xcode / SourceKitServer stability / decay

To this end, I would like to get advice on overcoming possible problems before they become traders.

In particular:

Q. What approach should be taken to minimize recompilation? Is it possible to combine class groups together in Framework or other mechanisms?

Q. The same for code size and application loading time. How can I group my code so that I can load class groups on demand more lazily? Will Frameworks help solve these problems?

Any advice or other thoughts that I might have missed are welcome.

[Change - many months and a lot of work later]

For the reasons stated above, I refused to try to use PaintCode or other solutions in the style of art code.

Although these products are ideally suited for a small number of works of art, the system does not scale well for large production and, of course, not for Swift and its state of support in Xcode 8.

Instead, I took a file-based approach where Sketch covers are created and layers are highlighted with drawing information. They are exported as SVG. The engine loads the SVG on demand , analyzes it, and the markup is used to indicate / direct logic and draw the application. Due to the large amount of work, this is unlikely for a small number of works of art - use PaintCode instead, but sometime this makes it possible to have more flexibility and speed, without interruptions in the operation of Xcode and sourcekitservice.

This approach allows you to deal with art assets, as usual: grouped into folders, loaded on demand, cached, freed, etc.

Answer 1

I'm all for quick, but given the limitations you are talking about, objc is probably your tool for this type of task. Alternatively, you can come up with a solution for the scenarios. A few thoughts:

• You have to rasterize your art: why did you encode it? The platform, and each technology that you mention, is an apple technology, so it helps to use its applications as a guide: each application for Apple uses either built-in controls or a huge amount of rasterized graphics. (examples include: Logic Studio, Window Server (Aqua), garage, calendar, etc.), this is due to the fact that the manipulation with the raster image is FAST. Millions of UIBezier in thousands of classes are a thousand times more complicated and can ruin your performance, because all this math would have to be done on the processor, and not on simple gpu raster stretches. Apple discussed this in detail in cocoa sessions.

• Swift runtime is not enough to handle code offloading. You can supposedly call dlopen() fast dylib, and it should work, but it will be completely different than working with real fast classes. Swift has no dynamism to support this. You also cannot call dlclose() . Apple Swift Bug Tracker clearly says dlclose not supported. (In fact, they say that they will not support it!) So, if you really have thousands of huge classes, once they are loaded, you cannot reliably unload them. Fast, so you cannot solve a problem like this.

• If you insist on doing so, you should investigate offloading the work of CGGraphicsContext to other topics right from the start, because you will need to manage quite a lot of the work that needs to happen on the main thread. I doubt that the paint code emits the correct code to handle this case.