Our greatest achievement: The software we never plan to ship

We’ve been busy… crazy busy… in the past couple years, developing apps for a variety of clients and third-party vendors. Chances are you’ve seen our work, even if you don’t know it’s ours (we’re like secret Santas in that). The projects have been varied, but they’ve all had one thing in common: A need to keep track of issues, requests and, yes, even bug reports as we’ve progressed from initial discussion to launch (and then some).

Over the years, we’ve used more bug-tracking and project-management software than we’d care to count: Jira, MantisBT, Assembla, FogBugz, Fossil, Redmine, Bugzilla, Pivotal and the list goes on. They all have their merits and their pain points, but no matter which system we’ve used (often at the request of clients; sometimes thanks to our own misguided efforts to find the right system), we always ended up using just a sliver of the functionality presented via the UI -- often navigating past multiple form fields just to enter the 5 or 6 items we actually cared about: Product, version, bug description and history, for instance.

That all ended (not abruptly, but it did end) about a year and a half ago, when we started using a system we developed in-house just for us and our clients. We call it, appropriately enough, “the in-house bug thing.”

It’s plugin-based (so we only use -- and see -- the information we care about), REST-driven (with a simple Bootstrap theme for its Web front-end and a handy iOS and Android front-end for those that prefer that too), and we’ve noticed our testers are not only logging bugs more thoroughly, but our developers are solving and marking them off quicker too. It actually IS enjoyable to use, and it DOES adapt to our company AND our developers’ ways of “getting things done.” I personally never “see” it, as I use my faithful OmniFocus app as its interface: As new issues arrive, they appear in my inbox, and as I complete working on them, they’re appropriately marked within the bigger system. A co-worker manages to make it work via black magic and dropbox, another handles it all via his email client, and our customers are just happy to have a usable Web interface that they can use to “see into” the entire process.

We’ve considered offering the system as a service to others (or open sourcing it for others’ use), but as we’re not in the business of supporting bug-tracking software (nor do we want to be), we figure for now we’ll let it just be one of the little things that makes our company different in an otherwise crowded field: The bug thing makes it easier for clients to work with us, developers to work for us and our software to just work.

So think about that when building your own in-house tools: Sometimes, you need to build just what you need -- not what you think the market wants.

Apple, we love you, but...

If you’re not already aware of the controversy surrounding Apple’s iOS subscription policy, I suggest you read this open letter before reading further... or before bothering to buy (or develop) any apps that rely on external servers for their content.

Although I’ve developed several iPhone/iOS apps for various clients and teams over the past three years, I still consider myself new on the scene when it comes to private commercial app development (ie, creating apps to generate revenue on my own). Still, I feel I have to stand in solidarity with other app developers when it comes to the bizarre moves made by Apple recently in regards to its subscription services -- and I really hope these moves don’t mark the beginning of the end of iOS development as we know it.

Since Apple officially announced its subscription service last week, it seems we hear daily of new cases of existing apps’ being rejected/denied from the store for not giving Apple what is basically a “finder’s fee” -- even if Apple didn’t find a damn thing. I honestly don’t have a problem with Apple’s requirement that anything available for purchase OUTSIDE of an app also be available INSIDE, via the in-app purchase mechanism: Apple has done a good job creating this service, and likewise, they should be paid for it. But what I DO have a problem with is the “catch” that anything available IN APP must be offered at the same price to consumers as it is offered elsewhere -- even though it now costs the developer 30% more to provide the service.

So now developers have three choices:

  1. Surrender another 30% of the revenues they’ve managed to earn on iOS devices to Apple...
  2. Pass on a huge price increase to ALL their customers -- iOS or not -- just for the privilege of continuing to offer iDevice users a chance to use the service
  3. Leave the iPhone development market

In other words, Apple wants EVERYONE to either eat or pass on a 30% increase in production costs -- even to non-iPhone users!

I for one am disgusted by this policy -- which is neither good for developers NOR consumers -- and I’m saddened for the developers and users of quality apps and services that may now find it necessary to leave the iPhone ecosystem in the face of this betrayal of trust (Skype, Netflix, Pandora, Last.FM, Hulu+, Amazon, DropBox, Readability,TinyGrab and InstaPaper, to name a few).

I’d hate to see any developer leave the iOS community... but I’d rather see them leave than levy an unfair “Apple Tax” on those that don’t even use Apple devices.

Beta program accepting applications

We’ve got a few projects in the works at the moment, and we’re always looking for new beta testers. If you’re an iOS or Mac user and want to help us test and fine-tune our upcoming products, please drop us a line and let us know. Please leave us your name, email address and UDID (if you’re interested in testing apps on your iDevice) in addition to any information on what types of apps you’d like to test, and we’ll let you know if/when we’re ready to have you test the next big thing from CodeCooler!