unethical blogger - Cocoa

The slow death of the indie mac dev

R. Tyler Croy — Thu, 13 May 2010 16:30:00 +0000

Once upon a time I was a Mac developer. I loved Cocoa, I loved building Mac software, Mac OS X was once upon a time the greatest thing ever. I recall writing posts, and even founding a mailing list in the earlier days of Core Data, which I was using in tandem with Cocoa Bindings, which themselves were almost a black art. I was on a couple of podcasts talking about web services with Cocoa or MacWorld. I loved the Mac platform, and would have gladly rubbed Steve Jobs' feet and thanked him a thousand times for saving Apple from the despair of the late 1990's. As Apple grew, things slowly started to change, and we started to grow apart.

As I started to drift away, I gave a presentation at CocoaHeads presenting some of the changes and improvements to the Windows development stack, not supremely keen on the idea of building Windows applications, I was clearly on the market for "something else". Further and further I drifted, until I eventually traded my MacBook Pro in for a Thinkpad, foregoing any future I might have developing Mac software. My decade long journey of tinkering and learning on Macintosh computers had ended.

When Mac OS X was in it's original Rhapsody-phase, in the weird nether-world between Platinum and Aqua, Apple realized that it had been held back by not giving developers tools to build for the platform. Apple began to push Project Builder which became Xcode, which became the key to the Intel-transition and has helped transform Mac OS from a perennial loser in the third-party software world to a platform offering the absolute best in third-party software. Third-party applications of impressive quality were built and distributed by the "indie mac devs", Adium, Voodoo Pad and Acorn from Flying Meat, Nicecast and Audio Hijack Pro from Rogue Amoeba, FuzzMeasure Pro from SuperMegaUltraGroovy, Growl, NetNewsWire or MarsEdit originally from Brent Simmons (NetNewsWire is now owned by NewsGator, while MarsEdit was acquired by Daniel Jalkut of Red Sweater Software), Yojimbo and BBEdit from BareBones, even Firefox, Camino and Opera filled the gap while Apple pulled Safari out of it's craptastic version 2 series. Applications were used on Mac OS X instead of web applications because the experience was better, faster and integrated with Address Book, iPhoto, Mail.app, iMovie and all of Apple's own stack.

Then came the iPhone, with its "Web SDK" nonsense. The story, at least at the time, was clear to me. Apple didn't care about me. Apple didn't care about its developers. Build a web application using JavaScript and AJAX (a Microsoft innovation, I might add) over AT&T's EDGE network? Fuck you! A number of months later, back-tracking on the "Web SDK" concept, the iPhone SDK came out at WWDC with a ridiculous NDA, forbidding developers from talking about it publicly. Then the App Store was bundled with iTunes and iPhone OS, with Apple becoming the gatekeeper between indie developer, and Joe User. Of course, more recently in the long line of iPhone/developer related tragedies, the infamous Section 3.3.1. There's also some hub-ub about the Apple Design Awards 2010, only focusing on iPhone and iPad apps which is quite disconcerting for indie mac devs, who routinely compete and win awards for the best Mac applications.

The message is clear, Apple wants to completely own users on its platform and sit between developers and their users, dictating terms.

It's no wonder that @rentzsch, a major voice in the indie mac dev community, and organizer of the C4 conference is throwing in the towel on organizing C4 entirely (discussed in this post).

It's not entirely clear whether the "indie mac dev" community will continue to exist for too much longer, there is some speculation that a "Mac App Store" is brewing in Cupertino right now or perhaps modifications to Mac OS X similar to what is present on the iPhone. If I were still part of the "indie mac dev" tribe, I'd feel very nervous right now about what will happen at this year's WWDC, as Dan Wood from Karelia knows, Apple feels no remorse with stomping on Mac developers.

Worst comes to worst, I sincerely invite indie Mac developers to bring their user-experience talent and software-building energy to the weird but exciting world of web software, so long as Google keeps Facebook in check, the web should remain open for a good long while.

I hate Mac OS X

R. Tyler Croy — Sun, 24 Feb 2008 06:32:49 +0000

Hate is such a strong word, but I think I can verifiably say that I hate Mac OS X (Leopard). In a past life I wrote Mac software on Mac OS X (Tiger) and everything was wonderful, I enjoyed using Mail, iCal, Xcode, Safari and even iTunes sometimes. I liked using my computer, I enjoyed using the tools handed to me by the gods on high in the mountains of Cupertino.

