First iPhone App: HockeyTweet has Launched

HockeyTweet is my first foray into the Apple App Store. HockeyTweet is a Twitter client which makes it fast to send Twitter updates about hockey games in real-time.

HockeyTweet is purpose built for the NHL. But enough of repeating the product page in the App Store, check out HockeyTweet in the App Store.

Here are some of the questions I've gotten about developing for the iPhone and what my next plans are:

Does it cost money to develop for the iPhone?

• Short answer no, for the majority of people though the long answer is yes.
  
• No, if you 1. Own a Mac, 2. Only want to write and test apps on your Mac.
  
• Yes, if you 1. Don't own a Mac, 2. Want to run the app on your own device, 3. You want to post the app to the App Store.

Ok, how much does it cost?

• $99/year (before taxes) for the iPhone Developer license.
  
• $$$$ for your Mac
• $219 CAN (before taxes) for the 8GB iPod Touch to approximately $1200/year for an iPhone
  

Does it cost any more?

• Well yes, what is your time worth? If you are like me and you love to try new things, love to play with different programming languages and create, then this is not a real cost. If you add that time into your costs, it starts to skyrocket, but hey we are here to have fun and design cool apps that solve problems for people.

What are the tools like?

• In a word, AWESOME. I love Xcode (the Apple provider IDE) and the toolset that it comes with. Basically everything I've used to write, debug, run, test software is available. The list of features is long but you won't be disappointed.
  
• NOTE: Your mileage may vary if you don't accept the tools and learn them. I love vi, the editor is not vi. I decided with Xcode to not fight the tools and try to use replacements. This is paying off as I learn more shortcuts and they start to sink in.

What is next for me and HockeyTweet?

• I plan to market HockeyTweet using several tactics with minimum cash. I'll write about how each of these pans out as I try them.
• I will be working on the next version. The app is designed to allow me to quickly integrate other sports. I will be improving the design as I work on the second sport and seeing how I can improve the design to let me integrate other niches quickly.
• I will be adding localization to the app for French.
• I will be monitoring user input for future features and working on any issues that arise.
  

What did you learn technology wise? I've gotten to learn the following (or at least scratch the surface):

• UI design
• Objective-C
• The Cocoa Touch framework - the SDK you build iPhone apps in
• Web Services using Google AppEngine
• Python for the Web Services
• Dealing with performance and responsiveness in a constrained environment
• Integrating open source frameworks into code
• Managing deadlines with team members
• Learning when to stop implementing and ship it ;-)
  

Is it hard to write an app?

• Are you a programmer? Do you have passion? Are you ready to learn? If so, no it is not hard. Again, back to the time issue. If you have it and are willing to do a lot of self learning then it is fairly easy.

Do I have a website?

• Yes, I am currently building Lockernine as my (planned) various apps home on the internet.
  

Have I had sales?

• Yes, though does my wife and friends count?
• I will post an update on sales numbers later once I have something interesting to report, be it good sales, or poor sales.
  

The Eve of iPhone Tech Talk Toronto

Phil Casgrain and I arrived today in Toronto via Porter. That was a great decision, Phil got to head into his companies Toronto office for some work and I planted myself at a Starbucks where I did work.

Tonight, thanks to Twitter, we saw that some iPhone Devs from Montreal were in the bar of the Hyatt (where the iPhone Tech Talk is being held Dec 3, 2009) and we headed over to meet some fellow devs. This networking was great, we got to trade some dev war stories, joke about the next great app (can you say a $69.99 web flashlight app? ok just kidding), and talk about many of the topics that have been floating about the internet with regards to iPhone development.

We also got to meet some of the Apple evangelists who will be leading the sessions tomorrow.

Some of the topics we covered included, but were not limited to, how app reviews are handled, the use of static analysis, strategies for releasing an app (be early with just enough or wait for more features and risk being beat out by another app), Square and it's new iPhone dongle payment system, how micro-payments are changing the landscape of the app store market, and more. As you can tell this was a lively discussion since Phil and I were there for only about 2.5 hours.

