Context
One year ago we decided, my friend and I, to work together during our spare time and to develop something (did no really know what by that time). As we did not have any experience on the development on the Apple ecosystem, we decided to build an iPhone application. Of course we knew that it would not be a revolutionary app, but we wanted to test some fancy technology and, most of all, we wanted to build something from A to Z (iPhone app and server part). Well, it took use one year (oh dude, that was long) but we really enjoyed that.
The project environment
- git for the collaboration (I love this tool). Obviously we used github to host the code.
- iOS for the client part (we though of HTML5 also but well we did not really catch this one)
- node.js for the application server side
- Redis: we wanted to give a try to a nosql db and redis seemed really cool (it actually is)
- and we took a « dedicated » VPS to install all those stuff (we used nodester.com and redistogo.com at the beginning but quickly decided to rent a VPS so we could do whatever we wanted on this guy).
The basic architecture
We decided to build an API server from which the iPhone app will send/get some data in json format. The server only sends data, it does not serve views. Doing that this way allow any kind of client to issue REST HTTP requests and perform its own interface. HTML5 and Android might come to the picture sometime maybe.
Sharing code
At the beginning my friend was dedicated to the iOS part, I was working on the server part.
Then, we both worked on the iOS client, the server was almost set and did not require much development at that time.
For the server part development, code sharing was really neat, not hard to set up.
Regarding the iOS code, it was not that easy mainly because of a bad .gitignore settings to which we did not give much importance at the beginning (we were wrong, it was an important part). Several times we had to change our project settings because it was over written by the other developer one’s. Well, it was just some stuff we keep for a too long time before realizing it was a pain in the ass not having set the stuff correctly from the start. For other projects, I now put the emphasize on the initial config as it really saves some time and troubles (and fight) during the development.
Our advice: spend some time right from the beginning to set those things up correctly, that is some time saved for the future.
Development process
Very early we put some friends in the testing process. The Build – Measure – Learn loop (from Eric Ries Lean’s startup movement) was something we really wanted to put in place so we can have user’s feedback really soon (it was our basic understanding of the lean movement by that time 
). That was great doing it this way as it helped us to learn a lot and to work on making an user interface more user friendly and intuitive. Oh boy, I’m too bad at building something that looks good (it’s very hard to be a developer and a designer, well…. hard for me at least). My friend was better at that, it’s a relief. Adding our friends into the loop from the beginning was very helpful as they pointed fingers to really ugly stuff and unfriendly function, stuff that we did not notice ourselves.
http://testflightapp.com/ is such a great tool to share iOS application and have testers very early into the loop.
Our advice: add some good friends in the loop quite soon so they can prevent you from making ugly stuff that you do not even realize
Our fights
There were not many, that’s a good point (and no real fight though). It was sometimes complicated for each of us to have the other agreement to develop a new functionality or to rebuild a big trunk of the code. Negotiations were pretty smooth and we usually agreed on some stuff that could satisfy the other. We were quite new to iOS design, and we figured out quite late that our global design needed some big changes to be cleaner (sometimes I was upset when I realized we made big mistakes in the conception phase and I was really pushing to rebuild a really big part, I mean pushing really hard). I talked about conception phase… hmmm… there was no real conception phase, and that was a mistake because we worked on that when we had already done too much dev.
Our advice: take some time at the beginning to figure out some best practices (mainly if you’r using a techno that you do not know) before going fingers first on the keyboard and start coding.
Our application
As already said, we wanted to build something entirely and discover some new stuff. Well…. we succeed at that at least and we are happy.
Today we will go into a real test and that’s great. The support part (for the few user will have, if any , will certainly be interesting).
If you want to give it a look (small personal advertisement), the application is named Sharies (http://sharies.net). It is dedicated to the sharing of things that users does not use anymore. You have a book you like, but you’ve already read it, so why not give it to someone that would appreciate to discover it ? It works for things but also for events that one would like to share.
Additional item: The AppStore approval process, first submission first rejection :(
I was pretty sure, after 7 days (that is the average validation delay of an application http://reviewtimes.shinydevelopment.com/), the app would be available this week-end but… I got the rejected status. Too bad. The reason was because the Google logo was not visible on the Google Map used in the app. We obviously did not hide it on purpose, but it was in fact hidden behind the tab bar. After a quick fix, the app was resubmitted. Dunno if it will take one whole week or if some kind of track records exist. BTW, I was quite surprised that the review process consists of running each app and manually testing it (to detail the rejection reason, I was send some screenshot of my app) where the logo was missing.
After 7 days, the second submission of the application is now available on the App Store.