Welcome the third and final part of our Animation series. In this story, we will discuss how to implement the animation when transiting between view controllers.

You can also find parts one and two here:

• Getting Start with iOS Animation (part 1)
• Getting Start With iOS Animation (Part 2)

Note: I recommend starting where we left at the last part, so you can download the project here. Otherwise, you can still follow this tutorial by creating two view controllers.

At this point, we have LoginViewController and GiftViewController:

The animation on the screen is great, but the transition between theses two views seems ordinary, so we will improve it by implementing some juicy animation. Here’s the final expected result:

Actually, we will go the extra mile by adding a controllable dismiss transition, which means by swiping from the left edge of the screen, the animation can move forward and backward a finger drag:

You may see the code seems intimidating at first, but actually the principle is simple. The transition animation can be done by creating a class conform with UIViewControllerAnimatedTransitioning. Then, we inject it in the UIViewControllerTransitioningDelegate of a view controller.

Tip: Animation parameters were found through trial and error. We often need to monitor closely each move we make, so we need to make that move slower. The simulator provides a great function for slow motion: go to Debug and select Slow Animations.

Present transition animation

We begin with the Present transition. Here are the animation steps:

• Rotating the “Open” button 90 degrees along the y-axis clockwise.
• Display the gift snapshot view at the place and with the size of “Open” button, but the initial place is 90 degrees anti-clockwise on the y-axis. It’s because it helps the button rotating looks continuous.
• Then we rotate it along y-axis clockwise 90 degrees.
• Zoom the gift view out to fill the screen.

Here’s the code:

The most important part is taking a snapshot of the destination view:

let snapshot = toVC.view.snapshotView(afterScreenUpdates: true)

And here the code of each step:

Rotating the “open” button 90 degrees along the y-axis clockwise:

UIView.addKeyframe(withRelativeStartTime: 0.0, relativeDuration: 1/4) {
     fromVC.loginButton.layer.transform = CATransform3DMakeRotation(CGFloat(-Double.pi / 2), 0.0, 1.0, 0.0)
}

By using UIView.addKeyframe, we can specify the animation’s duration of each step relative to the whole animation’s duration. Here we want the rotation time of the “Open” button take a quarter of the whole duration.

Rotating the Snapshot destination view 90 degrees:

But first, we must initialize it at 90 degrees anti-clockwise on the y-axis. We do this before the whole animation.

snapshot.layer.transform = CATransform3DMakeRotation(CGFloat(Double.pi / 2), 0.0, 1.0, 0.0)

And then rotate it after rotating the “Open” button:

UIView.addKeyframe(withRelativeStartTime: 1/4, relativeDuration: 1/4) {
     snapshot.layer.transform = CATransform3DMakeRotation(0.0, 0.0, 1.0, 0.0)
}

On the final step, we zoom out the snapshot to match the final destination view:

UIView.addKeyframe(withRelativeStartTime: 2/4, relativeDuration: 1/2) {
     snapshot.frame = finalFrame
}

At the completion of this whole animation, we do the cleanup:

• Display the destination view,
• Remove the snapshot, and
• Reset the “Open” button position.

And the present animation was born. Now, all we have to do is to wire it to our view controllers. So when the app prepares the segue, we must specify that we want to use our custom transition (by specifying transitioningDelegate) instead of the default one:

And then feed our animation instance in the right delegate function:

And it’s done. Run the app and enjoy the first animation.

Dismiss transition animation

Since we successfully created the present transition, we will just do the same thing to dismiss one.

Here’s the code for dismissing animation:

Just ignore SwipeInteractiveTransition for now. We talk about it later.

Here we’ll find the same pattern of code that we wrote in Present animation, just notice that .to and .from view controller was inverse.

We will create the dismiss view in three steps:

Zoom out the current view to the size of the destination button:

UIView.addKeyframe(withRelativeStartTime: 0.0, relativeDuration: 1/2) {
     snapshot.frame = self.destinationFrame
}

Rotate it 90 degrees on the y-axis: We also rotate the “Open” button by 90 degrees so at this moment we won’t see the “Open” text:

UIView.addKeyframe(withRelativeStartTime: 1/2, relativeDuration: 1/4) {
     snapshot.layer.transform = CATransform3DMakeRotation(CGFloat(Double.pi/2), 0.0, 1.0, 0.0)
     toVC.loginButton.layer.transform = CATransform3DMakeRotation(CGFloat(Double.pi/2), 0.0, 1.0, 0.0)
}

Finally, rotate the “Open” button back to the right position:

UIView.addKeyframe(withRelativeStartTime: 3/4, relativeDuration: 1/4) {
     toVC.loginButton.layer.transform = CATransform3DIdentity
}

Now that we have the animation created, we just need to wire it in the UIViewControllerTransitioningDelegate:

func animationController(forDismissed dismissed: UIViewController) -> UIViewControllerAnimatedTransitioning? {
     return DismissViewControllerAnimation(destinationFrame: loginButton.frame)
}

Cool, now we finished all the animations. Run the app and enjoy the magic!

Control the animation

iOS makes it really easy to give user interaction with the animation. And it works the same way as we did with these two animations. First, we create a subclass of UIPercentDrivenInteractiveTransition and then inject it in the function interactionControllerForDismissal of our UIViewControllerTransitioningDelegate . The class UIPercentDrivenInteractiveTransition provides three functions:

• update(): Tells us how much of the transition was complete. 0.0 is the beginning of transition and 1.0 is the end of the transition.
• cancel(): Cancel the transition. In our case, it will cancel the dismiss process.
• finish(): Finish the transition. In our case, it will dismiss the Gift view and show the Login view.

We usually use this interactive transition combined with gesture recognizer, since it gives user the ability to control the transition. Here’s the code of this subclass:

We will addUIScreenEdgePanGestureRecognizer to the gift view. This recognizer can detect a dragging from the edge of the screen. Then, based on how much the user is dragging, we use update to control the transition. When the gesture ends, we check if the progress is more than half, then we go forward and finish the dismissal; otherwise, we cancel it.

