Ride is Live!

On September 3rd I launched Ride, an app which is designed for people who ride electric skateboards.

It is undoubtedly one of the most fun things I’ve ever created, and I think that is largely why the app has been well received by the community. Riding an electric skateboard is ridiculously fun, and it deserves a fun app to go with it.

Ride isn’t really the first of its kind. There’s two main parts to Ride, the part which tracks your ride, and the part which connects to a Boosted Board. Both of these have been done individually, but neither has been done fantastically or indeed in the same app.

Apps like Strava and RunKeeper can all essentially do the same thing, you can often just choose “bike” instead of running and they’ll adapt their tracking. But that’s still not designed for electric skateboards, and often shows you things like your average pace. I don’t really care what my pace is on an electric skateboard tbh.

That’s where Ride comes in. It is built with electric skateboards as the primary use case, so focuses on speed, battery level and distance rather than pace etc.

Small beginnings

The whole project started as something much simpler; just a speedometer on your Apple Watch so you can see how fast you’re going. Two months later, it blossomed into a gorgeous ride tracking app that has the added benefits of being able to warn you when your board is running low on juice, and even change ride mode and see how much range you have left.

Now that Ride is on the store, I can take my finger off the throttle a bit and start to plan the next major release. It’s a nice position to be in, working to your own schedule, with your own ideas and with support from an incredible community.

Boosted and I

Let’s address the elephant in the room. Ride does not use official APIs to connect to the board. I would never knowingly do anything to damage people’s boards, but I do have a small disclaimer when you first run the app stating how Boosted aren’t responsible for anything that happens if you use Ride.

Boosted haven’t reached out in either a positive or negative stance towards Ride. If they ever did, I only hope it would be positive and that they understand that I want to help them and the community. This is the sort of app a Boosted Board deserves, and I would be very happy to work with them to make some amazing shit, if they were interested!

Shut up and tell me how well Ride is doing

Okay fine. So today is 13 days since Ride launched (12 really as I launched quite late at night) and I’m happy to say that Ride has had almost 500 downloads. The first full day saw the biggest spike at 239 downloads and then it fluctuates as people talk about the app, but I guess averaging about 20 downloads a day after that.

Ride has an in-app “tip jar”, but in my haste to release for fear of Apple rejecting the app it has ended up quite hidden, so although there have been a few donations from very kind people, there haven’t been as many as I had hoped. There are 4 different options people can choose from to donate, ranging from £0.99 to £9.99. According to iTunes Connect, there have been $63 of sales, however iTunes Connect is currently sending me in a redirect loop when I try to break this down into which tier people have paid, so I can’t give you more information than that just yet. I’m hoping when I surface the tip jar a bit better, this number will be a bit healthier. I’m incredibly grateful for everyone who has donated, though!

I guess you’re wondering how that compares to MacID? Well, they’re actually similar in number of downloads per day, however MacID is a paid app, so I would say that MacID is doing better, even with all the macOS Core Bluetooth bugs.

Marketing

I have spent very little on any sort of marketing for Ride or MacID. I have ran a few ad campaigns on Twitter for MacID right at the start, but found I didn’t need to. As egotistical as it sounds, I didn’t really need to. I made stuff people want to use, and made it better than other people who made similar stuff. That’s really the key to a successful app.

Word of mouth is worth significantly more than any ad conversion, although the people who make Clash of Clans might disagree with me there. You can make the comparison yourself between a game like Clash of Clans versus one like Mini Metro or Monument Valley. I’ve never seen an ad for the latter, and yet I would say it’s more popular than the former.

So my advice to anyone who is launching an app: make a big deal about it, tell everyone, get as many people using and talking about it as you can by giving it away if it’s a paid app, and create a community around your app.

Give your app a personality and brand, make a Twitter account for it and use it, engage with your users, give them a voice and make them feel cared about.

Create stickers and get your friends to give them out. Email every single blog and give them promo codes. Make a YouTube video. Put it on Product Hunt.

Shout about your app, you worked hella hard to make it, you deserve to make a big deal about it!

Ride for watchOS and iOS – Now in Beta

Not too long ago I got my grubby hands on a Dual+ Boosted Board. I absolutely love it, so much so that even after having a medium-nasty accident I was back out on it two days later.

That said, there’s on glaring issue with it. The official Boosted Board companion app is lacking a bit in features. So I started thinking about what I would really want from a companion app (and asked some people on Reddit too).

