Aleksandar • Vacić

iOS bits and pieces

How to symbolicate watchOS 2 extension crash logs from device

I’m working on the next version of Run 5k app, which includes standalone watchOS 2 app. In current Xcode 7 beta 4, it takes 30-40mins for the watch .app bundle to get copied from iPhone to the watch device. No idea why it takes so long; it’s even called out as issue in Xcode 7 beta 4 release notes (they promise it will be resolved in future seeds).

The main problem with this is that debugging is next to impossible. Due to this you can’t realistically debug with the devices attached to Xcode so the only way is to install the iOS app, let it copy the watch bundle over and then use the app once it’s done.

My last-night test ended in a very repeatable crash. Great. Crashes from the Apple Watch are always copied to its paired iPhone and you can get them by connecting the iPhone, then opening Windows / Devices in Xcode, then tap “Show device logs” button.

Xcode then goes and symbolicate each .crash log file for you. However, in my case it symbolicated everything except my own code.

I am speaking at VoxxedDays Belgrade 2015

A lively local bunch have taken on themselves to organize a tech conference in Belgrade, at start of October.

Why you should care?

If you are interested in one (or more) of the myriad of topics announced so far, you should get yourself a ticket, which are still in the early bird phase.

Second – have you seen the awesome illustration used as background for the web site? It perfectly illustrates the vibe this conference aims for. :)

Third – October is one of the nicest months to visit this city. Plus the venue is amazing, right in the heart of the downtown Belgrade. If you are unfimilar with Serbia, checkout #MySerbia hashtag on Twitter.

Fourth – I’m speaking on it. ☺️
My talk will be on WatchOS 2 apps with emphasis on what you should do to have a good chance of being featured by App Store editors.

I hope I have at least picked your interest and hopefully will see you in October.

Masterclass: iOS development in Objective C

That’s one pompous title, I admit. But I have no better idea how to call this series of posts I wanted to write for a long time. So let’s add a bit of context to it:

…for non-Computer Science developers.

I’ve been working on ObjC/iOS apps for a very long time, since day 1 of the iPhone SDK. Before that, I was (as it’s now called) front-end developer for 15 years, mostly working in HTML (since 2.0 times baby), witnessed the CSS birth and rise. Been part of the first batch of Javascript developers back in Netscape Navigator 2 then all the way through its rise into plethora of framework abominations “real” (sic!) developers made out of it when they were forced to use it. I did it because I was a designer at first, an UX designer at heart and web was new and exciting canvas for both.

You can see one thing missing from this retrospective. I was never a Computer Science student.

App Store pricing rules

Today’s post by Dan Counsell on his excellent blog touched on the subject I have analyzed long and hard, for months now: app pricing model. While his posts are usually very reasonable and grounded thinking I agree with, I found this one to be written from the position of a successful and well press-connected developer.
Most iOS developers will not be in that camp. They will be in my camp of devs making quality apps but being way out of limelight. Thus I think it may be worth it to you to hear a different opinion and try to find your way somewhere in between.

When launching new app, Dan recommends to go with the lowered introductory price. Say if you plan to charge 4.99, launch with 1.99. This will work only and really only if you have entire relevant press ready to write about your app. Blogs like MacStories, Mac Rumors, iMore, App Advice and/or heavyweights like Tech Crunch, Mashable, The Next Web or influencers like Daring Fireball. Or if you have an existing customer mailing list of 100k+ people.

If you don’t have such leverage, launching at discount is the worst thing you can do for your app business. The starting price is the precedent you make upon which all your future pricing will be judged. Do you see brand new movies or albums being launched at 50% off? Do you see TVs or cameras being launched with introductory discounts? No, because it makes no sense.

The launch price should be the highest ever price you intend to charge for the given major software version 1

Continuing from this, Dan recommends: “Putting your app on sale three or four times a year can give your bottom line a much needed boost.”

Err – no, will not. The same press-coverage factor comes to play here too. Unless you are already very big name and have a lot of press ready to write about your sale, the only thing that discount sales will get you is lowered income. Even worse – you may actually alienate your original customers who did not get the deal.

Don’t do sales unless accompanied by large marketing campaign.

Tweetbot or Clear going on sale will be a success because this will be mentioned everywhere, on blogs like Mac Rumors where even a sidebar mention is a huge deal. My Banca or Unitica going on sale will be mentioned by no one.

Lastly, pricing. That topic is very hand-wavy but there are few lessons I can share from multi-year and multi-app experience.

First, go see this talk by Michael Jurewitz and read his 5-part story on pricing as well.

Forget anything below $4.99.

Just don’t bother. Go with freemium app if the niche you’re entering is very crowded but your IAPs should also be $4.99 or above. Between Apple’s 30% charge and the taxes you need to pay, even a fiver is very low price.

If you do freemium, you actually need to charge more and need to be very, very clever how you position your pay steps. You need to offer enough for people to recognize the value but put the paywall at just the right place to make it worthwhile to pay up. Every app is a world for itself and there is no formula that will tell you what that place is. You need to find it for your app. And target for 10% conversion between people that will start your app at least 5 times and those that will pay. Price accordingly.

I’m at the end of the process of updating my apps and moving the prices up. I have low number of downloads, low number of actual customers. I make quality apps and target people valuing that quality. The volume and discount game is for rich and famous.

  1. A good call by Brian Oppenlander here. If you continue to improve your app, it’s quite OK to increase the price since the value has increased too