We can instantiate this controller in GiftViewController:

private(set) var swipeTransition: SwipeInteractiveTransition?

override func viewDidLoad() {
     super.viewDidLoad()
     setupUI()
     swipeTransition = SwipeInteractiveTransition(viewController: self)
}

And then inject it in a function of UIViewControllerTransitioningDelegate. Here’s the final version of this delegate:

Awesome! We finished it. Now it’s time to admire our stunning transition animation!

Where to Go From Here

You can download the final project here.

In this tutorial, we learned:

• How to implement an animated transition between the view controller
• How to give user control on this animation

I hope you like this story. If you want to know more about animation, you can check my two first stories.

The first part is about animating views:

Getting Start with iOS Animation (part 1)

The second part is about animating a sequence of image (a movie-like animation):

Getting Start With iOS Animation (Part 2)

Getting Started With iOS Animation (Part 3) was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to create movie-like animations

In the first part of this series, we learned how to implement UIView animation. In this part, we’ll see how to create an animation from an image’s sequence in iOS.

We’ll begin with animating a loading-circle sequence’s images using only UIKit build-in functions. Next, we’ll see how to implement the Lottie library to make this same kind of animation (the singing bird) but much more elegantly and easily — while also providing for better performance. Finally, we’ll do a comparison of the various methods and tools that can produce this same kind of animation.

So here’s the desired result we should have at the end of this tutorial:

This tutorial is developing from the previous tutorial. You can download that project here. But you can follow along with this tutorial even if you’re starting from scratch with a project. Just keep in mind this story is on a separate view controller and has has a function, Go Back, enabling one to dismiss and go back to previous (first) view controller.

Set Up the View

Now we have to set up the initial view components:

As you may have noticed, we inserted a UIImageView into the center of the view and added a back button at the top left. Now we don’t have much to see here since we only have a back button to go back to the previous page. In viewDidAppear, we call the animateSequenceImages function, but right now it’s empty.

Animating an Image Sequence Using UIKit

Firstly, we’ll create the loading animation. So we should have an image’s sequence as assets provided to this animation. We need to create a reference folder of images, like this, in Xcode:

You can download the project via the link at the end of this story. Or you can download a GIF file you found on Google and split it into an image sequence. If you do so, I suggest using ezgif to split that GIF file.

Cool! We had the assets — now animate it:

It’s pretty straightforward:

1. Feed the UIImageView with all of the UIImage assets through the animationImages variable.
2. Assign the animation duration (animationDuration = 5).
3. We don’t repeat the animation (animationRepeatCount = 0).
4. Finally, start the animation (sequenceImageView.startAnimating()).

Actually, we’d like to fade out this loading view while it’s animating — that’s why we make the animating duration five seconds — but we fade it out after just two seconds.

Here’s the result so far:

Animating With Lottie

Lottie is an open-source framework originally created by Airbnb:

“Lottie is an iOS, Android, and React Native library that renders After Effects animations in real time, allowing apps to use animations as easily as they use static images.” — Lottie’s official site

Firstly, we need to install lottie-ios in our project. Lottie supports CocoaPods, Carthage, and Swift Package Manager. You can consult the details in their GitHub repo.

Secondly, we need to find the asset for Lottie. LottieFiles is a great resources to search for animating assets. Download any free JSON you found here, and name it bird.json. Drag and drop this file into your current project. An animating JSON file for Lottie is like a PNG for a UIImageView.

Then, we set up the Lottie view (AnimationView) in our view controller. Actually, using AnimationView is very similar to an ordinary UIImageView. We declare the variable:

private var giftView: AnimationView!

Now we can initialize this view in the setupUI() function:

giftView = AnimationView(name: "bird")
giftView.frame = self.view.frame
giftView.contentMode = .scaleAspectFit
giftView.alpha = 0
giftView.loopMode = .autoReverse
view.addSubview(giftView)

AnimationView(name: “bird”) is to tell the Lottie framework to look for the file bird.json in the main bundle. We can notice that besides loopMode, everything else is exactly similar to an UIImageView. loopMode tells us that the animation will be played forward and backward until stopped.

Now we want to trigger the singing-bird animation when the loading fades out. We’ll call animateGift() at the completion of animateSequenceImages()in viewDidAppear:

animateSequenceImages {
    self.animateGift()
}

Inside animateGift() , we fade in the AnimationView:

The play() function starts the animation of AnimationView. Here’s our final result:

Comparing Different Forms of Animation

Actually, there’s many ways to embed a movielike animation like this into a view controller.

Besides Lottie and the image-sequence method we just did, we can also use a GIF, a video, or even code it using a Bézier path and/or a combination of UIView’s animation functions. There are many reasons why designers and developers are starting to prefer Lottie animations over other formats. Let’s compare Lottie to the other options you have.

PNG-sequence image

One of the biggest drawbacks of PNG-sequence graphics is they’re rather large in size, which can make them something of a hassle to export and manipulate on different interfaces for designers.

Lottie files, in comparison, are extremely small and conveniently sized, consequently having a quick download speed and keeping your site or app operations as smooth as possible.

GIF

While smaller than PNG graphics, GIFs are still a pretty space-occupying format, being in average double in size than a simple Lottie animation.

GIFs are also typically scaled at a fixed size. This means you can’t modify them to better fit to scale on a different interface than where they were originally created. Lottie animations give you the space you need to adjust them to large-scale solutions as well as to smaller-scale screens.

Video

Regarding a simple and short animation, video content comes up quite often. For video content, particularly live-action stuff, you need to arrange for a host of resources, including props, actors, and locations. Animations are relatively simpler and cheaper alternatives that still get the job done.

In term of coding, handling a video is much more of a hassle than an AnimationView (which is as simple as a UIImageView). Not to mention: A good animation keeps your visitor engaged and doesn’t compel them to turn it off.

Code animation

App-development teams want to streamline the development process and make it as cost- or resource-effective as possible.

