Blog

Crash in NSLog when used in swift – and how to avoid it

As a senior iOS programmer, I have learned to use and love a logging feature method called NSLog(). It is usually called with a format string and some arguments. If I have a function callback that comes with two parameters called response and error and I want to print them out, I can do that in Objective-C with the following line:

NSLog(@”response %@, error %@”, response, error);

In that line, the pattern %@ is replaced by the arguments added behind the format string. This also means, it is not so easy to print the pattern %@, because that has a special meaning. But back to my todays problem.

In swift, the same method is very similar:

NSLog(“response %@, error %@”, response, error)

But due to a nice feature in the string class of swift which allows it to include variables in strings, if they are surrounded by backspace and parenthesis, e.g. “\(variable)”, I was writing the above line in the following way:

NSLog(“response \(response), error \(error)”)

It always worked – until today – where it crashed. Why? Because the first string given to NSLog is the format string. This means, that if the content of \(response) creates a special meaning string, e.g. %@ then NSLog tries to interpret that according to the rules. So one safe way to print the same line is, by giving a format string:

NSLog(“%@”, “response \(response), error \(error)”)

This prevents the real string to be interpreted as a format string, because now it is an argument to the format string.

Of course, I had a distant memory, that I had made a similar error when using printf in my first year(s) as a C programmer. By changing to swift, I just had forgotten about checking for this side effect, that I am aware now for so long. A nice example of risk management and how to forget about the risks of a situation when you change the environment.

Xcode replace old style code to new style

Assume you have

[personData setValue:someProperty forKey:someKey]

and you want to change that to

personData[someKey] = someProperty

…and that for about 100 lines ?

Easy! Just type Find (cmd-f in your Xcode, change it to replace, then click on the magnifying glass and select edit find options, and then regular expression for “matching style”. Then type in

Find: \[(.*) setValue:(.*).*forKey:(.*)\];

Replace: $1[$3] = $2;

The ()-part in the find finds the first text addressed by $1, the second ()-part is addressed later by $2

You gotta love regular expressions!

China Domain name registration scam

In the past years, we received at least once a year an email where some nice registration company from china asks us if we would mind, if some client of theirs would register the domain small-apps.cn. Today was the day for 2016.

Let me tell you that registering your domain name in china is easy and cheap – about 12-20 $/€ a year I read in a price list of nicenic.net. German reseller companies offer it for 60€/year.

Swift code comment special words

Swift can help you a lot to document your code – it allows you to use markup. However, in order to use it not only as formatted text but as source code commentary, it is nice to use the special keywords known.

I created my own cheat sheet for these keywords, which create their own left column or blocks. Always use them with a preceding minus, like this

– returns: the object or nil, if not successful

  • returns:
  • throws:
  • parameter <param>:
  • parameters:
    • <param1>:
    • <Param2>:

You can also use the following keywords to have bold text formatted inside the description block:

  • Author:
  • important:
  • version:
  • Attention:
  • todo:

For more keywords, see the reference, linked above.

Appside Down: Should my App Work Upside Down?

When creating an iPhone app, many app developers lean towards disallowing their app being used upside down. Reasons given are usually:

  • The big companies (Apple, Google) have most of their apps only in portrait mode, not in upside down portrait mode
  • When allowing upside down and a phone call comes in, the user is confused, which would not have happened, if the user had to use the phone in portrait mode only

While I do see the reasons behind this, there are situations, where this portrait mode only is just not convenient:

  • When the app is used on a bike, in a rain-shelter but a cable needs to go outside (either phone or charging / lightning). If you are lucky, your bike app shelter knows where the cable is. Else you wish, you could use your navigation app upside down.
  • When the app is used in a car and you want to place the iPhone holder on the windshield in a phone holder as low as possible – then you either are 2-3 cm (or 1 inch) over the windshield due to the charging / lightning cable going out below, or you can turn your iPhone upside down and put the cable in on top, allowing you to lower the phone a little more.
  • When you are charging your phone in a car where there is no phone holder (e.g. rental car), then the cup holders are helpful (sometimes). Being able to put a phone into the cup holder upside down and still being able to see the content of your app helps you save the money for the car phone holder.

So when designing an app that is used over a longer time, e.g. could be used with the lightning cable being plugged in, then the option of using the app upside down suddenly may make sense for your customers.

What do you think?