DEV Community: Samuel Edwin

Getting the most out of your crash reporter

Samuel Edwin — Wed, 10 Nov 2021 04:13:19 +0000

We developers are not perfect humans, we make mistakes from time to time. Crashes are one of the most common problems we encounter because of those mistakes.

Crash reporters have been an iOS developer's long time friend. They make it easy to find out where things go wrong like the image below.

You know immediately that the crash happened in ViewController.btnDidTap. All you have to do then is to try reproducing the problem in that method.

In other cases though, crashes can be hard to debug, like this one

This happened when we did something wrong with UICollectionView. This one can tough to debug if we have dozens of view controllers that use UICollectionView. It's not obvious which view controller that caused the crash.

What should you do in this situation?
Add more debugging information.
A lot of people know how to use Crashlytics, but not many know how to improve the debugging information.
Here are some less well known features of Crashlytics that I'm sure will be useful for you.

Note

In this post I'm going to use Firebase Crashlytics as an example because it is the most popular one. Other crash reporters also have similar features so you can still benefit from the techniques I will describe.

1. Filtering by user id

Imagine how easy it would be if you can just limit the search of your crashes by user id. This is what Crashlytics has already provided.

Adding user id is only one line of code away. Add this code below whenever your user has logged in or logged out from your app.

// Call this when the user is logged in
Crashlytics.crashlytics().setUserID(“12345”)

// Call this when the user is logged out
Crashlytics.crashlytics().setUserID(“”)

Once you added this code, use the search bar to filter crashes made by this user.

2. Adding custom value

Crashlytics has already provided us a lot of useful information such as the iPhone type, OS version, device orientation and so on.

This is not enough in some cases, and fortunately adding more information also takes only one line of code.

crashlytics.setCustomValue("My value", forKey: "My key")

Once you're done, it will show up like below.

Here are some ideas of custom values you should put in Crashlytics:

Calendar type
Language
Region
Time Zone
Accessibility settings

This is how the information going to look like

Case study: A complaint from year 2560

A few years ago we received a crash report in a certain view controller. We know where it happened but not what triggered it.

After looking at the custom values, we noticed a pattern. it is immediately clear that all the crashes happened only when our users use the Buddhist calendar in their phone.

3. Logs/Breadcrumbs

Another tool that I find useful is the logging capability. It shows events in order of time. This improves debugging speed because we know the steps to reproduce it.

Where should you add the logs?

App life cycle

Some crashes happen not when the user is using the app, but when the app is in background. By logging every life cycle method, you can know for certain when the crash happened.

Here are some of the app life cycle methods you should log

application(didFinishLaunchingWithOptions:)
applicationWillResignActive
applicationDidEnterBackground
applicationWillEnterForeground
applicationDidBecomeActive
applicationWillTerminate

Using the above image as an example, you can clearly tell that the crash happened when the app entered the background state.

App entry points

The iOS app ecosystem is getting more complex each year. There are a few ways to launch the app besides tapping the icon from the home screen:

Universal linking
Push notification
Home screen quick action or 3d touch
Siri Shortcut
WidgetKit
And many other ways

Here is the log when the crash happened when the user is in another app:

Case study: Can't notify the dead

There was a crash that happened in a very specific condition:

The app must be in a killed state
The crash must be triggered only with a specific push notification payload.

By logging the app life cycle and app entry points, we can see how to reproduce this specific scenario. This would be a chore to find without the help of logging.

Opening view controllers

Let's go back a bit to the UICollectionView crash I mentioned before.

If we have a list of previously visited view controllers, finding out where the crash happened would be easy.

One straightforward way to add the log is by using this code

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)

    Crashlytics.crashlytics.log("\(self)")
}

And here is the result. You can tell immediately where the crash happened.

But I have 100 view controllers 😰

Adding the code snippet above for 5 view controllers is not a problem, but it can be tedious when you have 100 view controllers.

Fortunately there's a solution, you can use swizzling to log all the view controllers.

For those who never heard of swizzling, it is a way to swap a method implementation with ours. You can find more about it by searching the internet.

This code snippet below replaces every UIViewController's viewDidAppear method that is implemented by Apple with our implementation.
Note that I'm using a library called JRSwizzle in this example to make swizzling quick simple.

extension UIViewController {
    // This method that will replace Apple's viewDidAppear implementation
    @objc public func swizzled_viewDidAppear(_ animated: Bool) {
        Crashlytics.crashlytics().log("\(self)")

        // call original viewDidAppear
        self.swizzled_viewDidAppear(animated)
    }
}

