The initial focus of this post had been to give a detailed insight into the processes we adopted in building out our initial release of the Availo iOS App. This is a fairly common topic so I wanted to focus it more towards the practices we have adopted into a lighter article.
Experience tells us that a little planning goes a long way in any kind of development project, even more so when developing your initial product release or MVP. If everything goes to plan your first release will evolve as it’s functionality grows. With this in mind it’s important to plan ahead — no one can place a safe bet on where their product will be a few miles down the line and therefore it is important to consider these evolutions from the get-go.
Here at Availo our development team come from years of experience working in various sized organizations on many types of projects, the following is just a small insight in the process we used to create our initial release.
The Big Debate
From the Availo perspective we were always going to go IOS for our initial release — our founding team consisted of an IOS developer, IOS development is known to be quicker to develop in and Android and it would greatly reduce our testing processes as we aimed for release. Android is on our roadmap within the first 3–6 months of our final release, so fear not it is coming!
Like any good project planning the team’s ideas can be huge, with long road maps and managing the ever increasing expectations of potential users it’s fundamental to keep everything on track and focus on the key proposition features. During our early team meetings, we discussed and highlighted the key areas we could see issues with from each sector of the business and with the development side it was important for us to show progress to potential partners and investors. These people are interested in top level features and your road map — they are not interested in the details at this early stage — areas like these can be built out following MVP. It is important to find that balance between feature rich and bug free when on a projects you are setting key dates for releases.
Set the Focus
For Availo we are able to break the application into 2 key areas, user profiles and messaging. There are some great updates on the horizon but this will always be the key focus of Availo at early stage — showcasing freelancers and allowing users to start communications as easily and effortlessly as possible.
Now to the untrained this may seem like a small feature set, after there’s only 2 right? But wait a sec… once we break down the user journeys there are a number of situations we need to cater for. This is where the beauty of the agile development methodology comes to play — working in sprints and identifying key user stories/ journeys. At the moment we don’t have a fully featured messaging platform to compete with the likes of WhatsApp and Facebook Messenger, where we can send gifs, videos — groups chat etc., these are examples of details we can easily pass to future releases.
Setting up the Project
It can sometimes be great being the sole developer on a project, especially when starting out where like us usually it will consist of a small team with a specialist in each sector (e.g. design, management, development) — but sometimes we all need a bit of interaction in our lives and making this as painless as possible is great for the soul. Coding standards, folder structure, authoring certificates and server choices are all areas you will need to make decisions upon.
Any good team no matter how large or small will have a clear set of coding style guides (we’ve all seen the “Spaces or Tabs” debate episode). Coding standards let a team know how to write their code in a structure that ensures a large project is coded in a consistent way that is easier to understand and also allows new developers to see how the codebase is written out. If all goes to plan your team will need to grow and no one likes a grumpy developer.
At Availo we are a lover of Cocoapods for dependency management. For any iOS developers who haven’t checked it out definitely take a look. CocoaPods was created by Eloy Durán in 2011 as a way of resolving dependencies and downloading their required source code. From a very top level perspective, it is a very quick and easy way to manage any third party libraries you may be using in your app — from a house keeping point of view it is super easy to add, remove and update libraries as you require them without a trail of git submodules in your commits.
What… No Storyboards?
After a good few years of developing apps our team have a good understanding of different ways in which apps can be built with and without storyboards. Storyboards are great for visualizing the structure of your app and the layout of your views with auto layout. With Availo we opted to go for fully code based interface — no Storyboards or Xibs, all hand coded, although we do utilize third party software such as PaintCode and QuartzCode for complex animations and visuals.
As apps become more complex and the requirements of visuals and interactions become more complex it is very easy for storyboards to become a horrid mess of views and segues which offer little more than an indication of an overviewing layout.
Everyone has had to deal with a storyboard merge conflict at some point in their career, splitting sections or views into storyboards is the best way to solve this when working with multiple developers but it’s not bullet proof without a quick nod towards your fellow developer to see which area of the app they are working on.
With the introduction of the Adaptive Layout and Size Classes in iOS 8 many developers jumped onboard with the Storyboard concept but it feels like we are now returning full cycle — at the end of the day developers work more effectively when they’re coding. Checking depths and looking for hidden views in Interface builder because someone ticked the visible box is just one of those things we would all prefer less time scratching our heads over.
Here’s a few other points worth considering, sorry for the brain dump…
• You’ll learn Swift/ Obj-C a lot quicker if your coding in it than switching in and out of Interface Builder
• You can’t “Find and replace” like you can in your code
• Porting a project to Android will be a lot easier if you just need to study code
• Code reviews take a bit more work
One of the biggest areas of Availo is the messaging — like any non-messaging startup we were never looking to build out our own messaging platform for MVP. Further down the line this is something we may look into but for now we’ve adopted a solution that would meet some fairly basic requirements
• Allow users to locate, initiate and perform a conversation with a fellow user
• Allow users to manage conversations with other users — i.e. archive, delete
• Send push notifications to users about messages
Again through experience our developers had experience with a few messaging platforms and a decision was made — reasons for our final messaging platform are a post in their own but by breaking down requirements and the product roadmap we were able to implement the said functionality relatively painlessly over the course of a few days. There are a few big players in this field that offer some great solutions and products across a range of delivery methods (e.g. ip messaging, voice calls, sms). Do some homework and also try a few out — code examples and tests on small implementations are a great way to see if the platform is something you and your team can work with ;)
Unit testing and Bug Tracking
“Write tests before Code”… in an ideal world right? Through the development phase of the build we were working from designs that although signed off were still evolving… the beauty of agile right? As we countdown to Beta release these are still to be reviewed again by user groups and our creative team. It would be great to be able to write Unit Tests for every aspect of the build but like any team will tell you this more often not just doesn’t happen. Deadlines still need to be met and you have a test team to pick up on the bugs right? At Availo we like to let people take ownership of their own department, at present we are still a very small team (under 10), and as we grow we need to get the correct foundations in place. This is not to say that we don’t Unit Test.
After the initial phase of early development, we have fully adopted Unit Testing, including UITests and the testing of our Restful services including timeouts. Our reason for leaving this a little later was just the timelines we were working to, trying to build out our MVP in time for meetings and demos.
I suppose I’m trying to say sometimes a bit of self-interpretation can go a long way… from agency experience it’s fairly common to not hear the phrase Unit Test mentioned a little more than at an initial briefing as a question from a potential developer. We incorporated Fabric from the start — and Crashyltics is great at keeping us posted on any issues experienced out in the wild — there’s nothing more addictive than testing your app on the go, out and about, on the tube, in and out of Wi-Fi — real life situations in which you can a user may find yourself using your product.
So where are we now, after a fairly relaxed development cycle we are now counting down to our early release — final amends, onboarding testers and adding in those last few features.
I know this is a fairly basic overview into our development processes — if there’s anything you feel we’ve missed and would like to ask — feel free, it can be a daunting task taking on a new project and leading in such an evolving sector.