iOS Development Code Kitchen

December 6, 2010 · Posted in advice, code, iphone, projects, work · Comment 

I’ll be putting on a workshop on iOS and iPhone development this Saturday from 9AM to 5PM on the Virginia Tech campus. The event is free so if you’re in the area feel free to sign up:

The event will run all day and will be hands-on programming, but all levels of experience are welcome and encouraged to come.

I Am Not an Entrepreneur

October 7, 2010 · Posted in iphone, news, personal, projects · 4 Comments 

Many people throw around the term entrepreneur. It seems most people put that in their bios. Don’t tell me you’re an entrepreneur, show me. What have you done?

When we started LTZ, our mobile and web app development company, we didn’t need any venture capital funding. We didn’t need a fancy office to rent. We didn’t need to do the whole fancy company launch. We just sat down at our computers and started coding. And when we finally had a product to ship, we did all the legal paper work and got ourselves a little LLC.

Sure there were risks. The risk of becoming single again was always there. Sure there were long days. 16 hours seemed to be the norm. And sure there were a few new technologies that we created. But when it came down to it, we just had a simple plan: work really hard and make some great products.

The business model we had, seemed like a great idea: become an authority and gateway for indie developers to develop their apps with. Sort of like a record label for mobile app developers, but without the whole ripping them off bit. We’d mentor and direct them to a finished product and take a minimal cut from the net profits. Any programmer can attest to the numerous projects that never make it to a finished, polished, tested app. But that’s exactly what separates the professionals from the amateurs: finished products.

Now, we’re looking at things differently and adjusting our model. We’ve found out a little more about what works and what doesn’t in this new space. When you’re such a small company, the saying, “If you want things done right, you gotta do it yourself,” turns into, “If you want something done, you gotta do it yourself.” It’s really hard to concentrate on writing good code when you’re the tester, the project manager and the client manager all in one.

I’ll talk more about the new direction we’re heading soon. In the meantime, we’re still working on the details and we’ll update everyone as soon as we finalize everything.

I am not an entrepreneur. I just create stuff.

Corona Game Template in Lua

June 27, 2010 · Posted in code, iphone, projects · 14 Comments 

This is a template I threw together for the Corona SDK from Ansca Mobile. Since Lua is not a language most people are familiar with, I figured I’d throw together some sample code for Corona and share what I learned so far with the rest of the Corona SDK community by including the template here.

The template includes example code for:

  • Display groups
  • Orientation and accelerometer
  • Touch with buttons
  • File reading
  • Example level file for scripting game play

The template separates functionality into modules for an object oriented approach. I’m still learning the techniques for Lua, so if you notice a better way to do it, please don’t hesitate to let me know in the comments below. Some things in the template are not the best way to accomplish some things, but should give people a good idea on best practices of software design. This will also with work Corona’s Game Edition.

If you find the template useful, take a look at some of our current applications to support us. It’d mean a lot.

Download the Template Code

Also, check out the links on the side. Thanks!

BarNinja – An iPhone App Postmortem

April 14, 2010 · Posted in code, iphone, personal, projects · Comment 

The BarNinja iPhone app is a mixed drink application with over 730 drink recipes with additional features including a random drink selector, bartending tips, powerful search, and a shots per bottle calculator for party planning.

The Beginning

As far as we could tell when we started the BarNinja iPhone app, there weren’t any other apps like it on the Apple App Store. That was back in April of 2009. While I was in San Francisco back in March, I got a Facebook message from Jason asking if I was interested in doing an iPhone app. I had done a bunch of Mac development and even independently sold a previous application. I had also attended Apple’s developer conference (WWDC) on two separate occasions so I was quite comfortable with developing for Apple products. When I got back from California, we sat down at a local bar in Blacksburg and wrote down our ideas for the app he wanted to make. That was prior to iPhone OS 3.0 being released and we were counting on some key features in that release for our app. In the end, we ultimately failed when the features didn’t work out exactly as we expected. Luckily, only a little code had been written and that was enough to get me up to speed with the current iPhone development platform.

