From uuuh to App Store
Costello’s lyrics discuss the contradiction of the war bringing back prosperity to traditional areas (…) to build new ships to replace those being sunk in the war, whilst also sending off the sons of these areas to fight and, potentially, lose their lives in those same ships. (wikipedia)
Why oh why?
I already added counters to this weebly site when I put it up, and I had a couple of visitors from the Lego project. I followed the usage of the site by using Google’s web page. But I found it much too cluttered, too daunting. I needed just one big screen with page views. A page simple enough to show it to non-technical people (like my parents). After a little searching on the web I came across the Google Core Reporting Api. That opened up the door.
The problem was, I’ve never done any iOS or OS X app development before and i was seriously lacking the proper skills. I’m quite proficient with C# and Microsoft Products, but I really didn’t want to buy a Windows Phone or Android based tablet, since I already have a Macbook Air, a sparkling new iPad Retina and a somewhat aged iPhone 3Gs – the difference between the iPad and the 3Gs actually turned out to be good test platforms!
Getting your skills up
First step: Get the required tools. Notepad won’t cut it, and without a compiler you can’t do anything. For iOS development, you need Xcode from the Apple site. There’s no alternative. Well, there actually are a few, like Xamarin Studio and AppCode, but they still need Xcode to package and deploy. Xcode basically installs everything you need for coding and packaging and even comes source control (more about that later). You can start developing your App in Xcode. You can even test your App on the iPhone/iPad simulator. You will not be able to deploy to a real device until you get your Apple Developer registration done. You may be able to deploy your app on a jailbroken device, but that kind of defeats the point of getting an App in the App Store.
Having the basic tools doesn’t cut it without the know-how. There’s Objective-C which might be daunting at first. You need to Learn iOS. You still need to learn how the IDE works. I found some excellent help and resources on the internet (duh). One of the best resources came from it-ebooks.info, which has a ton of free PDF’s about all kinds of IT topics as the name suggests. Beginning iOS 6 Development covers everything you need to know to get started. It explains everything from using Xcode, your first application, signing up for Apple Developer and releasing your first App with iTunes Connect. If that’s not helping out then there’s Stackoverflow where you post your problem and usually get a serious answer. And then there’s Google.
After a few weeks, I can say I am getting a feel for coding in Objective-C and using the iOS paradigms and libraries. It’s really down-to-earth. One of the things that surprised me was the compactness of the basic type library. You have your basic types like int, float, string etc, and a few collection classes (mostly NSArray and NSDictionary). That’s basically it. The rest is if, while, and method calls. I do miss the compile-time safety of C# generics a little, especially when working with the collection classes. In all honesty though – that is part of the power of Objective-C. On top of these classes you have UIView, UIViewController, CALayer, and all your basic support classes for fonts, labels, buttons, scrollviews, and tables. Do not let them scare you back. This stuff is actually quicker to learn than Visual Basic (and I’m not too proud of Visual Basic).
Useful tools and techniques
All those coding skills are handy-dandy. But what I really like about iOS programming is the new set of tools I got to work with. Granted, Xcode is nothing to be proud of. Give me Visual Studio any time. Nevertheless I felt like a little boy in a toy store getting to know a few goodies i would have missed if I didn’t start doing this.
The first and biggest one is Git. For those who don’t know Git: It is a bit like SubVersion. For those who don’t know Subversion: it’s miles ahead of SourceSafe. For those who haven’t worked with SourceSafe: Be very happy. Git is source control. At first it takes some getting use to, because it basically starts out as a command line tool. There are loads of clients for Windows, Linux, OS X with frankly do nothing more that prettify the command line. Ray did an excellent guide on using Git with Xcode, so no use in repeating it.
Every time you click or press ‘Build and Run’ I run a little script that increments the build number of SimplyStats. I run a version number (currently 1.1), and a Build number (which is now 2319). These numbers are embedded in the final product. Using a little source code I extract these number and display them on the About screen. I also include these numbers when I send out a crash report. The build number is also under source control so if anything goes wrong I can see exactly what version was running. Next to that, it looks cool. Simply add a Run Script block to the Build Phases section of your product and add the script. I copied mine from here and made a few tiny changes.
When I started, I had my source code hosted on GitHub.com, a free location to store your repositories. It’s very popular and will be the market leader for days to come, but it has a little problem – the product must be open source. Now there’s nothing wrong with open source except that in this case i’d like to keep my little app a little more private. Especially because there’s an unavoidable catch that there are a few API keys tucked away in the source code. I had no intention of excluding this from revision control. I wanted a private repository. A fellow programmer pointed me towards BitBucket.org. BitBucket has a few advantages for me:
- It’s still free
- Unlimited private repositories (free) for small teams
- Unlimited public repositories
- It can import existing git and svn repositories including version history
- It has awesome documentation and tutorials
- It supports basically every git feature for tagging, merging and branching, and last but certainly not least:
- Comes with an integrated issue tracker
It’s the issue tracker that sucked me in. It’s awesome to commit a set of files with ‘Added PieChart, closes issue #32’ and it automatically closes the issue. Also the issue tracker can also cross reference from issues to commits so you can instantly see what code has changed for a particular issue(!). There are loads of commands to use in the commit message. Not only that, but you can connect your issue list to JIRA and that integrates nicely. Little note of warning: to see the changes in the issue list you must push your commits to the remote repository (this took me a while to find out).
Applying with Apple
Wether your App is ready or not, there comes a time to test it out on the real hardware. As said, this can only be done by registered Apple Developers, or with a jailbroken device. But since you want to get your app to the App Store, you will need to register with Apple anyway; better take that hurdle sooner than later, because sometimes the registration process takes a little longer than expected.
Apple has excellent documentation on what you need to do to get registered. That is not the problem. The problem at hand, is that they want to be absolutely sure that you are who you say you are. When paying for the license fee make sure you don’t borrow your dads card or anything. If you are a company, you have to prove it. If you are an individual, the same rule applies. Every developer has a certain ‘fictitious company name’ they like to use when signing their product like ‘Simplicate Enterprises’ for example. Well those won’t go with Apple. I made the error to sign up with the short version of my first name instead of the one that’s on my birth certificate and it took me 2 weeks to get it sorted.
If you are trying to release a paid app (not a free one) there’s some contracts for taxes to go through. I didn’t have to do that because SimplyStats is free.
- Get your documents ready. You definitely need a creditcard, and you might need to show a passport or a drivers license.
- Always make sure you pay the developer entrance fee with your own credit card.
- For dutch residents: there’s no need to an expensive lawyer, your local city hall can sign your copies. The proper dutch term for a notarised copy is gewaarmerkte kopie. It’ll cost about €8.
- As soon as you are accepted, start reading the guides on User Interface, Deployment guidelines and Apple legal issues.
And now comes the hard bit. Testing, testing. testing. Everything must be tested. I found quite a few bugs working with the simulator. But no simulation is as real as the real thing.
You think you are almost done. While play-testing the app the idea’s started flowing. I fell in the horrible pit called feature creep. Wouldn’t it be cool if i added animations here? How about more colour schemes? I even felt the need to add more features to avoid being rejected by users. After all, your first release should be perfect to keep people hanging on!
The thing that really helped me here was making use of the milestones. I assigned an explicit due date for release 1.0. Every new bug or enhancement issue i assigned to a later milestone (or releases). This approach gave me good structure, and made it possible to prioritise some of the bugs i encountered.
I did manage to fix all bugs before the release date which gave me a little spare time before the deadline. I had a really stable version now. So i tagged that version in the repository as ready.
Then came the fun bit. In a no-pressure zone I could go and polish the App a little more. I selected a few features from the next milestone and bumped them up. Whatever happened to my new features (or possibly adding new bugs), i could always go back to the stable version and release that one. Such a safety net is really helpful if you start doing stuff like this.
- Use issue tracking. Anything is better than nothing here.
- Work with releases and set deadlines
- Put new ideas on hold unless they have a high priority for marketing.
- Be careful of feature creep
- Go for quality and consistency
We’re ready for Lunch erm Launch.
Or, handing over your baby to Apple to be scrutinised.
You’ve done so much work already. You feel it is finished. It feels so good to get your App to the App Store. It really does. It gives adrenaline. Something primal. Especially because it is your first.
Tag that release in your version control. Just do it. Even if you implemented an automatic version increment and you checked in regularly, it’s good to see it in your version history. Prepare to make a release tag if you are using SVN. If Apple finds a problem with your app, you can fix that branch and reintegrate later. Also, it looks cool.
After you submitted your App to iTunes Connect, don’t think you are done. Spend some serious time on your support page and site. Add screenshots, features, Q&A’s, and much more. Use your bèta testers to verify all content. Create demo accounts and support email addresses for your users. Open up a users forum if possible. Or a blog where you can write about the release date. After the App is released you can keep your users informed about known bugs or new and upcoming features. If you create a support email account, add an auto-respond message so people know their question arrived at the right place.
- Make sure your application does not crash to the home screen.
- Finish your support site.
- Make sure your don’t use an existing or competing company name anywhere in your description, keywords, title, app name, anyway. Especially the name ‘Apple’.
Already working on release 1.2
And now the end is near?
Hopefully, SimplyStats will not end up as the ships from the song. It might be a hit, although it probably won’t be. I realistic enough for that. But even if i’ve been able to simplify the live of a few users with this app, i’ve succeeded.