From An Idea To The App Store

App development is hard work. Taking an idea and bringing it to fruition is a long and winding road with numerous hurdles to overcome.

Many consumers don’t really appreciate the hard work that goes into creating an app. I believe this is related to the idea that people don’t see apps the same way they see software on their laptops. They believe that apps are simple, watered down creations for a phone.

This was probably true back in the day when apps were new. However, these days, many apps the consumer uses on their smartphone are equally as powerful and use complicated code to achieve the desired results. You could argue that it’s more challenging to develop a great piece of software for a smartphone due to having a lot less screen real estate and not having the luxury of detailed menus and multiple windows etc.

An app for a smartphone has to be thought of very differently to that of its older sibling on a laptop or desktop machine.

Two Years Ago An Idea Was Born

In 2016, I got together with 3 guys I worked with at Microsoft. We had an idea for a real-time location sharing app. One that was aimed at cyclists, something that would allow a social element to cycling and one that would make it easier for cyclists to meet up when arriving from different directions.

In this small team of four we had one Designer (Neil), one QA Tester/Product Owner (Steve), one other QA Tester and cycling nut (Frazier) and me, the iOS Front-End Developer.

We came up with the name Zuvolo, which is actually a small province in Italy, nestling in the Dolomites. However, we didn’t realise this until after we had named the app!

Getting To Work

One of the first major hurdles we hit was none of us had back-end development skills! To achieve our objective it was crucial we had a backend server to allow us to update users devices so they could see where their friends were on the map.

Because we had many future ideas for the app, we’d need something pretty robust and something with enough flexibilty to allow us to work in an agile manner.

I started doing some research and concluded that Google Firebase was probably the most sensible route for our needs, and it seemed like I could probably wrap my head around it. Bearing in mind we had no users at this point and we needed something that was going to be cheap to get us started and could scale appropriately depending on our needs.

After agreement, I was suddenly the front and backend dev. Should have seen that coming!

The Bear Bones

One of the first areas to tackle, in terms of tracking a friends location, was to set up the back-end and ensure the viewing device could see their friend updating on their map.

It was a crude implementation, a hack if you like but it was necessary to get a feel for how the underlying mechanics would work.

We were pretty chuffed with ourselves when we got a handful of friends updating on the map in near real-time.

Decisions, Decisions, Decisions

Once we had the basic tracking working we then had to make a number of decisions. What were some of the limitations of iOS, what sort of location accuracy should we consider, would Firebase fully support the features we wanted going forward.

How would friends connect with one another in Zuvolo, how would users manage their friends list, how could we make it easy for users to simply start and stop sharing their location with ease and to ensure they had full control over their privacy.

Getting Others Involved

Whilst we were working on Zuvolo and moving it forward, at a slower pace than we would have liked, a couple of other colleagues started showing their interest. At that time we didn’t really know if they would be willing to commit their time but we got lucky because both had server-side skills.

After explaining what we intended to do, they came back with a different architecture for the back-end. They suggested we kill Firebase and move to Microsoft Azure.

We had spent a good amount of time with Firebase by this time and the entire app pretty much revolved around it. However, these guys had the necessary expertise in terms of back-end architecture so we went with their advice and started again.

Our team had grown and we now had 2 new members, Mike and Jon, both developing server-side.

Moving Forward

With Mike and Jon onboard, we started to feel more comfortable with our approach, knowing we had the expertise we needed to make this work properly.

We set up a simple Zuvolo registration process so friends could connect with one another and it gave us the scope to go cross-platform in the future.

We removed much of the Firebase dependencies and focused our efforts on Azure.

After a couple of months, Jon left us as he was moving to a new job so wanted to concentrate on settling in so we were down to 5.


Steve and Frazier are great at testing, after all it is their day jobs, and would put the app and any new features we added through testing. You could be sure that they would always find something that wasn’t behaving as expected…very annoying ;-)

They tested it in all sorts of places from urban areas to rural areas, it was tested in Italy, in France in the mountains, in Spain, in Croatia, in the USA.

