The first method works for regular apps. At the end I show a option if you’re building a framework/static library.

Easiest way: Use the Info.plist preprocessor. Add this as a Run Script phase at the top of your target (after Target Dependencies).

We’re using the output of git describe as the full version string (which can be anything, according to Apple), and the count of the total commits for CFBundleVersion, which should be numeric, else certain functions like Finder’s ability to find the lastest app version might break. Counting git commits is not the best way, but it works.

Then, enable “Preprocess Info.plist File” and add “Info.plist Preprocessor Prefix File” to “InfoPlist.h”.

Almost done! Add GIT_VERSION and GIT_COMMIT_COUNT to your Info.plist file:

Finally, you need to create the InfoPlist.h file once, else Xcode doesn’t compile at all.

That’s it! Note that you probably don’t want to use “1.x.x-00-g34g3343″ as a version for the AppStore. In this case, make a target for publishing and change the git describe to “git describe –abbrev=0 –tags” (this will return the latest tag – you DO tag your code, right?)

If you are doing more tricky things, like compiling your own static framework (I provide one for PSPDFKit), you need stronger weapons. Add this to your build script. No need for custom Info.plist preprocessing in this case. (I manually copy Info.plist into the directory, so the original plist file never gets changed.)

Thanks for everyone on Twitter helping me to get this right! This blog post on CIMGF was also pretty helpful.

Of you like posts like this, you should follow me on Twitter.

Related posts:

1. XCode opens windows off-screen?
2. Add a version timestamp with capistrano
3. Enable Clang in XCode

[cc lang="objc"]
if ([self.delegate respondsToSelector:@selector(pdfViewController:didDisplayDocument:)]) {
[self.delegate pdfViewController:self didDisplayDocument:self.document];
}
[/cc]

I consider this code smell, and it doesn’t get easier once you decide to change the delegate. While developing PSPDFKit (a commercial, extremely fast iOS pdf framework), i found myself in the situation of polluting my code with those delegate calls all over the place. There has to be a better way.

During my Twitter research, I fond some experiments like using an NSProxy or using _cmd as a shortcut. Using _cmd would imply that you name your delegate caller the same as your delegate method. THATS A VERY, VERY BAD IDEA. It’s often practical to extend a class and set the delegate to itself – in fact that’s the suggested way to customize PSPDFViewController. Using the _cmd trick would imply that the user calls [super ---] on every delegate – forgetting that would work most times, except when he tries to nil out the delegate on viewWillDisappear, and still receive messages (because there is no caller any more) – leading to very confusing errors.

A pattern that’s common in Apple classes is to pre-analyze the delegate, and remember which methods are implemented and which aren’t. I did some profiling and discovered that this is about twice as fast. In reality, you may not care, delegates usually are not called in tight loops, where you could actually gain some feelable performance with this task.

But we gain something else: clarity. Here’s my proposal:

[cc lang="objc" lines="100"]
// pre-process delegate
- (void)setDelegate:(id)delegate {
if (delegate != delegate_) {
delegate_ = delegate;

delegateFlags_.delegateDidDisplayDocument = [delegate respondsToSelector:@selector(pdfViewController:didDisplayDocument:)];
delegateFlags_.delegateDidShowPage = [delegate respondsToSelector:@selector(pdfViewController:didShowPage:)];
}
}

