Author: Chaise Hocking

I recently had the opportunity to work for a client who wanted to develop what they termed "app indexing". What they meant by this was that they wanted their users to be directed into a specific screen of their iPhone app when they tapped on a particular Google search result. Put differently, they wanted the user to feel as if Google had returned search results specifically for their iPhone app. They also wanted to be able to send out links via email, SMS or other marketing channels. If the app was installed, opening such a link on their phone would result in the user being taken to the relevant points in the iPhone app. If the app wasn't installed then they would just be taken to the mobile website. The way this is achieved is through what Apple refer to as "Universal Links". In this post I'm going to discuss how we implemented Universal Links at a client of ours, some of the obstacles we faced, and how we overcame those obstacles.
beacons I was recently lucky enough to get a hold of a couple of sets of Bluetooth low-energy beacons; three Estimote beacons and a set of five Kontakt beacons. Whilst the Estimote beacons sure looked a lot fancier, I was keen to see if it was all just for show, or if they truly were a superior product. So I got to work putting them through their paces by conducting some controlled experiments to test their behaviour. Throughout the rest of this post I'm going to discuss the results of these experiments and conclude with some observations on their real-world usefulness for providing proximity-based services.
We’ve all heard developers say it: “I’m a terrible drawer” or “I’ve got no design skills”. Perhaps we’re even guilty of saying it ourselves - I know I am. But after attending this year’s Swipe Conference I now subscribe to the opinion that this is no longer acceptable. We are all responsible for the design of the app we are building; developer, designer, tester, or producer: every member of the team is accountable for helping shape the app’s design and interactions.
A common problem that we often experience when developing iOS applications, is how to allow communication between our controllers, without the need to have excessive coupling. Three common patterns that appear time and time again throughout iOS applications include:
  1. Delegation
  2. Notifications through Notification Center, and
  3. Key value observing
So why do we need these patterns and when should and shouldn't they be used?