Indie Mac Development in the UK
Pages: 1, 2
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.
Frameworks, Code, and Customers
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."
The Indie Way of Thinking
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.
Return to MacDevCenter.com.