Hacker Boss | Developing software and managing development teams.

Why Apple Doesn’t Want Your App

Monday, April 12, 2010

So you make an iPhone app, and it doesn’t enjoy the success you think it deserves. Or you make an app, and you create a technology framework on the side, and they ban your framework, and your app and framework don’t enjoy the success you think they deserve. Here’s why.

First, a detour to clarify what Apple makes money from. For perspective, let’s look at Microsoft first.

Microsoft is, and has pretty much always been, in the business of selling Windows. Microsoft wants PCs to be cheap, so they can sell more Windows. The whole PC and peripherals market is fiercely competed and the profit margins for hardware vendors are really low. That’s been working out nicely for Microsoft, since most PCs still ship with a version of Windows included, and Windows is making tons of money.

Microsoft is also in the business of selling Microsoft Office. In 2008, Microsoft made as much money with Office as it did with Windows. Kind of like the fax machine was (and still is in some parts of the world), Office is the standard method of information interchange in the business world. Just like the fax machine, you need Office because everyone else has it, too.

Apple, on the other hand, is in the business of selling hardware. Despite their recent high-profile focus in the iPhone OS software, Apple is very much a hardware company.

So let’s get this straight: Apple is not making a lot of money off the App Store. Apple is not even trying to make a lot of money off the App Store.

Apple wants apps to be a cheap commodity. When there are a lot of cool apps around, and they cost next to nothing, it really makes you want to go buy an iPhone, doesn’t it? Useful, cheap apps sell more iPhones. Microsoft is the opposite: cheap hardware sells more Windows.

In this light, I find it strange how Apple is conducting some of their business towards the community of independent software developers. The latest ban on using anything but Objective C, C, C++ for native apps, for example, strikes me as quite strange. By which I mean it strikes me as completely idiotic. Banning programmers’ favorite tools is stuff which makes talented developers call it quits and stop working on the iPhone platform. How can that possibly be in Apple’s business interests?

Many iPhone developers seem to be driven by the “publish an app and get rich quick” myth. However, the app market is fiercely competed. In order to make any significant money on the App Store, your app must be really good, one of the first of it’s kind (if not the first), and you must be lucky. This is App Store poker. It’s like trying to win the World Series of Poker by entering a satellite freeroll. It can happen, but I’m willing to be it won’t happen to you.

Is App Store poker enough to maintain a steady influx of apps to iPhone OS? Oh yes, it is. It is more than enough. Like with their hardware, Apple wants the apps to be about quality, not quantity. Robert Scoble says:

So, what does Apple need? Is it more apps? No way. At 130,000 apps Apple already has enough apps to keep a sizeable lead for years over its competitors like Google’s Android OS.
No, what Apple needs is better quality apps. So, does Apple care about templated apps or ones developed in Flash or some other cross-device language/system? No way.

Apple doesn’t want your app because your app sucks. Probably. Statistically, anyway. Most apps aren’t anything special, why should yours be any different?

{ 9 comments }

If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.

Is Your Regex Matcher Up to Snuff?

Tuesday, March 16, 2010

Did you know that your regex matching library may suck? Most libraries do, in certain circumstances, suck exponentially. This came to me as a great suprise when, a long time ago in the olden days before Google, iPods, and salmon skin leather, I was researching regex matching engines hoping to find a good one for use in a real-time system.

I’ll illustrate with a dusty ten-year-old picture from my Master’s Thesis:

Horror! When I showed this to my colleagues, they didn’t believe it. Everyone just sort of assumed that the regex matchers they were using every day would, you know, work. The lesson here is that some regex matchers take potentially exponential time to find a match, while others always take linear time.

This picture may be over ten years old, but the world of regex matchers hasn’t really changed a whole lot. Virtually all libraries included in programming languages or their standard libraries use so called “backtracking” matchers and suffer from this performance issue. Python, Perl, PCRE, PHP, Java, and Ruby all come with a backtracking matcher. An infinite number of combinations of regexes and input strings exist which completely choke these matchers. For a detailed explanation, I recommend Regular Expression Matching Can Be Simple And Fast by Russ Cox, where he also has these better pictures (note difference in y axis scale in the two images):

