True confessions of a former iPhone developer

True confessions of a former iPhone developer

Summary: As of last Wednesday, I am officially no longer an iPhone developer -- which frees me up to tell you about my sordid experiences as an iPhone developer.

TOPICS: Apple, Apps, Smartphones, SMBs

The next two apps were DaysTo Baby and DaysTo Anniversary. These required the addition of a calendar screen, but that was just a little additional code. By now, the app development process consisted of creating a cute image for the screen, and copying the code for each new app, customizing for dates. I also had to design the app icons, and my wife (who's been a writer and editor for years) wrote the descriptive copy for the iTunes store (more on that in a while).

I did more holidays, like DaysTo Halloween, DaysTo Hanukkah, DaysTo Valentine's Day, DaysTo Thanksgiving, and DaysTo Cinco de Mayo. I didn't plan on doing any marketing, so I just wanted things that would show up in App Store search results.


Within a week of the apps appearing on the store (which took an average of 13 days), I started getting requests. A woman asked me to do DaysTo Divorce. A man serving in the Marines asked for DaysTo Discharge. And the head of a major movie studio (yes, you'd recognize it) begged me to do DaysTo Retirement. He had had it with that gig.


Others included DaysTo BBQ, DaysTo Concert, DaysTo Interview, DaysTo Taxes, DaysTo Presentation, DaysTo Spring Break ... you get the idea. Not exactly rocket science.

I did think about the idea of combining the apps into one bigger DaysTo app, with all the events. But the letters I got from buyers indicated that they really grooved on just being able to hit the icon and see the one thing they were strongly looking forward to. Pinpoint apps -- apps that do exactly one specific thing -- are often very popular with users, and I didn't want to build something cumbersome with a huge list of selections just because it was technically possible.

The one that got rejected

Before I tell you more about my career as an App developer, let me tell you about the one that got away. I wrote DaysOf Bush -- the one app that Apple wouldn't accept.

DaysOf Bush was an app that calculated the days until the end of the Bush administration. As a picture, I used the official White House photo of the then-President (sadly, I can't seem to find a screen shot of the app). The descriptive copy recognized that some people loved President Bush and others didn't -- as is the case with all partisan politics:

Whether you love him or you love to hate him, simply tap the icon and you'll immediately know how many more days of George W. Bush's presidency you'll be savoring or enduring.

Enjoy the heightened sense of anticipation or bitter sweetness, making this unique time in history just that much more fun.

Interestingly, I couldn't get this into the App Store. The key sentences in Apple's rejection were:

Applications must not contain any obscene, pornographic, offensive or defamatory content or materials of any kind (text, graphics, images, photographs, etc.), or other content or materials that in Apple's reasonable judgement may be found objectionable by iPhone or iPod touch users.

Defaming, demeaning, or attacking particular political representatives is considered inappropriate.

While I didn't think Apple's criticism (especially since I used Mr. Bush's official White House photo) was particularly appropriate -- and, for the record, I still haven't decided on whether I favor Mr. Obama or Mr. Romney in 2012 -- I also didn't care enough to make this app a major battle. I apparently didn't even care enough to save a screen shot.

The major takeaway for me was that it wasn't worth risking a lot of time coding if I couldn't be sure the finished app would be accepted.

Apple's miserable support

When you code iPhone apps, at least back then, you code in Objective-C. I've coded in many different dialects of C, and I can handle them all. But I don't particularly like Objective-C (it's a lot like someone welded two separate programming languages together and forgot to grind down the rough edges), and I don't particularly like using the Mac. Together, that meant that programming iPhone apps wasn't particularly enjoyable.

Shortly after I'd released my 40 apps, Apple released an update to Xcode. You need to understand something. When you pay your hundred bucks for developer status, Apple explicitly advertises that you'll get two support incidents, where Apple claims it will actually provide you with support.


They don't.

When I upgraded Xcode, my provisioning credentials were somehow corrupted during the upgrade. These are the software keys you need to compile and upload apps to the App Store. No amount of reinstalling or rebuilding the development environment would fix the credentials.

So I contacted Apple developer support through the appropriate channels. Even though I'd bought support incidents, Apple never replied. Ever. My support dashboard did indicate support incidents had been used. I think the first one triggered when I asked for help and never got any. The second one seemed to trigger when I then tried to tell them that I'd never gotten any help from my first support request.

So, I wasn't able to build more apps. Frankly, by then, I was pretty disgusted with the whole process -- more on that on the next page. App building wasn't my mainstream gig, and while I could have eventually gotten the problem solved (I have extremely good problem-solving skills) I didn't care to spend any more time on the problem.

Even though I've bought and paid for a total of eight support incidents, Apple has never -- not once -- responded to a single support request. This becomes even more of an issue, as you'll see on the next page.

Even worse, Apple -- at the time -- had some sort of weird restriction where you violated your development agreement if you published anything about iPhone development. No courses, no books, no forums, no nothing. There were a few underground forums out there, but there really wasn't much in the way of professional peer support.

It was ridiculous. But it didn't seem to matter to Apple nor its legion of app developers.

There's more to this story. We're headed for the bad and the ugly.

Topics: Apple, Apps, Smartphones, SMBs


David Gewirtz, Distinguished Lecturer at CBS Interactive, is an author, U.S. policy advisor, and computer scientist. He is featured in the History Channel special The President's Book of Secrets and is a member of the National Press Club.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Did you actually write 40 Apps, or just write one app.

    And change the graphics o it to suit a different "X". This whole "Days till "X"", would seem to get silly after a short while, ad Many probably saw your listings, and thought "tacky"
    Troll Hunter J
    • 40 apps... sort of

      Each is a separate app, meaning a separate bundle of resources uploaded to the App Store. In reality, there were two variants of code and resources: one for the single-screen app format and one for the two-screen format.

      To produce these, I cloned one of those formats, wrote an appropriate date calculation function, if necessary, added the pretty pictures, and called it a day.

      So, if you're asking if I did the heavy lifting to write 40 unique code bases, no, of course not. I spent just a month on the whole project. But if you're asking if there were 40 apps on the App Store that Apple separately accounted for and different users bought, yes there were.

      I thought I was quite clear on that in the main article.
      David Gewirtz
      • David, please correct one miscalculation:

        You say developers get 30% of the money paid by buyers, but this is a reverse case actually. Developers get 70%, so if you got $7000 it means that buyers paid $10000 overall.
        • Oops...did that before coffee

          Yeah, you're right. I'll clean that up. Thanks.
          David Gewirtz
      • What surprised me the most that I did not realize

        "Now that I've let my developer status lapse, these apps are no longer available on the App Store" That Apple requires you to continue to pay them to remain "a developer", (on top of their 30% cut) to continue to make the App available in the App Store.

        Is this normal in the programming world?
        John Zern
        • Depends on what you mean by 'the normal world'

          Normally you write an app and package it - then send it to stores at OEM pricing (the 70% price). They pay you up front then try to sell your product at a proft (adding on the extra 30% - although in the real world these percentages are entirely variable). So once you've sold it to the reseller, you're out of the loop.

          This is generally true even for 'download only' apps, although exactly how depends on whether you're hosting it yourself or you have some other company do the hosting and marketing.

          But tying this to 'developer fees' or 'developer status' is not the norm outside of specialised markets like Apple or Google...
          The Werewolf!
          • Or Microsoft...

            wouldn't want to leave the newest company to copy the Apple model, would you?
          • And a new screen identity, we see.

            what is this? 14 or 15 now?
            William Farrel
        • Better than terrestrial distribution

          Back in the day, when software was sold through retail stores like Egghead, you'd sell your software to a distributor (like Ingram) at a 60-65% discount off SRP. So you'd get 35-40% of the retail price. If you sold directly to a small store, you might get 60% of the SRP. In either case, Apple's 70% is more generous rate and is comparable with other distribution channels.

          Now, also, back then, you didn't have to pay to get distribution (technically), but you also had to buy your inventory (printing boxes and duplicating disks was darned expensive) and -- here's where it got bad -- many distributors demanded (and Best Buy and the like probably still do, your supermarket does) something called a "slotting fee". This was essentially a fee to buy shelf space in their store.

          So, they'd take a big discount and then require you to essentially rent space in their store.

          I have no problem with Apple's discount rate or their $99/year fee. My problem is they are completely unhelpful and unresponsive. Even in the worst days of predatory retail, you could get a call returned.
          David Gewirtz
          • Selective customer service...

            Do you suppose they put you in a triage of sorts? (i.e. Don't bother to help those that are making simple one-off, and mostly unprofitable apps)

            Or is it too speculative to assume that if you were a Rovio, you would get bumped to the front of the support line?
          • relevance?

            How much does this matter?
          • Spot on

            For many years I was involved with producing and selling small apps and extensions. It was hard work, global distribution pre-Internet a difficult proposition.

            Back then our good ideas were cloned as well. Much like the patent lawsuits of today it is difficult to defend copyright in multiple jurisdictions for the small player.

            Apple's App store has revolutionised the software distribution model. David's experience with dealing with Apple and their developer program very similar to my experiences with ADC many years before ( to be fair MSDN is no better for the individual developer).

            Copyright theft is what really hurts, I sympathise with David. I've had weeks of work on a workaround appear in competitor's solutions briefly after my products release.

            Whilst some things get easier, many challenges remain the same. A Mac mini might have been a better purchase for David upon reflection.
            Richard Flude
          • And sometimes you're forced to be an Apple developer

            I had no desire to publish iOS apps. We work in a variety of languages, but they are either Windows or server based. Our own software product develops HTML eLearning in a WYSIWYG environment, but is written in .Net.

            When we developed an eLearning module on Bushfire Safety for a government organisation we made sure that it was in standard HTML/Javascript and used either Flash or HTML 5 to run the synchronised audio/video. Then we start testing - no problem on PC or Mac or any tablet or smartphone that provided these features - except for iOS.

            iOS has a lovely little "feature" that prevents you from running audio or video in HTML 5 directly (no autorun on and tags). This is supposedly deliberate to prevent you racking up data charges, but in reality, it forces anyone who develops standard HTML modules that use audio and video to become an Apple developer, use Apple's second rate development environment on a Mac, wrap their standard HTML 5 app in a webview, turn off two switches and voila! You now have your same application, except in can only be downloaded from the iPnone store.

            Now mine was a free app, but I did have to pay to be an Apple developer and rent a Mac - all for a HTML app that runs on everything else - Android and Windows smartphones/tablets - including Win 8.

            I await each verison of iOS in the hope they've finally implemented full HTML 5.
          • WTB comments editor

            it removed the less than and greateer than signs form my text.

            the bracketed text should read

            (no autorun on the audio and video tags)

            This comment system is slower, buggier and provides a lot less features than the previous ones.
          • HTML5 itself isn't complete..

            We're going to be waiting a few years before we get a "full" implementation on the desktops as well.

            The intention of HTML5 is good, but in the end, it's the same old story wrapped in a prettier package. At the most basic level, there's really no difference between "plug in" and "built in" except for who's responsible for maintaining that bit of code.

            "Standards" aren't really standards when you have to have browser and platform specific code just because one interpretation of the standard is different than another's.

            I've encountered some challenges like the one you cited. To be honest, from a usability standpoint, it's probably a good idea to hide playing of media behind a user prompt anyway. But I do agree that Apple shouldn't be enforcing this at the browser level. Or, they should come to some compromise. iOS knows if you're connecting via wifi or cellular. They *could* integrate that check into the browser experience when deciding if they should allow an auto-play type feature.
  • Probably the best article I've seen on a tech blog in months

    Seriously, I really thought it was informative and very interesting. Congrats on a well written piece.
    • Ditto

      I completely agree.........Calfee
    • Oh yeah!

      I hope Zdnet takes note. This is the kind of stuff we want to read not just opinionated fluff that is churned out in minutes. Brilliant article, and I guess the author is very well adjusted not to be pissed off by his experience.
  • The fact that he made $7K

    from a series of rebranded little countdown apps that required minimal effort really has me considering getting into iOS development.

    I agree the article was well written and David put some effort into full disclosure (e.g. admitting to getting sucked in and buying a more expensive Mac than was needed). However, from various articles about pirated apps, copycat apps and fake, malware infested apps on Android, at least some of the issues he outlined don't seem unique to Apple. Be curious to hear from other iOS developers on the support side of things.
    • early mover advantage

      you do realise that the majority of sales came before there was competition? that the same amount of effort now only yields the cost of a pizza a month? do you understand the concept of amortising investment?