As a developer this type of socializing was a great experience. It is seldom, since University, that I have been in an environment where everyone is so into programming and are all floating about the same wavelength.

It's fun to roam among your own kind.

My First iPhone App Submission

I just completed my first iPhone App for the App Store.

It's a Hockey Twitter app for tweeting about Hockey, specifically the NHL teams and games.

I'll post more info on the app later but for now I am going to cover tonight's submission process. The submission took about 3 hours. This was time spent reading Apple docs, filling out App submission paper work, reworking my icon (I had it in jpg not png), reworking my App Store icon (it was a little blurry so I sharpened it up), and redoing multiple builds.

To build I needed a Distribution certificate which I could have done before and saved some time tonight (lesson learned). The artwork is now solid (I hope) so I won't need to do that for this app again.

Overall the submission went fairly smoothly; I did get annoyed by a quirk in the submission pages which kept sending me back a page and losing data I had typed. This was very frustrating but once I figured out the issue I made it through without losing data.

I'm taking a couple days break before I jump back in and get back to work. I'll be recording a preview video, redoing the website, and posting a followup when I get through the review process.

I also have an article on the decisions I made during the app and how I choose various features and approached the design. That one is still cooking and will come later.

Next week is a big week as well, I am off to Toronto for the iPhone Tech Talk.

Did I mention? I just submitted my first iPhone App? (Me -> nervous, excited, tired...)

Indie Software Development - You Need A Process

Process sucks. It slows you down.
Process rocks. It speeds up development.

It's a problem developers face all the time; how much process is enough? As a full-time industry developer working on large software systems with teams ranging from 10-500, process is important. Process helps you:

• communicate
  
• plan
  
• deliver quality software
  

As an indie developer though, how does process help? First off perform the Joel Test: 12 Steps to Better Code. Joel's test is as important to any indie developer, even a one man shop, as it is to a large organization.

Crazy you say! One developer does not need a process!

Do you want to ship?

If the answer is yes, then you need a process.

I use process to help me:

• keep track of what I need to do
  
• tell me when I am done (when my original list of features is done)
  
• help me deliver quality code
  
• help me estimate future projects better
  

As a one man shop, I sometimes skipped process and it bites me. I then end up wasting time on rethinking what I have to get done.

On the other hand, when I follow my process I quickly know what I need to do. That said, I have adapted my process as I've learnt what works best. Here is what works best for me:

• Source Control: git, it's free, it's easy, it's fast, I like it. I've heard complaints but so far it has served me well.
  
• Specs: What am I building? I write Use Cases, sketch UI mockups, write a feature list, and I work out how the system will be implemented (web services, data structures, and data interfaces).
  
• Bug Tracking: I use FogBugz; if you are a student or startup (2 people or less, like me) then you can use FogBugz for Free
  
• Schedule: See previous for FogBugz
  
• Functional Testing: I do it myself with a mix of unit testing, frequent code+test iterations of each new feature, and I solicit Beta-Testers to get feedback on devices/OS configurations I do not have. This is something I want to spend more time on to get a better balance of unit tests to ad-hoc testing. Currently I am doing more ad-hoc than unit tests and it bites me with wasted time.
  
• Usability Testing: I show the app to lots of people, iPhone/Touch owners and non owners to get feedback on the UI. Is it intuitive? Is it fast? Does anything jump out at the user as bad/ugly/hard to use?
  
• Bugs: Log them when I find them and fix them ASAP. I log them so that I can review what I have in my bug list before I move onto other code. I try to keep true to the rules of "Fix the First Problem First" and "Fix It When You Find It". This helps me stay focused on my task so I am not trying to work around things I know are broken. This wastes brain power.
  

That's my main process for a one man shop. It is how I keep things straight with only 1-3 hours/day to work on my projects. Working in small units of time means being efficient and coming up with ways to keep track of tasks that are usually in a mid-completed state.