Time to match a?ⁿaⁿ against aⁿ

So when does this behavior matter? If you let untrusted users supply regexes, you may have a security issue in your hands, a denial-of-service the very least, if your library is bad. If you want to be sure your program won’t run out of memory or out of time, no matter what regex you throw at it, you cannot use the built-in libraries.

Luckily, there are some good efficient regex libraries which guarantee linear time matching and fixed memory usage:

RE2 by Russ Cox, released 2010
The Plan 9 regex matcher by Rob Pike, late 1980s, early 90s?
TRE by me, released 2001

Others may exist, but these are in library form. RE2 is mostly PCRE compatible. TRE is POSIX compatible, and also supports approximate matching. The Plan 9 matcher has its own API.

So, there you have it. Parsing text is one of the things which is best done with a suitable theoretical background. You can’t parse HTML with regex, and you cannot efficiently parse a regular language with a backtracking matcher.

{ 10 comments }

If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.

Metric of the Month: Duplicate Code

February 10, 2010

There are few hard and fast rules in software development, but this one comes close: don’t copy and paste code. Keeping multiple copies around within the same code base is almost never a good idea.
Question is, do you have duplicate code in your code base? How much would you be willing to bet?
Recently [...]

6 comments Read the full article →

Should You Be a Generalist Or a Specialist?

January 15, 2010

When I was a young student, I had a fashionable infatuation with martial arts. One day at the dojo I was busy practicing a particular punch to the side of the neck. The teacher watched my repeated fumbling for a while, and finally pulled me aside and gave me one of the best [...]

22 comments Read the full article →

Building High Performance Software Teams

December 24, 2009

A matrix organization allows you to build teams with a high degree of specialization and top-notch skills, plan your resourcing easily, and encourages sharing knowledge between product teams. A matrix organization is great. Except that it’s not, not for developing software.
It’s not great when coders don’t do any testing because it’s the QA department’s [...]

14 comments Read the full article →

The Silver Bullet That Wasn’t

December 8, 2009

I have a confession to make. I occasionally fall prey to a most basic mistake: I think a tool will solve a problem before I even understand the problem. Here’s what happened this time…
Like any company, we have an intranet. Ours is a motley collection of internal websites and tools: we have a [...]

8 comments Read the full article →

If Your Code Crashes in Production, Does it Make a Sound?

November 18, 2009

Meet Frank. Frank works as a product manager at Faxes-R-Us. He’s finishing up a presentation on their latest fax machine model: FRU-1221i with integrated Twitter and Facebook support. This one will sell like hot cakes.
Frank’s presentation is due tomorrow, and he’s now trying to include pictures on some of the slides. [...]

4 comments Read the full article →

The Three Doors of Type Systems

November 11, 2009

Every so often, I get drawn into a discussion about the merits of static typing (Java, C, C#, ML) versus dynamic typing (JavaScript, Python, Ruby, Scheme). Many programmers seem to be firmly in one camp or the other. But somewhere in between, there’s a third door. Let me explain…
I hate dynamic typing.
Dynamic [...]

4 comments Read the full article →

Hashed Bits becomes Hacker Boss

November 9, 2009

I decided to change the name of this blog to something more descriptive and less “meh”. This blog is about developing software and managing development teams. That is, about hacking, and about being a boss. Frequently at the same time.
It is likely that RSS subscribers will see old posts coming up [...]

0 comments Read the full article →

The Essence of Lambda

November 6, 2009

When I was studying Scheme on a programming course at HUT, I remember I was a bit baffled by first-class functions. My previous experiences were with C, Pascal, Basic, and other languges which didn’t have first-class functions. Data is data, code is code. You don’t go mixing those two. Why would [...]

5 comments Read the full article →

← Previous Entries

Developing software and managing development teams.