Frequently Asked Questions

What is Xamarin (pronounced ‘Zamarin’)?

Xamarin is technology provided by Microsoft that allows developers to create a single design and write a single app that runs natively on both Apple or Android. One design, one build, two apps. We have a distinct advantage over those of our competitors who do not use Xamarin as we are able to develop Apple and Android apps simultaneously which means we can deliver your app faster and at less cost to you.

Apple and Android devices have distinctly different development languages (ObjectiveC/Swift and Java) which traditionally meant writing two apps, one for each. The Xamarin technology allows developers to write apps in a single language (C Sharp) that deploys natively to both devices.

A further complication has always been the user interface. Users of apps on an Apple device expect the screens to operate in a certain way. Android apps on the other hand operate less uniformly, but the users expect certain behaviour and do not necessarily warm to the way an Apple app behaves. Xamarin provides a tool called Xamarin.Forms that allows the building of a single user interface that operates in slightly different ways depending on the device it runs on. Very clever.

It would be incorrect to say that all the development is generic across Apple and Android devices as there are still a number of device specific controls, like how you interface with Facebook and Google Maps, plus there are a number of design activities that were traditionally common across devices. But even with this in mind we believe that we can be 30% more efficient than developing using the old traditional native app development tools. We are able to pass on the savings which stem from these efficiencies to our clients.

Full details about Xamarin can be found on the Xamarin site (but note, their site is aimed at developers like us).

What are ‘native’ apps?

We talk about apps that run ‘natively’– this means that the app talks directly to the operating system and utilises the full capabilities of the phone or tablet. The alternatives are systems that run within ’emulators’ on the phone. We believe in writing native apps and getting the maximum performance and flexibility from each device.

What other technology do you use?

We use the Xamarin toolset to code in the C# language which creates native apps on Android and iOS devices. We utilise the MVVM Cross architecture for cross device deployment, and BitBucket as our code repository utilising the GitFlow methodology for source code management. Within the design we architect business objects using the UML methodology. On iOS we create our user interface using Xcode Interface Builder producing xib files and on Android the user interface is created as axml files. For project management we use the Agile Methodology.

But the technology is only half the story. Enterprises demand the delivery of high quality, highly maintainable, enhanceable code that underlies the delivered app. This is what distinguishes us from our competition – we have extensive experience delivering IT systems in corporate environments and know how to deliver to a standard that will exceed your expectations.

What level of involvement do you require of us?

Different clients have different levels of IT skills and want to have different levels of involvement, but as a minimum we require that clients make time to help define the specification, sign-off key documents and be involved in the daily 30 minute “scrum” meetings.

What maintenance options are there?

We build apps that are highly maintainable and suitable for our clients to maintain in-house. Ongoing maintenance and enhancements can be done in one of three ways: in-house by the client, by us, or outsourced to another organisation.

Do we get the code?

Absolutely. In fact, depending on your internal IT capabilities, our preference is for you to progressively receive, build and User Acceptance Test the product as we build it. You will receive and be able to review and test the code continually throughout the project.

How do you manage ‘scope creep’?

A particularly important question for a fixed price build. Scope Creep refers to additional requirements being added to a project after the design process is complete. What may seem like minor changes in requirements often have quite significant impacts on the build process, not because they are difficult but because they simply haven’t been considered within the overall design, and therefore may upset the build process.

Some changes to the original specification occur because the specification wasn’t sufficiently detailed. It is our responsibility to define the specification to a level of detail where this doesn’t occur.

But, of course, during the design and build phase additional requirements do become apparent. We park these in a category called “backlog”, then complete and deliver to the original specification before considering the inclusion of the backlog. This is the most overall efficient path.

How do you handle project delays?

Projects can get delayed for a number of reasons (we call these “blockers”). Technical blockers within the app are our responsibility to clear. Requirements clarifications are the responsibility of the client. Every other blocker is addressed on a case by case basis at the daily scrum meeting.

In extreme cases the whole project can be blocked in which case the project will be suspended until we can proceed.