Blog

Pump Up the Volume

If you’re an iOS developer or part of a team that creates iOS apps, you know how difficult it can be to distribute those apps to devices outside the App Store.  For review and testing, Ad Hoc distribution can be a headache, even with wonderful services like TestFlight and Hockey.

But final distribution can be painful as well, especially if you’re distributing apps to clients outside the App Store. I understand why Apple wants you to use their store, but a lot of our clients are enterprises and businesses that do not want their apps publicly available.

You can use Enterprise distribution if your client has an Enterprise license, assuming they also have a solid IT team who can make sure everything runs smoothly.  But smaller teams often don’t have these licenses. Many of us have tried using something like TestFlight, but Ad Hoc distribution is just not meant for anything other than testing and review.

So what is a developer to do? That’s where Apple’s Volume Purchase Program comes to the rescue!  Never heard of the VPP? You’re not alone.  It's become apparent to us through MeetUps and other discussions that a lot of developers and companies are simply not aware of the program and what it can do for them.

From our perspective, we’ve really come to see it as the way to distribute any production-ready app if you’re not publicly available and you don’t have an Enterprise license. Here’s how Apple views the VPP:

Whether you have ten employees or ten thousand, the Volume Purchase Program makes it simple to find, buy, and distribute the iOS apps...your business needs.
The Volume Purchase Program also provides a way to get custom B2B apps built by third-party developers to meet the unique needs of your business.

The program has actually been around for a few years, but it initially required a minimum charge of $9.99 per app per user.  That just wasn’t an option for a company like us, though $9.99 per would be great for one of those clients with ten thousand users! ;)

So last year at WWDC 2012, Rick and I were very excited when Apple announced that they were removing the minimum charge. It took us a while, but we’re finally rolling out apps for clients using the Volume Purchase Program. It's not hard, per se. You follow a similar process for submitting to the App Store, using iTunes Connect, where you select the Custom B2B App checkmark to specify it for VPP.

We did encounter some snags the first few times, however, and I’m outlining them below so that hopefully it becomes easier for anyone else out there trying it out.

  • You MUST specify VPP customers—You cannot just upload an app and handle distribution yourself. You are the developer, and you must specify who your customers are in order to distribute the app. We tried to make ourselves our own customer but Apple was pretty strict about keeping that separation.

  • Your customers need special VPP accounts—They need to be Apple IDs created specifically for VPP.  According to Apple:

For a custom B2B app, you must enter at least one Apple ID that was created for use with the Volume Purchase Program (the Apple ID is usually an email address). This app will only be available to the Volume Purchase Program Apple IDs you specify here (you can add as many as you would like).

