Category: AppDevelopment

iBeacon App Development Considerations

If you are considering writing apps to communicate with iBeacons, here are some high level things you need to think about that are specific to beacon app development:

  • Detecting whether Location and Bluetooth are on/off and alerting the user for permission to use these
  • Detecting beacons in background when the iOS app is closed or the Android app is in doze mode
  • On Android, taking account of the various Bluetooth APIs that exist for the different Android releases
  • Fetching data, associated with a beacon, from a service, such that it’s cached and not fetched every time
  • Arranging for some initial data bundled with the app so that it works straight away without a data connection
  • Fetching data before it is needed such that it’s available with no delay and when there’s no network connection
  • Re-fetching of data when it becomes stale
  • Fetching metadata from the server to control the behaviour of triggering
  • Arranging how Apple will test the app for app review otherwise complications will arise and the review will take weeks
  • Assessing whether to use the mobile OS or manufacturer supplied SDKs (or both)
  • If connecting to beacons, taking account of the unreliability of wireless connections
  • Collecting and uploading statistics/analytics to assess usage
  • Providing end user diagnostics to aid support troubleshooting

Need an experienced beacon app developer to get these things done quicker? Consider our development services.

Choosing an iBeacon Developer

We are sometimes approached by companies after their initial choice of developer has let them down. The usual pattern is failure to meet deadlines after which the developer gives excuses why they can’t continue on the project. iBeacon projects introduce extra complexities that, if not experienced previously, can slow or stall projects. In the worst of cases this can cause developers to drop out wasting valuable time and in some cases loss of money that can’t be recovered.

A resultant problem is that it’s difficult to take on others’ code. The only time this is usually possible is when the developer has left for a good reason and is still around for a short time to answer questions. Noone wants to take on abandoned code as as it’s usually poorly implemented and documented.

Organisations are generally too casual about how and who they take on for development, concentrating on cost and speed at the expense of risk. Do some checking so you reduce some of the risks.

Ask who (yes a person, not a company) will be actually doing the work. How long have they been with the company? Try to assess whether they are likely to see your project through to the end. Try to get a reference for work done by the person. Ask the reference about quality and whether the work was completed on time. The better developers provide weekly or even daily builds for you to review. This allows you to evaluate progress and provide feedback. Think about how much pre-sales feedback has been received. For most projects, developers ask things and provide initial advice. If it’s all ‘can do’ or ‘yes’ then suspect something is amiss.

Successful development is a long term relationship and a random approach to choosing one is more likely to land you in trouble. It’s sometimes the case that there’s more work to be done on amendments, enhancements, solving end-user problems and creating variants than on the original development. Think longer term.

Read about our development services.