During this testing we came across an issue that could be confusing to a person viewing their friend on the map. Essentially, if a friend went into an area with poor or no network they were unable to send their location and therefore the person viewing would see them as static on the map without movement.

We were trying to figure out how we might overcome this issue. How could we advise the viewing device that the sending device had no network. We obviously had no way to send any data from the sending device to say there was no network.

We eventually came up with an algorithm that would allow the viewing device to see that their friend had no network by turning their friends map icon grey, to let them know their friend was in a blackspot. Once their friend had a network connection again they would seamlessly start updating on the viewing devices map.

Changing Our Audience

During development and using the app frequently between the team and a handful of beta testers, it suddenly dawned on us that the app had far greater appeal than just cyclists. We noticed we were using it when meeting up at different venues and using it with our loved ones.

We no longer had to call or text each other to find out when one of us was arriving or whether one of us was running late. We simply opened Zuvolo and could instantly see where we all were.

Although we had yet to release in the App Store, we decided to change tact and focus on the wider user case. Zuvolo was now focused on everyone.

Privacy Zones

Because privacy was important to us and even though it was only friends you accepted that could see you on the map when you shared you location, we still wanted to give users more control.

We decided that being able to add privacy zone, around your home for example, would be a positive addition and one users would appreciate. In short, we added the ability for a user to be able to add a privacy zone of varying sizes on a location they chose. Even if they were sharing their location they would never appear on the map to their friends when they were inside their privacy zone. Everytime they entered their zone they would stop updating on the map and would start updating again on exit.


Another feature we realised that could be very useful was ‘Markers’. This would allow a user to simply place a marker on the map, choose a time that it would expire automatically and it would immediately be shared with their friends on Zuvolo.

Once we had implemented this feature we realised just how useful it was. We were using it for all sorts of things. Steve for example used markers a lot when travelling. He placed a marker on his car at the airport carpark so he knew exactly where it was on his return. He asked his friends to add markers in Italy suggesting places he should visit when he was there. We used them when we were meeting up as a team so everyone knew where to meet.

Thinking About Launching

We were 18 months into development and although we had plenty of stuff on the backlog, we knew we really had to think about getting the app out there for real.

There was still a number of bugs and areas that needed attention before this was possible so we backed off on adding any other features and started focusing on tidying everything up.

We spent 6 months squashing bugs, polishing the UI and testing to ensure everything was working as expected.

In April 2018, we felt we were ready to hit the big green button but we still needed a website and needed to get all the artwork ready for the App Store.

The following 2 months was spent on getting the necessary assets together and building a basic website. We submitted to Apple for review and on 15th June 2018 we were live on the App Store.

It’s Not About The Money

Developing an app is not about becoming rich and rolling around on a bed full of cash. App development is about the creative process, about the sense of accomplishment, about creating software that others might find useful.

For more detail around why you shouldn’t develop an app for the money, see my previous article which explains the reasons why.

The Future

I mentioned at the beginning of this article that app development is hard work and many consumers don’t appreciate the work that goes into developing an app. It took us 2 years to get Zuvolo to the App Store and I’ve only scratched the surface in terms of the app development process above.

For the future we need to create an Android version and a web version so Zuvolo can be cross platform. We are currently in the process of working on API 2.0 which will give us far greater flexibility for future features and it will make it easier to add all the things we have on our backlog.

It’s Never Finished

An app, or any software for that matter, is never finished. It’s a constant cycle of iteration, adding new features, improving on current features, listening to users, enhancing interaction etc.

It’s a journey, one of exploration and discovery but it doesn’t have a final destination. Sometimes this journey can feel like a long one, filled with frustration and filled with a sense of accomplishment all at the same time.

Sometimes it’s necessary to take a step back to see how far you’ve come. During development you can sometimes feel as though things aren’t moving forward and frustration can set in.

When this happens, it’s important to think about what‘s been achieved, an idea that was born in the brain and starting as a simple thought, is now a reality, a real piece of software that people are using and you should feel very proud.

So with that in mind, here’s a visual representation of what I mean, a snapshot of the early development stages of Zuvolo, all the way through to its current version today…the journey has just begun.

A 40s something guy. That’s it!