Category: Business

App Updates for iOS 7

Like many of my fellow developers, I am in the middle of an update of an app for iOS 7. As you’d expect, it’s a lot more work than previous versions of iOS. But results are stunning: both David Lanham and I have commented that our shipping version was “feeling old and clunky.”

While cranking along on the update, a couple of thoughts occurred to me: how many other developers were doing the same thing and were they going to commit fully to iOS 7? The depth and breadth of the changes in iOS 7 makes it difficult to support older versions of the OS.

So I just asked. I also included a simple question that any developer who was actively working on an update would be able to answer as a sort of CAPTCHA.

After a little over 24 hours, I had my answers:

An overwhelming number of developers are updating apps for iOS 7. Of 575 valid responses, 545 developers indicated that they were working on an update for iOS 7. That’s an adoption rate of 95%!

Of those developers who were working on an update, I then calculated how many were going to require iOS 7 (and drop support for iOS 6):

Just over half of developers (284 of 545) were leaving the past behind. Initially I was surprised that this number was so high, but then I remembered how much time and effort I was putting into my own work :-)

If you’re a consumer of apps, this is great news: it’s likely that your favorite apps will be ready for action come this fall. If you’re someone who has a device that’s a couple of years old, now’s the time to start thinking about upgrading. Many apps will require a device capable of running iOS 7.

After I posted the survey, I heard from several game developers who complained that they didn’t know the answer to the trick question: UIView -tintColor is only used in traditional interfaces. Most of the difficulty in adapting apps is changing navigational and content elements to match the new style. Games don’t have this problem: they’re basically all content. Considering these facts, my guess is that games will have much broader support for older versions of iOS.

If you’d like the raw data and my analysis using Numbers, here you go: iOS_7_Updates.numbers

Written on August 2nd, 2013 for Advice, Business, Development

The Rise and Fall of the Independent Developer

I’m old enough to remember a time before the Internet. I know what it’s like to develop software both with and without a worldwide network.

Little has changed with the process of software development since the 1980’s. Of course there have been improvements in our tools and techniques, but the basic act of creating software products is much the same. What has changed dramatically in the past 30 years is how we distribute our creations.

In the days where software was distributed on magnetic media, such as reels of tape, cassettes, or floppy disks, it cost a lot of money to get the product to a customer. As a result, large companies and software publishers were the only ones with the financial resources to get these applications into a retail channel. There were very few independent software developers; and those who did exist were very small operations.

Then along came the Internet and everything changed. Distribution was suddenly cheap.

I remember a conversation with my good friend Cabel Sasser a few years ago. He and I were reminiscing about our first foray into online distribution and were surprised that we had the same initial reaction: “Holy crap! We can put our software on the Internet and people will actually buy it!”

Many other developers had this same experience and began leaving large companies to work on their own. Making a good living while having the freedom to work on their passion was a great life.

Now distribution is going mainstream with the App Store. And it’s already begun changing the lives and businesses of independent software developers. On the surface, it all looks good. There are more customers, increased revenues, and many great new products.

But this expanded distribution is also putting our business at risk: there are people in this new market who claim a right to a part of our hard work. Either by patent or copyright infringement, developers are finding this new cost of litigation to be onerous.

The scary part is that these infringements can happen with any part of our products or websites: things that you’d never imagine being a violation of someone else’s intellectual property. It feels like coding in a mine field.

From our experience, it’s entirely possible that all the revenue for a product can be eaten up by legal fees. After years of pouring your heart and soul into that product, it’s devastating. It makes you question why the hell you’re in the business: when you can’t pay salaries from product sales, there’s no point in building it in the first place.

So, just as in the days of magnetic media, the independent developer now finds him or herself at a point where it is again becoming very expensive to distribute their products to a mass market. This time the retail channel itself is very cheap, but the ancillary costs, both financially and emotionally, are very high.

And, of course, only large companies and publishers can bear these costs. My fear is that It’s only a matter of time before developers find the risks and expenses prohibitive and retreat to the safety of a larger organization. We’ll be going back to square one.

Over the years many of the top selling apps have been created by independent developers, starting with Steve Demeter and Trism at the App Store launch, and continuing to this day with titles like Tiny Wings by Andreas Illiger.

Losing that kind of talent and innovation to a legal system is the real crime.

Written on July 13th, 2011 for Business, Development, Opinion

Predators

Dear Steve,