// Do the swizzling at the start of the app
func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
    FirebaseApp.configure()

    // From now on, swizzled_viewDidAppear will be called time a view controller appears on screen
    try? UIViewController.jr_swizzleMethod(
        method: #selector(UIViewController.viewDidAppear(_:)),
        withMethod: #selector(UIViewController.swizzled_viewDidAppear(_:))
    )
}

Now Crashlytics will automatically log every view controller that is visited by the app 🥳.

Conclusion

Debugging crashes can be difficult sometimes, but crash reporters have some tools that you can use to make them easier.

If you have been scratching your head figuring how to reproduce this crash, try the techniques described above. I hope it can solve your problems!

Change variable values instantly without rebuilds

Samuel Edwin — Mon, 25 Oct 2021 19:08:28 +0000

Most of the apps distributed in the App Store requires a back end server. Facebook, Instagram, Twitter, Netflix, Amazon, you name it.

There are at least two kinds of servers involved when building these apps: production server and testing server.
Testing server is used to prevent unstable features from going to production.

This practice impacts our development activities. We often need to switch servers depending on the situation. How do we handle changing these servers?

The simple way and the complexities it introduced

let productionURL = "https://api.myapp.com"
let stagingURL = "https://staging-api.myapp.com"

let baseURL = productionURL

This is the typical way people do to switch servers, simple and straightforward.
Change the baseURL to either productionURL or stagingURL when you need to, rebuild the app, and see the results.

While this approach works, there are some problems you need to be aware of:

1. It gets slower over time

Your project's build speed will get slower as your codebase grows.
I have reached a point where I have to wait for 3 minutes just to change servers.

2. Human error eventually hits hard

When using the above technique, you have to modify your code in order to switch servers.

- let baseURL = productionURL
+ // let baseURL = productionURL
+ let baseURL = stagingURL

You have to be very careful to not let the code above get committed and published to the App Store.

This of course can be prevented by code review, but humans eventually make mistakes. It is only a matter of time when you let your guard down and published this to production. I did, at some point in my career.

3. Huge inconvenience for testers

Aside from developers, testers are the ones that also need access to both staging and production servers.

If you use CI/CD system to distribute test apps, then you need to provide two builds with each build pointing to a different server.

This is a big waste of time. Builds take twice longer, and also testers need to download the builds again just to switch servers.

So now you're convinced that even though the simple technique works, it has some drawbacks.
Wouldn't it be nice if we can switch servers instantly?

SwiftTweaks to the rescue

SwiftTweaks is a library to change things instantly without having to recompile, and written in ... Swift. I thought it was PHP 😮.

How does it work?

SwiftTweaks works by showing a pop up when you shake your phone. Choose whatever settings you want to tweak and that's it.

In our case, SwiftTweaks will show a menu so we can switch between servers instantly. No rebuilds needed.

If this looks appealing to you, then let me show you how it's done.

Let's build our own tweaks

Create a new project and add the library as instructed here.
I won't go into details here since this is not a beginner article.
After you're done, we can start the next steps.

1. Create a tweak store

// AppTweaks.swift
import SwiftTweaks

struct AppTweaks: TweakLibraryType {
    // A
    static let serverURL = Tweak<StringOption>(
        "General",
        "Networking",
        "Server URL",
        options: [
            "https://api.myapp.com", 
            "https://api-staging.myapp.com"
        ]
    )

    static var defaultStore: TweakStore {
        return TweakStore(
            tweaks: [serverURL], // B
            enabled: TweakDebug.isActive
        )
    }
}

This seems like a lot of code but trust me it is simpler than what it looks like.

There are two things that we do here, as marked in comments A and B.

In comment A, we are creating a tweakable serverURL with two available options: https://api.myapp.com, https://api-staging.myapp.com.
The first option will be chosen as the default.
This option will show up under the General > Networking > Server URL option.

In comment B, we are putting all the available options in the tweaks argument so they can show up in the UI.

2. Change the default UIWindow

These options will show up when you shake the phone while the app is active.
In order to do that, we need to use the TweakWindow class provided by SwiftTweaks instead of UIWindow.

window = TweakWindow(
    frame: UIScreen.main.bounds, 
    tweakStore: AppTweaks.defaultStore
)

// Create the root view controller as usual
window?.rootViewController = MyViewController()
window?.makeKeyAndVisible()