The first thing I thought of that I thought would be fairly achievable quickly was a speedometer. To be able to see my current speed on my Apple Watch would be great, and after a quick investigation I realised that I could use the Workout APIs to keep the app on screen for as long as I want.

To get the speed from the watch, I can just use location tracking and do some averaging and filtering of the locations from the Core Location APIs. While working on it I thought: “hey, I’ve got these locations, why not keep hold of them and display them on a map?”. So then I started working on transferring the ride information to display on a map in the iOS app. This gave the iOS app some purpose, as well, which is great.

I started off with a shitty design on the phone, really just to get to grips with the MapKit framework on iOS. I still haven’t got everything worked out but I’ve got it pretty good now. If there’s a massive gap between locations, I show a dotted line. That was more challenging to implement than I imagined!

So at this point I’ve got a pretty decent app that anyone with an Apple Watch can use to track their rides. But I really wanted more. I wanted to be able to connect to the board with my app and display the battery level on the watch.

Luckily (or not so luckily), I have some experience with Core Bluetooth on iOS. I was quickly able to get a sample project set up to look at the characteristics that the board has, and then just figured out which one was the one for determining if the board was charging etc. After a little while I got the app reading the battery level, charge status and board mode from the board which is now displayed on iOS and watchOS, as well as in an iOS widget and a watchOS complication.

Better still, Ride doesn’t even need to be re-launched when the system kills it for memory, because it implements full background Bluetooth and restoration. So long as the app is in the App Switcher (a limitation put in place by Apple), the board can reconnect. This meant that I could then start adding things like notifications for when the board connects and disconnects, as well as custom triggers for “sufficient charge” and critical battery. This is super useful because while you’re in a coffee shop recharging, you might only want to get back up to say 80% charge so that you can carry on riding.

Since then I’ve been tweaking the location filtering and adding nice little features, like automatically ending a ride if the board disconnects. I found myself forgetting to end a ride when I got to work and wasted my watch battery, as well as skewing some of the ride data.

It’s been a fun project, and even if it never makes it on to the App Store for whatever reason I’ve gained knowledge and I’ve made an app I will use a lot. You can keep up to date with the project at @RideHelp on Twitter. (Seriously how was that Twitter handle available?)

Also, if you’re reading this, Boosted, and you want to work together let me know 😉

IMG_3468IMG_3510IMG_3473IMG_3491IMG_3509IMG_3508IMG_3478

IMG_3479
IMG_3480
IMG_3476

AirPods – the most expensive backup headphones I’ve ever bought…

… But utterly worth it.

I have a pair of wireless Bose QC35s which are awesome, they are the headphones I primarily use because the noise cancelling is insane, and for my non-audiophile ears they sound amazing.

But they are big, and not really appropriate for use if I don’t have a bag to put them in. That’s why, until now, I’ve always kept a pair of wired in-ear headphones that I can take out with me when I don’t want to carry around a bag and carry case.

As an example, if I’m going on a night out I want to carry as little as possible on me, but I really need some way of listening to music on the train home (because nobody needs to deal with the last train home without music). In these sorts of situations, audio quality is definitely not at the top of my list, but portability and discreteness are; two things AirPods excel at.

That’s not to say the audio quality on AirPods is bad, although they leak sound just like regular EarPods, they sound great to me and I’ve had absolutely no issue with connection at all.

On top of being insanely portable, sounding great and being easy to set up, when used alongside an Apple Watch it’s a match made in heaven. The lack of track and volume controls totally disappears when you have access to both the Music app and the Now Playing “Glance” (you can add this to the Dock in watchOS 3). Better still, the Now Playing Glance lets you control Spotify, or indeed anything else that shows up in the audio controls section of Control Center on iOS.

AirPods are, currently, an extravagance. As someone who loves gadgets I can find ways to justify the cost to myself, but not everyone can. But they are new, and Apple knows they can make some extra bucks from early adopters (as they have done many times in the past, with the first MacBook Air, Retina MacBook Pro and 12″ MacBook as examples). Wireless is the future, and I long for the day wires are completely abolished from everything, not just computing. The cost of them will come down as competition becomes more fierce and the technology matures, but until then I can firmly say, these are the most expensive backup headphones I’ve ever bought, but they are truly, utterly worth it.

It’s ShowTime

Over the weekend I finally got time to work on something I’ve been meaning to get round to for quite some time now.

Introducing ShowTime, an insanely simple way to show your taps and gestures while demoing your iOS app.

Why another one?

