Why Should Apple Consider App Upgrades

When we released the Mark II Artist’s Viewfinder as a new app in the fall of 2013, we faced quite a backlash from angry Viewfinder Basic/Pro/Cine users who demanded free upgrades until eternity.

The problem was, and still is, that one can’t innovate in the “pay once, upgrade for free forever” model. Especially in the professional app area, where downloads are not counted in millions, and development is really expensive. Relying only on new app sales does not result in a sustainable business on the long run, or will result in tombstone apps with no updates for years.

This is bad for all three involved parties: users, developers and Apple.

Fast forward to the fall of 2014. With iOS 8 the App Store introduced an exciting new feature, called bundles. Developers quickly figured out that this feature could be used to offer upgrades. We introduced Mark II Artist’s Viewfinder upgrades at the end of November.

As it turned out quickly, users love it (the number of complaints went to zero from the weekly 1-2, no bad reviews, etc). And as you can see on the following graph, we love it too.

Monthly profit increase thanks to upgrades

Monthly profit increase thanks to upgrades (in %)

On average, upgrades increased the app’s profit by 42% during the last 12 months. That means that Apple also earns more money selling this app, so they should also love it.

Upgrades are a well established way to make a software business sustainable. It has clear benefits for all involved parties in the professional software area. Even in niche markets, like ours. Maybe things are different for games or worthless farting apps, but I have no experience with those.

I would really welcome a real, proper upgrade pricing model for the App Store, so that we don’t have to fiddle with suboptimal hacks. Oh, and please introduce that to the Mac App Store as well.

But until then, we keep to offer upgrades using the bundle method to keep our loyal users, Apple, and ourselves happy.

iPhone 6 Slow Motion as a Visual Debugging Tool

In iOS app development it is imperative to get animations right. No question about that. Otherwise your app will look ugly and out-of-place. But debugging animations and transitions can present some headaches.

For the non-developers reading this: debugging is the act of examining the app with special tools to pinpoint problems. It usually involves slowing down or even stopping the program execution to the point where the developer can check and see how things are going.

For my custom animations I usually slow down the speed to check that everything is happening according to the choreography I have in mind. But there are a few places where I simply can’t do it. Case in point: navigation controller pops.

IMG_0138As I implemented search in my Mark II Artist’s Viewfinder app, I had a feeling that’s something goes wrong when I select a camera in the search results list and the navigation controller moves back to the virtual camera configuration screen. Something seemed to be under the search bar during the animation, but 0.3 seconds was hardly enough to see it.

Like in love – all is fair in debugging. So I picked up an iPhone 6 from our test device pool and recorded my 6 Plus’ screen during the animation – in SLO-MO mode at 240fps.

You can see a frame from that video on the left – and no, nobody will laugh on you when you record movies in portrait orientation for debugging purposes…

It’s noisy crap because it was recorded during Thursday evening, with the only light source in the room besides the phone’s screen itself being my monitor.

The search screen goes away horizontally to the right, and the keyboard slides down. There are some motion artifacts in the direction of the movement, but you can clearly see part of a second copy of the search bar under the real one (top right corner). This was due to not taking the status bar’s height into account when positioning the snapshot used to persist the search display controller’s image during the animation.

Bottom line: the iPhone 6’s high speed recording capability is something I will utilize more often for debugging.

Running Perforce on FreeBSD 10

Yesterday I updated our company server to FreeBSD 10. It went pretty well with only a few glitches: had to remove libiconv (documented in UPDATING) and some of the ports (such as Perl 5.16) needed manual recompilation as portupgrade failed on them.

But I quickly discovered that Perforce does not work – attempting to start the server produces the error message:

Shared object "libstdc++.so.6" not found, required by "p4d"

The reason is that FreeBSD 10 includes a new C++ stack and gcc, including libstdc++, is not installed by default.

So the problem is easy to fix: install lang/gcc from ports. This will bring back libstdc++ and Perforce will run smoothly again.

Update 4/23/2014: Perforce version 2014.1 has a FreeBSD 10 specific build, which does not depend on libstdc++.

Forcing Xcode to Use Downloaded DocSets

Since Xcode is available from the App Store, developer documentation is a separate download. As is command line tools. When you first start Xcode it starts to download them. But during the latest AirPort Extreme firmware fiasco I realized something shocking: Xcode does not use the downloaded docsets at all! You can try it for yourself: disconnect your Mac from the net and try to access any of the docs.

This is a huge problem if you want to do some work in a network-less location (on a plane for example).

Why?

The Xcode app installs a stubs for the docsets, so that you can begin to use them right off the bat. These stubs contain just the table of contents and get the actual pages off the web. The problem is that even after downloading the (almost) full docsets, Xcode still uses these stubs. I said almost, because even the full docsets have some parts missing: such as OS X man pages (which is not a big deal, just use man for those).

You can check the currently used docset locations on the Xcode Preferences pane: go into Downloads | Documentation, click on a docset name, and click on the triangle on the left below the docset list. This will bring up some information about the given docset. Scroll down to check “Installed Location”: if it shows that the docset resides inside Xcode, then you have this problem.

The Fix

Fixing this is easy:

  • Quit Xcode.
  • Find and remove all docset bundles from your Mac. You’ll find them in /Applications/Xcode.app/Contents/Developer/Documentation/DocSets (these are the stubs) and ~/Library/Developer/Shared/Documentation/DocSets (these are the downloaded-but-not-used ones).
  • Start Xcode and open the Preferences pane. Under Downloads | Documentation tab you can download the docsets you plan to use. Now if you check the “Installed Location” it should show that the docsets in use are the downloaded ones from your home folder.

Of course you’ll have run these circles after each Xcode update – until Apple fixes the problem.