With the iPhone 5 just out, guest blogger Andreas Kwiatkowski (left) talks us through what it takes to put together an iPhone app, drawing on his recent experience making and releasing productivity app EISENHOWER.
Many web startups reach a point where a corresponding iOS client shall come into play. In fact, many product managers and developers are faced with the problem that although there are plenty of bits and pieces online, sometimes it just helps a lot listening to somebody sharing his experiences from start to finish at the campfire – including a few tips where to start looking for the right tools and help in times of issues or weird compiler errors.
Following our experiences with different iOS development projects we especially wanted to share with you how we made EISENHOWER – from the very beginning until App Store release, to give you a better understanding in what to expect, plan with and do according to a short but comprehensive guide…
Pizza, beer and wireframing
When building EISENHOWER, we started off with rough ideas over pizza and beers at a restaurant around the corner and then quickly went on to turn these into sketches on paper.
Many people prefer wireframing tools with which you can even build click prototypes to help people better understand your ideas, too. In addition to that, many mobile development agencies are pretty happy with a deck of wireframes with annotations instead of long and complex waterfall documentation as a basis for their proposal and developer briefings.
At different stages during our conception phase, we chose OmniGraffle for expressing and testing rough ideas as it is not only fast to create simple mockups but you also do not need to worry about somebody being unable to read your handwriting.
If you would rather not spend that much, there are many decent alternatives available to help you getting started: Balsamiq Mockups, Mockflow, Hot Gloo, or the entirely free web application Mockingbird might be worth checking out. For some, even an existing PowerPoint or Keynote installation or Google Docs’ drawing option while using templates might be a good solution, too.
If you also want to add some clickable buttons, page load events and further logic to simulate a client-ready prototype, you could try WireframeSketcher or Lumzy instead. InVision is another solution that allows you to not only build wireframes but also link them together simulating a working prototype.
Be prepared for even more choices when searching for “wireframe or mock-up app” on Google. Furthermore, there are lots of templates like those from Graffletopia and other resources up to entire sets of design widgets to help you get started.
Project management – a few tools
When starting development, you will soon realise – when it comes to breaking down views and logic into manageable work items – that development tasks are nearly endless. Even more – when maintaining an already released application, people will provide you with lots of feature requests and bug reports to be taken care off.
As EISENHOWER is a part-time project, we chose to work more like Kanban (a development process focused on just-in-time delivery, using a queue system) and therefore are using Trello (pictured above). Depending on your individual requirements you might prefer other story and bug-tracking software such as Pivotal Tracker for SCRUM-based environments, JIRA if your team demands a more strict process management and tools like Lighthouse, Redmine or Bugzilla for additional bug tracking in case you can’t live with the latter’s features in terms of bug management.
Design for all budgets
You could probably use entirely free tools like GIMP (pictured below – now running natively on Mac OS X) and Inkscape, or superior but pretty affordable graphic design tools like Pixelmator, to create files with different layers for all single parts to be exported later.
While creating EISEHOWER, we went with Photoshop for several reasons: you can do basically everything with it, there are thousands of plug-ins, actions and templates out there and they recently even introduced a subscription service that can get you an up-to-date Photoshop version for around €20 a month. However, if you are quick and your app design is more a one-time effort, you might finish your designs within the 30 days of unlimited trial.
In addition to built-in features, external tools like Slicy can speed up the process of exporting retina and non-retina graphics for development and thus support the choice of Photoshop over its alternatives.
When looking for a mobile designer instead of designing yourself, reach out to app designers within or outside of your network who have made apps you like. You could also browse established designer communities like Dribbble, Scoutzie or one of many places showcasing app designs like Meerli. In most cases, you do not need to hire local resources, but can kickoff the project with one or two personal meetings and then switch to Skype and design feedback tools like Notable.
If you do not have the capabilities or resources at hand to create an individual design for your app, check out template sites for components or entire app designs at places like 365psd or App Design Vault. Well-done templates in most cases will cost you a few bucks but €100-200 is nothing compared to paying for a designer working with you for a week or two.
If you are starting with designing for iOS, make sure you are using an iPhone as your primary device (or have at least some valid experience with the platform) and install and check out applications similar to yours (and some user experience masterpieces apart from that). No matter what, make sure to at least skip through the Apple design documentation once before firing up your graphic editor.
Development – from Xcode install to TestFlight
To build an iPhone app, all you need is a recent Mac OS X with Xcode installed – which is available for free on the Mac App Store. If you already know Objective-C and the iOS SDK, you are good to go and can start coding your next big thing right away.
Otherwise, there are plenty of great introductory guides and books to help you get started. Start Developing iOS Apps Today and Ray Wenderlich’s blog might be a good start. Find videos on NSScreencast or iDeveloper TV. And for the old-fashioned, books like iOS Programming: The Big Nerd Ranch Guide should be a good choice.
When you’re having problems, there’s a lot to find around the web. The best bet is almost always Stack Overflow, where you can find a lot of people willing to help out.
As we were both contributing to EISENHOWER at the same time (Tim – pictured below – with code, myself with graphics and translations) but occasionally working remotely, we set up a free source code repository at Bitbucket which has recently been acquired by JIRA developers Atlassian. GitHub is more popular and has a strong community but having a non-open sourced repository requires a paid plan.
At least when building an app that you are planning to work on for months or even years it is definitely a good idea to use automated tests. With EISENHOWER, we took the extra mile and added necessary code early on, reducing future efforts in testing when further developing or changing the existing code base.
For unit tests we used Kiwi, which makes it possible to use RSpec syntax for Objective-C tests. If you are less experienced with test-driven development, Graham Lee’s Test-Driven Development iOS Development is a great read to start with.
For integration tests we used Frank, letting us write Cucumber features to test our app from the outside, thus supporting a great user experience from the very first start on.
Instead of manually having users figure out their unique device identifier (UDID), and adding them to your provisioning file one at a time, we used TestFlight to automate user management and distribute early builds to our testers. TestFlight also lets you see who really spends time on testing and who is rather wasting one of your precious 100 testing device slots (after adding people’s UDIDs, you unfortunately can only delete them once a year).
For automated crash reporting and analysis of EISENHOWER, we chose Crashlytics, which aggregates all crashes that have appeared while testing (and in future production mode) by crash pattern and frequency, allowing the developer to identify and focus on the most critical problems.
Within larger development projects, it is best to use a continuous integration server like Jenkins to automatically create builds and then send them to TestFlight every time new code has been pushed to the git repository. This very much helps your developers to care more about coding instead of keeping people entertained with fresh builds all the time.
Getting into Apple’s App Store
To submit apps to the App Store you need to join the iOS developer program for $99 a year. You can enroll as an independent developer (“individual”) or using your company (“organisation”). In any case, plan around a week to have your information reviewed and approved by Apple following the initial steps.
If you are planning to make money by selling apps or subscriptions or through in-app purchases or advertising, you are also required to fill in short surveys and should expect separate approval within a day.
App Store submission
As many review requests come in every minute, you will get queued for a week or two until your app is reviewed by someone at Apple both automatically (illegal components or program routines) and manually (smoke testing).
Certain escalation routines that let you climb the ladder from submission to “In Review” faster (Expedited Review Request), but you should play that card wisely as you need to provide a good reason (app not working, investors going mad about it etc) and Apple only allows you to do this a few times a year.
Tip: Try not to finish your app around Christmas as the review process is usually paused then and there might be many others in line before you when it resumes.
App Store review
The review part of the process takes up less time, sometimes as little as an hour or two. For apps with very complex functionality or business models, better plan for more than a day – up to another week. Just like a call center, some app reviews can be escalated up until somebody e-mails you back in the middle of a review or even calls you on the phone (including a friendly excuse when aware of the different time zones).
Personal interaction, however, rarely happens, so make sure everything is working fine before submitting, otherwise you might risk a decline with only brief reasons given. To prevent unnecessary delays, always also provide user name and password credentials set-up for testing when your service requires authentication in the “Review notes” form field.
This page gives you an impression of the currently anticipated time for getting a production build into the App Store. In terms of EISENHOWER, it took us 12 days from build upload to approval. That’s plus another few hours from “Ready for sale” until it finally appeared in all search indices across the various countries’ App Stores.
Ready, steady, release!
How to woo the tech bloggers
There are many ways to gain traction in your very first days of sales. Many of them are free, like getting in touch with the press shortly before and after release. Mike Butcher from TechCrunch has published a short presentation including tips on how get through to relevant blogs here.
Beyond a short and precise press briefing, get your app website ready and (especially if you are not offering a free app) make and integrate a nice app video demonstrating your core functionality in 30 to 60 seconds. Think of payment – or only the need to push two buttons and enter your App Store password – as a wall between potential customers and the real app experience. A video demo is your window through, helping visitors to assess if your app is really worth the effort.
For our EISENHOWER video, we did the entire screen capturing using Reflection. As we are dealing with a specific niche, we also produced a short tutorial video on using the Eisenhower matrix. Scripted and exported with Apple Keynote and cut with a pre-installed iMovie, this also saved us some serious money. A friend’s voiceover and sound effects have been recorded and arranged with GarageBand before exporting and uploading the final movie.
The actual release – and analytics to follow it up
Before the final states – “Processing for App Store” and “Ready for Sale” – comes a little configuration in iTunes Connect, including selecting countries where you want your app to appear in the regional App Store, choosing a pricing tier and composing your description and app screenshots for the app’s App Store meta information. Then you are ready to go and can start marketing efforts, with success measured mostly by daily sales statistics available in iTunes Connect daily (updated at around lunch time in Western Europe with numbers of each previous day of sales).
For EISENHOWER, we are using AppSales (only available through manual installation on development devices) together with Boxcar to have these reports pushed to our iPhones as soon as they arrive. AppAnnie then also delivers a daily report, plus information on overall and category ranks and their trends in different App Stores across the globe.
Good luck – and always keep in mind there is no such thing as an overnight success. Success on a marketplace with close to a million choices is built by continuous passionate work, leading to rare but happy moments of publicity and sales spikes. Make sure you build a loyal fan base with high satisfaction and retention instead of a huge pile of e-mail addresses…
FOR RELATED READING, CHECK OUT:
App of the week: Eisenhower, the to-do list to keep you on task – just 32 of them
Why you should stop looking for a technical co-founder – at least for now
New app analytics site Apptrace launches from Berlin