Now a couple months since upgrading to Leopard certain that everything was going to be even more awesome than before, I type this from my openSUSE 10.3 workstation, running Opera, Thunderbird, Sunbird, Banshee and Gnome Terminals open all over the place. The tipping point was an afternoon at a coffee shop with my lovely MacBook Pro (code named "cherry") when I closed Safari entirely because it was leaking memory, only to open it again for about an hour, and notice that it had started leaking again and in the course of an hour had a memory footprint of 1.3GB.

Using Mail.app in Leopard has been nothing but a complete and total nightmare, somehow Mail.app's internal IMAP implementation can lock up the entire machine causing the Finder, Safari and Terminal all to beachball while Mail.app takes 15 minutes only to end up crashing. Too many stack traces I've watched Mail.app emit have all been rooted in their IMAP support. Thunderbird is also a miserable piece of software, I'm convinced that everybody except the one engineer I know at Mozilla is a complete and utter idiot, but when Thunderbird locks up, I can still use the rest of my system. Somehow Apple has munged the lines between userland and kernel space so much that userland applications can take control of the machine leaving the user on the sidelines while applications compete for resources and bicker amongst themselves.

Time Machine, and Spaces are the only two redeeming features in Leopard for me, but after losing multiple modal dialogs in Spaces and watching iChat or Adium steal focus and rip focus from one space to another became too much to handle. Somehow every window manager on the planet has gracefully supported multiple workspaces for well over a decade and Apple was able to do it wrong.

I really like Apple's hardware, I own a 20" iMac, 13" MacBook, 12" PowerBook and have a 15" MacBook Pro at work, but either Apple let go, or lost some really good engineers in their famed deathmarches up to releases, especially up to the release of Mac OS 10.5. I'm sure the iPhone is a great revenue stream, the Apple TV is "cute" and iPods are still my preferred portable media devices, but I never realized that when "Apple Computer, Inc." became "Apple, Inc" that it was going to have such an effect on the quality of their products.

Now I have a split partition on my MacBook Pro, and I intend on putting openSUSE on the machine this weekend. My trust in the open source community, as low as it is, is now higher than my trust in Apple to release quality software. Grrrr.

What a heaping pile of FAIL.

R. Tyler Croy — Tue, 18 Dec 2007 13:20:55 +0000

I had mentioned previously that iChatAgent in Leopard leaks, I'm going to take that statement back. iChatAgent in Leopard hemorrhages memory, and I think I know why now.

While I was napping, there was a network hiccup causing iChat to get disconnected, when the network connectivity returned, it first tried to sign on a couple of Jabber accounts, both of which use self-signed SSL certificates. Being the lovely old chap that iChat is it prompted the user (napping at the time) to accept the self-signed certificate. While the dialog box was up, iChat sat waiting around before it signed on the other accounts and spun and spun and spun.

iChat spun and spun and spun until all the available disk space for virtual memory was used up by every process that had to swap out to make space for iChatAgent's demands on real memory, and then by iChatAgent itself swapping out.

God fucking damnit.

iChatAgent leaks in Leopard

R. Tyler Croy — Sat, 24 Nov 2007 19:52:13 +0000

I really don't have much that I can say about this, I came into the office after leaving my Mac on (as per usual) for about 12 hours and found that I was out of space on my startup disk, out of all available system memory, and things were crashing left and right.

What the fuck right?

Well, after I recovered the system enough to pop open "Activity Monitor" I found the exact culprit.

CocoaHeads Silicon Valley

R. Tyler Croy — Thu, 12 Apr 2007 05:54:11 +0000