3. Use the chosen option from the code

Now we need to change how the baseURL gets its value.

- let baseURL = productionURL
+ let baseURL = AppTweaks.assign(AppTweaks.serverURL).value

Instead of hardcoding the server URLs, we can now just let SwiftTweaks decide which server URL that we want to use.

4. Restart the app and see the changes

We'll now see how easy it is to change configurations using SwiftTweaks:

Run your app as usual
Shake your device (ctrl + cmd + z from the simulator), a view controller will pop up showing all your configurations.
Change your selected server from production to staging.
Restart your app to see the changes.

That's it! No more code changes needed when you want to switch servers. You can switch servers whenever you like.

I don't want my users to use this tool

Me too. God knows what weird things your users will do with this.

So how do you prevent this tool from leaking to app store builds? nothing.

Yes, you don't have to do anything. SwiftTweaks is smart enough to know that this will only show up in debug builds.

Other useful SwiftTweaks usages

Now you have seen how powerful this tool is. You might be wondering, what else can you use this for? I have some ideas for you.

Toggle onboardings or tutorials

Onboardings or tutorials teach users on how to use your app. It is a very common pattern nowadays.

The thing with onboardings is they only show up once when the users open the app for the first time.

let showOnboarding = !UserDefaults
    .standard
    .bool(forKey: "has_shown_onboarding")

if showOnboarding {
    UserDefaults
        .standard.set(true, forKey: "has_shown_onboarding")

    window?.rootViewController = OnboardingViewController()
} else {
    window?.rootViewController = MainViewController()
}

Ordinary humans like me can't develop onboardings perfectly on the first try. We have to run the app multiple times until we got it right.
I usually hard coded showOnboarding to true until I've finished with the development.

Thanks to SwiftTweaks, I don't have to do any hard coding anymore. All I have to do is create a new tweak.

static let showOnboarding = Tweak(
    "General",
    "Onboarding",
    "Show onboarding",
    !UserDefaults.standard.bool(forKey: "has_shown_onboarding")
)

And then I just need to change the logic for a bit.

- let showOnboarding = !UserDefaults
-     .standard
-     .bool(forKey: "has_shown_onboarding")
+ let showOnboarding = 
+    AppTweaks.assign(AppTweaks.alwaysShowOnboarding)

Toggle SDK loggings

Third party SDKs such as Mixpanel have logging capability to ease debugging.

Mixpanel.mainInstance().loggingEnabled = true

You mostly want this option to be turned off unless for some occasions. The reason is the logs can pollute your debugging console and make important information harder to find.

SwiftTweaks lets you toggle this on/off anytime you want.

static let enableMixpanelLogging = Tweak(
    "General",
    "Logging",
    "Enable Mixpanel logging",
    false
)

Mixpanel.mainInstance().loggingEnabled = 
    AppTweaks.assign(AppTweaks.enableMixpanelLogging)

Conclusion

We do some small tweaks here and there in our coding activity. Tweaking those configurations doesn't have to be time consuming. SwiftTweaks lets you do small tweaks instantly. This will save you a lot of time.

There are so many things that you can do with this. You can change colors, fonts, animations on the fly with out having to recompile your code.

Start using it now see how your quality of life gets better because of it.

Conflict-free Xcode Project Management

Samuel Edwin — Tue, 05 Oct 2021 10:31:19 +0000

There is one pain that every iOS developers face, especially when they work in a team.

Xcode merge conflicts.

It is one of the most dreadful and time wasting activity that nobody likes to do. This pain only stings more the bigger your team and codebase gets.

Why does it keep happening?

Xcode keeps track of all source files that needs to be compiled within this project.pbxproj. It is a plain text file which has the content like below.