I know, if you Google “show touches iOS app” you’ll get a few results. Some old with no recent support and some newer with some support. The reason I still decided to make ShowTime is because none of the solutions I’ve tried work with both single- and multi-window iOS apps.

The last two projects I’ve inherited at work both display new content in multiple windows. This would mean replacing each window with one of the “show touches” window solutions, which isn’t a trivial amount of work.

No, what I want is something that has little to no set up whatsoever, works with multiple windows automatically and can show the level of pressure shown on devices that support 3D Touch. Oh and it needs to be pure Swift code.

So I made one myself.

Why show touches on screen?

If you’re watching someone use an app on their phone, you can see what their fingers are doing so the gestures make sense. In contrast, if you’re watching someone use an app on a screen or video without being able to see their hands, you suddenly loose a lot of context, especially around multiple-touch gestures.

We work hard on making apps, and demoing them is part of our job as professional developers. As an iOS developer we don’t have a native way of showing touches on screen like Android do, so we have to get creative.

How does it work?

ShowTime uses method swizzling, a technique used to replace a default implementation of a class’ function with your own. Swift itself doesn’t support method swizzling, but because any Swift type that inherits from NSObject uses the Obj-C runtime, it is possible to swizzle their methods.

Thankfully, UIWindow inherits from NSObject so it’s possible to swizzle its methods, and the one we’re specifically interested in is sendEvent(_:) which takes a UIEvent as its argument.

ShowTime replaces the default sendEvent(_:) method with its own, and intercepts the event to extract touches. It then displays those touches on the window receiving sendEvent(_:) and then lets the window carry out its default implementation of sendEvent(_:).

This means that all instances of UIWindow (and its subclasses) will automatically get this behaviour, so it doesn’t matter if new windows are created, touches will always be shown.

How to set up ShowTime

There’s actually nothing to do to set up ShowTime other than to include ShowTime.swift in your project.

That said, you can customise the behaviour if you want. You can change the fill and outline of each visual touch, whether force is shown visually, whether to include the number of taps inside each visual touch (great for demoing maps), and more. By default ShowTime shows a blue visual touch, because it contrasts well with most content.

My recommendation for keeping ShowTime around without putting it into production code is to create a demo branch in your repo which has ShowTime installed. You can then merge develop into this branch whenever you’re demoing something, and because there’s such little setup with ShowTime you’ll rarely get merge conflicts.

 

Hopefully you’ll try ShowTime during your next client demo, internal demo or while creating a product video. If you do, please let me know how you get on!

Extending NSCoding

NSCoding is used often through many iOS, macOS, watchOS and tvOS apps, and usually results in instances that conform being archived into data for transportation or persisting.

So lets extend NSCoding so we can easily archive that object. It’s very simple but very useful:

Now any type that conforms to Archivable will have to conform to NSCoding and will also be easily archived by calling instance.archivedData. Because we’ve extended the protocol itself, all types that declare they conform get this behaviour for free. Neat ?

Why I Think watchOS 1 Did Long-term Damage to Apple Watch’s Reputation

Let me start by saying I do not hate Apple Watch. I love Apple Watch, I have two different models and have owned more than that, and the device hasn’t been out even a year yet. It’s an awesome little device and has so much potential.

But, I personally feel Apple made a significant error releasing Apple Watch with watchOS 1 which will do some very long-term damage to Apple Watch’s reputation for iterations to come. Here’s why:

1. People think Apple Watch is slow

watchOS 1 apps had a very different architecture to watchOS 2 apps. watchOS 1 apps were, in essence, extensions of an iOS app which ran on the iPhone itself, and essentially just used the watch as a second screen.

To load anything, or respond to taps, Apple Watch had to ask the iPhone for the information or to carry out the task and then refresh the UI and send any data back. Over Bluetooth. This took a lot of time, especially when first loading the app’s UI, and everything felt sluggish.

Mere months later, Apple release watchOS 2 to developers with native apps. Native apps no longer get loaded from the iPhone each time and all components of the app are stored on the watch. Apple Watch apps can now do most computation on-device, and don’t need to load the UI from the iPhone. Everything is super speedy, well-written apps load in 3-5 seconds, and UI is very responsive, but it requires (parts of) the app to be re-written. This brings me to point 2:

2. Many developers don’t want to spend time porting a watchOS 1 app to watchOS 2

Whether you’re a big company or an independent developer, finding out there’s a whole new architecture (and new APIs to port to as a result1) to develop for just a few months after the device has released isn’t great news. It takes time to develop an app, especially on a brand new platform, even on a device as small as Apple Watch.