For our usage, we asked our client for an e-mail address from their domain so we could manage their end of VPP for them. It’s not difficult, but many clients just want the app. They don’t want to have to manage anything on iTunes to get it.

  • You go through the same review process—Prep your customers with the same speech you give regarding App Store submissions (ie, Yes it takes this long. No there's nothing you can do to speed it up)! This also means you have to have your icons, screenshots and information ready when you submit.

  • You have to set up everything under Contracts, Tax and Banking—This was the most confounding for us. We set everything up, our apps were uploaded, reviewed, and approved, yet we could not see them on our customer’s dashboard. It was only after doing some research when we realized we had to complete that entire section, even though the app was free. Once that was done, the app was available.

  • You generate Excel spreadsheets filled with redemption codes—Seems a little 1995 to us, but that’s how you distribute redemption codes. The client specifies how many apps they want to “purchase”, and the service generates a spreadsheet with all the requested codes. Archaic? A bit. But guess what? No more UDIDs!

Like a lot of what we do, this isn't rocket science. Hopefully you're reading this and thinking, "Duh, it all makes sense to me." More than anything, we hope more of our colleagues become aware of this really cool alternative for app distribution.

 

Insights into the 2013 iOS Developer Survey

Last week we put out a call to our fellow iOS developers to see what our little industry is charging. We had a great response (88 total), and want to thank everyone who took the time to submit their information.

The results are in! We put together a number of charts that highlight the most interesting data we received, but there are a few things we wanted to call out that we found especially significant. First off, the average hourly rate overall was $93/hr, and the median rate was $97/hr. Before the survey, I would have wagered on an average rate of around $100/hr, so that is pretty close.

Those averages were based on a wide range, however, starting at $10/hr and topping out at $250/hr. We know of superstar teams who charge over $200/hr, so the upper end wasn’t astonishing to us at least. But to be completely candid, we were very surprised at the large number of teams that charged $50/hr or less for iOS development.

By no means would we question any kind of work or rate that our colleagues are able to garner. It’s all about building strong relationships and a solid portfolio of work. But from a purely personal perspective, both Rick and I charged more than that prior to Big Swing as solo freelancers working in Flash.

To be fair, we were either based in NYC or at least had connections to that market, which is able to support a higher rate. Beyond that, we didn’t limit the survey to US-only developers, so it could also be a case of iOS work on the global market still fluctuating. We would love to learn more about those of you who charge on the lower end. Is this a full-time job? Do you stay booked? Are you overbooked?

Not only were rates all over the place, but your thoughts about those rates varied. One respondent thought they were probably charging too little at $200/hr, while another thought they were probably a bit too high at under $60/hr. The biggest concern is whether the market will bear your rates, so I’m curious if those thoughts were based on how booked the respondents were.

One final interesting thing I wanted to highlight was the average company sizes for the respondents. A large majority of you are at small companies of ten or less. I initially wondered if this was a revelation on the type of companies doing iOS work. However, I reminded myself that the type of questions we posed were definitely geared more towards freelance, contract, or project-based work.

Larger companies would likely hire teams of full-time programmers, which from a rate perspective would sit outside of the purview of this survey. Along those lines, we did receive a couple requests for questions that also targeted those of our colleagues who have salaried positions as iOS developers. We’ve definitely been discussing writing up a follow-up survey that does just that, so we’ll keep you posted.

We want to thank everyone again who responded. We hope the information we gathered can help our iOS comrades out there as they continue to work and grow.

 EDIT: We've had a bunch of great comments, including a terrific discussion over at Hacker News. One thing that's come to light is that we weren't clear in this post that the rates we were discussing are hourly rates. We've edited the copy above to reflect that. Sorry if it was confusing and thanks everyone for reading.

What do iOS developers charge

We put together a brief survey for iOS developers to find out what our little industry is charging. If you invoice clients for your iOS work, please contribute by filling it out.

Read More

Going Native

When Rick and I started Big Swing, we decided to focus primarily on developing native iOS apps. Like many developers new to iOS, I had checked out many of the cross-platform alternatives, or as Rick likes to say, "I did everything I could NOT to learn iOS." But I quickly saw the limitations of these solutions and jumped into Cocoa head-first.

It's a big decision, and one we've had to defend quite often. We've been asked by many clients about building cross-platform apps. What an alluring concept: save time(!), save money(!), double or triple your customers(!). If your app is simple and doesn't really need full integration with the hardware, mobile web may be the way to go.

But we've talked to a few teams who have tried going cross-platform and either ending up with a compromised product or needing to start over from scratch with native tools. Even Facebook and LinkedIn, two of the largest, staunchest supporters of mobile web, changed their tunes and released native iOS versions of their apps.

So why go native? First, even though mobile devices are getting more powerful every year, they're still a far cry from laptops and desktops. You need every ounce of performance you can get out of mobile devices. Apple gives you very powerful classes and APIs to access this power (as does Google and Microsoft for their ecosystems).

When you use third-party tools, you're one or two steps removed from the platform itself. You rely on a third party's decision on how to enable any kind of functionality, and how polished and tested their decisions actually are. This can really limit your choices when things aren't working well, or just not working.

Second, although the "write-once-run-anywhere" motto of mobile web is alluring, it's easier said than done. Even with a code base that uses open HTML5 or JavaScript, you'll  need a large development and QA effort to make sure everything runs consistently on all supported platforms.

Beyond that, iOS, Android and Windows are entirely different platforms, and their users  want their apps to maintain a consistency with on another. Throw in an app that was designed primary for the iPhone, and an Android user will find the experience lackluster or confusing.

So is that the final answer? Definitely not. The tools and tech are still evolving, and some pretty smart people are figuring out really cool things to do with mobile web. Even Rick and I are hard at work on some projects that make heavy use of HTML5.

But for now, if you're planning to make an app that is more than a web site in your pocket, native is still the way to go. As Facebook stated in their native iOS announcement, "Building on native iOS gives us a major opportunity to keep making the app faster, more reliable and feature-rich."

How “We’re booked” was ruining our business.

“We’re all booked up until next year.” That’s what we were telling everyone in the second half of 2012. We said that to potential new clients, existing clients, and even colleagues and fellow app makers.

It felt great to say. We were really proud of being off to such a strong start, so having an opportunity to show what a hot commodity we were seemed like a great idea. Better yet, we were doing those clients a favor by telling them the hard truth up front—right?!

More than just using the phrase, we put ourselves into a “booked” mindset that shut us off from opportunity. We were just too busy programming to field opportunities, and it bit us in the ass later.

We finished up the projects that kept us so busy and then hit a major lull. We started doing business development again and responding with an “open for business” mindset, but we were basically starting over from square one. It would be months before our next major projects would kick off and we could send out invoices again.

The specific way that we screwed up was jumping into “all booked up” too early in the conversation. I started conversations by asking about timeline and would say something nice like “I want to save us both some time here because we’re all booked up…” That’s terrible business development, which is as much of a creative exercise as the rest of your business. These were opportunities to get creative, but instead I started off on a nonconstructive foot.

I can’t say how much work we lost, but I can say that we stay busy when we’re in an “open for business” mindset, and the business stopped flowing when we were “all booked up.”

Here’s our advice: You’re never too booked for business development, or you’re going to have a hard time staying in business. I hope that sounds stupidly obvious, but it’s hard to keep sight of that when you’re under the gun for a deliverable. How can you spend hours responding to feeler emails and meeting people for a casual coffee to talk about what they have coming up? I’ll let you know if I figure out an easy answer. I’m pretty sure it’s summed up as “hustle”.

As a mentor recently told me—you just can’t take time off from biz dev because you’re too busy doing the work.