Every year we seem to buy a bigger Christmas tree. This year is no exception and it is now proving difficult to maneuver around it to turn the lights on and off. To fix this, I’ve connected my lights up to a Belkin WeMo and I’m running the excellent Homebridge¹ server so that I can control it all via Siri:

To get this up and running on your own machine, you’ll need to do the following in the Mac Terminal:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install node
sudo npm install -g homebridge
sudo npm install -g homebridge-wemo
homebridge

This will install brew, install node, install Homebridge, install the WeMo plugin for Homebridge, and then attempt to run Homebridge (which will fail as you have no config file). Next, you’ll want to go to ~/.homebridge and create a config.json file that looks like this:

{
    "bridge": {
        "name": "Homebridge",
        "username": "CC:22:3D:E3:CE:30",
        "port": 51826,
        "pin": "031-45-154"
    },
    
    "description": "This is an example configuration file with all supported devices. You can use this as a template for creating your own configuration file containing devices you actually own.",

    "accessories": [
        {
            "accessory": "WeMo",
            "name": "Christmas Tree",
            "description": "This shim supports Belkin WeMo devices on the same network as this server. You can create duplicate entries for this device and change the 'name' attribute to reflect what device is plugged into the WeMo, for instance 'Air Conditioner' or 'Coffee Maker'. This name will be used by Siri. Make sure to update the 'wemo_name' attribute with the EXACT name of the device in the WeMo app itself. This can be the same value as 'name' but it doesn't have to be.",
            "wemo_name": "Christmas Tree"
        }
    ]
}

The important part is to make sure that the wemo_name matches the name of your device within the WeMo app; the name attribute is what you want your device to be called on HomeKit. Run the homebridge command again and you should see that your device is found and Homebridge is running.

Next, you’ll need to get a HomeKit enabled app to run all of this. My recommendation is to use the one that Apple provides to developers, HomeKit Catalog, although that will require you to know how to sideload apps from Xcode. Alternatively you can download the Elgato Eve app. Once you have an app, you’ll need to add the Homebridge using the pin that is in your config file. You can play around with the app and create rooms, scenes, zones, etc, but for now the basic commands should work. If you can turn your device on and off via the HomeKit enabled app, you will be able to activate Siri and say “turn on the Christmas tree”, “turn off the Christmas tree”, and “is the Christmas tree on?”.

Added bonus: if you have an Apple TV, you are signed into iCloud, and you use iCloud keychain, then you’ll be able to use all of these voice commands when you’re outside of your house! It’s a pretty useful way to activate these devices and I have several of them dotted around my home². Homebridge also supports many other services such as Philips Hue (without the need for their HomeKit bridge) and you can write your own plugins very easily³.

My next task is to dig out some code I wrote last year to turn the tree lights on and off automatically depending on if I’m in the house using an iBeacon…

A big update I worked on for Brapp went live today on the App Store. It’s the first major update for the app and adds the following:

• You can now adjust audio levels of yourself and the beat after recording. Sweet.
• You can now rotate videos after recording so you’re not sideways when you don’t want to be.
• We’ve added 5 new video filters! Ice, Whitewash, Planet Rock, Purple Haze and Blackout.
• We’ve added controls for brightness and video filter intensity so there are infinite variations.
• The new video player is faster, smoother, lighter to control and does not overlay on top of videos.
• Producer’s names now show on videos made on their beats.
• The new beat player shows real waveforms because real waveforms rule.
• You can now loop beats by pressing the ∞ button.
• Spins now show on beats! Spins are all the plays of a beat INCLUDING plays of videos made on them.
• You can now filter your Saved Beats by title, producer name, #hashtag and bpm.
• You can now edit info on your beats & videos. Phew.
• When you make a video you can see it’s progress as it uploads, you no longer have to wait hopingly!
• When you tap the beat icon on any video it shows you the beat, now it also shows you all the other - videos made on that beat on the same page.
• When commenting on a beat/video it won’t stop playing what you are listening to.
• You can tap profile pictures to make them big.
• It is now easier to find your Facebook and Twitter friends, and connect with popular users on Brapp.
• And there’s a heap of other handsome UI, UX and stability updates. P.s. We’re just getting started!