I’ve lost the article now (I think it was on WatchAware.com) but there was a report about how few apps have been updated to be native, and for me this is still true for many watchOS apps that I use like Philips Hue. It’s frustrating to know that their app could load significantly faster if they ported to watchOS 2, and if a company that far advanced in terms of iOS and HomeKit support haven’t ported to watchOS 2, is it so surprising that more independent developers haven’t either?

We can’t expect all users of Apple Watch to understand that even though they’ve updated to watchOS 2, an app isn’t automatically native. To them, it’s just another slow to load app. This hurts the developers’ reputation and also Apple Watch’s reputation.

So many developers wanted to make the gold rush when Apple Watch was released, there were so many apps being released at the time that it was staggering. Imagine if every single one of those apps were native and had access to the same APIs that apps could a mere few months later.

In my opinion, Apple should have waited. It would have launched with reviews of how responsive the UI is in apps, rather than the opposite.

***

1 Updating my app, MacID for Apple Watch, to support watchOS 2 was surprisingly more difficult than I expected. If I had multiple apps to port to watchOS 2 I honestly couldn’t say if I would have spent the time porting all of them, but that just further highlights my point.

Hello, I’m gay.

Yesterday was National Coming Out Day, a day I love because we all get to share our stories, remember our experiences and, hopefully, show other gay people that it’s okay and everything will be alright. 

While pottering about thinking about my own experience, it dawned on me; although I “officially” came out when I was 13 (if there is such a thing), I’ve never stopped coming out since. 

Coming out is made to sound like a one-time, rip-the-plaster-off experience. Often painful, but better to do quickly, right? In reality, that is hardly the case. Sure, I may now find it easier to tell new people I’m gay, but each time I do, I’m still coming out to them all over again. 
If I start a new job or get a new barber, I will inevitably have to let them know at some point, or be subjected to talk about “fit birds” or asked if I saw “that one”. Telling a new barber is especially scary as not only are they in control of how I look for the next few weeks, they also have a razor to hand. Yes, it is still a fear even in 2015. 

When talking to someone new and they ask me whether I have a girlfriend and I say no, it’s assumed I’m single. The onus is on me to clarify and risk being shunned out of a potential new circle of friends.

I’m not trying to say that coming out isn’t easier in 2015; quite the contrary. We have such easy access to a fantastic community and array of support I would say it’s easier than ever (if you live in certain countries), but these things are all still very real and can get incredibly tedious. I’m 28 now, I can’t even imagine how many times I’ve been told I don’t “look gay”. Well, comrade, I can assure you I am, it’s been the one constant in my life and something that has made me a very independent person.

To clarify, I don’t really give a fuck if some closed-minded person dislikes me because I happen to find men more attractive than women, I know there are more people in the world who I would prefer dedicating my friendship to. But that doesn’t change the possibility of violence, or the possibility that it could negatively affect my career.

We take a lot of shit as gay people, and far too many people are still uncomfortable talking naturally about themselves in conversation. This needs to change. If you’re ever on the other side of the conversation and realising that someone is gay, brush it off and carry on. Let them know you’re okay with gay people by continuing to be the same person, so they can too. Don’t say ridiculous things like “I don’t have a problem with gay people.”, or “I have a gay friend, do you know them?”. It’s insulting, even if you didn’t realise it before now. 

You don’t have to come out as someone who accepts me, just accept me. Besides, I’m awesome and it’s your loss if you don’t.

Where Does Apple Watch Fit In?

After getting my grubby fingers all over an Apple Watch since the 24th April I’ve had a fair bit of time to use it, both for personal use and for development of MacID.

During that time I’ve been asked time and time again:

What does it do? Is it worth it?

The answers I give to that are “everything” and “yes”, but I think what people really want to know when they ask is, “what is it good for?”.

To answer that, lets have a look at where Apple’s other products fit in to our lives. (This, of course, is circumstantial and just a generalisation).

The Mac, nowadays, is ultimately for creating content. OS X is still the parent of all other Apple products, and it’s still usually the easiest way of doing multiple things at once when you’re working on a project. The iPad tries to be a content creator, but in reality it still fails in many aspects. Sure, it’s good for a quick edit of a Pages document, but if you want to create a website, code an app, do some detailed design work, or write an essay, you still need to use a proper operating system with much more accurate input.

