I have an idea.  I would like to write an open source framework for dealing with application feedback in a sparkle-esque manner – by which I mean in that elegant, convenient, “Just Works” kind of way that we as Cocoa developers have come to love and respect.  This framework would allow developers to provide users with a unified way of giving feedback, opening support tickets, feature requests, and just about anything else.

What I have in mind is a system for sending POST data to a remote script (configured in Info.plist of course) containing all information sent by the user.  The script would be responsible for checking the type of the feedback and reacting accordingly.

I need to work out a bit more of how this framework should work, but I really like the idea of it.  Who knows, maybe I’ll start working on it a bit soon.

The past couple days I’ve been working on developing my first iPhone application.  It is a very simple application (by desktop development standards, at least), and it has been an enormous pain to write so far.  There are a couple crucial problems with the way the SDK has been designed that I wish Apple had taken into consideration, because as a highly experienced Cocoa developer, I should not have had as much trouble as I did. Let me explain in a bit more depth.

First of all, let’s talk some NDA action.  Currently, the entire SDK is under a NDA, and I don’t plan to go into super specific details about the code or anything like that.  Speaking of the NDA though, that is a really annoying part of developing for the iPhone at this stage.  When trying to solve a problem it often helps to look up how other people are solving the same problem – there were a couple times where I would search google for something SDK-related and pull up a seemingly relevant result only to find that everything was shrouded in NDA-ness.  Ugh.  Please please please, Apple, cut this NDA shit out.  Moving on.

Next on my list of complaints is the arbitrarily imposed limitations.  iPhone apps are so heavily sandboxed off from the rest of the system, it’s ridiculous.  The first four iPhone app ideas I had were really cool ideas, but were simply not possible and thus abandoned.  The SDK allows very specific things to be allowed, and it’s tricky to get my brain to think within those terms only when I’m never quite sure what exactly isn’t allowed.  I think it’s totally the wrong metaphor to send about development – instead of focusing on the cool things an iPhone app can do you spend all your time just trying to think of an idea that is allowed to exist.  Do not want.

The final thing I would like to complain about is the glaring fundamental differences between the structure of the iPhone OS and OS X.  Now, this is most likely a highly opinionated matter, so this is just my opinion. Coming from OS X development, there are certain similarities I assume and even expect.  I am totally open to learning new APIs and structures, but it makes it a lot harder to sit down and write a cool iPhone app when you basically have to start from the beginning.  Cocoa development experience only gets you past the bare basics.  And that’s fine, it’s just a bit irritating.

Overall, it’s a wonderful experience for any developer to sit down and think about how to write code from a totally different perspective and for a totally different type of user.  And really, once you get past the fact that you really need to learn a lot of the SDK from the ground up, things start to go pretty damn smoothly.

In my humble opinion, Mail.app has some issues.  And when I say issues, I mean there are a couple relatively minor things that make it more annoying to use than it ought to be.  Almost every Mac user I’ve met uses Mail without the knowledge that their email experience can be improved.  Here’s a couple tips:

• For some fast relief, go into Mail’s preferences and tweak the various fonts in the Fonts & Colors pane. For me, setting both the mailbox and message list fonts to Lucida Grande size 11 was like a breath of fresh air. I also recommend choosing a font other than Helvetica for the message font (I’m happily using Lucida Grande 12).
• Next and arguably most important, download and install Dane Harnett’s exellent WideMail plugin. WideMail lets you tweak a nice number of things about Mail’s interface and I wouldn’t ever think to use Mail without it. For me, harmony was achieved by turning alternating row colors on, setting grid line style to None, and setting Intercell spacing to 4. Aaaaah, that’s better isn’t it? Further states of nirvana can be reached by changing the divider style to 1 pixel.
• Make use of the Mailbox -> Use This Mailbox For menu item, because it can greatly clean up the left side of Mail.

I get asked a lot of questions about OS X software piracy. I recently talked with a friend of mine who is just learning Objective-C and wants to get into developing indie Cocoa applications, and one of the first topics that came up was that of piracy and secure registration mechanisms.  Now, I have released a couple applications at this point (or at least been involved with more than one shipping application), enough to have a bit of perspective in this area.