If you haven’t checked it out yet, you can get Brapp for free on the App Store. You can also read about the initial build and release.

I’m happy to announce that an iPhone app I’ve been working on since September this year has gone live in the App Store; Chipp’d v2.0.

Chipp’d is an app that works with real world products (available at John Lewis) to let you share secrets or private messages with your friends. You simply scan the QR code on the sticker, create your secret (with video, audio, photos, and text), and send the sticker or card; your friend will then be able to see that secret when they scan it with the app or any other QR scanner.

It is also possible to share secrets for free using the app via auto-generated URLs that can be sent via email or SMS.

I was the sole iOS developer on the project and worked closely with the CTO of Chipp’d to integrate their existing API into the product on an incredibly agressive timescale¹. Everything was written in Swift 2.0 and used AutoLayout for flexible layouts on all iPhone screen sizes. I’m particularly proud of the QR scanner which I custom built when it transpired that the products that had been printed and shipped to distributors were too light for a conventional QR scanner to detect; I used GPUImage to manipulate the live video feed with multiple filters per second in order to quickly scan at different brightnesses and solve the issue before it caused major problems.

You can check out Chipp’d on the App Store (it’s free) and you can purchase the stickers and cards to use with it at John Lewis.

iOS provides a number of useful modal views within it’s system frameworks with everything from sending email to taking photos or video. However, there is still not a standard way to perform what is a fairly basic task; recording a voice memo.

I had a need for such a feature on a project recently and so I put together AudioRecorderViewController. It’s a basic modal view controller that allows you to record, playback, re-record, and save audio locally in mp4 format.

Usage is insanely simple and modelled on such classes as UIImagePickerController:

@IBAction func presentAudioRecorder(sender: AnyObject) {
    let controller = AudioRecorderViewController()
    controller.audioRecorderDelegate = self
    presentViewController(controller, animated: true, completion: nil)
}

func audioRecorderViewControllerDismissed(withFileURL fileURL: NSURL?) {
    // do something with fileURL
    dismissViewControllerAnimated(true, completion: nil)
}

Check out AudioRecorderViewController-Swift on GitHub.

Following on from my post yesterday about the broken implementation of the HKHealthStore method deleteObjectsOfType:predicate:withCompletion:, I’ve put together a gist which provides a fixed method that works with HKSampleType objects; deleteSamplesOfType:predicate:withCompletion:

import Foundation
import HealthKit

extension HKHealthStore {
    
    func deleteSamplesOfType(sampleType: HKSampleType, predicate: NSPredicate, withCompletion completion: (success: Bool, count: Int, error: NSError?) -> Void) {
        
        let query = HKSampleQuery(sampleType: sampleType, predicate: predicate, limit: 0, sortDescriptors: nil) { (query, results, error) -> Void in
            
            if let _ = error {
                completion(success: false, count: 0, error: error)
                return
            }
            
            if let objects = results {
                if objects.count == 0 {
                    completion(success: true, count: 0, error: nil)
                } else {
                    self.deleteObjects(objects, withCompletion: { (success, error) -> Void in
                        completion(success: error == nil, count: objects.count, error: error)
                    })
                }
            } else {
                completion(success: true, count: 0, error: nil)
            }

        }
        self.executeQuery(query)
    }
    
}

It simply uses the NSPredicate within a HKSampleQuery in order to find any objects that match the HKSampleType and then deletes them with the HKHealthStore method deleteObjects:withCompletion: - this correctly ensures that you are only deleting objects that match both the predicate and type.

By way of example, this simply extends HKHealthStore so you can do something like this:

let date = NSDate()

let predicate = HKQuery.predicateForSamplesWithStartDate(date.beginningOfDay(), endDate: NSDate().endOfDay(), options: .None)

let stepType = HKQuantityType.quantityTypeForIdentifier(HKQuantityTypeIdentifierStepCount)!
healthStore.deleteSamplesOfType(stepType, predicate: predicate, withCompletion: { (success, count, error) -> Void in
    NSLog("deleted \(count) step objects: \(error)")
    let stepQuantity = HKQuantity(unit: HKUnit.countUnit(), doubleValue: 9800)
    let stepSample = HKQuantitySample(type: stepType, quantity: stepQuantity, startDate: date, endDate: date)
    self.healthStore.saveObject(stepSample) { (success, error) -> Void in
    }
})