Writing animation in code can be a time- and skill-intensive process, not to mention how easy it is to encounter a host of problems while writing the code. Instead of dedicating valued resources to either outsourcing the project or hiring skilled staff, why not use an alternative animation tool in the form of Lottie that is intuitive, scalable, and compatible with multiple platforms?

Where to Go From Here

You can download the project here.

In this article, we learned how to create movielike animation by using PNG-sequence images and Lottie. We also discovered a great resources for Lottie animations: LottieFiles. And we saw why Lottie outperforms all of the other animation forms when it comes to short animations.

We finished the second part of the series. In the next part, we’ll see how to animate the transition between view controllers. Here’s the final result of our three-part series:

Getting Started With iOS Animation (Part 2) was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Animation is essential to make our apps enjoyable and professional. Users tend to trust and engage more with your app if they feel that the developer has invested effort and been meticulous in making the app more user friendly.

In this three-part series, we will see a complete stack of animations we can do in iOS:

• View animation. In this first article, we’ll create a view and make the view’s component move in and around.
• Movie-like animation. In this article, we will learn how to implement the Lottie framework and image sequence. At the end, we will compare video, GIF, image sequence, coding animation, and the Lottie framework.
• Transition animation. In this article, we will touch the final and the most complicated part of iOS animation: view controller transition animation.

Prerequisite: The reader should know how to create view components like UIView, UIButton, and UIImageView.

During this first part, we will see how to implement all recommended ways of making a view component animated. Furthermore, we analyze the limit and use cases of each method.

Since one animated image is worth a thousand words, here’s the final result (actually we will add some more user’s interactive animation as a bonus):

Setup for This Tutorial

Before diving into the animations, we must initialize some view components and add them to the main view. This is the beginning point of all our animations. Please add this code in your initial view controller:

Basically, what we are doing here is inserting the app logo image and open button (hidden) in the centre of the view. We also added a car ImageView at the footer of our screen. Here’s what’s we have now:

Before diving into the animation code, it’s worth mentioning that creating an animation needs a lot of trial and error. We need to test many times to find out the perfect duration, frame timing, position, and other parameter values. To facilitate the test, we should use the slow-motion tool of the simulator (Simulator -> Debug -> Slow Animations) to monitor the animation.

Simplest Form of View Animation: UIView.animated function

The easiest way to animate a view is by using UIView.animated function. Here we want to do two things: move the app logo “Animation” to the top and fade in the Open button.

Add this function to your current code:

As you may see, this function is quite simple. It contains three inputs:

• withDuration: Specifies the duration of the animation. Here we want to move the logo in one second.
• animations: Describes the final state of this animation. Here we specify the final position (frame) of our logo image view. The function itself will interpolate the origin frame value and destination frame value to animate the action.
• completion (optional): This is a completion handler that informs us of whether the animation sequence was finished or not. Here we make it our own completion.

Now we execute this function in viewDidAppear. Plus, when the animated logo finishes, we also use the UIView.animate function to fade in the Open button:

Now run our app. We should see this:

This function is able to work with frame, bound, centre, transform, alpha, and background colour of a view.

UIView’s animation function has some variants that allow specifying more animation properties, like damping, animation options (easy in, easy out, etc.), delay, and so on. We recommend you read Apple’s documentation to learn more details.

Animating Layer Property: CABasicAnimation

CABasicAnimation is an object that provides basic, single-keyframe animation capabilities for a layer property. You create an instance of CABasicAnimation using the inherited init(keyPath:) method, specifying the key path of the property to be animated in the render. Like the UIView.animated function, by specifying fromValue and toValue, Core Animation will interpolate the transition values and make the animation. You can consult the full list of key paths in the Core Animation Programming Guide, Appendix B and Appendix C.

We’ll use CABasicAnimation to animate drawing the line around the Open button. To do this, we use four steps:

1. Create the Bezier path for that line.
2. Inject that path into aCAShapeLayer.
3. Create CABasicAnimation object by specifying our animation parameters.
4. Execute this CABasicAnimation on our CAShapeLayer by using CATransaction.

Here’s the code:

The code looks intimidating, but actually most of it is for specifying our animation parameters like duration, start position, end position, timing easyInEasyOut, etc., and those values are found through trial and error.

We execute this function by replacing the completion of animateLogo with our function self.animateLoginButton(). We receive the result below (please ignore the car moving; we’ll do it later):

Based on what we just learned here, we can easily create a “shaking” animation based on a user’s touch. Basically, when the user touches the Animation logo, we want the logo to be shaken. As you may already have figured out, that animation will be a position type (go to left and to right), autoreverse, and loop about four or five times. The code should look like this:

To wire the tap event to this function, we can register a gesture recognizer to the logo image view in setupUI function:

logoImageView.isUserInteractionEnabled = true
logoImageView.addGestureRecognizer(UITapGestureRecognizer(target: self, action: #selector(shakeLogo)))

Run the code, here’s the result when you tap on the logo image:

Animating With User’s Interaction

The most convenient way to interact with a view’s animation is to use UIViewPropertyAnimator. From Apple’s documentation:

“A UIViewPropertyAnimator object lets you animate changes to views and dynamically modify your animations before they finish. With a property animator, you can run your animations from start to finish normally or you can turn them into interactive animations and control the timing yourself. The animator operates on animatable properties of views, such as the frame, center, alpha, and transform properties, creating the needed animations from the blocks you provide.”

Actually, UIViewPropertyAnimator is relatively similar to the UIView.animated function. When we create this object, we must specify a block containing code that modifies the properties of one or multiple views, the timing curve, the duration, and a completion block to execute when animations finish.

We will apply this object to make the car’s animation. We would like to make it move to the right, then back to the left, infinitely. Plus, we need to catch the user’s tap gesture and then make the car move back. So basically we need three functions. One function runs when the user taps on the car, one makes the car run to the right, and a final one makes it move to the left:

Now we wire these functions to our view in viewDidAppear and add self.animateCarToRight(). In setupUI(), add the following:

carImageView.isUserInteractionEnabled = true
carImageView.addGestureRecognizer(UITapGestureRecognizer(target: self, action: #selector(userTapOnCar)))

Run the app, and try tapping on the car to see it if it pulls back. Here’s the result:

Where to Go From Here

You can download the code of this tutorial.

In this article, we learned how to animate a UIView using the UIView.animated function. We also saw how Core Animation can help us to draw layer animation using a Bezier path and CABasicAnimation. And finally, we figured out how to enable a user’s interaction with the animation.

We are now experts in animating the view’s components. In the next article, we aim to animate a sequence of images (movie-like animation), and in the final article, we’ll animate transitions between view controllers.

Here’s what we’ll have after the second part:

And in the final part, we animate the present transition and the dismiss transition. We also learn how to programmatically control the progress of this animation.

I hope you enjoyed this tutorial. See you again soon in the next part.

How to Get Started With iOS Animation (Part 1) was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sometimes we need to debugging a new iOS version on an older Xcode. This is usually needed due to various reasons like testing on iOS Beta, be constrained updating to new Xcode and more. So in this story, we will see how to run a simulator and devices that have iOS version higher than the version Xcode supported.

A common step in setting up for both Simulator and Device is downloading and installing the target Xcode. For example if you want to run iOS 13.4, you need to have Xcode 11.4 or later on your Mac in addition of your current Xcode. Your application folder now must have at least two Xcode versions:

Setup for debugging on newer iOS Simulators

Firstly, switch Xcode’s command-line to target version, in this example, we set it to Xcode 11.4. There are two ways doing that:

1. Using command line in Terminal:

sudo xcode-select --switch /Applications/Xcode11.4.app/Contents/Developer

or

2. On the Xcode you want to run, go to Xcode -> Preferences -> open Locations tab -> change Command Line Tools to target Xcode (11.4)

Next step, you need to show the list of available simulators. Run this command in your Terminal:

xcrun simctl list

Now you will see something similar to this:

Since all the iOS 13.4 simulators are shutdown, you have to turn on the target simulator by using this command:

xcrun simctl boot DEVICE_ID

In effect, I will turn on the iPhone 11:

xcrun simctl boot 39E956F8-0495-4760-A23E-88DB7887635A

Finally, open your current Xcode, you’ll see the simulators you just turn on are ready to use:

To resume, here’s the steps:

1. Switch Xcode’s command-line
2. Find and Boot the target simulator
3. Now the target simulator will be available in all your old Xcode

Setup for debugging on newer iOS Devices

When you tried running old Xcode on your recent iOS iPhone, you are most likely encounter an error similar to this:

The iOS deployment target ‘IPHONEOS_DEPLOYMENT_TARGET’ is set to 13.4, but the range of supported deployment target versions is 10.0 to 13.0.

The reason is your current Xcode 11.1 do not have support files for iOS 13.4. So to fix this, we just need to redirect Xcode 11.1’s device support path to the right one in Xcode 11.4. Using this command line does so:

sudo ln -s /Applications/Xcode11.4.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/13.4 /Applications/Xcode11.1.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport

Check the folder at /Applications/Xcode11.1.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport, you’ll see the symbolic link was created:

Now open your old Xcode and run debugging again on your iPhone/iPad, it just works :]

How to Debug on Recent iOS Simulators and Devices Using Old Xcode? was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

As you may already noticed, Xcode takes a lot of space on your hard drive. From time to time you could see warnings about low storage. Recently I had this problem and my first reflex is finding a script or an app to “clean” my Mac. It helps a bit but not much, since theses apps can only give you “safe” cleaning, typically removing caches data. They don’t “dare” to touch user’s data. After doing some research, I find out 50 Gb to delete from my Xcode related data, and I would like to share with you theses tips. Theses actions are safe because you know what you do.

Xcode Caches

It’s safe to delete the folder com.apple.dt.Xcode because Xcode can recreate its caches (it could take some time at first relaunch, if Xcode need to re-download something).

The location of this folder is at ~/Library/Caches/com.apple.dt.Xcode

Derived Data

Contents of Derived Data folder is generated while Xcode builds your project, so it’s safe to empty it.

The location of this folder is at ~/Library/Developer/Xcode/DerivedData

Xcode Archives

Archives could take a lot of spaces. Since you always generate an archive for every release, over time it can cumulate to a big mountain. You can delete them by going to Organizer -> Archives tab -> right-click on the archive you want to delete -> Open in Finder -> remove the .xcarchive file

The location of this folder is at ~/Library/Developer/Xcode/Archives

Xcode Device Support

Remove the unneeded iOS’s version support from Xcode can save big space for your Mac (for example, the Device Support folder for iOS 13.1 takes about 3 Gb). This folder is basically needed only to symbolicate crash logs. If your work requires you to support iOS 11 and later, you can safely remove support folder for iOS 10.x and earlier.

The location of this folder are at ~/Library/Developer/Xcode/iOS DeviceSupport/

Simulator Data

Simulator’s user data can consume a lot of space. When you want to empty user’s data from a simulator, the official way is to use “Reset Content and Settings” option in Setting app on Simulator. But if you get tired of doing it one by one, you can empty the folder ~/Library/Developer/CoreSimulator Another handy command line xcrun simctl delete unavailable to delete unavailable simulator.

Additional Simulators

Sometimes you need to download additional simulator of older iOS versions to test your apps. But when you no longer need those simulators, it’s good idea to get rid of them. A simulator takes approximately same size as the iOS.

The location of this folder are at /Library/Developer/CoreSimulator/Profiles/Runtimes (be careful, the path is /Library, not ~/Library)

I hope theses tips help you to get some extra storage for your Mac. All the tips mentioned in this story are safe, because even you accidentally deleted something you still need, you can be able to regenerate or re-download it. Enjoy cleaning!

Clean your Mac for Xcode’s Users was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

In iOS 13, Apple made a big changes in location permission’s behaviour, especially for “Always Allow” permission. As I have been working full time on a location tracking app since 3 years, I encountered a big challenge and learned a lot from it when supporting iOS 13. In this story, I would like to share my experience when dealing with “Always Allow” request, and how iOS 13.4 brought a big improvement for user experience (though it looks like a workaround) to this request.

Note: I assume that audience knows implementing CoreLocation’s permission and functionality. In this story, I discuss only behaviour aspect, this is not a coding tutorial.

Summary of permission’s behaviour

In the code, developers can request two types of permission: “When in use” (requestWhenInUseAuthorization) and “Always Allow” (requestAlwaysAuthorization). In iOS 13, whichever option we use, we get this system popup:

This popup uses NSLocationWhenInUseUsageDescription string in the message. As you can see, even you request for “Always Allow”, this option is not available to choose anymore.

If user selects “Don’t Allow”, in the app and in the iOS Setting, we get .denied permission. This is a straightforward case to handle.

If user selects “Allow Once”, in the app we received .authorizedWhenInUse permission, and “Ask next time” in the iOS Setting. This option is new in iOS 13, and it replace the “Always Allow” option. If user selects this option, when restarting the app, both in app’s and iOS Setting’s permission status change back to .notDeterminated so we can request again the location permission.

If user selects “Allow While Using App”, well, this is the confusing part since the behaviour is different between requesting “When in Use” and “Always Allow”, and between iOS versions.

In case app requests “When in Use”, this choice “Allow While Using App” gives both app and system setting the .authorizedWhenInUse permission. It’s good since app get what it’s supposed to get.

In case app requests “Always Allow”, this choice “Allow While Using App” gives app .authorizedAlways and system setting .authorizedWhenInUse.

You may ask “Why are they different? Is it a bug?”. Well, you’re not alone. This is what Apple called deferred permission, or provisional permission. Whatever we call it, it means the real “Always Allow” permission will be shown later, at the time decided by iOS system.

In real life, user can expect to see the popup below a few days later:

Actually, this is the real popup for “Always Allow”, which uses your NSLocationAlwaysAndWhenInUseUsageDescription string as message. If user selects “Change to Only While Using”, both app and setting get the permission .authorizedWhenInUse. Otherwise, if user selects “Always Allow”, then both app and setting now get the “true” .authorizedAlways.

This new behaviour in iOS 13 imply frustration for tracking app’s designers. Since app get the “pretended” Always Allow permission at the beginning, user may accidentally “Change to Only While Using” on second confirmation, and disrupt app’s functionality. Many companies had to design a force setting permission screen in their apps to redirect user to location permission in iOS Setting and let users manually choose the correct one.

Improvement for iOS 13.4

Since iOS 13.4, it seems like Apple realized that it need some user experience improvement. So, as I mentioned at the beginning, they decided to allow developer to show the second popup immediately. But it doesn’t come with a straightforward implementation. As stated in requestAlwaysAuthorization documentation in Xcode 11.4:

An application which currently has “when-in-use” authorization and has never before requested “always” authorization may use this method to request “always” authorization one time only

In fact, this means, for a fresh user (never gives any location permission before in app), we must show firstly a “When in Use” request. If user gives “When in Use” permission, then we make the “Always Allow” request to pop the second one. You can inspire from the code below:

Simple, right? In iOS 13.4, we can just setup a closure, so when user answer the first popup, we can detect if they give the “right” choice and if so, show the “Always Allow” request.

Using this code, we will get the desired result:

Where to go from here?

If you want to understand deeper in Core Location changes in iOS 13, I suggest the excellent presentation from WWDC 2019: What’s New in Core Location

Location Permission in iOS 13 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tutorial on how to implement Fastlane to automated your mobile development tasks

In previous parts of this tutorial, we talked about how automation is powerful, even essential to our daily work:

Why does CI/CD automation become essential in mobile development?

In part 1 of “CI/CD automation for mobile development from scratch”, we talked about setting up Bitrise, connect it with your repo, and create a workflow to detect and test all our pull requests:

CI/CD automation for mobile development from scratch (part 1)

We also mentioned using Fastlane will level up our ability. Since you are here reading this, we assume that this automation tool interest you :].

Fastlane is an amazing tools to make your CI/CD workflow truly versatile and powerful. It provides a rich set of preset actions for boring mobile tasks, so you don’t have to manually do it. It is also easy to integrate many Ruby gems or other scripts with Fastlane to handle specific tasks.

In this tutorial, we would like to show how Fastlane support local process as well as integrate with existing cloud CI/CD. We will write a simple flow that help downloading dSYM zip file from iOS App Store Connect and uploading it to Firebase Crashlytics. Crash Analytic tool like Crashlytics is important to monitor our app’s stability. Since dSYM is essential data in order to make Crash Analytics tools works properly, this workflow is a typical step in the release process. Finally, we will talk about some inspiring automated tasks that you could begin with.

Prerequisites: I assume that Fastlane was setup correctly on your local. If not, follow Fastlane setup guide for iOS

Create the lane

First step: now we open our Fastfile with a text editor, or Xcode. We prepare a lane like this:

• desc: description of the lane.
• lane: similar to a function, it goes with lane name upload_dsym_appstore and options (input parameter list)
• UI.message: to print out the text to terminal console
• end: end of the lane

Now we can open the Terminal and run the command line:

fastlane upload_dsym_appstore

We must see the output text ‘Hello World’. It seems nothing for now, but this is the most important milestone in implementing Fastlane. It proves that we actually make it worked, like we made in our first iOS apps with a label ‘Hello World’ in a white background ;]

Second step: Fastlane provides many preset actions. At this step, we will implement preset action to download dSYM: download_dsyms. Search this action in that preset list and click on the action to get this download_dsyms action’s documentation. Replace UI.message with the download_dsyms.

username: your App Store Connect’s email account

app_identifier: the bundle ID of target app

team_id: I have hard time figure out this magic ID since it is not the team ID we can find on Apple Developer website. To get this, we have to log in our team’s account on appstoreconnect. Then open this website: https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/user/detail

It gives us a JSON. Now look through associatedAccounts array to find contentProviderId that match our team’s name.

version: specify the app’s version we want to download dSYM. Use “latest” if we want to download the most recent app’s version dSYM.

Run this code and we can expected to see a .zip file that contains our app’s dSYM

Third step: now just upload them all to Firebase Crashlytics. Go back to that action list again, and search for action upload_symbols_to_crashlytics. Now the code looks like this:

Here we list all the zip file and loop through them. The action upload_symbols_to_crashlytics requires only the file path and the Crashlytics token. This action uses upload-symbols script in Crashlytics framework to upload dSYM, so we need to had Crashlytics installed by Cocoapods.

The last line clean_build_artifacts is to clean all files, including the zip file.

Run the code and enjoy seeing the lane doing all the hard work for us.

Integrate with cloud CI/CD

Now we have a working lane, that works perfectly on our local. All we need to do is to execute the command fastlane upload_dsym_appstore in Terminal. As an excellent developer, you could ask: Could we even be lazier? What about make it completely automatic, so we don’t even have to think about it?

If you read the part 1 of this series, you know that it’s feasible and you may even have a clear idea how to do that. If you didn’t read it, just take a look on the details how to implement cloud CI/CD quickly and come back here later. Here we can go straight the to the final result, which looks like this on Bitrise:

The flow is very intuitive and minimalism:

1. Clone the repo
2. Run pod install: this step is needed because we need to set up crashlytics framework and have upload-symbols script available
3. Add step fastlane here and make it run the lane we just create: fastlane upload_dsym_appstore
4. (Optional) Slack to our team channel to get confirmation.

Now we have two ways to automatically trigger it:

1. If we have a release workflow already, which send builds to App Store, it makes sense to add this workflow at the end of the release one. The inconvenient side effect of this solution is that sometime App Store take many hours to processing a build, so it will makes our workflow stuck there doing nothing for a long time.
2. Or we can schedule to upload dSYM on a specified schedule, for example every midnight. The inconvenience of this solution is that most of our trigger is for nothing because we only need to upload dSYM once for a new build. But well, it doesn’t harm anything since it runs during the night, where our work traffic is light.

Release flows

Uploading dSYM is a typical flow followed the release workflow. Fastlane makes it feasible to integrate it with your current release process and make it automatic. You can find below a popular release flow used in some companies and some hints on how realizing it with Fastlane.

1. Create release branch base on your development branch: in Fastfile, using sh command to run shell command. We use shell command to interact with git functions. Example: sh(“git pull”, log: false) will pull all remote changes from your current branch.
2. Execute release_build workflow on Bitrise thanks to sh “curl …”. Use this Bitrise’s API documentation
3. That release_build workflow run the lane release_app_store on Fastfile. This lane will archive, sign the build, update certificates and provisionning profile if needed, then finally send the build to App Store. All these functions can be found in Fastlane’s documentation
4. Bump current app’s minor version on a branch from development branch thanks to a Cocoapods’s Ruby public library Xcodeproj. Push it.
5. Create a pull request to merge this bumping branch to development branch. Here’s Bitbucket API’s documentation
6. Waiting for App Store build processing finished and upload dSYM.

Where to go from here?

As an iOS Engineer, I have fun time learn and implement our CI/CD tools. You may enjoy it too.

Every team has different needs and capacity. Before implementing the workflows, we should discuss with our team to figure out our development strategy, our release strategy, and our special business needs.

Here a non-exhaustive list of flows that you can inspire your team:

1. Merge check: run unit tests to validate all the branch-to-merge. This lane is the simplest automated task to implement, but it gives big improvement on development’s quality since it gives early warnings of bugs or compilation failed.
2. Deploy debug builds: could be run at the merge, or schedule to run a few times a day. This lane archive and send builds to a Beta distribution services, like Firebase App Distribution. This lane automatically gives QA access to the most recent code changes.
3. Release builds: typically run when release branch create, or have new pushes. This lane archives, tests and sends build to App Store, waiting to release. This flow can end up with the workflow of uploading dSYM on iOS side.
4. Testing lane: typically run during the night. This run through all your unit tests, UI tests, performance tests. Depending on the size of your tests, it could takes hours to finished them, that’s why it’s recommended to schedule to run it during night.
5. Sync app’s text: typically run during the night. This lane download all copy-related Confluence page, or Excel files, parse them and generate updated .strings file for our apps. Finally, it create a pull request. So next morning, we can just check and merge this branch to have synced strings. This flow is very efficient if you have a separated marketing/writer/services team working on texts.

After years of developing automation tasks, my team had a rich set of automatic flows, which allowed us to truly focus on what we love to do: developing mobile apps. By investing some time on this, you could also save a lot of time to work on something you love: developing mobile apps. Let the robot handle the boring tasks!

CI/CD automation for mobile development from scratch (part 2) was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tutorial on how to implement a Bitrise pipeline in less than one hour

This story guide you to implement the CI/CD cloud service in less than one hour. CI/CD is one of the best practices for mobile development teams to implement:

Why does CI/CD automation become essential in mobile development?

It is also an agile methodology best practice, as it enables mobile development team to focus on meeting business requirements, code quality, and security because other tasks are automated.

In this tutorial, I would like to introduce Bitrise. Bitrise is a leading CI/CD cloud platform for mobile. The setup of workflows using in this platform is easy and intuitive. As a mobile developer, we can setup some basic workflows in just a few hours. In this story, you will be presented how to setup a typical workflow: merge check for a Pull Request. The main objective of this workflow is to validate the pull request created by a developer in our team, before merging it in development branch. This example workflow will run all tests (UI tests, unit tests, …) enabled in the project’s test target.

Prerequisites: in this tutorial, I assume that you already had a Bitrise’s account and was given all necessary permissions to create and modify a Bitrise’s app. If you don’t have an account, you can create one for free. A Bitrise’s app can be quickly created from Dashboard -> Add new app -> then follow the guide to connect your repo to the app. Though this tutorial’s objective is to merge check an iOS build, it’s still relevant for Android developers to look at and learn the set up process.

Setup Bitrise app

To create this merge-check workflow, firstly go to the app dashboard, then click on workflow tab to open Workflow manager.

You will see workflow manager displayed like below:

On the first row, it displays all configurations needed for an iOS build:

1. Workflows: this is where we can see and manage all workflows. On the second line, there are options we can use to switch, create, add existing, and rearrange workflows. When we created this app, by default, Bitrise provide us a “primary” workflow, which is used to archive iOS apps. Now, click on “+ Workflow” and give it a name (in this tutorial I will use “DemoWorkflow”) by cloning the “primary”. We now have our first baby workflow. For the sake of our tutorial, we remove all preset steps, so we can created them from scratch.
2. Code Signing: this is where we can safely keep certificates and provisioning profiles. At the top of this tab, we will see the guide about using a script to export our local certificates and provisioning profiles on Bitrise. In this tutorial, we don’t need to setup them, since the tests will run only on simulator. Later, when we need to archive the build to export it to Beta tools or App Store, we definitely need to setup this.
3. Secrets and Env Vars: basically theses are stored parameters we need to use in the workflows. “Secrets”, well, mean confidential ones. Parameters saved here will be encrypted and will never be exposed in the logs. Info stored will be displayed as ***** in this section and in the logs. This is typical place to save passwords, token…etc. On the other hand, “Env Vars”, stored regular variables. This is where our stored parameters like: scheme name, project path, app version, …etc. Info stored here are exposed to all of our team members.
4. Triggers: this is where we create rules on how to trigger a workflow. Bitrise provide 3 ways of triggering: Pull request, Push and Tagging. In this tutorial, we want to tests a pull request, so check the Pull Request tab, click on “+ Add Trigger” and fill the source, destination and workflow, we will get something like this:

This config mean when there’s a pull request from any branch, toward branch ‘develop’, it will trigger the workflow ‘DemoWorkflow’. Do ‘Save’ (Cmd + S) now. In addition of this triggers, we can also schedule a workflow at specified time, but it will be presented a bit later.

5. Stack: this is where we specify Xcode and Mac OS version to run our workflow. Select the correct one for your project.

6. bitrise.yml: this is the configuration file that sum up our whole setup in this Bitrise’s app. We may need to backup this file from time to time, just in case we need to rollback.

Setup Pre-Merge workflow

Now, it’s time for real work …:] Actually, there’s not much left to do here, we will finish it in 5 minutes. So, let’s switch back to Workflow tab. We will design the flow like this: get the repo, install pod or Carthage if needed, run tests, and that’s it.

