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.
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.
FileLock, the application I have been co-developing for over two years, has now finally come to fruition and been released. We have some really exciting plans for the future of FileLock - so exciting, in fact, that I can hardly wait to get started on them. Check it out, feedback is always warmly accepted!
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:
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.
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.
Well, hello again. This is now my third or forth attempt at having a meaningful blog and I have a better idea about what I want to write about - coding. I often have cool ideas for code tutorials or snippets to share, and that’s what this blog is going to be about. I have no idea how often I’ll be able to post, but it will be interesting experiment to try. [self beginBlogging];