As you may be aware, we at down with design recently launched our first ever IOS app.
This post will describe the general process of creating the app, rather than from a code specific point of view. Starting from the software download phase right up to submitting the application to the app store, I will aim to shed some light on some of the issues I came across, offering solutions and tips where I can.
Setting up the environment
The three basic requirements you need for developing IOS applications are as follows:
- An intel-based Mac running Mac OSX Leopard or later
- Apple’s Software Development Kit (SDK)
- An apple developer account (free)
The SDK ships with four development tools:
- Xcode – The place where you write, debug and run your code
- Interface Builder – Where the GUI (Graphical user interface) is created
- Simulator – Available as both iPhone and Ipad for testing your app
- Instruments -Used for analyzing the performance data of the application
With the above environment in place, I was able to code my app and test it in the SDK’s simulator. It should be noted at this point that while the simulator is an extremely useful tool for quick testing of an app, it does not give a true reflection of how an app will perform on a real device. It differs in many ways, the most important of which is the fact that it runs at a faster processing speed than a real device. Having realized this, I decided I needed to be able to test on a real device.
To do so, I had to sign up to the IOS developer program at a cost of $99/year. It may seem like a large outlay to make before you even start developing applications, but to get a true reflection of how your app will perform and to actually submit your app to the apple store, this really is a worthwhile purchase.
This is where my first issue arose though. To use a device with Xcode, you need to provide the device with a provisioning profile. Following the automated apple process of doing this for my iPhone didn’t work for me, so I had to manually complete the task by navigating to my developer account, and launching the IOS provisioning assistant.
Creating the app
Coding
As I mentioned previously, I won’t dig into the actual app coding process too much, as this is no different from programming and testing your code using any other programming language, with any other piece of software. Having said that, I would like to point you in the direction of a book I found extremely useful in my learning of Objective C (C+), the language IOS apps are written in:
- Programming in Objective C – Not a book directly aimed at IOS development, but one that helped me greatly in understanding the underlying language behind IOS applications.
The general process of coding and testing the application using a real device was very simple. You simply save your project, build and run it, and 5-10 seconds later it installs on your device just like those you download from the app store.
Images
The app we created had over 20 different images included within the bundle. In the first instance, we created these images with a resolution of 480px X 320px. However, upon testing on an iPhone 4s we noticed that the images looked stretched and blurry. Following some research we soon realized that these figures we had designed for were in fact outdated. The iPhone 4 and the new iPhone 4s have a much superior screen resolution, namely 960px X 640px. Our solution therefore was to design the application for this newer superior resolution, and allowing it to scale down gracefully.
Building on image sizes, I think I should mention the icon files that apple expect to be included in your app bundle. As a very minimum requirement, apple require you to submit a 57px X 57px icon in the Resources folder of your Xcode project. Other optional sizes to include are a 114px X 114px for higher iPod and iPhone screen resolutions, a 72px X 72px for older iPads and a 144px X 144px for high resolution iPads. You could of course upload a 57 x 57 file and a 144 x 144 file and allow the larger file to downgrade gracefully, but through my experience i find it is better to upload an icon file in each of these sizes so that you can be sure that your icons will look correctly.
The same facts are true for the launch icon. Apple requires you to include a 320px X 480px image as a minimum. I would again recommend including the four different file sizes to support all four user devices. The information regarding icons and launch pages above has been taken directly from the apple developer website, and can be read about in more detail here.
Settings
During development, I came across a couple of default settings that I wanted to override. These were all easily solved by adding new entry keys into the applications plist. As a reference point, I will briefly outline them here:
- Making the app full screen – We wanted our app to fill the whole device screen, and as such, hide the status bar that is displayed by Xcode in its default settings. “UIStatusBarHidden” set to true achieved this.
- Hiding the spinning animation on the launch page – Adding the “ShowSplashScreenSpinner” boolean key and setting it to NO achieved this.
- Delaying hiding the launch screen – We wanted to delay the hiding of the launch screen longer than the default loading time – Adding “AutoHideSplashScreen” boolean key and setting it to NO enabled us to set our own delay time.
- Removing the default shine from our icon – This was achieved by simply adding the “
UIPrerenderedIcon” key to our .plist file and setting its value to NO.
One final issue we came across was connecting to an external data source from within our application. During testing we could not figure out why (being newbies), when our code was perfectly written, that our app was not grabbing data from our external source. Research showed that we needed to enable this data source in our white list. To achieve this, we added a new entry under our “ExternalHosts” key, and simply gave it the value of “*”, thus meaning that all external sources had been added to the whitelist, enabling data to be sent to and received from all connections.
Submitting to the app store
Having fully developed our new application, and being satisfied it was ready for release, the next and final stage was to submit it to the app store. This would be the easiest stage, you would think! The process of submitting an app to the app store does seem overly complicated, but upon reflection, as long as you follow the correct process, you shouldn’t come across any problems.
The first thing we had to do was ensure that our project was using my code signing identity in its build settings.
Now we needed to archive our application (basically, package it for distribution) by going to project -> archive which opens up the project organizer. Once this was completed we needed to create a new account at itunes connect and once registered, create a new app under “manage applications”.
This opens up a wizard where we needed to give our app a name, identify its bundle ID (which we discovered has to be the same as the bundle identifier in the plist) add keywords, screenshots, icons etc. In short, the wizard links up your xcode project and adds all of the information needed to display the app for sale in the app store.
It was at this stage we first experienced the app status inside the apple connect interface. At this stage it read “waiting for upload”. Shortly after this, the status of the app changed to “Missing scrrenshot – Ipad”. Having coded our application with iPod and iPhone in mind, we couldn’t understand this error. It turned out the issue was the “target family” setting in our projects build settings was set to iPhone/iPad rather than just iPhone, so changing this to iPhone quickly resolved the missing screenshots issue.
Viewing the details of our app, and running through the binary upload wizard, we succesfully changed our app status to read “ready for upload”.
Back to the Xcode organizer, it was time to “validate” our app. We did run into one issue which was it could not locate our icon file. This was a simple file naming issue and was easily solved. Once validated, we proceeded to submit our app. Around 5 minutes later, our app was successfully submitted and our app status had changed to “waiting for review”.
Waiting for review
Eagerly anticipating the result of our applications review. We checked back on a daily basis to see if anything had changed. 8 days later our app status changed to “in review’. Another 5 hours our app status became “processing for app store” followed by “ready for sale” a further 40 minutes later.
Voila! We had successfully designed, coded, submitted and gotten our app onto the app store in the space of a month.
For those interested in the app itself, please feel free to download it here, we would appreciate all feedback, good or bad.