1. Cloning the git repo on the pull request’s branch: if your repo is private, add the step SSH Key (click on the “+” sign, and search for keyword ‘SSH’). This will activate the SSH key you generate when creating this Bitrise’s app. Then we add the step Git Clone repository. Normally, this’s all correct already, since Bitrise is smart enough to pre-fill all the information needed like Git URL, branch name (which is always Source branch)

2. Depend on the project, you may need to do pod install, or run Carthage. Do add step using keyword ‘Cocoapods’ or ‘Carthage’. Again you may not need to specify anything in the step’s config (in case of Cocoapods, Bitrise will setup pod repo and do pod install by default)

3. Now we have the project setup, we need to run tests. To do so add the step ‘Xcode Test’. In this step we should check if all pre-filled parameters are actually what we want, for example: the scheme, the iDevice to run tests, the iOS version…

At this point, we’re proud to say our mission was archived. This workflow will tests our app when there’s a pull request toward our develop branch. In effect, we can stop here, save our changes, and make a pull request to see if everything connects correctly together. Our workflow now will look similar to below:

It’s worth to mention that some cloud repo, like Bitbucket, integrates Bitrise seamlessly, so we will see a green checkmark once workflow finish successfully:

Below is two popular extra steps that make our CI/CD fancier ^^

4. Export apps, logs or artifacts: this step will export everything generated by the previous steps: logs, unit tests reports, archives, IPA, dSYM… so we can download it for review. Once implement this, we will get all the stuffs in the Apps & Artifacts tab:

5. Send success/fail message to Slack: we may not want to go check our Bitrise or Git repo from time to time to see if the tests passed. By sending message to our communication tools, we passively and immediately notified workflow’s result. So go search for ‘Slack’ step. This step required our Slack’s Wekhook URL or Slack’s API token, which is sensitive so we should stored them in ‘Secrets’

The final workflow now look like this:

Some helpful tips

It’s better to use environment variables in our workflow, rather than hard-code ones. When all ENV VARS in one place, it’s easier to review our configurations.

Variables should avoid Bitrise prefix: almost all steps in Bitrise generate output variables which have Bitrise prefix. Do not use this prefix help you avoid confuse when reading step’s config and possible conflicts.

Create common workflow steps: as you may notices, a workflow can be combined of multiple other workflows. If we intend to create many workflows for different scenarios, we should group the common steps in one workflow. For example, every workflow need firsts steps similar to SSH-> Git clone -> Pod install. So those steps could be set up in a workflow name ‘PreBuild’.

Use Pull, Push cache steps: Bitrise provide Pull/Push steps, which allow to pull cache builds from previous build, and push the current cache when workflow done. It improve considerably workflow’s build time.

Use option ‘Run if previous steps failed’: every step has this toggle. Use it when we feel convenient. For example, we don’t need to export apps build if previous step archiving app failed. It helps saving time since we don’t have to spend time in running a step for nothing.