let flightsType = HKQuantityType.quantityTypeForIdentifier(HKQuantityTypeIdentifierFlightsClimbed)!
healthStore.deleteSamplesOfType(flightsType, predicate: predicate, withCompletion: { (success, count, error) -> Void in
    NSLog("deleted \(count) flight objects: \(error)")
    let flightsQuantity = HKQuantity(unit: HKUnit.countUnit(), doubleValue: 15)
    let flightsSample = HKQuantitySample(type: flightsType, quantity: flightsQuantity, startDate: date, endDate: date)
    self.healthStore.saveObject(flightsSample) { (success, error) -> Void in
    }
})

As a reminder, you can file a duplicate of (rdar://22977320) if you’d like to see the original bug fixed but in the meantime the above should allow you to carry on with your HealthKit app without worrying about deleting other data.

Working with any code, it is inevitable that you’ll stumble across bugs. When this happens with iOS development, Apple ask developers to submit a “radar” so that they can track and hopefully fix any issues that arise. The issue is that the Apple Bug Reporter is locked down and non-searchable so you have no idea if anyone else has submitted the same issue. Apple supposedly collate all of the bugs and mark any issues as duplicates and then use the number submitted to gauge how important an issue is and prioritise it’s fix. This has led to sites like Open Radar that let developers copy and paste their bug reports so other developers can search and then simply submit new bugs as a duplicate.

In any case, today I found an interesting bug in HealthKit. iOS 9 added a new method named deleteObjectsOfType:predicate:withCompletion which is supposed to let you delete any objects you have written to HealthKit nice and easily. For example, I might have an app which constantly checks your step count and flights climbed throughout the day and so it will want to delete any steps and flights from 00.00 to 23.59 before it adds the updated count. Unfortunately, the method doesn’t seem to respect the type parameter and so it will delete everything that matches your query regardless of what HKObjectType it is.

For example, consider the following code:

let date = NSDate()

let predicate = HKQuery.predicateForSamplesWithStartDate(date.beginningOfDay(), endDate: NSDate().endOfDay(), options: .None)

let stepType = HKQuantityType.quantityTypeForIdentifier(HKQuantityTypeIdentifierStepCount)!
healthStore.deleteObjectsOfType(stepType, predicate: predicate, withCompletion: { (success, count, error) -> Void in
    NSLog("deleted \(count) step objects: \(error)")
})
let stepQuantity = HKQuantity(unit: HKUnit.countUnit(), doubleValue: 9800)
let stepSample = HKQuantitySample(type: stepType, quantity: stepQuantity, startDate: date, endDate: date)
healthStore.saveObject(stepSample) { (success, error) -> Void in
}

let flightsType = HKQuantityType.quantityTypeForIdentifier(HKQuantityTypeIdentifierFlightsClimbed)!
healthStore.deleteObjectsOfType(flightsType, predicate: predicate, withCompletion: { (success, count, error) -> Void in
    NSLog("deleted \(count) flight objects: \(error)")
})
let flightsQuantity = HKQuantity(unit: HKUnit.countUnit(), doubleValue: 15)
let flightsSample = HKQuantitySample(type: flightsType, quantity: flightsQuantity, startDate: date, endDate: date)
healthStore.saveObject(flightsSample) { (success, error) -> Void in
}

The expected result is that you’ll end up with an entry for Step Count (9800 steps) and an entry for Flights Climbed (15). However, you’ll only get the Flights Climbed entry as the line healthStore.deleteObjectsOfType(flightsType, predicate: predicate, withCompletion:... will delete all entries that match the predicate, regardless of the HKObjectType. In addition, if you look at the headers for this method within the HealthKit framework, they don’t add up with what is expected:

This suggests that this method was refactored at some point prior to release and has this rather serious bug. I’ve filed this as a radar (rdar://22977320) but in the mean time you’ll need to do a manual search for objects with HKSampleQuery and delete them with a separate call if you want to avoid this.

Update: I’ve put together a fix for this issue with a new HKHealthStore method, deleteSamplesOfType:predicate:withCompletion:

Update: Whilst iOS 9.1 hasn’t fixed this issue, my bug report has today (23rd Oct 2015) been marked as a duplicate of issue 23097982 so looks like they may be getting around to fixing it. iOS 9.2 perhaps?

Over three and a half years ago I announced the launch of WallaBee, “the ultimate collectibles game for iOS”. Whilst it has been a labour of love for me for over the past four years, it has also been incredibly stressful and draining at times. Today I was very happy to announce that I’d sold WallaBee to Munzee. I won’t go into the details of how that will work for players (you can find out all about it on the WallaBee Blog) but I did want to talk a bit about how a relatively simple game became a huge business.

I created WallaBee as it was a game I wanted to play¹. I’d built several iOS apps in the past (including several that were featured by Apple) and my day job previously had been as a PHP developer so it was fairly trivial for me to throw the basic building blocks together. Over a few months of testing and iteration the game went live; it was free but monetised by using In-App Purchases for in game currency as well as a pro subscription for $5 a month which gave additional benefits to players. The feedback was great and I iterated quickly to a v1.1 product which launched at Nonick 012 where WallaBee was voted the ‘Best European Gaming Startup of 2012’. Over the coming years I’d add extra bits of complexity and hidden secrets² and generally expand things out.

However, my big plan was to launch a version 2 product. I’d always considered v1.* to be a proof of concept and I had a ton of ideas for things I wanted to improve on. I pitched the idea to my co-founders in November 2012 and we showed off some screens and concepts to our players on April 1st 2013³. It was around that time that the number of players was expanding rapidly and so I spent most of my time dealing with server issues and scalability. Over time, the fast iteration I’d started with slowed to a halt as I dealt with server scaling and that lead to issues when the innovation of iOS overtook us; for example, we didn’t implement AutoLayout and so weren’t equipped to deal with things like the iPhone 6 resolution change. This eventually led to nearly every issue needing the same solution; a complete rewrite of both the app and API. Unfortunately this was difficult to manage as all of my time as the sole developer was being taken up either trying to hold the server issues together enough for another release or dealing with player issues that crop up when you have thousands of people able to communicate with each other.

After a while, it just wasn’t fun for me anymore so I made the decision that I would shut it down. A few minutes after that announcement, Rob Vardeman from Munzee got in touch and asked if we could speak. I’d met him before when he was in London for a Munzee event and after a discussion, some emails, and a lot of thinking, I decided to let Munzee acquire the company so that they could continue to grow it in the way I had wanted to. I am confident that they will do an excellent job at maintaining the quirky side of WallaBee⁴ whilst also being able to add some amazing new features; I’m so sure of it that I have remained as a shareholder of the company.

Based on my experiences, I have a few pieces of wisdom to share:

• It’s fine to get something launched but don’t forget to put in the groundwork for scalability. If you don’t know what you’re doing, find someone who does.

• Monetise your game from the start. We never had any issues but I see startups every day that get a big of investment and think that if they build it they can monetise it later; don’t do that. We launched with 30-day and 90-day subscriptions and most players bought a 90-day one straight off. It is much easier to alter your existing payment structure (as we did when we went from subscriptions to single payments for goods) than to try and add one when everything was free previously.

• Never announce something before it is built. This is a lesson that few people have mastered as it is insanely difficult trying to keep something awesome from the people who are going to love it most; it is also easy to announce something as then you feel like it forces you to launch it by that date but it doesn’t work. Take a leaf out of Apple’s book and only announce something when it is done and going to ship within the next 2 weeks (and when it comes to software, announcing something that is available “Today” should be the rule).

• Do not underestimate how difficult it is to manage a community of players or how crucial it is that you do. I frequently had to deal with issues such as bullying, stalking, and just generally petty squabbles. We had births, deaths, celebrations, and everything in between⁵. There was also the inevitable bugs and server issues that required an apology. However, because of the way we handled those issues publicly and fairly, it cut us a lot of slack when things went wrong. A good community is the key thing for any social app and must be nurtured.

So what now? Without WallaBee to manage over the past few weeks, I’ve found myself at a bit of a loose end with so much more free time! I’ve written three apps so far including a content blocker, an app based on HealthKit, and an app to let me fly my Bebop Drone with an iOS MFI controller⁶; all of them will be available on the App Store at some point. I’m also collaborating on an Apple TV game with another developer which will hopefully be live in November. Beyond that I haven’t decided what the future has in store but I’m enjoying working on small, offline apps for the time being.

The final thing to mention is a slight change to the way I do my freelance work. Due to WallaBee becoming my main business for a while, I changed my company name from Ben Dodson Apps Ltd to WallaBee Ltd. As Munzee are based in the US, they have no need for a UK Limited company and so they have simply purchased the rights and assets of the WallaBee app and brand. I’ve therefore changed the company name to Dodo Apps Ltd⁷ and that is what I’ll be using for all of my freelance business from now on.

I’m happy to announce that an iPhone app I’ve been working on since March this year has gone live in the App Store; Brapp.

Brapp is a free and easy way to create and discover exciting musical collaborations all over the world. Producers can share their beats allowing anyone to make mini music videos right on their phone. When you choose a beat and hit record, the camera starts rolling and the custom studio technology balances your audio (be it singing, rapping, or playing an instrument) onto the beat ready for you to add video filters and share with the world.

I was the sole iOS developer on the project and worked closely with the app creator¹ and his API developer to bring it all to life. I was able to write the app in Swift and use AutoLayout to make sure everything scales beautifully on all 4 sizes of iPhone from the 3.5” iPhone 4S upto the 5.5” iPhone 6S Plus. In addition, I made use of GPUImage for the custom video filters and a whole load of low-level audio APIs to get the audio balance just right as well as real time waveforms and switching between external microphones. The design went through a number of iterations, each better than the last, and I was able to use my extensive UX knowledge to help shape the end result.

This was a great project to work on with a load of interesting technologies plus I got to lay down some sick beats². You can check out Brapp on the App Store (it’s free) or learn more on the official website.

Earlier this month I was interviewed by AppIndex about my work as a freelance app developer. You can read the full article on their website but I’ve also put their questions and my answers below:

How long have you been involved in developing apps for?

I started developing apps professionally in August 2009, shortly after iOS 3.0 was released, but I tinkered around with the iOS SDK when it was first announced the year before.

What types of apps do you work on?

I have quite a varied portfolio but for a long time the apps I worked on were location based (i.e. travel guides, restaurant finders, interesting places nearby, etc). Nowadays I tend to work on a lot of social network type apps but that’s probably more indicative of what clients are looking for at the moment.

What platforms, tools and languages do you work with?

On the mobile side I only deal with iOS and all my new projects are written in Xcode using Swift 2.0 (with only a couple of legacy apps written in Objective-C). However, I also do backend development for APIs which I write exclusively in PHP. All my work is done on OS X.

What apps have you worked on that you are most proud of?

I think the app I was most proud of with was the “Horse Tracker” for the Grand National horse race. I worked with a company that attached trackers to the horses so we could see in realtime where they were on the field and display that to the user. It was really nice to use, especially on the iPad which had a full map view of the racecourse (which was never released in the end) and used lots of really cool technology such as audio indexing to perfectly match the time of the race on your TV screen to the data coming from the trackers, even if you were watching on a delayed stream or via a catch-up service hours later. Of course, nothing makes me more proud than the apps I write and publish myself so they will always beat client projects but that one was special.

What are the big trends you see in app development right now?

I’m starting to see a lot more thoughtful design coming through at the moment. Previously everybody was still trying to work out how to get data onto a small screen and most designers I worked with via clients had experience in print or web which didn’t always translate across; nowadays the level of design work seems to be much improved and everybody wants a slicker experience with more animation. The transition to the iOS 7 style of design (flat and minimal) seems to have helped as well.

What is the best thing about working in apps and mobile?

I really enjoy the varied work. It can be difficult sometimes with deadlines and quite a big responsibility if your app is in millions of peoples hands but there is a huge amount of variety. I never really know what I’m going to be working on next which I find exciting.

What is the one thing you’d like to change about app development?

I have two big gripes which are more to do with people than app development itself; being told I should port my apps to Android (“you’d make so much more money”) and being pitched an idea which isn’t so much an app as a service that requires servers, infrastructure, and has large operating costs (“I want an app that can let people upload photos and videos – I’ll give you 25% of the profit if you build it for free”).

What mobile devices do you use?

I use an iPhone 6 Plus and an iPad Air at the moment. I’m particularly interested in the rumoured 12” iPad Pro although I have something similar in the form of the 12” Macbook which I take to client meetings.

What are your favourite apps / games?

Ironically I don’t actually use that many apps beyond the stock things like mail. I’d say my most used 3rd party apps are Dark Sky for their weather alerts and Philips Hue for turning the lights on and off in my house. With games, I tend to play something solidly for a week and then get bored of it; I’m currently playing Alto’s Adventure, Rollercoaster Tycoon 3, and Kindo.

What do you think of the Apple Watch?

I love my Apple Watch. It’s definitely a luxury rather than a necessity but I love getting notifications on my wrist, the fitness features, and Apple Pay. I’m looking forward to watchOS 2 especially as then I’ll be able to log a swim and have it count towards my exercise totals. It’ll be interesting to see how much better the 3rd party app experience is when the update arrives – I’ve dabbled with developing a few apps but the lag talking to the iPhone always limited the amount I could do.

I was recently asked my opinion on Windows Bridge and the “App Gap” between iOS, Android, and Windows Phone by FierceDeveloper. You can read the article on their website but I’ve also put the full questions that were put to me along with my answers below:

Would something like Windows Bridge make you any more likely to bring your apps to Windows Phone? Why or why not?

It wouldn’t convince me as there are two big problems: firstly, it only works with Objective-C whilst I have already made the switch over to Swift so I wouldn’t be able to make use of this (and the benefits of Swift massively outnumber the benefits of being on Windows Phone for me); secondly, whilst it may be easy to port an Objective-C app over, I would still need to build a custom Windows UI which would take a long time. In addition, this custom UI would need to be supported as and when new devices and screen sizes come out and I’d need to maintain feature parity between iOS and Windows making every release take significantly longer to bring to market.

What do you think are the biggest reasons for the “app gap” between Apple’s App Store and what’s available in Microsoft’s app store?

There are lots of reasons for this but I think the two bigs ones are developer usage and money. When the iPhone came out, it was revolutionary and most developers who work in mobile began due to using an iPhone and wanting to write apps on it (that is certainly true in my case). That meant the iPhone got a lot of exciting apps developed on it first as the people that made those apps used iPhones. Over time, this has compounded into giving an Apple a massive advantage and whilst Android has caught up in many regards they haven’t got anywhere close when it comes to money. Simply put, iOS users spend more than Android users. I don’t know if that is due to the security and convenience of iTunes and TouchID or whether it is a more social thing (you’ve spent $700 on a phone so what is $100 a year on apps) but in all of the research I’ve done it has been the case that iOS users are willing to pay where Android users are not. It is for that reason I don’t port any of my apps to Android. Back to Microsoft though, the reason there is an app gap is that all of the developers started on iOS (and now Android) leading to a shortage of apps - this led to less customers and thus less money so they are now in the situation where it is very hard to attract developers as there are neither usage numbers nor financial figures to entice us.

Is there more Microsoft could/should do to make developers more interested in creating apps and games for their platform?

To be honest, I don’t think there is much Microsoft can do at this point. Consumers are simply not buying Windows Phones and that is the real problem. Whilst their initiatives such as building one app that can run on Windows 10, Xbox One, and Windows Phone are interesting, there simply isn’t enough consumer interest nor money to get iOS and Android developers to create apps on those platforms. Ultimately, Microsoft would probably be better chasing the gaming market over the app market - produce a Windows Phone that is more akin to a Playstation Vita and is able to run games that can also run on Xbox One and Windows 10. These wouldn’t be massively powerful games but would fit in with the “write once, run everywhere” better than apps do (typically games are used to having to scale at different resolutions and have custom UIs whereas regular apps tend to be designed to the UI of the platform making “write once, run everywhere” unfeasible).