Preparing a walkthrough: Freeze effect :s I have a method that load my walkthrough view. I have my view controller composed of a scroll view. And others views controllers used only for the walkthrough (maybe I should used xib uiview instead of uiviewcontroller). And when I'm on the viewWillAppear, I'm calling this method:

/**
Prepare dynamicly the walkthrough views ( app presentation ), like the final content size of `myScrollView, the origin of the views, etc..
So if we want to add another view on our walkthrough, we just add it to `listPages` and on the storyboard.

Copied from an old personal project
*/
func prepareWalkthroughViews() {

    // I use a contentView with the scroll view because of the auto layout.
    var i = CGFloat(self.listPages.count-1)

    // We iterate each view controller. We add the views on the inverse order, like a stack
    for currentController in reverse(self.listPages) {
        contentView.addSubview(currentController.view)
        var currentFrame       = currentController.view.frame
        currentFrame.origin.x  = i-- * currentFrame.width // ex : 6 * 320
        currentController.view.frame = currentFrame
    }

    self.myScrollView.addSubview(self.contentView)
    let scrollWidth  = CGFloat(self.listPages.count) * self.view.frame.width
    let scrollHeight = self.myScrollView.frame.height
    self.myScrollView.contentSize = CGSizeMake(scrollWidth, self.contentView.frame.height)
}


When my segue is performed, there is something like 2-3 seconds of freeze (the time the method is executed).

How can this be improved?

I thought about adding some properties global so I can call the method in background queue when I launch the app, but I think that's not very safe to have a lot of global properties everywhere.
The problem here isn't going to just be that the segue is performed slowly.  At a certain point, if you add enough view controller's views to this scroll view, it's very likely that you'll run into memory issues as well, particularly on mobile devices.

We have a scroll view.  Only one screen's worth of the scroll view can be on the screen at any given time.  But in viewWillAppear, we are attempting to load several screen's worth of views onto our scroll view all at once.  This takes time.  And the more views you are adding to it, the more time it takes.

Consider UITableView and UICollectionView are both direct subclasses of UIScrollview.  How do these guys handle adding views to the scroll view?  They do it one at a time, as needed.

If you put a breakpoint or any sort of print statement in the cellForRowAtIndexPath: (or the collection view equivalent), you'll see that this method is only called for any given cell just as that index path is about to scroll on screen.

Using your approach of adding at the views at the same time means you'll holding them all in memory at once, so there's a top end cap on how many views you can stick on there, and it means you're loading them all at once, so there's a big block of time where it takes to run through adding them to the scroll view.  With a table view or collection view, it's not necessarily any faster to add each individual view to the screen, but only the ones necessary are added at once.  Moreover, as views scroll off the screen, they're released from memory as new ones are added.  So you can have an unlimited number of views on the collection view without running out of memory and without it taking an unmanageably long amount of time to load.

Instead of re-inventing the wheel and try to implement some UIScrollViewDelegate methods by hand to add and remove your views as they're needed, I instead recommend that you change your scroll view to a collection view and work with that.