iOS on the other hand, is amazing for consuming content and communication. Twitter, Instagram, messaging, iBooks, listening to Music; these are all far superior on iOS. Again, you can do all of this on your Mac now, but engagement is much higher on mobile devices for this sort of content.

So, what about Apple Watch? I personally think Apple Watch will excel with utility apps. Apps which allow you to unlock your Mac or hotel room, board a plane, check your car’s current charge, book a cab, control your TV, or check off a shopping list. These all take seconds of your time for each interaction, and are perfect for the small form factor.

Once developers stop seeing Apple Watch as something they have to get their current apps onto, and start understanding where it will excel, Apple Watch (and other wearables) will start to become integral in our lives just like laptops and smartphones.

Winning the War Bluetooth on OS X

If you’re experiencing issues with MacID not reconnecting properly, this post outlines some of the things that you can do to try and overcome the problems.

Bluetooth in OS X is becoming the new wifi in OS X. That is to say, it’s now exceptionally buggy for some people.

While we wait for Apple to send out updates there are a few things we can do. There are a few files associated with Bluetooth on your Mac, don’t worry about breaking your Mac by deleting anything I recommend in this post because OS X will re-generate the files when it needs to.

In this post on Stack Overflow you can see there are two main files associated with the Bluetooth cache on your Mac. They’re located in two different places though so if this is your first time digging around in system folders you might get a little lost.

Here’s what to do:

There are two different Bluetooth files you need to find to clear the cache. Although I have already written a post on the first file, it uses Terminal, so here’s how to delete the file manually. Note that the file in the ByHost folder will have a few random characters in, but it will always start with com.apple.Bluetooth 

First find these two folders:

  • /Library/Preferences can be found by opening Finder, clicking Go, then clicking on your hard drive, then choose Library, then choose Preferences.

    /Library/Preferences/com.apple.Bluetooth.plist - file to delete
    /Library/Preferences/com.apple.Bluetooth.plist – file to delete
  • ~/Library/Preferences/ByHost can be found by opening Finder, clicking Go while holding ALT on your keyboard, then clicking Library, then Preferences, then ByHost.

    ~/Library/Preferences/ByHost/com.apple.Bluetooth.randomcharacters.plist - file to delete
    ~/Library/Preferences/ByHost/com.apple.Bluetooth.randomcharacters.plist – file to delete
  1. Unpair your device from the MacID menu.
  2. Turn off Bluetooth.
  3. Delete com.apple.Bluetooth.plist from /Library/Preferences
  4. Delete files named com.apple.Bluetooth.somerandomcharacters.plist from ~/Library/Preferences/ByHost (note that this is the user preference folder, not the system one)
  5. Restart BOTH your Mac and iPhone.
  6. Turn Bluetooth back on.
  7. Open both MacID for iOS and MacID for OS X to re-pair them.

What else can you do?

When I first started development on MacID I couldn’t get Bluetooth to turn off, the option was greyed out. Turns out there was a file lurking about that completely screwed everything up. After deleting a file in /Library/Preferences/SystemConfiguration called com.apple.Bluetooth everything worked properly for me.

If that file exists on your machine, deleting it may help you here too.

You can also try my other post on clearing the cache using Terminal.

But why is this happening?

When MacID disconnects, either OS X or iOS (neither I nor Apple are sure which yet) is making the MacID app look like a new device by changing the identifier associated with it.

When you pair MacID for iOS with MacID for OS X, MacID for OS X stores the identifier and uses it to reconnect (so that it knows your iPhone is the right one). If that identifier changes, as above, then MacID will never be able to reconnect without re-pairing.

To make matters even more complicated, connection attempts never time-out with Bluetooth LE so it will forever sit at “waiting to attempt” assuming that your iPhone is just out of range.

During development this happened a few times, but always sorted itself out. Usually after clearing the cache as described above, and restarting both Mac and iPhone a couple of times.

I have now filed two separate bug reports with Apple and are sending them reports when I can.

Clear Bluetooth Cache for Core Bluetooth on Mac OS X

OS X really aggressively caches Bluetooth connections, which makes working with Core Bluetooth a royal pain.

After much searching about, I’ve found a way that seems to clear the cache properly. Turn off Bluetooth, open up terminal and copy and paste these three commands in order. You’ll have to enter your password after the first one, and you won’t see your password entered as you type (but it is being entered, so hit return once you’ve entered it and then copy the next two commands):

Once you’ve done that, you’ll need to restart. Voila, once you boot back up it should show you name changes on your iOS peripherals etc.