Enable rolling builds: activate all theses options in App’s Settings. It will cancel all previous builds for Pull Requests/Pushes to the same branch, so we avoid duplicated worked

Schedule workflow: in addition of trigger on events, we can schedule workflow to run at a specific time. At the app’s dashboard, click on “Start/Schedule a build” -> toggle ON “Schedule this build” and setup the day, time and the workflow we want to run. This feature is mostly use for time consuming tasks, like UI tests, performance tests, TestFlight build delivery. Since it’s time consuming, we don’t want them to run during our workday, because they will create traffic jams without much adding value. We should make our CI/CD works while we sleep ;)

Where to go from here?

There are still many awesome step features to discover. What we did in this tutorial is just a scratch on the surface of what CI/CD can help us improving our daily performance. Take your time to discover them and try them. That may help you generate some ideas on how to facilitate your daily tasks’s.

Cloud CI/CD is a great start in enabling automation in our development process. In fact, my team use this tool alone during two first years and it improves a lot our work’s velocity, quality and happiness. But it turns out that CI/CD level up to full power and versatility only when combining with Fastlane. Fastlane is an open source automation app that allows you to write customized tasks, defined your own action’s rules, and sync all our work platforms seamlessly. To name a few:

• Capture screenshots automatically
• Distribute beta builds to multiple Beta testing services (Testflight, Firebase App Distribution, Hockey…)
• Publish multiple apps at once with a single command line
• Automatic code signing for iOS
• Update test, build, delivery info on your JIRA ticket
• All of these happen while we’re working on something else

