Our BlogTips, Tricks, and Thoughts from Cerebral Gardens

As we all scramble to learn this fantastic new language Apple gifted to us at WWDC 2014, we're coming across new ways of doing things, either because the new way is better, or because the old way is no longer possible.

One of the main features that Swift has taken away, is the C preprocessor. That's what enabled #define's to work. A common #define used is for debug logging, to include useful info with every line.

#define DLog(...) NSLog(@"%s(%p) %@", __PRETTY_FUNCTION__, self, [NSString stringWithFormat:__VA_ARGS__])

This lets us go from this:

NSLog(@"Simple Message");
2014-06-08 05:38:54.649 TestApp[35062:60b] Simple Message

to this:

DLog(@"Simple Message");
2014-06-08 05:38:54.649 TestApp[35062:60b] -[TSTAppDelegate application:didFinishLaunchingWithOptions:](0x10961f2e0) Simple Message

We now get a lot more info in our log messages and can see where in our code the log message came from without having to type it in for every line.

In Swift, we lost this functionality. The reason this was traditionally done with a #define, and not a function or class, is so that we can use the __PRETTY_FUNCTION__, __FUNCTION__, __FILE__, and __LINE__ macros. The preprocessor replaces those macros with their actual values. For example, __FILE__ will always contain the filename where the macro is placed for example. If you were to use them in a logging function, the macros would always contain the information of the logging function, not the calling function, rendering them useless.

This looked like it was going to be a major inconvenience in Swift so I filed a radar about it: http://openradar.appspot.com/17170702. After playing with Swift for a while, I've discovered a solution. I've built a library you can use in your projects.

Introducing XCGLogger. My first open sourced third party library, that I think will be essential to add to your project.

The source can be found on GitHub here: https://github.com/DaveWoodCom/XCGLogger, with basic instructions on how to use it.

At a glance, it will change your logs from this:

Simple message

to this:

2014-06-09 06:44:43.600 [Debug] [AppDelegate.swift:40] application(_:didFinishLaunchingWithOptions:): Simple message

By writing code like this:

log.debug("Simple message")

instead of this:

println("Simple message")

A few things to note:

  1. Swift is brand new and in a state of flux, so it — and any libraries using it — will be subject to frequent changes.
  2. This is my first released library, so please let me know what you think and please share any ideas for improvement.
  3. There is a bug in Xcode 6 when using __FUNCTION__. XCGLogger uses a workaround for now, but will remove that once the bug is fixed. See: http://openradar.appspot.com/17219684
  4. This library is intended for use in Swift projects. There's no Objective-C compatibility included in it at this time. If it's a requested feature, it can be added.

Since Swift is brand new, there are a lot of different ways to accomplish the same thing. Over time, some best practices and patterns will emerge. I've used what I think are good practices and patterns in this library and hopefully they'll be helpful for developers as we work to establish what's best. For example, how to store static tokens for dispatch_once calls, shared instances, and global variables etc.

How does this work when I said earlier that using __FUNCTION__ and its friends in a function only gives you the information in the function instead of where it's called? Well, that's the secret sauce I discovered last week. If you set the default value of a parameter in a function to one of the macros, the compiler fills in that value at the calling location giving us the effect we need. Giving us access to the correct macro values inside the function that's called.

If you find this library helpful, you'll definitely find these other tools helpful:

Watchdog - monitors Xcode® and automatically cleans up stale cache files

Slender - cleans up Xcode projects, removing duplicate and/or unused assets

Briefs - powerful app prototyping, lets you and your clients try before you build

Follow me on Twitter @DaveWoodX


This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Today, Cerebral Gardens introduces Watchdog for Xcode. Watchdog is a helpful utility for iOS and Mac OS X developers that monitors Xcode cache files (DerivedData) and cleans out stale files before they interfere with your builds.

If you’ve been building apps in Xcode for a while, you will see the value in Watchdog instantly as you are familiar with the weird errors that can happen with Xcode. If you’re new to using Xcode, you may not have run into these issues yet, but eventually you will and that’s when Watchdog will save immense time and frustration.

A Watchdog user will no longer see these weird issues:

  • Old images that you've replaced, still showing up in your app.
  • The DerivedData folder growing continuously over time, often taking up 10+ gigabytes of space.
  • Constants/Defines not updating in the app after you've changed them in the code.
  • Localization file changes not being seen.
  • Phantom breakpoints and/or breakpoints stopping on the wrong line.
  • Xcode refusing to run a build on your device, only reporting something obscure like: "Error launching remote program: No such file or directory"

Sometimes the cause is related to your version control system updating files without Xcode noticing. Sometimes it’s random. Regardless, the result is the same: a bad build, time wasted, a frustrated developer, or even worse, an annoyed customer.

These errors can be mind numbing. Let Watchdog be your guard against these errors so you never again have your time wasted.

Watchdog gives you truly clean builds, saves time, and your sanity. It guards, protects and, most importantly, prevents.

Download Watchdog for Xcode.

I'm sure by now most of you have heard of App.Net. A new microblogging type service that aims to be much more. At first glance it looks a lot like Twitter, but it is much better in a few fundamental ways.

The first thing you'll notice is that you have 256 characters per 'post' instead of Twitter's 140. It is very liberating. Think in terms of 140 characters, and then actually spell out all of the words, use punctuation and clearly articulate your point.

