Ever wondered what's it like to be a Mac developer outside the U.S.? Sure, the coding part of things is pretty much the same--it's the same OS, wherever you live--but other aspects of building successful Mac software are a little bit different.
Mac DevCenter recently got in touch with a group of U.K.-based indie developers to ask them a little about their lives, how they stay in touch with Apple, and why international exchange rates make such a difference to them.
To begin with, we contacted a dozen or so individuals, and from that group a smaller one of seven opinionated developers took part in the discussions (which were conducted online).
The developers (in alphabetical order):
Central to the non-American coder's life is the state of international exchange rates. Someone living in the U.S. and earning U.S. dollars earns a reasonable amount of money. Someone living in the U.K. and earning U.S. dollars makes half that amount, in real terms.
Consequently, they have to price their products with the exchange rate in mind. And the way it changes doesn't help much, either.
Fraser Speirs is blunt:
"I suppose the exchange rate is a little outside our circle of influence, but it does have an impact on selling to the U.S. I reckon 70 percent of my market is U.S."
That said, he adds that sales have remained steady despite the slide of the dollar against the pound.
Keith Blount employs a strategy with fluctuating exchange rates in mind:
"I set my price in dollars, but basing it on the assumption that the exchange rate would always be about 2:1. That way, when the dollar has a good couple of weeks, I can smile."
And customers don't tend to think much about international pricing, either. Keith adds: "Even with a low price I get emails daily about educational pricing and possible discounts. For $35! After eSellerate takes their share, that's barely five pints in a London pub…"
To which Fraser responds with a wry: "It's so expensive to live here compared to the U.S."
Rory Prior has started selling his products in euros. He says: "It's hard to tell what the fallout will be exactly, but it sure is nice to claw back some of the income the dollar was taking with it."
"Pricing is definitely hard," agrees Keith Blount. "I could easily have pitched Scrivener at twice the price. But then I would have had to manage an official student discount scheme. And a lot of people will buy shareware under $40 without thinking about it too much. But of course, that is both a blessing and a curse. It means you get a lot of sales, but also a lot of customers who hope that the low price means that they can tell you what your app should be. Um, that sounds ungrateful, but I don't mean it that way. Most of my customers are brilliant, but there definitely is a contingent who see the low price as an indication that you are looking for input of some kind, I think."
Richard King's only shareware product has been through several prices, all of them $10 and under. Oddly, he says, there's been little corresponding shift in sales.
James Thomson adds: "I have considered increasing the pricing to compensate for the exchange rate, but it's hard to justify that without a corresponding big upgrade."
How do U.K.-based developers keep in touch with the Apple mothership? Is there any difference for non-American Mac developers, and is there anything they think Apple could do differently to improve cross-Atlantic communication?
Fraser Speirs says: "The biggest problem for me is that people at Apple don't always appreciate that you're eight hours ahead of them. Sometimes I get emails at midnight wanting something complex urgently. But otherwise I have a great relationship with my contacts at Apple, mostly the Aperture team."
But he adds: "I'm curious as to how important people think a 'relationship' with Apple is. I'm fortunate to have a very good one, but it's been a recent development. I think that a lot of new Mac devs put more emphasis on it than is really warranted sometimes."
Keith Blount is full of praise for the way Apple talks to developers, no matter where they are.
"Apple have a fantastic relationship with developers in general," he remarks.
"I used to live on the Cocoa-dev lists provided by Apple (and archived at cocoabuilder.com). I cannot count the number of times I have had e-mail help from Douglas Davidson, one of the senior Apple text engineers, in getting to grips with customizing and bending the Apple text system to my needs. And that cost me nothing--all I had to do was join the dev lists, for free. I can't praise them enough for that."
Does Apple need to change the way it communicates with developers? Fraser Speirs thinks not.
"There's a case to be made for Apple being more open with customers. However, for developers, I think that they already do a good informal job. If you look at the macosx-dev, cocoa-dev and xcode-users mailing lists, you'll see a lot of Apple people giving informal help. The cost of getting formal code-level help is high, but not insurmountable if you're completely screwed."
Richard King agrees wholeheartedly:
"I am member of the ADC and find that and the mailing lists more than sufficient. I once had a brief exchange with some Apple employees who were using one of my free tools, but that was about it. I don't find the ADC membership costs exorbitant, considering the software you get and the hardware discount. Oh, and the exchange rate," he adds.
Keith Blount also sees a difference between the Apple that consumers see, and the Apple that developers see.
"As a developer, I feel Apple has a lot to offer. I don't particularly feel I have any special relationship with Apple as a developer--I don't. As a customer, I have been frustrated by problems that have been well-publicized amongst the Apple-buying public but which Apple themselves refuse to acknowledge. I even went to the extent of sending email to firstname.lastname@example.org. I never thought that would work, but it did--within days I had corporate relations contacting me and helping me solve my issues. They were great, but it should never have come to that.
"My partner, who is a journalist, gets short-shrift from Apple whenever she tries to contact them about issues that are hot-gossip on the Internet. They have a really bad rep for PR among journalists, in fact. I wish they would sort that out. I'm happy with ADC, though. It's definitely worth it, especially preparing for Leopard."
One issue that crops up during conversation is the idea of a U.K.- or Europe-based version of WWDC, which is treated by everyone concerned as little more than a nice pipe-dream. Fraser Speirs is the one who points out that the big attraction of WWDC is the huge number of Apple technicians there, ready and willing to chat about detailed specifics. To really make a successful clone of WWDC outside the U.S., Apple would have to fly all those people over to Europe, and provide somewhere for them to stay. In other words, it would be hugely expensive and a logistical challenge to put it mildly, and is unlikely to happen.
That said, Peter Michelsen points out that "Apple does have coding support engineers based in the U.K., which can be very useful."
Perhaps much smaller-scale events for developers might be welcomed by the U.K. Mac dev community.
It's not U.K.-specific, but how to these developers like to code more efficiently? What are their favorite tricks for producing leaner applications?
Peter Michelsen starts the list: "One of the best factors to reduce software development is to look for or create frameworks. Sparkle and MediaBrowser spring to mind. The flip side is that it is not your own software."
"Sparkle is fantastic," agrees Keith Blount. "Users are always commenting that Scrivener's update feature is flawless, and I had nothing to do with it--it's all the work of Andy Matuschak. I wish there were more frameworks like it out there."
Peter responds: "I was pushing for Apple to produce a media browser like Pages or Keynote's as a single call like color picker style window. There are other frameworks but you really have to look."
And Keith again: "I think that is one of the things lacking at the moment on OS X, actually--good and solid third-party frameworks, free or commercial. Yes, I wish they would do that, too. The media browser thing, that is.
"The creator of Mori has a framework called Blocks, and a new word-processor-for-novelists, Storyist, was built on that and the Omni frameworks. Can't miss out the Omni frameworks, too--the Omni UI stuff is definitely useful. They added state-saving to a split view whereas Apple have been really tardy about basics like that."
Keith would dearly love to see a framework for HUDs.
"A HUD framework would be good. I think HUDs are going to be coming with Leopard, though, judging by the way they are everywhere now. I had to write my own HUD window code--again based on stuff Andy Matuschak had coded--and it's pretty messy."
Fraser interjects at this point, not with a comment, but simply with a link to HMBlkAppKit.
And there's something else Keith would like to see, too: "I really wish Apple provided an area for ADC members to discuss Leopard's progress and new features. That would be as helpful as a framework, I think. If there was somewhere to go there would be a larger pool of expertise when it is actually released, and more examples and code snippets ready to roll out by users."
Joshua Coventry says that listening to customers is another essential part of building better software.
"What do they want? Why do they want it? How do they want it? And when do they want it? Listen to feature requests, let them speak! Marketing research is very useful too. Companies that don't listen to their customers end up failing; and it's really important that developers listen because adding in features that have high demand is bound to increase sales and interest of your product."
For his app Scrivener, Keith Blount encourages user feedback on a web forum and considers it essential that sending him feedback about it should be as easy as possible:
"Making explanations available to customers of why this or that particular feature that has been requested won't fit into your app really helps in abating potential customer frustration. Personally, in the case of Scrivener, I think that having a year-long public beta was the best thing I could have done. It built up a user base, gave me loads of input into which features worked and which needed refining at a stage where changing them would be accepted by users, and gave my users a feeling of being involved in the development to a certain extent. So, communication and solid beta testing have got to be up there in the priorities for creating good software."
James Thomson adds a friendly warning: "You also don't want to listen too closely to your customers--don't let them design your software."
And with that sage advice, we bring this discussion to a close.
Ultimately, coding for the Mac in the U.K., or any other country, is not very different to coding for it in the U.S. The differences are more related to the meta-tasks surrounding software development; the research, pricing, business organizing, marketing, and professional networking that have to be done on top of the coding.
There's not much any of these people can do to control international exchange rates, but that doesn't stop them having ideas, and writing code to bring those ideas to life.
Long may it continue, whatever the price ends up being, and in whatever currency.
Giles Turnbull is a freelance writer and editor. He has been writing on and about the Internet since 1997. He has a web site at http://gilest.org.
Return to MacDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.