I’m one of the developers that is affected by the Lodsys patent infringement claim. I’m writing not to beg for your support, but rather to give you a better idea of how this legal action affects the average iOS developer.

We’re a small company. We have 12 employees that have created 14 products for Mac and iOS. We have been incorporated in the state of North Carolina since 1999. We won an Apple Design Award in 2008.

We’ve been doing product development long enough to know that legal expenses are just a part of doing business. But as we both know, the costs of patent litigation can be staggering. As a small company, we don’t have the resources to defend ourselves, so that leaves us with one option: to pay a licensing fee.

And that worries us and every other iOS developer we know.

In and of itself, paying half of a percent of our App Store sales to Lodsys isn’t going to put us out of business. The fear we have is that this is the first step on a very slippery slope.

It’s well known that the top titles in the App Store can earn tens of thousands of dollars per day. There are many predators with dubious patents who see dollar signs when they look at the flock of iOS developers.

What these predators don’t realize is that for every developer who’s earning millions, there are many thousands who are earning much less. This backbone of the iOS ecosystem is doing well with work we love, but that is very much at risk with increased legal costs. We wonder what happens when these predators discover that the earnings from these apps are much lower than they expect. Will the licensing fees increase as a result? Will our next infringement be 5%, 10%, or more?

Of course, this is also a slippery slope for Apple. Taking on a legal burden for an entire platform is not something we would want to do, especially when the root of the problem is a screwed up patent system.

We love developing products for iOS and the Mac, but this legal mess has already started killing that enthusiasm. Apple has revolutionized the distribution of software via the App Store and that has been a great boon for smaller developers. It makes us furious that these greedy predators can put all of that at risk with patents.

Thanks for your time,

Craig Hockenberry

Written on May 23rd, 2011 for Business, Development, Miscellaneous

UDID not

Here we are on the brink of a new iPhone OS product introduction and developers are facing yet another crunch with device IDs for Ad Hoc testing.

Apple currently lets each iPhone developer, whether a company or an individual account, assign 100 devices for testing purposes. A large chunk of those available devices get used by employees with multiple devices. We also have a valuable group of external testers that we use for Ad Hoc beta testing. Many of these individuals buy the latest and greatest hardware, so each time there is a new product introduced, we use up more devices from our list.

On April 3rd, almost everyone on our beta test list will be buying an iPad and want to run Twitterrific on it. Unfortunately, some of these testers are going to be out of luck because we don’t have enough devices left to allocate. I have no idea what we’re going to do if the next version of the iPhone OS is introduced before our iPhone Developer account gets renewed.

As a developer, I never like turning a valuable tester away from my product. But that’s what we’re doing now.

To be clear, I think Apple’s policy is justified. Developers were abusing the system, so something had to be done. The problem, in my mind, is that the throttling valve is being put on the wrong piece of pipe.

As developers, we want to maintain a pool of testers, not devices that they test on. Devices are ephemeral: they change as new hardware is introduced and replaced. The thing that remains constant are the people who test our products.

A tweet from Mike Piontek crystalized this thought: the limitation for Ad Hoc provisioning should be based around individuals, not the devices that they own. It makes more sense to regulate Apple IDs rather than UDIDs. I want John Gruber to be able to run my apps on whatever devices he currently owns. I want to put my own name on the provisioning list and enable the five iPhone OS devices sitting on my desk. All that Apple cares about is that are only 98 other people besides Gruber and me.

(I suspect that Enterprise IT has similar problems and would welcome a solution based on employees rather than the hardware they own. I can only imagine the headaches of managing thousands of devices.)

Of course, there’s a huge amount of infrastructure around verification based on UDIDs: the Program Portal, device firmware, and our own internal processes would require changes. But I think it’s a good goal to work toward, because the current system isn’t scaling well and will only get worse as Apple introduces new products.

Updated April 13th, 2011: It’s been over a year and the situation just keeps getting worse. Please take a moment and duplicate rdar://9255432. Thanks!

Written on March 22nd, 2010 for Business, Development, Observation

Waving a red flag

As a result of my last essay, it has come to my attention that there is a simple and effective way to get Apple’s attention for critical bug fixes. An email to appreview@apple.com that explains the critical problem and which product is affected will help speed your update through the system.

Use this email address only for issues with application reviews. If you have a problem with iTunes, getting paid or any other part of the App Store business, use the Contact Us section of iTunes Connect.

Don’t abuse this important communication channel, or we’ll lose it.

Written on July 23rd, 2009 for Advice, Business, Development
Newer
Older