Ok, who's kidding? That's actually the second thing you'll notice. First you'll notice that you have to pay for an account! WHHHHHAAAAAAATTTT? Pay? Money? For a social network? Aren't they all free? - No, social networks such as Twitter, Facebook, Linked In, and pretty much most of the others (excluding Ping1) are not free. You don't pay with money, but you pay with time, attention, and the loss of personal privacy. With most social networks, you are not the customer, you are the product being sold2. With App.Net, you are the customer, and so you're the one paying with money. A normal member account is $50 per year. Which, is arguably cheap compared to Twitter. WHHHHHAAAAAAATTTT?

Let's take a quick look using some rough guesstimates comparing just 1 metric that you use to pay for your Twitter account: Time. Twitter is now starting to sell a lot of ads (promoted tweets) on its network. They've even started to push into selling a high volume of small accounts to users such as you and me, not just to the big guys. They've been giving away $100 starter accounts to promote their ad service. So, here's where we start to guess some numbers, we'll attempt to guess low in order to give Twitter the benefit of the doubt.

  • Assumption 1: on an average day, you see 15 tweets that are ads (promoted tweets, spam tweets, etc).
  • Assumption 2: it takes you 2 seconds to read/recognize and discard/move on.
  • Assumption 3: your time is worth more than $20/hour.

This means, over the course of a year, you're wasting 365 days * 15 tweets * 2 seconds = 10950 seconds = 182.5 minutes = 3 hours. For a monetary cost of over $60/year. And I know my time is worth a lot more than $20/hour.

This example ignores the cost you pay with your lack of privacy; Twitter and Facebook both track you as you move from site to site on the Internet, even when you're logged out!3

Two other benefits of App.Net that I won't get into detail on are: conversation views — much improved as you can see the whole thing, instead of having it forked into uselessness. It's a platform, not just a Twitter clone. Other apps and services that aren't possible with Twitter are being built right now on top of App.Net.

So, I encourage you to get on board with app.net, own your content, be the customer, and if you act pretty fast, get the name you always wanted....

Follow me on App.Net as @davewood and @cerebralgardens.

Footnotes:

1. No one uses Ping so there's no cost in time. (back)

2. Original quote via Gruber (back)

3. Original research (back)


This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Our latest app, Party Doodles was recently featured on TUAW's Origins Stories. The web series takes a closer look at the reasons why developers create their apps. Our very own Dave sat down with TUAW's Victor Agreda, Jr. to discuss how Party Doodles came to be and why it is such a unique app. Check it out!

WWDC 2012 sold out in less than 2 hours, a record that had been easily predicted by many. Tickets went on sale at about 8:30 Eastern time and were sold out before most people on the west coast had even woken up. The demand for tickets was obviously extremely high, and the supply was limited to about 5000. How can Apple solve this for next year?

Of course, the first question is, does Apple even want to solve this. I believe they do. They have information they want to put into the hands (and heads) of developers, as many developers as possible. That's why they release the videos shortly after the event. That's why they've had the free Tech Talks in various cities. So yes, Apple does want to get the information out to many developers as they can. So it's to their advantage to increase the supply of tickets for WWDC.

One idea that often comes up when this topic is discussed is to have two events. Perhaps keep the first one in San Francisco and have another a couple of weeks later somewhere in Europe. The SF one would have the main Keynote for press, just like the present; the Europe one would skip the keynote but have all of the same sessions. This would temper the expectations of the press, who may be disappointed if the event were held months later without additional product announcements. The SF one would still be called WWDC, but would now actually be 'Western World Developers Conference', the Europe one would be EWDC, 'Eastern World Developers Conference'. The downside of this scenario for Apple is the increased cost, not just the direct costs of hosting an event in Europe, but the time involved in tying up Apple's engineers for an additional week (or two including travel/prep etc).

My personal suggestion is to keep it as one event, but increase attendance to about 10,000. The most common argument against this idea is that Apple likes to have a roughly 1:5 engineer to developer ratio, and they don't have enough engineers available to maintain that ratio if they double the developer attendance. I've only been to one WWDC, so this could be inexperience talking, but to me, the number of engineers there was almost irrelevant. Each session had 1-5 engineers on stage, but it didn't matter whether there were 500, 1000, or 2500 people in the audience, only the size of the room affected how many people could attend. Where the number of engineers matters is in the labs (which are more like Q&A sessions than labs). So I have an idea to increase the usefulness of the labs for everyone, while at the same time increasing the efficiency so that the same number of engineers can support 10,000 attendees.

The idea is to have attendees submit the questions that they intend to ask an engineer in a lab, to a special WWDC lab email address (along with their project source if applicable). These questions will be prescreened by Apple engineers (or even interns) way before WWDC. Some questions will be simple enough that an email response will be enough to answer them. For the rest, an appointment at WWDC can be scheduled with an engineer that can actually answer the question for the developer. In a lot of cases there will be duplicate questions that can be answered in a group session. This plan will reduce the need to have such a high ratio of engineers to developers while increasing the value of engineer and developer meetings. No more lining up to talk to an engineer that doesn't know any more about the problem you're trying to solve than you.

The only other logistic is how to fit an extra 5000 people ino the sessions. My plan there would be to expand to Moscone North and/or South, and make all of the rooms bigger. Same number of sessions, same number of engineers, just a larger audience. I heard developers this year talk about how long the lines were to get into each session, and that they weren't that long in previous years. But the consensus seems to be that Apple was just way better organized this year than in previous years and that the lines just looked longer than a massive mob of unorganized people. My point here is that Apple did a great job of moving the 5000 attendees around this year. If they increase the time between sessions a little, it should be possible to move 10,000 people around the 3 buildings efficiently.

Whatever the plan, I can't wait to attend WWDC 2013.

If you enjoy reading my blog, please follow me on Twitter, and/or like Cerebral Gardens on Facebook.


This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.