Create a Loading Animation in Swift
Walk on, with hope in your heart
Difficulty: Beginner | Easy | Normal | Challenging
This article has been developed using Xcode 11.4.1, and Swift 5.2.2
Want to display a loading screen that can appear when you’re doing some heavyweight operations? Perhaps you want this with when you are producing your App with a Storyboard, perhaps you want to do this programatically. Either way, this article has you covered.
Oh, and there are versions using
UIView.animate all nestled rather nicely in the attached Repo.
- You will be expected to be aware how to make a Single View Application() in Swift.
- This article uses storyboard constraints and loadview
Storyboard: A visual representation of the User Interface of an Application
This article is about producing a rather wonderful loading screen, with an infinitely scrolling background and a tree moving in parallax.
How is it possible to do this, when using the
The Storyboard version
UIViewController can be created that will have two background images side-by-side.
Now for this to adequately work, the background images must be at least double the width of the devices screen you wish to cover.
Storyboard is created as below with constraints to keep the images horizontally centered in the screen.
The man has a single static image (we will animate walking this in code), as does the tree and both are in static positions on the screen that can be moved later.
Animating the man
viewDidLoad() we can animate the man walking (albeit on the spot), appending images from the asset catalog.
Fading in and out nicely
Storyboard I set the man, the tree and the two backgrounds as invisible — the alpha as
0.0 for each of them.
Then before we animate we have the following code, using
.curveEaseOut to weight the animation towards the beginning of the animation.
with a similar animation to make them fade out just before the screen disappears.
viewWillDisappear is called just before the view disappears from the screen, that is when we press one of the buttons to see the other implementation variants of this code!
Here I am using
CABasicAnimation — the tricky part here is to make sure that the first city
city and the second city
city2 move at the same pace across the screen, here working through the
This animate function is called from
viewDidAppear, a good place to start the animation as the constraints are set (everything is in position) and this is called just before the view is visible to the user.
The programmatic version
ProgrammaticViewController displays the items programmatically, but animating the man is done as before!
**Load the view**
Nothing much to see here, but this is much like my guide to programmatically create a view with loadview.
Adding the objects
I’ve added the objects in
viewWillAppear since the frame of the
UIView is set at this point, but it is before the user will see the screen.
Here is the code:
Called once again from
viewWillAppear however I’ve put a little delay to make this seem like a nicer transition in my
NavigationBar implementation here.
Here I’m using
UIView.animate, and this means the animation is working in just a few lines!
BUT by not using constraints…what happens when we rotate a device? Bad things happen! Of course I could do some various fixes for this, but why not just use constraints?
The programmatic version using constraints
Animating the man is done as before, when we choose to load in views it doesn’t matter if we have
constraints or not.
In fact, all the animation is done in much the same way.
Load the view
Now this is where we are creating the subviews in code. The
constraints here mirror those set up in the
Storyboard version detailed above.
*Interesting* parts here might be considered to be `clipsToBounds` which keeps the
UIImage within the bounds, and of course
translatesAutoresizingMaskIntoConstraints to let the compiler know that we are taking care of the
This article is useful to help you with the difference between
My take on this is that the version using
constraints programatically is not only easier to write, but easier to maintain and change in the future. If you’re not that familiar with walking away from the
storyboard you might enjoy my storyboard technical article.
It is rather complex in the description, but rather easy in the implementation. Take a look at the attached Repo. It is a rather wonderful thing.
If you’ve any questions, comments or suggestions please hit me up on Twitter