David Cordero

Improving the iOS development cycle with breakpoints

Published on 28 Mar 2019

The Development, Build and Run cycle is by far one of the most annoying parts when working in native iOS development. Your thinking and creativity flows are suddenly stopped by unnecessary waiting times, just because for some reason Xcode decided that it was a good moment to build again certain files that were not modified at all.

Apart from that, one always ends up having to navigate over and over again to the screen in which you are working on.

This cycle is very slow especially when it is compared with the hot reloading technologies that can be found in the world of web or Android development.

Even though we can not do too much to improve the build step, I would like to share a simple method (@GoldsbyChris’s idea) that we have been using since quite recently in Zattoo, in order to improve our development cycle.

Breakpoints to the rescue

The solution is based on breakpoints. Among the different type of breakpoints that one can create in Xcode, there is one of type “Debugger command”.

This type of breakpoint, together with the command “expression” of lldb, allows injecting and running arbitrary code that is executed in runtime.

You can also mark the checkbox, to avoid that your App execution is stopped but just to evalute the expression and continue automatically.

You can find listed below some examples where we are using this method.

■ Navigate to specific screens via deeplink:

Because our App has a quite complete set of deeplinks, using this technique is very easy to make the App navigate to the screen you are working on, just adding a breakpoint that triggers our handler for deeplinks when the App starts.

expr rootWireframe.handle(deeplink: "zattoo://guide")

It is not like having hot reloading, but definitely much better than nothing.

■ Filling up forms automatically:

The same technique can be used when working in a screen in which some information needs to be filled up, for example in a login or contact screen.

expr usernameTextField.text = "dummy@account.com"
expr passwordTextField.text = "12345"

■ Mute video player in development:

When working in tvOS development, there is no way to mute the simulator. This is really annoying when you are doing pair programming or a demo remotely.

This can be solved by adding the following breakpoint when your player is configured.

expr viewPlayer.isMuted = true

■ Moving among environments:

Changing the environment in which the App is running, that means moving between Local, Staging or Production, can be also done quite easily changing your host with a breakpoint when you needed it.

expr apiClient.host = "127.0.0.1"
expr apiClient.port = "3000"

Sharing is caring

By right clicking on them, these breakpoints can be easily shared with your team.

Doing that, you can end up with a very useful suite of custom breakpoints for your projects that can ease the daily work of your team.

Naming breakpoints

Since Xcode Version 12.0 beta 4, it is also possible to name breakpoints to make it easier to find the one that you want to enable. To do that you only need to provide a name in the new parameter “Name” added to the breakpoints form, and the breakpoint will be listed showing the given name.

Feel free to follow me on github, twitter or dcordero.me if you have any further question.