Basically Fastlane is able to sync with every platform that provide an API, and his abilities is limited only by our imagination ;]

If you’re interested to know more about Fastlane, this is the part 2 of this tutorial:

CI/CD automation for mobile development from scratch (part 2)

CI/CD automation for mobile development from scratch (part 1) was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

6 reasons to make your mobile development’s workflow automated

Continuous integration (CI) and continuous delivery (CD) is a set of operating principles, and collection of practices that enable mobile development teams to deliver code changes more frequently, reliably and automatically. The implementation is also known as the CI/CD pipeline.

From almost a decade working as a software engineer, I learned that this is one of the most vital tools we need in the team. The bigger the mobile team we have, the more important this tools become.

Why should we use CI/CD?

CI/CD is one of the best practices for mobile development teams to implement. It is also an agile methodology best practice, as it enables mobile development team to focus on meeting business requirements, code quality, and security because other tasks are automated.

Continuous testing

Automated testing is one of the best benefit of CI. Developer can setup CI tool in a way that once there is an event, like pull request creating, pushing on a branch, or tagging on the repo, the tool will checkout the repo, make the build, and run various tests. This step ensures that developers only merge or deliver code after theses tests passed on the code changes.

Enable more frequent deployments

In short, CI pipeline builds and alerts developers if their changes failed any tests (unit tests, UI tests, performance tests). CD is the automation that delivers changes to Beta services infrastructure and executes additional tests.

CI/CD pipelines are designed for businesses that want to improve applications frequently and require a reliable delivery process. Once in place, it enables teams to focus on the process of app development and less on the system details of delivering it to Beta distribution or App Store.

CI/CD is a devOps best practice because it addresses the misalignment between developers who want to push changes frequently, with product owner that want stable applications. With automation in place, developers can push changes more frequently. Product owner see greater stability because environments have standard configurations, there is continuous testing in the integration process, local environment variables are separated from the application.

Great ability to attract and retain talent

Engineers that can focus on what they are best at will be happier and more productive, and that has far-reaching impact. Turnover can be expensive and disruptive. A good CI/CD strategy means engineers can work on important projects and not worry about time-consuming manual tasks. They can also work confidently knowing that errors are caught automatically, not right before deployment. This kind of cooperative engineering culture inevitably attracts talent.

Higher quality code and operations

Developers can focus on development. Bad code rarely makes it to production because testing is automated. Developers can focus on the code rather than the production environment or manual stuffs, and operations does not have to feel like a barrier. Both sides can work to their strengths, and automated handoffs make for seamless processes.

Versatile and Powerful

Beside the main CI/CD functions (build, test, integrate and delivery), theses tools are able to interact with almost all others working platform, to name a few: Slack, version control repository’s cloud server (Bitbucket, Github…), JIRA, Confluence, Firebase... Combining with Fastlane automation app, CI/CD lets us automate every aspect of our mobile development and release workflow.

Give away little effort on setting up and maintaining, getting big benefits

Some companies have operation team, who handle CI/CD pipeline. But if we are a small team of devs, or even individual developer, CI/CD still brings great values and it’s easy to implement. The basic functions of CI/CD can be implemented from scratch in one working day.

Let’s take an example from Bitrise, a mobile CI/CD platform, here is what I’m able to implement and make it works during a few hours:

We could see the step is intuitive and easy to understand. Basically, the workflow clone the repo, setup iOS certificates, build and unit tests, then finally send the result message to our team Slack channel. Each step require its dedicated parameters like git branch name, URL, Slack’s web-hook token, Slack’s channel name… Once in place, it just works.

How to optimize the use of CI/CD?

Getting started with CI/CD requires development teams and operational teams to collaborate on technologies, practices, and priorities. Teams need to develop consensus on the right approaches for their business and technologies so that once CI/CD is in place, the team is onboard with following practices consistently.

Most CI/CD tools let developers kick off builds on demand, triggered by code commits in the version control repository, or on a defined schedule. Teams need to discuss the build schedule base on the size of the team, the number of daily commits expected, and the tasks to execute.

What are the tools needed for CI/CD?

Bitrise is a leading CI/CD cloud platform for mobile (iOS, Android) development. It offers a free plan so it is a good start if we want to try to implement the CI/CD practice. Beside there are Travis CI, Circle CI that could be worth to try.

A great tool to add to CI/CD cloud platform is Fastlane, an automation app. It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing our application. Furthermore, this is the tool we need to make our pipeline truly versatile and powerful. Thanks to Fastlane, you can write the task and programme action’s rule on all working platforms.

Where to go from here?

This is the first story of my series on CI/CD. I hope this gave you an inspiration on how to bring your mobile team’s performance to the next level. This could be a good time to begin your team’s discussion and implement the basic functionalities of CI/CD.

On the next articles, I will give details on how-to and best practices. More in-depth analyze of mobile development’s manual tasks and how CI/CD can automate them. It also provide step-to-step guide on how to implement some essentials tasks.

My first tutorial will be on implementing a useful Bitrise’s workflow to unit test all Pull Request.

CI/CD automation for mobile development from scratch (part 1)

The next one will level up automation to full power by using Fastlane. This tutorial guide you to implement Fastlane to download dSYM from App Store and upload them to Firebase Crashlytics.

CI/CD automation for mobile development from scratch (part 2)

If you are interested in this series, please following me to stay tuned for updates.

Why does CI/CD automation become essential in mobile development? was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.