First of all, the most important thing I can possibly stress to any Mac developer (I say Mac because I have no experience with writing Windows software or how piracy works on that OS) is to understand this:

People pirating your software are not to be considered a part of your target audience.

If someone downloads a cracked version of your app, they were most likely never going to purchase it in the first place.  Therefore, they are not stealing because you have lost nothing from their act of piracy.  This also deeply influences my feelings about strict registration mechanisms… If you spend a lot of time and build an extremely powerful and secure system, you are only delaying your apps release and making it just that much more inconvenient for your honest users.  Obviously, you need to have some level of security so your honest users don’t come along and accidentally stumble on an easy crack – but it doesn’t need to be built to keep the king of pirates out.

Also, go into development assuming your app will get cracked at one point – because it probably will.  The OS X piracy community is VERY active.  The best thing you can do is develop a registration mechanism that is tied to a server to prevent serial numbers from floating around… other than that, it isn’t worth spending your time and energy trying to prevent crackers from doing what they do best.  We spent a lot of time trying to build FileLock in a way that made it hard to crack, and let’s just say it didn’t delay things in the slightest. I have heard complaints from fellow developers about using AquaticPrime as a registration system, and that it is far too easy to crack.  Well, it may be true that it is easy to crack, but not so easy your grandma could do it.  When it comes down to it, honest users will appreciate the simplistic registration process and ease of use, while pirates will still just crack your app.  You as the developer have lost nothing more by taking the shorter, friendlier, more crackable route.

Finally, and maybe most importantly, I believe that a balance can be reached with the pirates.  If a pirate tries the cracked version of your app and loves it, he/she might recommend it to an honest user friend, or maybe ideally a few honest user friends.  You haven’t lost a sale because the pirate wasn’t planning on ever purchasing your app, and you’ve only gained free word-of-mouth marketing (and maybe even new honest users).  Note that this isn’t a “technique” per se, and it isn’t taking advantage of pirates – it’s merely a way to think about where pirates fit into the ecosystem. They have their place.  And remember, respect is a two-way street.

At Off Leash Developments, we use quite a range of different tools in our day-to-day work and interaction – here is a list with a description of each.  This are things I more or less consider essential for running a small software company.  Also, this leaves out the platform specific dev tools (Xcode, Cocoa frameworks, etc.) on purpose, since there’s no point mentioning those.

• Trac - Ticket management and company wiki.  We use Trac like crazy!  The built-in wiki is very useful, and we have SCM integration, so it’s quite useful.  A lot of people don’t like Trac for one reason or another, but it works for what we need it to do, which is ticket management.
• Subversion - Source Code Management (SCM).  OK, I know this one is obvious, but I figure it’s at least worth mentioning.  If I had to start over and choose a different SCM system for us to use, it would definitely be Git. SCM is an absolute must-have, even if you are a single developer.
• Versions - Subversion client. This app is awesome. I would never dream of using anything else for interacting with a Subversion repository.
• Grassroots CMS – CMS our website is developed with (in house).  I wrote this CMS a couple years ago for the Off Leash website specifically, and just recently stuck a nice control panel on it.  A good CMS is essential for not spending a ton of time copying and pasting code in a static html site.
• Off Leash Store – Our store application (in house).  This is another entirely custom development, written using WebObjects.  Currently supports VISA and MasterCard, with PayPal and American Express on the way.
• Email – Alright, yes, this is totally obvious.  All I want to stress here is how much email is a part of running a company. Most communication happens via email, and all tech support is handled via email.  The reason we can get anything done and build a customer base at all is because of our use of email.  Our setup is a single account that everyone has POP access to, and when someone responds to an email using their personal off leash email they CC the response to our shared one.  It works nicely.

This could be missing a few things, and there are things that we haven’t really needed yet due to our size… but overall, this is a pretty solid list. I hope someone out there learned something from this post.