Our BlogTips, Tricks, and Thoughts from Cerebral Gardens

Dave Wood

Dave Wood

Founder + Developer at Cerebral Gardens

With the recent announcement of some App Store changes, and WWDC just days away, I figured I’d better write about an idea I had before it’s too late. I’ll keep this much shorter than the version that’s been floating around in my head.

I would suggest that Apple release their grip on the App Store, and start allowing other stores on iOS/tvOS which would, essentially create an App Mall. Open it up so that anyone can create a store. These will be distinct apps developed like any other third party app, clearly branded to avoid user confusion with Apple’s App Store. I envision stores created by brands you already know: TouchArcade, 148Apps, AppShopper, Google, Microsoft, Panic, OmniFocus, RelayFM (for sponsored apps) etc; as well as new ones that will appear.

These stores would be akin to radio stations. If a person likes Rock and Roll, they tune in to a Rock and Roll station. If they prefer Jazz, they listen to a Jazz station. Every once in a while you listen to something different. We’ll have stores that focus on pro apps, stores for games, a store for writers, developers, parents etc. Users will come to know and trust the curators of their favourite stores. This plan delegates some of the curation of apps out to the community where it can be handled much better (just because of sheer numbers). It doesn’t take away from Apple’s App Store curation, rather it enables a method to better group apps and aid with app discovery. Instead of trying to fit 2+ million apps into 25 categories, there will be another layer on top to help sort.

One huge side effect to this plan is that Apple would have more control over it’s own App Store. They will be able to delist a tonne of bad apps, and stop adding new bad apps by raising the criteria that allows apps to be listed in the official App Store. If an app is ugly as sin, riddled with spelling errors, etc, they can refuse to include it in their store, just as Saks Fifth Avenue can refuse to stock substandard products. Right now, Apple has a set of rules, and if your app follows those rules it should be allowed in the store. Ugly apps should never be featured anyway, but they still come up and clutter the search results, they still show up in the “Customers Also Bought” section. With my new plan, those apps won’t show up at all. It’s my belief that Apple has to generally accept any app that follows their rules, or else they’ll start to run afoul of anti-competition laws. Since there is no other way to sell apps to users with iOS/tvOS devices than through the Apple App Store, if they reject apps based on religious beliefs, politics, bad UI, etc, they are preventing other companies from operating, and could get into trouble.

It would sort of be like Panasonic selling a radio, and then saying no Justin Bieber songs can be played on them. How long would it be before Panasonic was dragged into court by the Department of Justice? So my point here is that because Apple would be allowing developers to list their apps in other stores, they’ll be free to be more selective in their own store.

None of this affects app review, signing, pricing or privacy BTW. All apps would still go through review (though it would be more for weeding out malware or buggy software). Apps would still be signed by the developers and installed from Apple’s servers. Just as the TestFlight app can install apps that aren’t in the App Store, third party stores would also be able to use an API to trigger app installs (securely of course, apps wouldn’t be able to install other apps without the user’s explicit permission). The price of an app would be the same, and the payment would still be handled by Apple. So privacy is preserved as Apple would still be the only one to know who the customer is. Apple could still take their 30% (or now 15% in some cases, hopefully more cases soon). The third party store developer would be compensated via the already existing affiliate program. Or depending on the store, they may charge the developer for a listing, just as grocery stores charge food producers for the valuable space on the end of the aisle.

The goal of this idea is to help with app discovery. By opening up the App Store in this way, it empowers the developers in our community to help solve this major problem that’s really hurting the platform, without compromising the security or privacy of the platform that users have come to expect.

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.


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.

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.