// single entry point to call delegate
- (void)delegateDidShowPage:(NSUInteger)page {
if (delegateFlags_.delegateDidShowPage) {
[self.delegate pdfViewController:self didShowPage:page];
}

// put this in header
struct {
unsigned int delegateWillDisplayDocument:1;
unsigned int delegateDidDisplayDocument:1;
unsigned int delegateWillShowPage:1;
unsigned int delegateDidShowPage:1;
unsigned int delegateDidChangeViewMode:1;
unsigned int delegateDidTapOnPage:1;
unsigned int delegateDidTapOnAnnotation:1;
unsigned int delegateWillLoadPage:1;
unsigned int delegateDidLoadPage:1;
unsigned int delegateWillUnloadPage:1;
unsigned int delegateDidUnloadPage:1;
} delegateFlags_;

[/cc]

So, this is much more code, what’s better?

• Instantly see which methods are implemented by the delegate.
• Calling [self delegateDidShowPage:1]; instead of the 3-line respondsToSelector improves code readability.
• Single calling function for delegates. Again, helps for debugging.
• Delegates can be changed much easier.
• Twice as fast!

Bonus feature: Because there’s now a single entry point, it’s easy to add a one-time deprecation warning (like an NSLog) to the delegate caller. That would be a PITA if you have multiple entry points.

I also experimented with further improvements, and you can squeeze out even more performance by using c-functions, and again more if you inline them. But it’s usually not worth it and the calling syntax doesn’t look nice.

Btw, I used mach_absolut_time to measure execution time. Don’t use NSDate for it, it’s too unprecise. (Some technical stuff: I used a tight 1-million for-loop to get some milliseconds to measure, and disabled optimization so that the if couldn’t be pre-optimized)

I’m open to comments. Is there a better way? Waste of time? Hit me up on Twitter! @steipete

Related posts:

1. Objective C != Operator overloading
2. Detect conflicting Objective C category methods
3. Objective C Blocks with Leopard 10.5 and iPhone 3.0

Currently it’s about 70% complete, and simple projects already compile. And the pull requests are already underway.
And because it’s from a working, living, money generating project, it won’t vanish anytime soon. Thank you, Iconfactory!

I added some initial helper macros for the parts for better code conditionals in PSFoundation (Categories, Macros and other useful stuff) And fixed the parts that don’t compile at all. This is going to be great!

The hardest part will be coding a replacement for NSFetchedResultsController; I started a stub w/o event handling…

No related posts.

In a nutshell, Apple now wants 30% of everything you purchase or use with an iOS device. And you are not allowed to make it more expensive to compensate the losses. If your margin is less than those magic 30%, you’re screwed.

Yes, for customers (short thought) it’s a good thing. You no longer have to give away your details (like name, address, credit card) and instead can use a payment provider you already trust (Apple) which handles everything and does not give away your contact details.

“Our philosophy is simple—when Apple brings a new subscriber to the app, Apple earns a 30 percent share; when the publisher brings an existing or new subscriber to the app, the publisher keeps 100 percent and Apple earns nothing,” – Steve Jobs

To keep a 70/30 cut for selling apps is one thing – here Apple offers service, like reviewing (hoho), distributing the app through their high-speed network, advertisement (if you’re lucky) and the whole AppStore-Infrastructure.

What do they do with In-App purchases? Handling your payments. No hosting, no additional service. That’s just not worth 30%. Google today launched Google One Pass, a solution for offering digital content – they take much more reasonable 10%. Paypal takes 3%.

Everyone’s talking about ‘publishers’ with these new App Store rules. What about vendors? They’re the ones getting royally screwed. – Jim Dovey, former developer of Kobo Books.

Many publishers and developers are screaming now, that Apple destroys their whole business. It’s because most businesses don’t have a 30% span they can share. So Apple is, in fact, asking them to lose money.

It’s also about process. Setting up IAP is a pain. Keeping it in sync with your library is even worse. And there are also limits – IAP allows up to 3500 items – Amazon Kindle currently has about 2,5 MILLION items.

I don’t see Amazon giving Apple 30% for just being on the iPad/iPhone. Furthermore, they would have to offer IAP at the same price to just stay in the store. Their current solution, which is offering a link to the Amazon Store that opens in Safari, is no longer allowed. (No external linking to the site shop).

So their only viable option: remove the App from the AppStore. Same for Netflix, Hulu, Pandora, Kobo, Zinio Magazines and many other services. This is bad for customers, and bad for Apple. And it makes me angry and sad. Damn it, it’s my device, I paid $$$ on it, and now they are taking away my apps. Not fair. It’s also utmost greedy – Apple’s not the company that would in any way need this extra money.

I genuinely hope that they end this madness.

No related posts.

In the end, money is the motivation why we all work. I earned good money at my last company, so why quit and go freelance? Cause I care about my work, and with freelancing you have a choice what and with whom you work for.

It wasn’t always easy, and I learned a lot. In fact, I am still learning so much every day. Fortunately, the mobile space is growing so crazy fast – most of the times I just have to say “no” to inquiries cause I’m already that overbooked. And being damn good at it supposedly helps, at least some customers argue. But to be really good at work, some factors need to be there:

Freedom to decide. Not every aspect, but its so tiresome if costumers think they know better, when in fact they simply don’t. Some freedom in features, design assures that you are able to care for the project. Let loose, give us some latitude.

Not too hard constraints on time. I don’t do apps that need to be finished “in two weeks from now”. When the most limiting factor is time, you pay big times afterwards, except maybe if it’s a trashy throwaway project. Especially with iOS, where the platform is iterating that fast, support is an issue and far more expensive if you have spagetti code.

Money. It’s a bad departure point if I feel undercharged to start with. I made that mistake a few times when I didn’t knew what I was worth. It’s generally difficult if you need to shoot a project price out of the blue. The better thing ™ is to be paid a daily rate. I tell my customers what I get per day, and how long I think it will take, with the best approximation I can do. They get my status reports and with techniques like Hockey (which I’m currently rewriting, but that’s another story) they can watch the progress.

If they suddenly want feature X instead if Y, i just tell them how much longer it will take. Those things happen, they did EVERY SINGLE TIME. With a fixed project budget you start arguing what’s included and what not, how much that would be extra, that you need a new contract – it’s a hassle. A daily rate solves this all. The greatest exercise is getting people to understand. Luckily I am in the position where a big company grasped this – it turned out great. (and I’m still doing stuff for them)

Please, if you have bitching customers, just send them a variation of this letter. If they don’t unterstand, move on.

Theme. I’m not interested in augmented reality. I don’t think it’s a good idea, i don’t use it, so I simply don’t write apps for it.  Sure i could write them, but why? Some projects are not paid that well – yet fascinating in some way, or need me to learn something new. Those are the ones I go for. You’re only getting shitty projects? Make one yourself! Damn it! It has NEVER been easier.

In fact, that’s my next big thing. I feel like iOS is my home now, it’s no challenge any more. I love writing apps and will continue thinking, designing, writing and publishing them. Part time.

My next “big thing” is already on the corner, with a new language (that keeps the Cocoa mindset), new challenges and a greate co-founder.  I’ll announce more soon.

No related posts.

Running it is rather unspectacular, all you see is a shadowed UITableView. It’s the libraries that are awesome; and for many of you there’ll be some new things to discover. It’s really useful as a kickstart for new apps. Feel free to fork and make changes; just contact me for what you use it.

Whats in the box?

• Localization for English/German pre-setup
• Xcode agnostic gitignore setup
• Completely setup autoupdating via Hockey, with custom Target for instant App-Distribution. All you need is to modify the ssh script in the BetaDistribute target and setup a server with the Hockey server parts: https://github.com/TheRealKerni/Hockey
• Integrated Crash Reporter Server sender. Just activate in PSDefines and https://github.com/TheRealKerni/CrashReporterDemo
• Adapted symbolicator for remove crash report symbolication
• Integrated super fast and efficient YAJL JSON parser

  http://lloyd.github.com/yajl/

• PSFoundation for all those little categories, reachability and co:

  https://github.com/steipete/PSFoundation

• Flurry for app statistics. Just add your statistics key to kFlurryStatisticsKey

  http://www.flurry.com/

• Custom logging (cocoa-lumberjack) with file logging and NSLogger integration See https://github.com/robbiehanson/CocoaLumberjack and https://github.com/fpillet/NSLogger
• RegexKitLite

  http://regexkit.sourceforge.net/RegexKitLite/

• asi-http-request for everything http-related; better alternative to NSURLConnection

  https://github.com/pokeb/asi-http-request

It’s on GitHub.

Related posts:

1. Use Xcode+git to automatically version your apps
2. synbolicatecrash troubles?
3. Cocoaheads Presentation: Hockey & Lumberjack

A more in-depth blogpost with all some technical details will follow soon. And hell, I even have the gloves

No related posts.

But wait! I’m using NSZombiesEnabled! Heck, I turned on every freakin’ debug aid i found!

While the app ran much slower with all that stuff turned on, i found nothing. Damnit! Couldn’t even sleep right with that feakin’ bug. So, we needed something bigger… and there is! Say hello to Guard Malloc! Check it with Run -> Enable Guard Malloc, and start a simulator build. You better turn off all those other helpers, as it’s going to be slow, and I mean really slow. I had to adapt my timeouts and timers to be slow, or else even login would fail.

And then… nothing again. Except that you literally fall asleep while trying to use the app. Guard Malloc really tries to make memory save. (And you’d better have enough RAM for the app). So i just sitted there, waiting.

And finally, half an hour later, i found it. An EXC_BAD_ACCESS within dealloc of one helper class. And within that, I found the stupidest greenhorn mistake you can do. EVAR. (Maybe it’s because this actually was my first iOS app, from 2008?)

So what the heck went wrong?

I called [super dealloc] in dealloc before releasing my ivars with [anIvar dealloc]. And that’s really evil. Or see the apple docs. After the NSObject dealloc (which super will somewhere down there call) our self pointer gets released. And If we are multithreaded (we are always) this memory may be already used by something else. A call like [ivar release] is automatically translated to the compiler to [self->ivar release]. So of self now is something different, we leak the old vars and release some stuff we really, really shouldn’t touch. And because malloc is highly optimized, there are no checksums or warnings that could recover from such an error, it just crashes, somewhere, somehow when trying to alloc that freed memory.

A one-line-fix that took he days to find. And you wonder why it didn’t crashed earlier on? Well, that helper classes… they leaked and got never released until I fixed them, thanks to clang static analysis…

Related posts:

1. Using GDB’s ‘po’ command while a malloc lock is being held

So, with Hockey (you’re doing it wrong if you don’t use it), there’s the script that autouploads the adhoc files on the server. And of course they get archived.

But ha! There’s the catch! Instead of naming them like

com.youdomain.app.1.0.0, change it to AppName.com.youdomain.app.1.0.0

Why, you ask? Well, symbolicatecrash is some perl crap and trunicates the appname after a dot. It’ll find you files, but not the executable within (it will search for “com” in the first example)

You’ll get errors (if run with -vv) like “Did not find executable for dsym” and “Warning: Can’t find any unstripped binary that matches version of …”

So, change lines of
$bundleIdentifier $bundleVersion.app
to
$executableName.$bundleIdentifier.$bundleVersion.app

and you’re good to go.

Update: And don’t forget to NOT use the symbolicatecrash from Apple, instead use this one.

No related posts.

Ab 1. Jänner gelten für Bestandskunden neue AGBs bei UPC. Wer nicht will, dass seine persönlichen Daten für Marketingzwecke, Bonitätsprüfungen und weitere Analysen bereitgestellt werden, sollte das dem Provider mitteilen.  (siehe ORF Artikel)

Update 1: Das ist keine Kündigung, es geht nur um Rechte, die sich UPC einverleibt, die sie nicht benötigen.

Update 2: Einer meiner Leser hat vorgeschlagen, dass man sich den Widerspruch bestätigen lassen soll, habe den Text dahingehend aktualisiert.

Widersprochen kann per Mail oder Fax, hier mit dem Text-Template:

[CC]

Meine Kundennummer: xxxxxxxxxxxx

Datum: TT.MM.JJJJ

Sehr geehrte Damen und Herren,

hiermit widerrufe ich die Zustimmung zur Verwendung meiner Stammdaten, Verkehrsdaten und sonstiger personenbezogener Daten, welche in den Punkten 19.6, 19.7 und 19.8 Ihrer ab 1.1.2011 gültigen Allgemeinen Geschäftsbedingungen formuliert ist.
Dies erfolgt gemäß dem darin zugestandenen Widerrufsrecht.

Ich erwarte von UPC eine Bestätigung per E-Mail, in der Sie meinen Einspruch zur Kenntnis nehmen und ihm Folge leisten.

Mit freundlichen Grüßen,
xxxxxxxxxxxxx

[/CC]

Related posts:

1. This Week’s Links
2. Raus aus dem T-Mobile/tele.ring Vertrag? Jetzt ist eure Chance!
3. Österreichische iOS-Entwickler