Hacking with Swift – Project 18

Still in Day 70 of my Learning how to code with Swift adventure I am beginning to tackle project 18, which consist of learning the first basics of debugging.

Setting up

All that’s needed by now is an empty iOS Single View app, nothing more.

Basic Swift debugging using print()

This is pretty basic because we have already used it in our project.

The new takeaways are:

1. print() is a variadic function, which means it can accept a variable amount of parameters (I guess they still have to be of the same type)
2. it has two optional parameters: separator, which lets you specify what you would like to be printed between each of the parameters and terminator, which is \n by default and can be overridden to specify a different way of ending the print statement.

Debugging with assert()

These are debug-only checks that will force the app to crash if a said condition is not met (i.e., is not true).

These assertions are removed from the release version of the app so that we can build an app in an extremely strict environment and, if that works, the release version will work much better.

Asserts take two parameter: the condition to be met and the message to be printed out if the condition fails.

Debugging with breakpoints

This starts to ramp up the difficulty level.

Using a for-in loop that cycles over numbers from 1 to 100 and prints the result we set a breakpoint next to the print statement’s line, which becomes selected with an arrow-like symbol in the gullet. These breakpoints will make the code pause its execution there and wait for your action. Clicking once on the breakpoint will disable it but not delete it, while editing it will allow for conditions to be added to them.

While the code is paused I tried to press Fn-F6 to progress but that open my iCloud Drive folder in the Finder, bizarre as I didn’t have that mapped in System Preferences, but never mind as the Ctrl-Cmd-Y shortcut can be used instead. They are slightly different but, for now, we can use this second one.

Via the breakpoint navigator (Cmd-8) we can have breakpoints be automatically triggered when certain exceptions (read, error by now) are thrown.

I would like to see this in action but I guess that will be just a matter of time.

View debugging

The last bit requires us to open a finished project and run it.

Then press the button just above the debug area (or at the bottom center) that looks like three concatenated screens and start fiddling with it.

There are plenty of things to experiment here, but by now we are left with just a taste of that.

No need for a GitHub repository here, we really didn’t do anything special here.

Please don’t forget to drop a hello and a thank you to Paul for all his great work (you can find him on Twitter) and don’t forget to visit the 100 Days Of Swift initiative page.

---

If you like what I’m doing here please consider liking this article and sharing it with some of your peers. If you are feeling like being really awesome, please consider making a small donation to support my studies and my writing (please appreciate that I am not using advertisement on my articles).

If you are interested in my music engraving and my publications don’t forget visit my Facebook page and the pages where I publish my scores (Gumroad, SheetMusicPlus, ScoreExchange and on Apple Books).

You can also support me by buying Paul Hudson’s books from this Affiliate Link.

Anyways, thank you so much for reading!

Till the next one!