// !$*UTF8*$!
{
    archiveVersion = 1;
    classes = {
    };
    objectVersion = 50;
    objects = {

/* Begin PBXBuildFile section */
        923EF325270C588D0058CE0F /* AppDelegate.swift in Sources */ = {isa = PBXBuildFile; fileRef = 923EF324270C588D0058CE0F /* AppDelegate.swift */; };
        923EF327270C588D0058CE0F /* SceneDelegate.swift in Sources */ = {isa = PBXBuildFile; fileRef = 923EF326270C588D0058CE0F /* SceneDelegate.swift */; };
        923EF329270C588D0058CE0F /* ViewController.swift in Sources */ = {isa = PBXBuildFile; fileRef = 923EF328270C588D0058CE0F /* ViewController.swift */; };
        923EF32C270C588D0058CE0F /* Main.storyboard in Resources */ = {isa = PBXBuildFile; fileRef = 923EF32A270C588D0058CE0F /* Main.storyboard */; };
        923EF32E270C588F0058CE0F /* Assets.xcassets in Resources */ = {isa = PBXBuildFile; fileRef = 923EF32D270C588F0058CE0F /* Assets.xcassets */; };
        923EF331270C588F0058CE0F /* LaunchScreen.storyboard in Resources */ = {isa = PBXBuildFile; fileRef = 923EF32F270C588F0058CE0F /* LaunchScreen.storyboard */; };
        923EF33A270C58E00058CE0F /* ShopViewController.swift in Sources */ = {isa = PBXBuildFile; fileRef = 923EF338270C58E00058CE0F /* ShopViewController.swift */; };
        923EF33B270C58E00058CE0F /* ShopViewController.xib in Resources */ = {isa = PBXBuildFile; fileRef = 923EF339270C58E00058CE0F /* ShopViewController.xib */; };
/* End PBXBuildFile section */

You don't even need to be in a team to experience this. If you work on multiple branches, the conflict often shows up whenever you merge them.

CONFLICT (content): Merge conflict in SadApp.xcodeproj/project.pbxproj
Automatic merge failed; fix conflicts and then commit the result.

Have you ever wished for the merge conflicts to go away?

I do, all the time. I have worked on Android and web projects in the past. The conflicts happen much less frequently, if they happen at all.

If you have been looking for a solution, you are lucky my friend. There is a hope to end this madness.

Swift Package Manager

Swift Package Manager(SPM) has existed for years since Swift 3.0.

We seldom see its usage outside of server side and command line Swift apps. The reason for this is because it used to have bad support for iOS development.

Things have changed though since the release of Xcode 12.

Xcode 12 adds a first class support for using Swift Package Manager in iOS app development.
All the pains I mentioned before instantly went away after I used it.

This is a powerful technique yet still unknown to many people, given how new it is.

Now I want to show you how to use it.

Let's give it a try

Create a new iOS project, as usual

You know the drill:

Open Xcode
Create a new iOS app. I'll just name it MyApp in this demo. Yes I have a wonderful naming sense.

Create a new Swift Package.

From your Xcode, go to File -> New -> Swift Package.
Give a name for your package. Some important things to notice:
- Make sure that the package will be stored inside your project folder as shown in the highlighted green box below.
- Select your previously created project in the Add to section as shown in the yellow box below.
If you did it right, the Swift Package will be shown in the file explorer.

Import the package from the app target.

In order to import your Swift package from your app, go to your app's Build Phases section, and add your package target in the Link Binary With Libraries subsection.

Build the project

Let's see if things work as they should:

Add new code inside Sources/MyAppPackage.
Import the code from your app target.

// MyAppPackage/Sources/MyAppPackage/MyAppPackage.swift
public func hello() {
  print("Hello from Swift Package")    
}

// MyApp/AppDelegate.swift
import MyAppPackage

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
  hello()
  return true
}

If you see the Hello from Swift Package message from your console, then that means you have used a Swift Package code from inside your app. Congratulations 🤝.

One important thing here project.pbxproj does not change no matter how many files you put in your package. That's why this technique is miles better compared to the old one.

What should I put in the Swift Package?

I'd put pretty much everything there except for Info.plist, Main and LaunchScreen storyboards.

For everything else I'll put them into the Swift Package: Swift files, Xibs, Storyboards, image assets.

Don't lose your assets

If you use Xibs, Storyboards, or image assets, you need to do a small tweak in your code. Pretty much things that related to bundles.

When you create a view controller, this is the initializer that a lot people use.

class MyViewController: UIViewController {
  init() {
    super.init(nibName: nil, bundle: nil)
  }
}

Notice that I put nil in the bundle argument. This means that the main Bundle will be used to locate the Nib resource.

If your Nib is located in a Swift Package like below,

you need to change the bundle argument.

super.init(nibName: nil, bundle: Bundle.module)

Conclusion

Swift Package Manager is a superior way to manage your Xcode projects because you don't have to deal with merge conflicts that often anymore. Things just work.

If you are starting a new project, I'd recommend you to use it right away.

If you are working in an existing project, better migrate them to Swift Package Manager as soon as you can.

If you have questions, let me know in the comments section. I'd love to answer your confusions.