Instead of quitting, we got BarNinja, another local Blacksburg startup involved in another app idea. We wanted to leverage the shake feature (iPhones can detect when you shake them) that was relatively new and make a mixed drink app based around that.

Soon after we started, a few other apps starting hitting the app store with exactly those features. But the competition didn’t deter us, but instead pushed the bar higher for us. We now knew we couldn’t just make another mixed drink app with a shaker feature, we had to make the best mixed drink app with a shaker feature. We were also creating a 730+ recipe database (including ingredients and other drink information) that would hopefully give us an added advantage. Luckily, at the last WWDC (2005) that I attended, they announced a technology called CoreData which allows developers to place small databases easily within their applications. They also included it in the iPhone OS and I ran with it.

Problems and Solutions

The problem with having 730+ recipes is that it becomes nearly impossible to find a drink in a list. The list view we had, took minutes to scroll through and even tired out your finger having to swipe so much! We added an index on the side to quickly scroll through the list alphabetically. We also added a search to find a drink by name and even added a filter to sort out if the drink was a “mixed drink” or a “shooter.” But that still wasn’t good enough.

I could find drinks like “Vodka Martini,” but what if I wanted a drink with vodka as an ingredient? So we added in a search that would find ingredients too. That worked out well, but often times vodka isn’t named vodka, it’s also names just “Absolut,” which everyone knows is vodka, but the iPhone doesn’t, so we had to teach it what kind of alcohol those products were.

More progress, and we were rolling right along until we tested it out on the actual device; it was painfully slow. The user would hit a key on the virtual iPhone keyboard and the key would get stuck in the “up” position until the search was done and only then could you hit the next key. Searching 730+ recipes is easy, but searching on average 6 ingredients for 730+ (~730 x 6 = a lot) takes 4 or 5 seconds on an iPod Touch 2nd generation. So we had to get a little creative.

My solution was to split off the search into a separate thread (a simultaneous process within the application) and perform the search in the background. This introduced a few other problems that I had to fix but the responsiveness improved dramatically. Then, using Apple’s performance tools, increased the search algorithm by about seven times. Thanks to all those boring Computer Science classes I took at Virginia Tech I was able to speed it up and also make it appear to speed up.

Updating the table view, after finding each recipe that matches the criteria, is slow (thanks to the performance tools for reminding me of this). So I returned the first 5 results instantly because those are the only ones you can see initially on the screen and then the rest were updated in a decaying frequency as they were found until the search was done.


Early Search

Early Search

Icons, glass name and index

Icons, glass name and index

Early drink details view

Early drink details view

The Final Product

Initial Screen

Initial Screen

New search screen

New search screen

New drink details view

New drink details view


They say if you’re happy with your 1.0 version of your application, you didn’t release it early enough. While we definitely have plenty of work yet to do on this application, we didn’t release it soon enough. It did not take a year of programming to get this done. The programming was the easy part, it was all the other stuff that got in the way, distracted me and things I had to wait on that took the longest. Back in the day, when doing my Computer Science homework, the motto was “Start early, and start often.” That rings true for every long term task.

We didn’t run any real usability tests. This upsets me a bit, but we never really got to show it to too many people. Now LTZ has a few more developers working on more apps, so we have a larger pool of testers, but in the end, we still need to test it out on real human beings and put all those Human Computer Interaction (HCI) skills I spent a lot of time learning, to use.

I did try to apply those skills with the layout of the app. When the app launches, the first screen is the random drink screen, which you can tailor to your tastes in the options. We wanted to give the person using our app something to do right away. We didn’t want to over whelm them with a list of 730+ ingredients; it doesn’t impress anyone. In our limited testing everyone figured it out and got a kick out of the shake feature. With other apps, we noticed, they presented a huge list of options that just left you wondering what you should do next. It’s that classic “uuuuh” moment. With ours, right after the launch of the app you can start enjoying the functionality.

