We've just had our first iOS app approved by the gods at Apple. It's an internal comms tool for a ridiculously large company based in London who really should have an internal dev team. The app works something like this:
- Administrators can post news articles and ask users questions via a web interface.
- Users get notification of new news articles and questions.
- Users can post comments and like news articles or post their own micro-blogs.
- Users can respond to questions posed, and view the results to date.
- Administrators can create groups of users via a web interface which will allow users to share messages privately.
You get the idea.
Five people were working on the app:
- One guy developing the app
- One gal developing the API
- One front-ender building a webApp using jQuery mobile (for non-iOS peeps)
- One designer
- Me writing the docs, answering questions on Slack, doing a bit of UAT and making cups of tea
The switch from building a website to an App was interesting. On web projects we have one repo which everyone works from. Everyone has a nosey around and there's usually a bit of cross-over and collaboration. With the app that was not the case at all. Everyone had their own codebase, responsibilities and little / no involvement in anyone else's work. With this in mind what became crucial was the API documentation.
For the docs we used Apiary (pictured above); this create model and prototype that all the devs could work towards. It allowed allowed everyone to work simultaneously and shaved weeks off the project timeline and also raised issue that would have otherwise passed me by... how does authentication work... what is the right response code if someone tries to like something twice...
In hindsight I wish I had spent more time on the API documentation and future proofed it a bit more (API version numbers, test domains etc) but I'll save that for my second app...