As for how I manage to complete features that are larger than 1-3hrs, I use the tried and true technique of breaking the problem down. Basically:

• Break features into smaller features.
  
• Work on one feature at a time.
  
• Test when feature is implemented.
  
• Commit feature.
  
• Rinse and repeat.
  

This works for me and let's me work on something that might take 10-15 hours of research, design, code, and test over several days. Without the frequent code/test/commit cycle I run into trouble trying to implement multiple features at one time, or trying to implement one large feature that could have been broken into many smaller features.

KISS (Keep It Simple Stupid) works for software development as well.

iPhone User Experience + UIWebView

Beta and UX testing has given me a couple things to work on:

• Bugs
• UX
• More bugs

Ok, the bugs are mostly found by me. The UX issues are things that people have mentioned when the use the app (UX=User Experience).

The first thing I do when I show someone the app for the first time is ask them to tell me the first things that come to mind about the usability. So far I've gotten 3 biggies that are worth investigating:

1. Live feeds of information pertaining to the app so the user can drop that information into a tweet instantly without having to look it up or type it. Good one and something I will consider for a future release since sourcing the life feeds I would need will take time to build since I have not found anything with the information that the user thought would be most valuable.
2. Customized tweet strings or tweet templates we will call it. Great idea and good for a future release.
   
3. Last but not least; one tester pointed out I should really make signup for a Twitter account as easy as possible for a user that does not have an account. Good point, this should go into release 1 I think.

So, I thought let's add a UIWebView for the Twitter signup page. Adding the UIWebView was easy so I dropped it in immediately so the user can navigate to the Twitter Signup page within my app and quickly create an account.

Now, if I could just nail down the last of those bugs. Currently I have some unhappy plists which I am using to store cached webservice data between runs of the app. Off to track those down now.

My Review of Programming the iPhone User Experience

Originally submitted at O'Reilly

This practical book provides you with a hands-on, example-driven tour of Apple's user interface toolkit, UIKit, and some common design patterns for creating gestural interfaces and multi-touch navigation for the iPhone and iPod Touch. You'll learn how to build applications with Apple's ...

Programming the iPhone User Experience

Lief Motif: Think Design First

By mthistle from Ottawa, ON, Canada on 10/15/2009

 

4out of 5

Pros: Good for beginners, Accurate, Easy to understand, Helpful examples

Cons: Lots of beginner info

Best Uses: Student, Intermediate, Novice

Describe Yourself: Designer, Maker, Developer

Summary of my favorite chapters in order of most useful:

Chapter 9: UX Anti-Patterns - the first chapter I read and the best one for a lot of good tips on how not to develop your UX. Every iPhone developer should read this chapter. I will reread this chapter occasionally to keep UX issues fresh in my mind.
Chapter 5: Cooperative Single-Tasking - for someone coming from an enterprise and server applications UNIX background, this chapter was an excellent discussion on how the iPhone environment is akin to a web based environment where each app is like a web-page. You can even (as most devs would know) pass control between apps using the iPhone SDK's Custom URLs. This also had a good discussion on launching quickly, handling standard interruptions, etc. I will revisit this chapter.
Chapter 8: Progressive Enhancement - This is a good overview of some of the sexier features you might want to drop into an app. Sound, location awareness, networking, etc. The coverage raises lots of questions for you to think about and has some good lists of things to think about like how will your app handle a lack of location awareness if the user has turned off location awareness or says no to the prompt to use location awareness in your app? How will you handle sound and sound effects in your app if you use them? How will you deal with incoming calls and sound? Lots of good things to think about if you touch on any of these features in your app.

(legalese)

Book Report: Programming the iPhone User Experience

Publisher: O'Reilly
Author: Toby Boudreaux

Title: Programming the iPhone User Experience
Tagline: Developing and Designing Cocoa Touch Applications

Overall

