What a (welcome) surprise. Although these changes enable me (and other developers) to use third-party tools to develop iPhone applications (i.e. Unity, MonoTouch, Flash CS5, etc.), I think I’m going to stick with using XCode. There’s no harm in knowing more than one programming/scripting language, and I don’t have to buy any software.
John Gruber outlines the major changes to Apple’s app store guidelines on his site. Definitely worth a read. Additionally, Engadget has the official list of what will be rejected. It’s nice to – finally – know what will be rejected before spending hours of development time beforehand.
Today marks two weeks of availability in the app store for my Japanese Alphabet Study Guide app and I thought I’d share my experience and what I’ve learned regarding iOS software development.
You can read about the rationale for creating the app, etc., if you’d like, via my guest post at JapanGaku. It’s not too long, but for the sake of the topic at hand, here’s a summary:
Learning the Kana (Hiragana & Katakana) is one of the first steps in learning the language. And, since Romaji isn’t used in Tae Kim’s guide, it seemed like a great place to start. … I looked at some of what appeared to be the more popular Kana/Kanji apps and tried to include in my own app what users felt was lacking in others (based on the reviews they were leaving). Ultimately, I decided not to include everything I initially wanted to before releasing the app. … [Doing so would have been] a significant effort, and as already mentioned, it makes little sense to invest in something that won’t be used (I’m reminded of the YAGNI programming mantra: You Ain’t Gonna Need It). (Source)
So, I had a pretty good idea of what I wanted to do before I started doing anything. In addition to researching related applications, I did some reading regarding the user interface design of an iOS app, and I looked at examples of some well-designed apps before deciding where to start. With some ideas in mind, I started throwing together some mockups together in Adobe Photoshop.
If you already know what the app looks like, it is evident that, graphically, a lot has changed (to me, anyway) since the initial design concept, but structurally, the app did not change significantly.
After deciding what I, basically, wanted the app to look like. I started putting together some prototypes, both in code and on paper, and began writing down ideas regarding application flow and functionality.
Typically, I might start with prototyping before I even think about how the design should look and feel, but since I already had in mind how the app was going to work, I did things a bit backwards this time around.
I learned a lot while creating my first application (I spent a lot of time on Stack Overflow), so I made sure to repeat those things that were beneficial/helpful the first time around. User testing, for example. I never realized how great a resource my Japanese meetup group was for testing until I started writing software. I would install beta versions of my apps on my phone to bring for testing and observe how various people interacted with the apps. It became immediately obvious that the way I thought the apps should work was different from the way other people expected them to work. What’s more, these people were/are actually my target demographic – perfect!
Additionally, organizing things/”to-do”s that needed to be completed and adding tasks and ideas as they popped up was simplified thanks to the Things application. Things is probably one of my favorite apps, especially for getting things done. I can’t describe how valuable it has been to be able to add items/tasks to my to-do lists as they would come into my head (while trying to sleep, watching TV, reading articles, etc.). If you already have a to-do list manager, great! Use what works for you, but if you’re looking for one that’s simple, powerful, and elegant. Give Things a try.
Finally, keep in mind that you’re not really done with your application once it’s available for sale. If you’re fortunate enough, you’ll get some users that will leave meaningful reviews and provide insight into how you can improve your app (i.e. “If this app had feature X, it would perfect”, etc.). If users start complaining about crashes, be sure to check the crash logs provided in iTunes Connect.
Well, I guess that about wraps it up. I feel like I’ve kind of rambled my way through this, but hopefully what I’ve shared here can be useful to someone starting out in iOS (or software in general) development. In bullet points:
- Plan & Research
- Prototype & Design
- User Testing