Scott Stevenson beat me to the punch in announcing it, but I might as well reflect the sentiment and invite you all (even those of you who actually don't live in Silicon Valley) to come out to Cupertino tomorrow (thursday) night to see if I can actually pull off a Windows-esque presentation in front of a room full of Mac developers.

I will be discussing a lot of the latest developments in .NET 3.0 and Visual Studio 2005 and contrasting them where appropriate to the state of Mac development with Xcode, Cocoa, Objective-C and all the other niceties that Leopard's developer tools offer. If possible I will also try to work in a bit about Mono as another alternative in the sea of options for developers these days.

I'll make sure that I either post my slides to my flickr stream or the PDF of the slides to this blog after the fact. If I don't however post before Saturday that means I've probably been beaten up and left for dead by a room full of angry Mac developers.

I ain't Shipley, but PmpMyApp

R. Tyler Croy — Fri, 09 Feb 2007 09:24:40 +0000

Ever since coming across the (draft) specification for NAT-PMP I've been almost in love with the absurdly simple NAT port mapping protocol. The unfortunate downside is that NAT-PMP isn't well supported except on Airport base stations, one of which I recently acquired, so as is customary when I welcome a new device into my apartment, I had to write some code for it. I hate to sound like a fan-boy, but like Bonjour, Stuart Cheshire's other baby, NAT-PMP is sickeningly simple. A series of straight-forward UDP packets is all that is needed for a local (inside the NAT) device to create a mapping on the NAT device itself.

To exhibit this functionality, I've created a sample application that uses a tiny little library I built to create and destroy mappings on the NAT-PMP enabled device. The application is called "PmpMyApp" and can be found on GitHub

The code contained in pmpmapper.c has three basic functions that perform the functionalities that NAT-PMP provides, and are aptly named as well:

struct sockaddr_in *pmp_get_public();
pmp_map_response_t *pmp_create_map(uint8_t type, uint16_t privateport, uint16_t publicport, uint32_t lifetime);
pmp_map_response_t *pmp_destroy_map(uint8_t type, uint16_t privateport);

The pmp_get_public() function returns a pointer to a sockaddr_in that contains the external IP address of the NAT device. The pmp_create_map() function does the heavy-lifting, in that it will create the actual mapping (and the deletion too, with a zero lifetime) and will tell the NAT device to persist the mapping for the number of seconds specified with the lifetime argument. The code is commented so it should be very easy to get a feel for how to use the pmpmapper functions, a good place to start is by examining how it's used in the PmpMyApp source. (Note: All of the PmpMyApp code is BSD licensed)

I'm on another podcast

R. Tyler Croy — Thu, 01 Feb 2007 23:15:07 +0000

Steve Scott of Late Night Cocoa asked me a couple weeks ago if I wanted to come on and talk about BuildFactory and continuous integration, and then that slowly morphed into talking about webservices and Dumbarton as he noticed I posted some WebServicesCore gripes. We got to chatting a bit about why Mac developers don't seem to "appreciate" webservices as much as those in the .NET world, etc and eventually got together to record Web Services with R. Tyler Ballance.

If you've not checked out Late Night Cocoa, I highly recommend it, it's already shaping up to be a good (technical) podcast about Mac development (the Core Data with Marcus Zarra interview was fantastic, a hard one to follow). If nothing else I hope most developers can use my interview to get a better feel for what's available in the growing webservices (2.0!) landscape. A more active discussion about the strengths and weaknesses in the Cocoa frameworks can do nothing but make the Mac development community stronger, check it out!

Basic HTTP Authentication with WebServicesCore

R. Tyler Croy — Wed, 31 Jan 2007 22:06:42 +0000

Todd Ditchendorf is the man I have to thank now, not only for his fantastic SOAP Client, but now for "showing me the way" in terms of using CFNetwork to handle basic HTTP authentication with SOAP webservices in Cocoa. Performing the basic HTTP authentication is still an absolute pain in the ass, but it is possible nonetheless.

Without further ado, take it away Todd.

WebServicesCore, On The Radar Screen

R. Tyler Croy — Mon, 22 Jan 2007 13:14:00 +0000

A little birdie chirped into my email wondering what the radar number for my previous gripings about WebServicesCore, and I figured that for all one of the Apple employees that actually read my inane bullshit, behold:

Radar #4945073 ("WebServicesCore lacks support for basic HTTP authentication")

Let's all cross our fingers and hope for a much needed update to WebServicesCore. If all else fails, we can tap our shoes together and wish for a new web services API right?

(What's that weird rdar url?)

WebServicesCore, Why Hath Thou Forsaken Me

R. Tyler Croy — Mon, 22 Jan 2007 11:39:25 +0000

I've been hacking around with more webservices-based applications recently (Twitterer for example) and I've also reminded myself what an utter pain in the ass they can be in Cocoa. With twitter, they make available both JSON and XML-based webservices, which is good since they use basic HTTP authentication for their user-specific webservices (i.e. everything but retrieving the public timeline). The XML-based webservices are more or less straight-forward to hack up with Cocoa, all one really needs to do is write a parser (NSXMLDocument) and then make use of the URL loading classes (NSURLConnection, NSMutableURLRequest) to retrieve and process, or POST data. This method of interacting with "webservices" (more wgetting than anything else) is rudimentary at best, and in my personal opinion, isn't as robust as SOAP webservices are. It does however, work. Regardless of the framework, programming language, or geo-orbital location of the moon, they will work because all you're doing is making an HTTP GET and then parsing the results.

The benefit of SOAP webservices however, is the almost "literal" translation of objects encapsulated into SOAP messages, into runtime objects. In effect, if I have a Person object defined in my WSDL and similarly defined in my application (with a good SOAP framework) the objects should be encoded and decoded appropriately when passed via SOAP. The real power of SOAP can be realized when used with ASP.NET (ick) webservices and .NET clients (see ASP.NET - Mono) where you can relatively quickly and easily build and deploy a services-oriented application. That's .NET/Mono however, my work is dealing with NuSOAP and Cocoa, a less than ideal mix.

To start hashing out a Cocoa-webservices-oriented application, your first stop should be at a local pub, brewery, or mayor's office for a good round of intoxication, only after every tissue in your body is soaked with fine casket-aged whiskey will you be prepared to embark on your journey. It's usually best to start with a complete WSDL, you can then use /Developer/Tools/WSMakeStubs to generate what resembles some Objective-C that you can flesh out to some extent to provide an intermediary layer between your sane Cocoa code and the actual SOAP method calls. Cocoa makes SOAP painful. The stub code revolves around one magical "object" WSMethodInvocationRef. Think of WSMethodInvocationRef like you would a sadistic elf that only pops out of his little elf home to kick you in the groin before shouting "TRY AGAIN IDIOT" and scurrying away, there's a bit of magic involved, but mostly pain. Since the invocations will just return a generic "id" type, the only way to really be sure what your webservice invocation returns is to either call [NSObject respondsToSelector:(SEL)] or just trust that the webservice you called will return what you expect, whether it be an NSString, NSDictionary, NSArray, or NSNumber (NSNumber is what's returned in place of numbers and booleans, it's WebServiceCore's cheap way of boxing those primitives). TRY AGAIN IDIOT.

Something else to note is that things you might expect to be able to use, such as basic HTTP authentication are absolutely non-existent in the magic WebServicesCore black-box. With a URL loading-based webservice (JSON, XML) you can just use the delegate method:
- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
And authenticate from there, popping around through the various NSURLConnection delegate methods. I have also experimented with updating the SOAP endpoint to include a URL something like the following:
http://user:password@bleepsoft.com/some/stupid/url
While one might assume the HTTP subsystem hidden behind that magical WSMethodInvocationRef would handle this appropriately, and translate it to the basic HTTP authentication tokens, it just doesn't work. TRY AGAIN IDIOT.

The alternatives are few and far between if you absolutely need to use SOAP webservices for a certain Cocoa project, I am working on converting a framework that Jonathan Wight wrote to use the URL loading classes in Cocoa, but other than that learn to love WSMethodInvocationRef or plead with your web developers to rewrite their existing webservices with REST, JSON, etc. WebServicesCore is an antiquated pain in the ass, and probably hasn't been updated since Steve Jobs was at NeXT.

TRY AGAIN IDIOT.

Cocoa Radio, I'm Almost Relevant

R. Tyler Croy — Tue, 16 Jan 2007 08:06:22 +0000

Through some twist of fate, I was interviewed on Cocoa Radio. I think I managed to maintain some semblance of competence throughout the interview until some random fellow sat really close to Blake and I and threw my concentration.

It was pretty fun, Blake and I hung out most of the week (I even rescued him from the airport in blue lightning on thursday) so doing the interview was a bit weird, as we talk regularly.

And thus begins my long hard trek into the public consciousness; I'll be super-famous, just like Sting, you'll see.

Emission, Coming Soon

R. Tyler Croy — Thu, 11 Jan 2007 19:02:02 +0000

As some of you (both rather) may have noticed, the bleepsoft.com homepage is a bit different these days.

In the very near future bleep will be releasing an application called "Emission" that, besides the cool icon, will certainly change how I work with the wide array of people across the globe that I deal with on a daily basis.

As a lot of the network core is still unwritten (yes, it's very network-ey), so I'm not going to disclose too many details, but check out the site, Fernando Lins has done a fantastic job on the icon.