The next screen is the raw list of drinks, plain and simple. Our search is straight forward and easy to figure out and the index on the right helps users navigate down the list quickly. We also stuck to using as many user interface elements from the standard set of Apple iPhone as possible. Many other apps try to be creative and diverge from the standard set of UI elements and consequently from the Human Interface Guidelines that Apple has set forth. The result is a poorly designed, clunky looking application that takes time to figure out how to use. Since we’re using a standard search bar, people using our app know right away what that means and can start right away in using the search feature.

We also chose a dark theme for our colors, not because it looks cool, but because most of our users, we assume, will be using it in a bar, or bar like conditions such as a party, etc. But we also didn’t want to give it a depressing theme since it was suppose to be fun and helpful, so there are a few bright colors in there. The design will most likely change and be updated, but that’s the rationale for the initial release. We’ll see what our users think and how they use the app.

We know our app isn’t perfect, but we’re confident we know where to go from here to improve it and fix some of the problems we know exist in it. Through additional usability testing, we’ll slowly improve upon BarNinja to make it the best drink application on the app store. We know we’re not there yet with the initial release, but we look forward to adding great functionality that people will love.

iPhone Pricing

April 10, 2010 · Posted in advice, iphone, work · Comment 

As with any product or service, the question of pricing is always one of the many challenges of selling a product or service. Many price their products or services low in an attempt to under cut their competition or initially sell a lot and get their name out there. Others charge way more than a person is willing to pay for such a product.

With iPhone development, more often than not, you’re selling a product as opposed to a service, which may be a compliment to your physical or web based service. If your iPhone app is a complimentary product to a service that you already offer and charge for, your iPhone app should probably be free (depending on complexity). Look at it as a value-added feature to put you above your competition and make using your service more convenient and enjoyable. By creating more ways to access your service, you provide more opportunity for your customers to use it more often and really benefit from what you’re trying to offer them.

So what’s the sweet spot for a price for your iPhone app? It obviously depends, but there are some guidelines we came up with.

Be Unique with Your iPhone App

The more unique your application is, the more you can sell it for. By being unique, you have less competition and thus a higher demand.

Complexity of Your iPhone App

If your application can be easily reproduced by a 16 year old kid on a weekend, you either shouldn’t charge for your application, or if you do, don’t charge more than a dollar because that 16 year old kid won’t.


If your application uses proprietary information, software, APIs or other technologies that aren’t easily implemented or obtained, you can charge more for your application. This relates to complexity, but be aware that people will often create equivalent systems if it’s popular enough so proprietary systems and information require a lot of maintenance to keep them relevant.

Usefulness of Your Application

How often will someone use your app? Is it just a novelty or something someone will only use for a certain chore that they rarely do? If so, the demand for the app diminishes and so should your price.

No application should be more than $10 with few exceptions. Remember that you’re developing for a mobile platform and the software is limited and your price should be limited too.

If it’s a game, how is the quality and length of game play? The quality, the game play and the fun factor all play a part in your price. Obviously, people much prefer spending money on entertainment than on a new fancy laundry list application. Games are usually unique (to the App Store at least), are complex and provide a greater satisfaction to buyers, which allows them to enjoy a higher price tag.


Having a higher price on the App Store shows more confidence in your application. Giving your app away usually means you don’t think people would be even willing to spend the price of a soda on your application. These applications are fine, but for some of us, we need to make a living.

Making your app a dollar usually means, I want to make some money, but I don’t think people will pay any more for it. But charging a dollar can also be good if your app has a wide appeal. What you lack in big numbers, you make up with bulk sales. So, if it’s a game, you could potentially have a larger market as opposed to a utility application that the user spends 30 seconds on. So you really need to look hard at your application and keep several factors in mind before you price your app. You can always change it later, so one approach is to start low and see how sales go.

Next Page »