The Development Process
“The whole difference between construction and creation is exactly this: that a thing constructed can only be loved after it is constructed; but a thing created is loved before it exists.” – Charles Dickens
You’re now in the game, congratulations! By going from having a dream to actually building it puts you ahead of 95% of the people out there, and for that you are destined for great things.
You’ve paid your deposit, the developer and development team have gotten all the information they need, and now you wait for next steps. But what exactly are they doing? How does an app REALLY get created? Well, here’s a very top level view for anyone who’s interested in the mechanics of this whole thing.
I’ve mentioned this a few times now and for those of you who don’t know what I’m talking about, I apologize. Xcode is the software that developers use to build apps in. It’s what Safari is for web browsing and what Mail is for email. It’s a piece of Apple software that allows you to write commands that interact with each other and perform actions.
The developers go into Xcode and start building out the architecture of your app – this is why you spent all that time on your hierarchy at the beginning. On the left side of the above diagram, there are all the files to edit, which are batched into different screens and functions. This may look like homescreen.m or splashscreen.m and so on. The middle screen is what’s called XIB file view (pronounced zib) which is kind of like a design viewer and is drag and drop. The right area is the raw editor where you can begin to associate different parts of the app to different actions (Touch this button, go here).
The developers will use what are called Frameworks within Xcode to do a lot of their core function building. These frameworks are pre-packaged sets of code that Apple gives to all developers so that the heavy lifting is already done and the developers can focus on the customization stuff. Steve Jobs was a really nice guy 🙂
Frameworks will be things like map functionality, OpenGL (graphics rendering), Address book, etc. The developers are going to import all the frameworks they need and start building the foundation of what your app is going to do. Once they have those “imported” into the areas they want, they start writing the custom code to do things that you want to happen.
Xcode provides a very robust environment but is wildly technical for anyone who’s not used to it. The funny thing is that the Xcode 4 release is a cakewalk compared to the early days, so ask any developer and they’ll say it’s so user-friendly now it’s ridiculous. Weird.
The good news is that you don’t really need to worry about Xcode until the very end, and that’s only if you want to. By having Xcode installed on your Mac (must be a Mac), you’ll be able to download the project when the developers complete it and run it on a virtual iPhone simulator on your computer. Do yourself a favor, though, and please don’t touch the code unless you know what you’re doing.
Most people will never see this software, and that’s fine – the developers should and can take care of everything.
The process continues, and the developers begin importing all the design files from…..
Some people prefer Illustrator or another design program, but I use Photoshop. At the end of the day, it’s all pretty similar and exports the same files.
Your designer is going to be hard at work creating layered files that get sliced up and send over to the developer for implementation. Photoshop is going to allow for the designer to create buttons, graphics, backgrounds, and everything in between. If they’re designing characters or planes, etc.create, they’ll probably use Illustrator.Photoshop is going to provide the environment where all the design happens, then sent over to Xcode. This means that the design files are edited independently from the development code and then re-added to the images directory. This provides you with SOME control if you really want it in terms being able to update images without changing any of the code.
Your designer will be compiling a set of files that will have all the master design files for your app which can be edited in Photoshop at any point after the project completes.
Creating a Prototype
One of the first milestones will probably build a wireframe and a prototype. The wireframe is essentially the design, which is straightforward. A prototype is where it gets interesting because you start to see how things interact with the user and realizing that you need a “back” button here or a “done” button there.
Once you see the app live and on a simulator, you’re able to see where any disconnect happened between you and the developers. Obviously when I saw this, I had mixed reactions – for one, the design looks awful. Secondly, the functionality was pretty much exactly what I asked for, but without that “magic” that the original (ahem, $250K app) had. I quickly realized that I was going to be getting an app that did exactly what the other one did, but without the attention to detail. A great lesson.
Different development firms may have different ways of showing you their prototype, but I think this is an excellent method – anything that shows a virtual user experience in action is better than screen shots. There is a distinct flow to each app, and you need to see it live before you know what that is.
If you’re working with a firm that’s local or where you can go in and be in person, you’ll be able to have some feedback loops in real time, and they may even be able to load a test version onto your phone for you to take home. If you’re hiring a firm that’s overseas (like I did for this) they will send you this video and include a note that says “Please let us know your feedback” and it’s up to you.
The most important thing is to make sure everything is in there and that it’s interacting correctly. The design can be modified easily down the road (most of the time), but the core functionality needs to be in place from the start. Review your original hierarchy and proposal and make sure everything you want is in there.
TIP: Don’t be afraid to ask for anything new once you see the prototype. If you think that there is something that adds to the user experience, just ask. The developers will tell you whether or not it’s feasible within the project you signed up for. It’s hard to foresee these types of additions until you see a live app.
Creating the Beta Version
Once all your feedback has gone in, and you’ve gone through another set of Q&A, the development and design teams will go back and make all the necessary updates and changes. This process will probably take half the time, assuming nothing was way off, and will be handled in a similar fashion.
HUGE improvement! This made me realize the importance of taking control over the outcome of this app.
If you want your app to be awesome, make it awesome.
This means give tons of feedback and don’t settle for something that isn’t exactly what you want. The developers can build it, the designers can design it – you just need to keep working at it until you get it out of them.
Once the beta version was built and I was able to walk through it all, the team sent over the Xcode project for me to test on my own computer and device. Please note *** this is not standard practice, and most developers will not send you the project because you can very easily mess it up.
Testing Your App
You probably won’t need to do too much of this on your own since the developers should be responsible for all testing, but here’s a quick checklist you’re going to want to run through before giving the go-ahead.
1. In-App Purchases – for goodness sake, this is how you’re going to make money! Make sure this is working correctly and logging all the correct actions (note – you can only test in-app purchases on the physical phone, not the simulator)
2. Game Center – if you have a game, and you built in the Game Center functionality, make sure that it’s working correctly and leaderboards and/or achievements are logging.
3. Different Phones – Sure it works on your hot new iPhone 6S, but how about that old iPhone 5?
4. Different iOS Versions – believe it or not, some people don’t update their software regularly. Make sure everything’s compatible across the board.
5. Bug Crashes – this is hard to pinpoint, but if you stress an app enough, you’re going to find out if there is a bug that crashes the app
6. Everything else – you get the picture.
At this point, you’ve done all your testing, you love how your app came together and
there is only one thing left to do – upload it!
And so begins the notorious iPhone Application Publishing process….