Native to web iOS apps, or there and back again
This is an interesting tale of startups, resource allocation, the allure of write once/deploy anywhere and the reality that native is always better if you want a properly native looking app that performs well. On 16 July 2009 (a time between the Dawn of Færie and the Dominion of Men) we submitted the first version of our iPhone app to Apple. This was just a few months after the founding of Server Density in April 2009 and quickly became a major selling point for our hosted server monitoring tool, with push notifications particularly popular.
The app was written by my co-founder, Harry Wincup, using the project to learn how to write Objective C and iPhone apps for the first time including writing our own custom graphing engine.
The main issue we faced was allocating time to work on improving the app. Since it was just the two of us in the whole company, after the app was released we moved onto other areas of development, although we did release several bug fixes in the following months. Harry was also our only designer and frontend coder and was overworked on new features for our main web UI. We hired a backend engineer in Dec 2009 and our team then remained just 3 until around March 2011 when we closed an angel round and started hiring more engineers.
Since most of our development was using web technologies – backend PHP and Python and frontend CSS, JS, etc – our team included more people with those abilities but we didn’t have the resources to hire a dedicated iOS engineer and so kept the app mostly in maintenance mode. With the fast development of tools like Phonegap in 2011, we started playing around with them to see if it’d make sense to create our apps in HTML and CSS so that anyone in the team could work on them. And in Nov 2011 we released v2 of the app rewritten using Phonegap.
The idea was to make it easy to add new features and deploy to both Android and iOS from the same codebase. Indeed, that worked well as several engineers were able to work on the app alongside Harry. However, there were many quirks we had to resolve during development including implementing our own custom view stack controller to make the app appear as native as possible.
Then this year a new member of the team, Rob Elkin, joined us to work on an internal project but as he also had extensive iOS development experience he set about rewriting the iOS app to see how quickly it could be done natively. This was because of a number of problems we found after releasing the app – a number of bugs within the HTML/CSS/JS implementation but the biggest issue being performance.
The current iOS app works nicely if you have a small number of alerts, devices and services. However, it lags horribly once you get over a certain number. This would’ve been fine back in 2009 but we’re now seeing much larger deployments and not only do we need a responsive UI, we need to improve the management of items on screen. This is easy to do with a native UITableView because you can include search, indexes and it’s much easier to optimise for speed even with custom elements. It is possible to create custom plugins natively but then why not just implement it all natively in the first place (some good technical points about this here).
Having reimplemented the app internally with great results, we decided to run this as a proper project. Rob was joined by one of our designers, Daniele, and time was allocated to work full time on v3 of the app. And also do a proper iPad version. The existing app supports the iPad but it’s really just scaled up whereas we wanted to do a proper iPad customised UI.
We also thought it’d be easier to use our existing graphing within Phonegap because it’s already JS based, but in reality native Objective C libraries are no significantly better and run optimised for the iOS hardware. We removed graphing in our v2 release but it was a big part of our roadmap for the next releases, so although it’s not going to be in the upcoming v3 release, it is planned for 3.1 and is next on the todo list. Especially for the iPad.
This isn’t to say that you should never use Phonegap, but that different priorities apply at different times. If you have the budget for dedicated platform engineers then my opinion is that you should always implement a native solution.
So what’s new in Server Density for iOS v3?
v3 has been reimplemented natively so is significantly faster and more responsive, especially with larger numbers of items in the list views. We’ve also focused more on alerting to make it easier to see open and recent alerts, and their current statuses. And we have a fully optimised iPad UI. We specifically built it to be similar to the existing app to avoid jarring changes so most of the improvements are behind the scenes. Screenshots show it best.
We expect to submit the app to Apple next week.
v1 = Native
v2 = Phonegap (HTML, CSS, JS)
v3 = Native
Enjoy this post? You may also like How to build stunning custom iOS graphs on iPhone and iPad