Are Multiple UI Threads Possible?

>> Each window may be reasonably intensive on a single thread

What does that mean, exactly? If the main thread is busy with UI activity for the window (for example, if you're creating and deleting lots of views in a short time, or if your UI has thousands of views) then you should redesign your app to use a different approach. Or, if the main thread is busy preparing data from display in the windows, then you should start using an async pattern, where you move the data preparation into the background (ideally using dispatch queues or NSOperation queues), presenting it back to the main thread when it's ready.

There's really no good reason (that I can think of) for a well-designed app to keep the main thread very busy.

To answer your specific question, there aren't really any "UI threads". There's the main thread/queue (one only) and background threads/queues (as many as you want). There are some background drawing capabilities, such as:

developer.apple.com/reference/quartzcore/calayer/1410974-drawsasynchronously

but Apple recommends against their use. Another general approach is to use OpenGL to replace a view hierarchy, but the feasibility depends on what you're displaying.

So, more specifics about exactly what I'm looking to do is.

I have a graph/chart heavy application. Those graphs/charts are intensive to render and are animated - hence they load the thread they are running on pretty well.

I need to be able to render multiple sets of charts in different confugrations and ultimately be able to stream it in video form over the internet.

It's almost like effectively running two separte iOS apps simultaneously - and streaming the view of one of them.

The application has been under development for a few years and was not originally designed to render multiple scenes at the same time.

So the simplest approach I can think of, is if it were possible to be able to render each scene on a different thread.

And since these scenes are composed of UIViews, with a mix of autolayout, drawRect, etc. Having another fully functional UI thread would be ideal for minimal refactoring/redesign time.

The UI performance is currently fine when only running a single scene. But at full interaction with animations and all kinds of stuff, the main thread is over 50% utilized - so doubling the load on the same thread (with another scene) results in less than acceptable results.

It's not my area of expertise, but for graphics-intensive rendering, you should probably move into Core Animation (layers and animations) instead of working directly with views. That should allow you do some rendering on background threads.

I was going to suggest Apple's Concurrency Programming Guide but it isn't swift and hasn't been updated in some time, so... (feel free to laugh if you get the hi tech humor)

I understand that UIKit is not designed to be thread safe, and that generally long running tasks need to be offloaded to other threads to avoid blocking the main thread.

I'm just currently making UIKit do a lot of work - animations, autolayout etc. Which cannot be offloaded to another thread - therefore being a prime candidate for the creation of another UI thread and everything that goes along with that.

So what I want is sounding to be unlikely.

I want to be able to duplicate my application into another window and have the second window not interfere with performance of the main window.

Without significant rewriting effort.

Another UI thread working on the separate window would solve my problem immediately and gracefully.

I do appreciate all of the comments though.

So, thank you.