Hi, I'm Jeremy Foo.
I write software to make lazy people lazier.
tweet @echoz email jeremy@ornyx.net
Background
Recently an app was posted to the App Store that had exactly similar functionality to my first foray into proper iOS development, Traversity.
Initially, I welcomed the new entrant. That lasted until I actually saw the app for myself. Right off the bat within the App Store, I could clearly seem some form of plagiarism (or flattery, but that would require some credit where its due).
There might be times where you beta testers are not near the computer they sync their iOS devices with and you don’t have invites to testflightapp. So one of the ways to get your betas onto their phones without requiring a sync is actually by using the iPhone Configuration Utility.
Steps so you can tell them how to get your beta onto their device,
- Launch iPhone Configuration Utility.
- Click on “Applications” in the sidebar.
- Hit cmd + o.
- Navigate and select the IPA file that was sent to them. It should appear in the Applications list.
- Connect their iOS device and select it under the “Devices” section of the sidebar
- Click on the “Applications” tab
- Navigate the list till you see your app and hit the install button at the right side of the row.
- Voila.
Not so sure about the updating part but it should be as simple as replacing an existing IPA.
A year back, I attended my first WWDC. It was a fantastic experience and upon coming back, I set to create an iPhone app as a precursor to starting development on the Mac.
Now the inspiration simply came from splitting the bill with friends when we went out to eat. I set to create a replica of an actual check and gave an iPhone user the power to accurately get the amount payable per person based upon the numerous taxes and weird charges that local eateries have.
It was an exciting time, I came up with concept art, I coded, I designed. Then reality set in and school consumed me. I had interesting ideas about the input methods and various other functionalities.
I never really did get to it ever again despite getting numerous prompts from friends to continue. I knew it had potential.
So when I was working on Traversity, I told myself it’ll be the next project once its done. Next because at that time and now, I know more than I used to, having pushed out a Mac app as well.
Then I found out about BistroMath.
The feeling was bittersweet. It was exactly the same idea, with a better UI. It was however something I am confident of coming up with if I had more time. I bought the app and spent some time playing around with it and was absolutely blown away by the whole thing.
It is simple, elegant and gets straight to the point. It was the whole thing I was writing about functional design. I loved the category selection. I loved the way you select and add other people to split the check with. It was genius. The intuitiveness of the whole process should not be underestimated as well. It is a fantastic product.
I’m happy that they didn’t butcher the idea. And sad that it wasn’t me that saw to its completion. So I’m dropping Go Dutch. Not really a point in duplicating features when they have such a sweet implementation.
I emailed the guys who worked on it with congratulations as well as a note to say that I’ve had something similar brewing in the works too. Daniel was nice enough to reply and I really hope to meet up with them come WWDC10.
Congrulations BlackPixel for shipping BistroMath. It rocks as much as I envisioned mine. :)
So yesterday Apple finally approved Traversity after 2 weeks in the App Review process. My education with regards to developing and deploying an app on the iPhone platform is more or less done. Save for bugfixes and feature improvements, Traversity should be on hold until I get the next app out.
Still, important lessons were learnt and it was a worthy project as a first foray into the whole thing. Go Dutch was not such a good platform, but I’ll save that for later.
So what did I learn?
- MVC works. Bringing the model portion of the project into a stable state proved invaluable in speeding up development time with regards to the Views and the Controllers. There wasn’t much context switching with a rock solid model. It became just an exercise in getting the model API right and having the views and controllers happy together. 1 week of intensive model development = 2 weeks of pain free UI work. Traversity took 3 weeks to complete.
- UI design should be functional. And 2 simple reasons at that. Familiarity and performance. If you really need functionality that does not exist in the system, try to logically extend existing controls. Make sure it makes intuitive sense and follows the HIG.
- It helps if you can find a good designer when it comes to icons. UI helps too.
- It is a bitch working alone. Between writing code, and designing the app, you still have to work on the publicity, the support options, the website, etc.
- Version Control is your friend.
- Its actually really fun!
- Waiting for app review totally sucks. The rush to complete everything is just suddenly replaced by restlessness while you wait.
- #ifdef means to remove the #define if you want to disable a feature.
- Erica Sadun’s APIKit roughly catches stuff. Better if you just do otool and nm against known private APIs.
- Its easy to talk about what you want to do, but eventually the best measure of everything is whether it is shipping. Prototypes are useless apart from saying that an idea exists.
- A good release workflow helps speeds things up.
- Strike a good balance between best practices and hackery to get things shipping.
- Go back and do better by the hacks once you ship.
It was a fun experience nonetheless and I will be applying what I have learnt into the next app that I’m planning.
Working on a new project. Using stuff learnt from the initial work on Traversity. Namely the process where creation of the data model and associated libraries are done first and foremost before connecting up the GUI.
As a usual practice, the library will be open source. No sense creating something that no one else will use. Check the progress on Github.
This should be fun.
Too often we get too caught up with features and frameworks available to us that we go overboard with using everything. There are many developers that overuse custom user interface elements, and others that misuse system user interface elements.
When I was developing Traversity, I was looking around to see how best to make the App look good. Of all the Apps on my iPhone, one that stood out the most was Tweetie. It was simple, thoughtful and very Apple-esque. That was where it hit me that the thoughtful or lack of usage of custom elements provides an infinitely better experience. That is unless you are Bjango or Tapbots.
Instead of throwing all your custom elements onto your app to showcase your design prowess, consider that perhaps user experience is more important than just plain aesthetic appeal. A picture is still a picture unless it does something after all.
Apart form following Apple’s guidelines, there are some additional things that should matter when thinking about design for iPhone applications.
- Progressive Disclosure
If there is not data to be displayed, removed the section completely from the tableview. - Custom, but not so custom
Add features, not graphics to UI elements provided. Users expect familiar controls, but also will be delighted to know if they also provide additional solid functionality. Cue Facebook’s usage of a UIButton in the Nav bar to bring you back to the home view. - Performance
No one wants a slow performing application. - Flow
At the end, it is also largely about information architecture. How and where you display/gather information and how they are related to each other. This provides context and easy understanding for the various functions of your App.
You don’t have to be an design god to make applications that work fantastically. Even little tweaks can help immensely.