• The book had a nice lief motif throughout which was to think about design first. I felt the discussions framed in this way were very helpful in eliciting thought about how can I do better with my app design? Have I thought various aspects of the design through enough? Or, I have not thought of that, what should I be doing about that aspect in my app?
• As someone that has read most of Apple's iPhone introduction guides for programmers, the book could have been shorter as I felt there was a lot of rehashing of the basics. Like application templates and controls. I am sure that if I had done anything outside of the basic touch actions then I would have covered most of the touch chapter as well. That said, if you are new to iPhone programming or you have not read the programming intro docs from Apple, then by all means this is a short book with lots of overview. You will want more details than contained here but this will give you a good overview of the iPhone features you'll want to think about while designing your app.
• The best chapter by far and the reason to buy this book in my opinion is chapter 9 on UX Anti-Patterns. Once you read this (and if you have used a reasonable number of apps) you will be saying, ya that is a bad design. If you've wondered what it was about such and such an app that made it not feel right then this chapter probably has a clue. Read this chapter to keep in mind UX designs to avoid without great thought.
  

Chapters In Order of Most Interest to Me

• Chapter 9: UX Anti-Patterns - the first chapter I read and the best one for a lot of good tips on how not to develop your UX. Every iPhone developer should read this chapter. I will reread this chapter occasionally to keep UX issues fresh in my mind.
  
• Chapter 5: Cooperative Single-Tasking - for someone coming from an enterprise and server applications UNIX background, this chapter was an excellent discussion on how the iPhone environment is akin to a web based environment where each app is like a web-page. You can even (as most devs would know) pass control between apps using the iPhone SDK's Custom URLs. This also had a good discussion on launching quickly, handling standard interruptions, etc. I will revisit this chapter.
• Chapter 8: Progressive Enhancement - This is a good overview of some of the sexier features you might want to drop into an app. Sound, location awareness, networking, etc. The coverage raises lots of questions for you to think about and has some good lists of things to think about like how will your app handle a lack of location awareness if the user has turned off location awareness or says no to the prompt to use location awareness in your app? How will you handle sound and sound effects in your app if you use them? How will you deal with incoming calls and sound? Lots of good things to think about if you touch on any of these features in your app.
  
• Chapter 4: Choosing an Application Template - this was a bit fluffy (see next point about things covered in the basic iPhone dev docs) but it did have a good discussion around identifying a problem to solve, thinking about how to solve it, and keeping your app focused. If your app's feature list and views are getting a little unwieldy then think about breaking it into different apps that are focused on solving only one of those features well. I thought this was a good idea and with the use of Custom URLs you could design a series of apps that work together collaboratively but would allow the user to purchase only the pieces they require. There are already devs out there that are opening their Custom URLs to others such as BirdFeed's Custom URLs from developer Buzz Andersen.
• Chapter 6: Touch Patterns - good discussion about how to handle touches, touch accuracy (which lots of apps ignore with tiny buttons that are almost impossible to click), and a good overview of how to interact with touchable views. Worth reading for the discussion about view touch accuracy alone.
• Chapter 7: Interaction Patterns and Controls - I found this rehashed a lot of the iPhone developer documents again so it would be good for beginners but if you have touched most of the controls in here then maybe the patterns will be of interest but the controls discussion was skip-able.
• Chapter 1 to Chapter 3 had too much fluff which was good for those that have not read the Apple iPhone development documents but in general if you have read the iPhone Application Guide and the Mobile HIG then you can skip these.
  

Ok, so the FTC just passed laws about disclosing how a reviewer/blogger/etc benefited or whatever for posting a review. So how did I benefit? Well first, the book was free to me. The CocoaHeads group I belong too has an O'Reilly User Group membership. We get free books to review as a group every so often. This book came in and I got to review it for the group. I had the book for a month and it goes back to the group tomorrow night when someone else gets to take it and review it for a month.

Would I buy the book? Yes, I found I ran out of time to implement some of the code ideas in the book and I'd like to take some time to sit down and work through the samples. First I want to go and read Coders at Work though, so that will be the next purchase.

If you want to join in our monthly discussions and are an iPhone Dev in Ottawa, Canada then check out our CocoaHeads meetings.