So, We're Making a Podcast

So, we're making a podcast. It's called So cast, and it's an excuse for Kai, Malin and I to drink coffee and have a chat each week, since they moved halfway around the world.

We're all software developers so, naturally, most of our conversations end up being about something tech related. Hopefully we're able to provide unique and interesting insights through these weekly discussions, and hopefully you find the show interesting enough to subscribe to.

We've hit the ground running and have five great episodes for you to listen to.

The show kicked off when we were fortunate enough to have access to the Apple Podcast Studio at WWDC, where we spoke about our WWDC experience. The second episode covers our early thoughts on the iOS 12 and watchOS 5 beta. In the third we discuss home automation and smart assistants, with a bit about Siri Shortcuts at the end. In episode 4 we talk about new MacBook Pros, and the 10th anniversary of the App Store. And finally in the fifth, we talk about everything from buying a new Mac, to what cloud storage to use, a whole bunch about emoji, and Apple Watch move streaks.

We've got some great future topics planned, and plan on recording and releasing weekly. If the show sounds like something you'd be interested in, it's likely available in your podcast player of choice, including iTunes, Pocket Casts, and Overcast.

If you've got any feedback, or would just like to find out when we release new episodes, you can follow the show account on Twitter: @So_cast.

"Hey Siri, what on earth is a Shortcut?"

At WWDC this year, Apple introduced Siri Shortcuts, which are a new way for developers to integrate their app with Siri on iOS, and watchOS.

I'm in the process of writing a talk on Siri Shortcuts to present at the fantastic /dev/world/2018 conference in late August, and one of the things I'm struggling the most with is how to explain Shortcuts, and how to differentiate between the types of Shortcuts. From a developer's point of view, there are many things referred to as Shortcuts. This post is an attempt to clear the thoughts in my mind, and hopefully help clarify things for you too.

Shortcuts, the app

In my experience from talking to people, "Shortcuts" tends to refer to Shortcuts the app, which is essentially Apple's replacement for the Workflow app after acquiring the team behind it in early 2017. The Shortcuts app allows you to chain actions together, and run them as a group. For example, you might have a "Running late" Shortcut that sends a message to your boss saying you'll be late, starts a "hurry" playlist, and opens Maps with directions to work. A lot of the integrations in Shortcuts at the moment are first-party actions - including controls such as toggling Wi-Fi or Do Not Disturb settings or interacting with built-in Apple apps. Shortcuts will shine once it's possible to run shortcuts (yes, that means something different here) as a part of the shortcuts you can create in the Shortcuts app. Have I confused you enough yet?

Siri Shortcuts

There is a new Shortcuts API available to developers. In this context, a shortcut is an action or task that is often repeated with a somewhat predictable pattern. Developers are responsible for "donating" a shortcut to the system when a user performs a relevant action, and the system takes care of when and where to suggest the shortcut. Suggestions are displayed both on the lock screen as notifications, and under the Siri app suggestions when you swipe down on the home screen. Examples of shortcuts include suggesting a lunch order when it's nearing midday, or opening a document that you often open when you first get to work. These suggestions also appear on the Apple Watch Siri watch face.

Shortcuts can be created in one of two ways. Firstly, using an NSUserActivity. You should create these for specific activities or screens within your app where a notable action is performed, and where there is a possibility of someone needing to return to the app in that state for whatever reason. NSUserActivity is used for handoff features allowing someone to pick up on one device where they left off on another. These activities can be "donated" to the system when a user performs a relevant task, and as long as the isEligibleForPrediction flag is set to true, they will begin to surface around iOS when they are relevant. A simple example of a useful NSUserActivity would be one that's donated every time someone starts a workout in a workout app. Over time, the system will get a sense for when this action is performed - perhaps when someone gets to the gym, or every morning at 6 am - and intelligently suggest it ahead of time.

The second way to donate a shortcut is by creating an INInteraction, built specifically for shortcut functionality. An INInteraction contains an INIntent which describes the user's request. If the purpose of the shortcut is to resume state in an app, then similar to donating an NSUserActivity, handling an intent is done from the App Delegate with the application(_:continue:restorationHandler:) method.

Intents Extension

Here's where things get interesting (but maybe a tad confusing). Up until now, the shortcuts I've mentioned are good for simple suggestions. These suggestions, when interacted with, kick the user to your app where you handle the rest of the interaction. There's a lot of practical use-cases for that, but what about if you want to do more? It might not always be necessary to open the app to achieve a task. For example, if I order coffee at 9 am every morning through a shortcut, do I want the app to open every time? Not only is it slow, but I might not have an interest in customising the order - it's the same every day! This is where an Intents Extension comes into play. An intents extension allows you to run code from an extension bundle, meaning you can perform tasks without opening your main app, or touching code from that bundle. It is suggested that any shared code or business logic that the extension needs access to be moved to a shared framework, and then imported into the relevant targets in your project (including the intents extension) where it's used. It is also possible to start an activity from a shortcut, and then resume that activity in the app. It might be useful if you find the user waiting too long for a server response, but it is recommended to design with the idea that the entire activity or task be completed from the extension.

Intents UI extension

Sometimes, a binary success/failure response isn't enough to properly convey the result of the shortcut that just ran. For this case, Apple provides an Intents UI extension which allows your intent to show a view controller and accompany the response with custom UI. These extensions are only supported on iOS (not watchOS). The only limitation to these view controllers is that they do not receive touch events. Design with the assumption a user is not able to interact with the view. Content can be updated as required, however. Extensions that use maps (e.g. Ride sharing) will already have a map provided by the system, so it's not necessary to also display a map in the UI extension. More on the different domains later on.

Interacting with shortcuts by voice

Hopefully, at this point, you've got a reasonable understanding of a Siri shortcut, and understanding the different uses for the word "shortcut." I've written about intents up to this point with the idea that they're surfaced as suggestions, and run from either a lock screen notification or the shortcuts area of the Siri search page. There is another way that these Shortcuts can be surfaced around the operating system, and that's via voice command using Siri. You can suggest that someone adds a shortcut from your app to Siri via a button in your app to open an INUIAddVoiceShortcutViewController. A user can also add a shortcut to Siri themselves, from the Siri options in the Settings app. There is a convenience aspect to being able to run a shortcut from Siri, but one of the biggest advantages I've found to running them from Siri instead of manually is that you're able to provide voice feedback on the request. An Intents extension (without UI) will show the name of the shortcut it's running, as well as the app running it, and then provide a success or failure indicator, or optionally kick the user back to the main iOS app. There is no other feedback. With an Intents UI extension, visual feedback can be given through the UI. When a shortcut is activated with Siri it can provide voice feedback from the request to the user, regardless of whether there is a UI component, making for a great Siri experience. In this way, Siri can become conversational. Asking Siri something simple such as, "When is the next bus to the city?" or, "Are the Dragons up?" could return a voice-based response making it a great way to get an answer on the go, or when making the request from across the room. I believe that these shortcuts can be run from both HomePod and Apple Watch, even if the app with the Shortcut doesn't have an Apple Watch app. This might only be with certain categories of SiriKit apps, however. I haven't been able to test it yet.

SiriKit Domains and Intents

Integrating your app with a voice assistant is tricky. People talk in different ways. The way I ask for directions might be different from the way you do. How does a voice assistant know what you mean? SiriKit uses intents which are a type of request the user can make. Up until now, SiriKit integration has been limited to intents in specific "domains," as Apple calls them. These domains are Messaging, Lists and Notes, Workouts, Payments, VoIP Calling, Visual Codes, Photos, Ride Booking, Car Commands, CarPlay and Restaurant Reservations. Previously, if your app didn't fit into one of these categories, you weren't able to integrate with Siri. Intents for these domains aren't new. What is new is the ability for any developer to create a custom intent, meaning any app can integrate with SiriKit. Each action needs to have a defined intent. These are defined through the new intents definition file that you can add to Xcode, and include fields for any required parameters necessary for either the request or the response.

With the old set of domains, there was room for ambiguity in the request. You, as the developer, could say that you didn't understand the request, or that you require more information. There's no room for ambiguity with the new domains as they're triggered by a custom phrase with no ability to input. At the time that a shortcut is added to Siri, the person adding it must tie a custom phrase to it. For example, you, a completely sensible human, might use the phrase, "Coffee order" for your morning coffee order, whereas I, a questionably sensible person, might use the phrase, "Banana peel."

Shortcut intents can take parameters as far as you, the developer, is concerned. The same "Order coffee" intent that you define might have an option for the number of sugars someone wants with their coffee. However, the number must be set at the time the shortcut is added. A "coffee order" shortcut can't have one sugar one day, and none the next. If it's set up, the parameters are all the same. Different shortcuts with unique trigger phrases would need to be set up by the user if they wish to have multiple options available when ordering coffee from Siri. You might suggest that the shortcut is set up for a coffee with no sugar after a user places this order a few times, but once it's added to Siri, it cannot be changed without removing the shortcut or adding a new one altogether.

Wrapping up

Many hours later, this post has certainly helped me come up with more precise distinctions between the types of shortcuts developers can build into their apps, and what it means for users of these apps. I hope it can clarify some of the questions you have, too. Maybe now the next time you're talking to someone about shortcuts, you'll better be able to pick up on exactly what aspect of shortcuts they're talking about - Shortcuts the app, the suggestions, Intents, or the Siri Shortcuts. If there's anything I've missed, or you'd like to ask a question, feel free to reach out on Twitter.

Parallel Testing in Xcode 10

Parallel testing

At the Apple Worldwide Developers Conference last week, Xcode 10 was announced with a bunch of new features and enhancements to various developer tools. One of the features that caught my eye was parallel testing.

We should all be writing tests for our code. Unit tests run relatively quickly and are used to test small sections of code, generally in isolation. UITests are another form of test that, as the name implies, test the UI of your application. They do this by running through full flows in your app - such as a purchase flow from start to end - ensuring that all the expected UI elements are present and that each button and control works as expected. UITests are useful for catching regressions, and for feeling confident that nothing broke after making a change to your app, but unfortunately can take a while to run. Dozens of 30-second flows in your app add up, and suddenly you might find your test suite taking 30+ minutes to run.

Enter parallel testing.

Previously only available to xcodebuild for separate simulators, and now available for all projects in Xcode, parallel testing allows multiple tests to be run simultaneously, with the main advantage being dramatically shortened XCTest and XCUITest times.

Screen Shot 2018-06-15 at 8.36.22 pm.png
How to enable parallel testing
  1. Select your target scheme in Xcode, and "Edit Scheme..."
  2. Find the settings for "Test", and press on the "Info" tab
  3. You'll see a list of your Unit and UI tests, press on the associated "Options..." button
  4. Select "Execute in parallel on Simulator"
  5. Optionally select "Randomize execution order"
Running tests in parallel

It's only possible to run Unit tests in parallel on macOS. Both Unit tests and UI tests can be run in parallel on iOS and tvOS.

When running tests in parallel, Xcode will run them on a clone of the same simulator. Most Macs should be capable of running at least two cloned simulators in parallel. Modern Macs with more RAM and more processor cores should be capable of running even more tests simultaneously.

Tests are split up by classes and allocated to each clone of the simulator as Xcode sees fit. What this means is that your tests are only as fast as the longest-running test class. For this reason, it's important to keep each test class as concise as possible and consider splitting tests into as many classes as is practical.


There are some things to consider now that tests can run in parallel, and optionally, in a random order.

Ensure that tests are able to run independently of one another and that no test relies on the test that comes before or after it to set up or clean up. Each test should be truly independent of all other tests. You are no longer able to ensure that test A will finish before test B begins, so this independence is important.

Performance tests will not achieve maximum performance when running in parallel. Apple suggests putting performance tests in their own bundle and disabling parallel testing for this bundle.

Wrapping up

Parallel testing certainly made for an impressive demo during the Platforms State of the Union at WWDC last week. It's something that will save countless hours of development time. Long testing time is something that may discourage additional tests from being written, and anything combatting that is a benefit to software quality going forward.

Introducing HeartMonitor

Update (5th May 2018): HeartMonitor is back on the App Store.

Update (12th April 2018): Late last week, HeartMonitor was removed from the App Store by Apple. I'm unsure if it will return to the App Store, but I'd like it to, and am working with Apple to hopefully find a way that can happen.

What is HeartMonitor?

HeartMonitor is an app for iPhone and Apple Watch that allows you to use the Apple Watch heart rate sensor to record "sessions" of heart rate activity - without having to start an active workout. The advantage of this is that HeartMonitor sessions have minimal impact on your activity rings.

Potential use-cases

HeartMonitor is useful for monitoring your heart rate in nervous situations, such as while giving a conference talk or presentation, in the dying moments of a football game, or while watching a horror movie. HeartMonitor is also useful if you want to keep an eye on your resting heart rate for short periods of time. I'm sure that there are other creative uses - if you think of any, let me know!


The idea

Almost two years ago, I wrote a blog post highlighting the case for a dedicated heart rate monitoring mode in watchOS - something that gives you the frequent heart rate readings of a workout session, but without having to start a workout and have your activity rings added to. There are issues with a feature like this. The original Apple Watch had mediocre battery life, and throwing in a 30-min heart rate tracking session would be enough to send the battery flat before the end of the day for most people. Since then, the Series 2 and more recent Series 3 have proven battery life is now a non-issue, with many Apple Watch wearers finishing the day with over 50% battery left. This leaves room for cool features that may use slightly more battery. It surprises me that there isn't a feature like this from Apple yet. When I wrote that original post, I was unable to find an app on the watch App Store that did this, and that was still the case up until the launch of HeartMonitor.


I had seen that people were starting a dedicate workout on their watch before an event where they wanted to measure heart rate, and then analysing that data later. There are two problems with this:

  1. It will very likely add unwanted activity data to your activity rings.
  2. There is no decent way to view the data afterwards.

HeartMonitor solves both of these problems. While it isn't perfect, it is far less likely that your exercise ring will be added to. HeartMonitor will add to your rings if your heart rate gets high enough that the activity you're doing should probably be considered exercise, but unlike the Workout app, it won't count every minute simply because you've told it you're working out.

HeartMonitor also solves the second issue of not having a place to view this data. The companion iPhone app will show you a list of sessions with detailed information and statistics for that session. From here, you can rename the session which makes it easier to remember what you were recording, and share the session with friends.


HeartMonitor is completely free. Free to download, with no advertising, or in-app-purchases. There is no analytics framework (first or third-party) in HeartMonitor, no third-party code, and no tracking whatsoever. You can download it assured there's no hidden catch.

So, what are you waiting for? Just open HeartMonitor on your Apple Watch to get started!

If you like the sound of HeartMonitor, you can download it for free on the App Store.

Feedback is always appreciated. I can be contacted here.

CGM Diaries: Things I Wish I Knew

I last wrote about the Dexcom Continuous Glucose Monitor (CGM) on 11 December, 2017. In that post, I highlighted what it was like after a week. The first week was not without hiccups, and the following few weren't perfect either. Things have improved dramatically after almost two months of wearing a CGM. The idea behind this post is to share things I've learnt that weren't obvious from the beginning. These are the things that had I known in December, would've made the first few weeks with the CGM a lot smoother. Your mileage may vary, but this is a collection of what has been working for me.


Get your overnight blood sugar level right. That is the single best piece of advice I can give. The biggest annoyance I had with the CGM after a week was the alarms - especially overnight. There's no such thing as perfect control, and things are going to go wrong, but if you can stabilise the night as much as possible, it'll make your life easier. If you've got a CGM, chances are you're controlling your blood sugar levels through an insulin pump. It's important to fine-tune your basal insulin to a rate that will keep you steady overnight. Easier said than done, of course, but if it works 5 or 6 nights per week, you'll be well on your way to having an easier time with the CGM. Being woken three nights a week is no fun for anyone.

But how? Before getting a CGM, I would've told you that it was impossible to have consistent levels overnight. I've since learnt this isn't true. I noticed a correlation between the nights I had stabilised my blood sugar level before sleep (i.e. Was hovering at a constant level, and had no active insulin - this was key). Short-acting insulin stays in your system for just over three hours, so it's important to avoid eating carbs up to three hours before sleeping. I've changed habits to have dinner finished by 7 pm at the latest so that insulin is out of my system by 10 pm. Now I know that if by 10 pm my blood sugar is between 5 & 7 mmol/L, it's unlikely to fluctuate, thanks to no active insulin, and a good basal rate. The result? Hours of uninterrupted sleep. For the sake of your sanity, especially when it comes to alarms that can't be turned off, you'll want to ensure this stability. You may need to tweak basal insulin rates, but it's well worth the effort.

A stable night is advantageous for two reasons; it gets the day off to a good start and helps your average BGL for that day. If my average is higher than usual towards the end of the day, there's a good chance that a bad night was a contributing factor. Ultimately, the goal of using a CGM is to have better stability and control of your blood glucose, which shows in HbA1c results. If the first 6-8 hours of your day are spent at a healthy blood glucose level, that will go a long way to improving your HbA1c.

Bolus early, bolus often

The second most important piece of advice I can give is to bolus (or inject, if needles are your thing) well in advance of eating a meal. Something you'll likely notice during the early days with a CGM is the delay between giving insulin and when it takes effect. If you give insulin for food at the time you begin to eat, you'll see that the food takes effect well before the insulin does, resulting in a spike in your BGL, followed by a dip 60-120 minutes later as the bulk of the insulin takes effect. I've found that giving insulin 20-30 minutes before a meal is the best way to avoid this spike. Your mileage may vary, but I haven't had to worry about my blood sugar falling too fast when bolusing up to half an hour before a meal. Any earlier would put you at risk of a hypo before the food takes effect, so I don't recommend it. Avoiding this spike will not only make you feel better but will help stabilise your blood sugar after eating. The idea is that you then consume food around the time the insulin starts to act in your system, and they balance each other out. It's never perfect, but it may be the difference between "spiking" to 9 mmol/L rather than 13 mmol/L. Avoiding these higher blood sugar levels a few times a day will undoubtedly benefit your HbA1c result.

It's easy to bolus early when you know what you're going to eat at a prepared meal such as an at-home dinner. Eating lunch at uncertain times at work, or eating out and not knowing what to expect can make this quite difficult. You can't bolus 30 minutes in advance of a meal when you don't know what time you'll get around to eating, nor can you bolus correctly for a meal you've never seen before - as is the case when you eat at a restaurant. Years of diabetes management has taught me to guess the carbohydrate content of meals at a glance. Apply this skill to a plate of food you haven't seen before, and you might be able to guesstimate carb quantity in advance. For example, it's a safe bet that a plate of pasta will have a non-zero amount of carb, whereas fish and veggies will have very little carb. In the case of the former, I'd be looking to bolus early for approximately 50% of the carbs I expect in the pasta. A typical bowl might have 50g worth of carb, but as you don't know the portion size, nor when the meal will arrive, I don't recommend bolusing for the full 50g in advance. It's unlikely a bowl of pasta will have <25g, data-preserve-html-node="true" so start by bolusing for that in advance. When the meal arrives, you can use your amazing carb-guessing skills to deliver insulin for the rest of the meal. This has been working for me. Again, it might be different for you. Don't bolus early if your BGL is low to begin with, or if your BGL tends to drop right after bolusing. In my case, I know that if I give insulin for 25g carb, I can afford to wait 30 minutes before eating and still avoid a hypo. It's not always practical to bolus in advance, and that's okay. It isn't the end of the world - after all, it's what you've been doing for years, isn't it? If you're not confident guessing the carb content of a meal in advance or bolusing in advance of eating, you can either choose low-carb food to avoid a spike or just enjoy the meal and accept that a spike now and then is a part of having diabetes. Just be sure to check in with your BGL a few hours later and correct if need be.


The next thing I wish I knew is that carbs are bad. Actually, carbs are great. But carbs are bad for your blood glucose levels. You might've read the section above on sleeping and thought, "That's great, but it isn't possible for me to avoid eating within three hours of sleeping." That's fine! Just be more careful with what you choose to eat. You'll quickly realise the types of foods in your diet that need to go. Have a low (or no) carb dinner if you can. Different foods affect different people in different ways, but these are some key things I've learnt:

  • Plain Weet-Bix (a cereal with effectively no sugar [~2.5%]) and low-fat milk will send my blood sugar soaring immediately after breakfast. It is classified as a medium-GI food.
  • Protein shakes have also been cut out entirely, despite there being no sugar in the protein powder itself. 200mL of milk and a small scoop of ice-cream is enough to raise sugar levels fast.
  • Low-GI bread is a lifesaver. Two slices of Lo-GI bread from Bakers Delight has replaced Weet-Bix as my breakfast, and this has a noticeably positive impact on my blood sugar. I rarely spike after breakfast, and if I do, it's to ~9mmol/L, instead of 14mmol/L.

Choosing low-GI foods where possible will help to stabilise your blood sugar levels as these foods release energy slower over a longer period, which is more aligned with how insulin acts in your body. I'd also recommend not eating too much carbohydrate in a short space of time, as it's harder to guess carb content and the effect it'll have on your body. Ideally, you won't see a noticeable spike in your blood sugar after eating, but the ideal is rarely possible. The next best thing is to minimise the spike, and that can be done through a combination of giving insulin early enough, not overeating carbs, and choosing low-GI food.

The sensor

There are a few things worth noting about the sensor itself that would've been handy to know from the beginning.

  • The Dexcom CGM sensor is meant to last seven days. I've had it last for less time and fail to give readings (fortunately Dexcom were great about this and offered a replacement), but also considerably more - up to 14 days. I don't suggest leaving it in longer the recommended seven days, but note I had success the one time I tried it. I've only been able to try it once as often the tape has started to peel after 5 or 6 days, so the sensor is ready to be removed on day 7.
  • If you're inserting the sensor in your stomach, it's most likely that the top of the tape (closest to your chest) will peel first, so when fixing the tape, I'd recommend sealing the top edge first to ensure it's stuck in place.
  • Inserting the sensor doesn't hurt, so don't be afraid. This is a case of do as I say, not as I do - years of changing insulin pump sets has me conditioned to expect pain far too often. Surprisingly, the Dexcom sensor insertion is completely painless. There's only been once where I've found it more noticeable than a tickle, but even then it couldn't be felt after a few minutes. The insertion device is quite large and can be intimidating, but it isn't as painful as it seems.

Sanity (check)

I'm the first person to praise the convenience and luxuries afforded by having an Apple Watch. The potential of the Apple Watch as a health and fitness device is truly unlimited. A long-term hope is that the Apple Watch can perform non-invasive blood glucose monitoring, but until that day we've got invasive solutions. Dexcom's integration with both iOS and watchOS is impressive. The apps are reliable, and that's exactly what you want from a medical device. The Dexcom app for Apple Watch supports a "complication" - this means it's possible to view your blood glucose reading in real-time on the face of your Apple Watch, with no need to open the watch app to see this data. At first, I thought there could be no better feature. After a while, I realised it's unhealthy to be glancing at my watch every five minutes to get an update on my blood glucose level. Focusing on this constantly, and anxiously watching it rise or fall, is no good for anyone. You survived up until now without such frequent updates, so you'll be okay to hide the complication. Opening the watch app every hour or so should still be enough for you to see significant benefit from wearing a CGM without going insane. Again, this is a case of do as I say, not as I do. I'm a lot better at not constantly checking my watch than even this time last month, but it's still more of a distraction than I'd like it to be.

Take a break

Continuous glucose monitoring is, on the whole, fantastic. That doesn't mean it isn't overwhelming at times. There have been many occasions where I've thought it's more trouble than it's worth. Since, things have settled down mainly thanks to bolusing early, and trying to get my levels stable before sleeping. If you feel overwhelmed, I encourage you to take a few days off from wearing it. A great time for this is in between taking out the sensor and putting in a new one. There's nothing wrong with going back to doing things the old way for a while. Sure, your levels might spike, but that's been happening for years, and at least you won't be anxious as you watch your BGL climb after a meal. You'll know when you're ready to put it back in. CGM has more of a learning curve than beginning to use an insulin pump does, and like an insulin pump isn't a device for everyone.

Learning experience

Everything mentioned thus far is something that I've learnt from experience with the CGM. It's only been a couple of months, and I'm sure that the learning will continue to be plentiful for a long time to come. Ultimately the best way to know what works for you is to try yourself. Things won't work perfectly at first. I could not have imagined how frustrated I would be by the alarms after a few weeks of wearing the Dexcom.

What I'd like to see

I'm looking forward to an update to the Dexcom Apple Watch app which brings the ability for the Dexcom to send data directly to an Apple Watch. Currently, your phone must be in range of the Dexcom to receive updates, which are pushed from the phone to the watch. As of watchOS 4, it is possible for a Bluetooth health device to send data directly to the Apple Watch, and Dexcom have said they will support this feature.

I'd also really like to see granular control of the alerts. There's a lot that could be improved here, including:

  • Make it clear that by acknowledging an alarm in the iOS app, it will be silenced. I spent days thinking it was impossible to silence alarms, and that I was stuck with being woken every five minutes until my blood sugar rose high enough to stop the alerts.
  • Time of day settings. Living in constant fear that your phone will sound an uncontrollable alert is no fun. People have occasions where they don't want to be alerted to things - at work, in meetings, at the cinema, etc. Silent alerts are possible for all but critical low alerts on the Dexcom. This is a start but not perfect, as you then have to remember to turn them on again or else you won't be alerted when you actually want to be - such as overnight. Almost 17 years of diabetes means that if I'm awake, I can tell with 99% accuracy that my blood sugar is low or high. How high, or how low? Who knows, that's what the Dexcom (and previously, finger-pricks) are for, but if I'm awake I'll be able to feel the onset of low or high blood sugar. I'd love to be able to tell the Dexcom to send audio alerts between 10 pm and 6 am, but no other time. Silent notifications to my Apple Watch and iPhone will suffice the other 16 hours of the day.
  • To extend on the above, there's the concept of "Low" blood sugar in the Dexcom app. This value is defined by the user (I have mine set to 3.7mmol/L), and anything under this reading will trigger an alert. There's also an "urgent low" alarm - set to 3.1mmol/L - which can't be changed, nor silenced under any circumstances. It's a long shot, and there are other things which should be a priority, but I'd like to see smarter use of these settings based on a wake-up alarm. For example, I absolutely should be alerted to a level of 3.6mmol/L at 2 am. However, if my BGL drops to 3.6mmol/L at 5:30 am, and the Dexcom knows my alarm is set to go off in the next 30 minutes, the fact that the low isn't "urgent" means it doesn't need to wake me. I have no issue with it waking me at any time if the level is considered an urgent low, of course. This is simply something I'd like, and I realise everyone would have a different preference.
  • On a similar note, a true wildcard feature would be integration with a sleep tracker on the Apple Watch (AutoWake?). This could mean that if your blood sugar was low and steady, but not falling nor urgently low, it would wait until the end of a sleep cycle to wake you. Let me tell you, Dexcom shows no mercy and will wake you 40 mins after falling asleep if it has to. That is not a time one would want to be woken if it can be avoided.

Again, these business rules are tricky to decide, and this is no easy task to tackle, but in a world where Dexcom have infinite time and resources to develop their mobile apps, I'd like to see it happen. As a general rule, fewer app settings are better, but not for a medical device like the Dexcom, which plays such an important role in the life of the wearer. Fine-grain control is exactly what's needed here, and I find the existing control over alerts to be frustratingly limiting.


Continuous glucose monitoring can benefit every person with diabetes in a slightly different way. For a young child who may not have yet developed the ability to detect low blood sugar, CGM does this for them. For that child's parents, they can send their child off to school knowing that the CGM will catch irregular blood sugar and alert the child sooner than a teacher might notice the child's pale face and scattered concentration, which are both indicators of low blood sugar. For someone my age, CGM is about the freedom and flexibility of not having to carry a blood glucose monitor everywhere I go, but more importantly, it's about smoothing the fluctuations in my blood sugar levels leading to better control which will (hopefully) mean fewer complications from diabetes later in life. For someone prone to fainting when their blood sugar falls, CGM is about saving their life, be it overnight, or just one afternoon while excitedly watching the footy and not realising their BGL has dropped. CGM has infinite potential to benefit people with diabetes, as well as those without it. Learning what works best for each individual takes time, and is no small task. Had I known the tips above this time two months ago, I would've had a much easier time using a CGM in the beginning, and I hope that someone new to using CGM finds the tips to be beneficial.

Overview: AutoWake 1.0

AutoWake has hit the App Store. It's the first haptic smart alarm for Apple Watch. AutoWake is developed by David Walsh, a self-confessed Objective-C lover, and maker of other popular health and wellbeing apps for the Apple Watch; HeartWatch, and AutoSleep

The idea is simple. AutoWake is an alarm that wakes you in a lighter phase of sleep. The result? You feel less tired and groggy upon waking. Similar apps have existed for the iPhone for years. They require you to sleep with your phone on your bed, so they can detect motion as you sleep. AutoWake is the first to bring this to Apple Watch. I've been using it for a few months and have found it to work well.

You configure AutoWake by choosing the time you wish to wake up by in the watch app. The alarm will go off up to either 15 or 30 minutes before that time (it's up to you), depending on your phase of sleep. AutoWake doesn't need to be open on the watch to work. However, you must have the AutoWake complication active on the watch face of your choice. I find either the extra large or the modular face work well as they both offer large countdown timers. AutoWake communicates with its iPhone app to work out an appropriate time to wake you. This means AutoWake also has to be running in the background on your iPhone. You can't force-quit the app as it needs to be active. You'll need to keep an active connection between your phone and watch, so neither can be in aeroplane mode.

It wakes you up with a haptic alarm - like the alarm app built into watchOS, but with a more subtle and comfortable vibration. Should this fail, AutoWake will fall back and wake you up with audio from the iPhone app. AutoWake also triggers a heart rate reading in the seconds before it wakes you up, and shows it to you once you silence the alarm. Waking heart rate is a good indication of overall heart health, and AutoWake ties in with another of David's apps, AutoSleep, to make use of this data.

Unlike almost every other alarm app, AutoWake doesn't have a snooze function. There's no dozing off after dismissing the alarm. After giving it some thought, it makes sense. If AutoWake works correctly and wakes you up in a lighter phase of sleep, you should wake feeling less groggy and more likely to get up straight away.


There are a few apps that have had success due to the personality and character of the app. Carrot Weather is one that comes to mind. AutoWake also has subtle hints of personality which add to the overall experience. You can choose a name that AutoWake will refer to you as, and from there, its audio alerts will refer to you by your name. It's a small touch, but it makes a difference. I've got my name set to, "Egghead," and it never fails to amuse me when my phone says, "Sleep well, Egghead!" after setting the alarm.

AutoWake is an app I've wanted to exist for quite a while, and I'm delighted that the initial version works as well as it does. AutoWake is available for a small upfront cost on the App Store, and is worth every cent.

AirPods - One Year On

AirPods, Apple's take on truly wireless earphones, have been out in the world for just over a year now. They were plagued with 4-6 week wait times right from the initial launch. These shipping delays continued throughout the year, and are now affecting 2017 Christmas holiday shoppers. Whatever way you look at it Apple just isn't able to make enough to meet demand. Whether this is because they're difficult to manufacture, or because demand is higher than expected, no one is sure. One thing is certain, however. AirPods are popular. You can't walk a block through the Sydney CBD without seeing someone wearing a pair, and it isn't uncommon for me to not be the only one on the bus wearing them. Alongside the Apple Watch Series 3, AirPods are my favourite Apple product released in years.

Now, one year on, I want to look back on what I wrote in my AirPods review and explore how my initial impressions have either changed or remained the same.

These are more than special earphones. They’re a new category of wearable device.

I still believe that AirPods have the potential to be considered a wearable device, and not just a pair of earphones. Over the last year thanks to software updates, transitioning the connection of AirPods between devices (iPhone, to Apple Watch, to Mac, to Apple TV) is more seamless than ever. If I'm wearing them, it doesn't matter if I press play on audio on my phone or watch, the AirPods intelligently will connect to whatever device is best. This has other implications, such as always being able to communicate with Siri. While wearing AirPods, I know I can activate Siri discreetly on my Apple Watch, and talk as though I was holding my phone near my face.

They haven’t once felt like they’re going to fall out and this includes while at the gym doing all of my regular exercises including running, weights, pull-ups, push-ups, sit-ups; you name it. They’re hardly noticeable in the ear.

It's easy to forget you're wearing AirPods. They remain as lightweight and comfortable as ever (though the comfort factor isn't the same for everyone), and despite not having perfect sound quality, the convenience of the AirPods design is enough to make me not want to leave the house with any other pair of earphones.

Although battery life isn’t fantastic for “wireless” earphones, my early usage suggests 5-6 hours on a single charge - in line with Apple’s estimates.

After using AirPods for a year, I'm convinced that the battery life does not matter. I'm not sure how long they last on a single charge anymore; it could be 2 hours, or it could be 7. It doesn't matter. There is almost never a situation in which I go more than 90 mins between putting them back in the case to charge. I've never found the battery life not to be good enough. Sure, a few hours may not sound like a lot, but how frequently are you using them continuously for that length of time? Even popping them back in the case while you visit the bathroom at work is enough to top them up for a few more hours of use.

Having to charge so frequently might sound in conflict with what I said earlier about wearing them constantly.

Still true. While battery life is good enough for day-to-day audio listening, the idea of AirPods as wearable tech won't be taken seriously as such until they can last in your ears all day should you need them to.

Siri on AirPods has been a disappointment for me so far. The way to active it is to double tap on either bud and then talk.

I've found the best way to talk to Siri with AirPods in is to activate it from the Apple Watch by pressing the Digital Crown. It's going to work every time.

To truly be free from your phone while using AirPods, a smartwatch with audio controls of some kind is necessary.

This is true more than ever. Controlling the AirPods with only a phone is still clunky, but using a smartwatch makes this a lot easier. Now that the Apple Watch Series 3 has a cellular/4G connection, the combination of AirPods + Apple Watch is even better. You can now leave the house without a phone and listen to music while walking around or exercising, while also being able to take phone calls, and dictate messages. It's a powerful combination, and having the AirPods with the cellular watch makes the experience notably better.

We've seen some small improvements in the last year to both the software controlling AirPods, and to the hardware they connect to. Improvements to the way AirPods handle connecting to different devices and new hardware such as the Apple Watch Series 3 take away some of the hassles I addressed in last year's review. There are a few improvements I'd like to see to AirPods going forward. The first is better sound quality. The sound quality of AirPods isn't bad by any means, but there are times when higher quality audio is appreciated, and not having to find another pair of earphones in these situations would be nice. Secondly, water resistance. iPhone and Apple Watch are both water resistant enough that if you're stuck in the rain with them it isn't an issue. It would be nice if AirPods were also water resistant. I've heard that they do survive submersion in water, but until Apple promote water resistance as a feature themselves, I'm reluctant to let the AirPods get wet. Finally, I'd like to see a dark (space?) grey or black colour offering - purely for cosmetic reasons. I know that Apple are unlikely to stray from their distinctive white earbud design, but the new Space Grey peripherals that come with iMac Pro show that they are open to mixing things up.

CGM Diaries: Week 1

I've now spent a week living with a continuous glucose monitor (CGM). I've got a lot of thoughts, but it's safe to say that it's nothing short of amazing. CGM is a transformative technology for people with type 1 diabetes. I've been amazed by the accuracy of the sensor, how unobtrusive the design is, and how useful it has become to know my almost real-time glucose level. I wrote about it extensively in the first few days, which you can read here, here, and here. I'll try not to recap any of that in this post.

What I've learnt

It's been quite impressive to witness glucose levels spiking right after certain meals, and not others. While this has undauntedly been happening for years, it's the type of things you don't notice when you're taking intermittent glucose readings. It can be frustrating to watch the reading rise while knowing it might be an hour before it starts to fall again. I Tweeted saying that I'm considering not eating carbs again, mainly to avoid these spikes. The Tweet was hyperbole, but it has made me start to reconsider certain food choices. For example, a bowl of Weet-Bix in the morning will likely be replaced with toast as it doesn't have such a negative impact on my levels. It's also been positive to learn that the Dexcom CGM is accurate. It requires two manual calibrations per day, and most of these have given readings within 0.5 mmol/L of what the Dexcom is showing.

What's useful

Near real-time glucose data is truly transformative. It takes the guesswork out of managing diabetes and means I can choose to take action on my glucose levels at almost any time. Feeling a bit on the high side? A quick glance at the watch will either confirm or disprove this feeling, and means I can take action if necessary. It's also reassuring to be able to check my Apple Watch in the middle of the night and know I'll get an instant reading. There are times when the reading is not bad enough to have triggered an alarm, but the fact I'm half awake means I can glance at the reading and decide whether to give insulin. Despite my dislike for alarms on the phone during the day, they're great overnight. It's useful to me alerted overnight when my levels aren't great. While not a life-saving advantage, another is being able to leave the manual finger pricker at home. It's one less thing to carry and worry about, and one less thing to awkwardly take out and use in public. With a glance at my wrist, I can discreetly check my glucose level, and move on with life.

The sensor

The physical design of the sensor is bulky, but despite this, it is less noticeable in most situations than the smaller connection for the cannula of an insulin pump. It's easy to brush against, especially when placed in the stomach, but the tape holding it in place is strong, and it isn't easy to knock out. It's also more comfortable than the pump connection, as it's hardly noticeable when sleeping. I did mention last week that it is slightly uncomfortable in the car as it brushes against the seat belt, and also while running. The former is still true, the latter not so much. Perhaps it just took some getting used to. I've also spent some time swimming at the beach these last few days, and it hasn't been an issue there either.

Changing the sensor

Since the sensor had been in for a week, it was time to change it this morning. The Dexcom app alerted me to this by sending multiple notifications this morning informing me the sensor would cease to work at precisely 10:20 am, and that it was time to replace it. There are two parts to the CGM. There's the sensor itself which sits just underneath the skin. This needs to be removed every week and replaced. There's also the transmitter, which is connected to the sensor. It sits on the outside and is what crunches the data, and sends it back to the phone. The transmitter lasts about three months, so it is retained and connected to the next sensor. Pulling it out is straightforward enough. Once the tape around the edges is removed, the sensor slides out easily. Unlike an insulin pump cannula, it hasn't left much of a mark on the skin. Once it's out, the insertion process begins again (on the other side of the stomach). As was the case with the initial insertion, it requires two hours for the new sensor to "warm up." Once that time has elapsed, two consecutive manual blood glucose readings are needed to calibrate the sensor, and then the CGM is back in business.

Time away

It's not always practical to be within Bluetooth range of your phone. It's happened a few times during the last week that I've not been nearby my phone for a few hours at a time. The transmitter simply stores a history of these readings every five minutes as it otherwise would, and sends them across with the first sync after your phone and Dexcom establish a connection again. It works reliably, and to my knowledge hasn't missed a single reading all week.

That's been the first week. I am enjoying having access to the real-time data a CGM provides, and the way that it can help me make informed choices when trying to control my glucose levels. The Dexcom app now lives on the home screen of my phone, and as a complication on my Apple Watch face. It's incredibly useful to have access to this information, and Dexcom's app is impressively reliable.

If you're reading this and reside in Australia, I'd really appreciate it if you took a moment to fill out a form here. It sends a letter to your local member of parliament requesting funding for CGM technology for everyone in Australia who needs it, and not just those under 21 years of age 21 as is currently the case. I wrote a letter and sent it tonight, and would really appreciate support from others. If you've got any questions, I'd be more than happy to answer. You can ask me question via the form here, or on Twitter.

CGM Diaries: Day 3

Day three. I'm starting to get used to the CGM and learn more about how it's going to fit into my life. Today was a good test for it, as I was out of the house for an extended period.

This morning began with the first run I've been on since getting the Dexcom. Having an Apple Watch with a built-in 4G connection meant I didn't take my phone. A side effect of this was not being able to see my glucose levels while running, as the Dexcom connects to the phone but not to the Apple Watch. This will change as a result of watchOS 4 and changes to CoreBluetooth, but as I type this those features aren't supported yet.

The Dexcom sensor is comfortable enough for day-to-day activities. I haven't been able to feel it when at the gym, or when sleeping (which is what I was most concerned about. It has brushed up against the seatbelt in the car which can get uncomfortable, but it's no big deal. Where it's been most uncomfortable was on this morning's run. There's no other way to describe it other than it felt heavy. I've not felt this way about an insulin pump set, but the Dexcom is absolutely noticeable - and somewhat uncomfortable - while running. Again, not a huge issue, but it's something to note.

After years of being trained to complete regular "finger pricks" around lunch time, losing this mindset is taking some time. With the CGM, I can just eat. As strange as that sounds it's true. There's no longer a prerequisite to eating. Similarly, earlier today I found myself feeling a rise in my blood sugar. It was only minor, and usually I wouldn't worry about it. With the CGM, I was able to glance at my wrist, note that it was slightly higher than it should be, and give a dose of insulin through the pump. Not having to draw blood to get this information is helpful.

As I've mentioned previously, it is recommended to calibrate the Dexcom sensor with a manual "finger prick" every 12 hours. Being out of the house for so long today meant that these two calibrations would occur about 16 hours apart. That hasn't stopped the Dexcom app from sending me a notification every five minutes since 6 pm this evening reminding me to, "Enter BGL meter value." There seems to be no way to clear this without entering a false calibration - which I'm reluctant to do. On the positive side, these notifications aren't making audio alerts. Another positive is that all of the calibrations so far, except one, have been within +/-0.5mmol/L of the current Dexcom sensor reading. It's reassuring to know that it's accurate.

Today was the best day I've had so far for learning what makes the CGM useful. Highs and lows are unpreventable for someone with type 1 diabetes, but a CGM ensures you're on top of these swings and can help you recover from them faster. The highs won't be so high. Nor the lows so low. It's about the convenience of leaving your blood glucose monitor at home for the day. Did I mention? I haven't seen the thing since seven this morning - which is almost certainly the longest time I've spent away from one in over 16 years.

CGM Diaries: Day 2

I feel the need to begin by stating that this is in no way a complaint about the Dexcom G5 continuous blood glucose monitor and that I am extremely fortunate to be wearing such a device that gives me continuous, real-time data. It works well. Being able to see this data in real time will undoubtedly lead to better overall control. It's already saved a hypo. This post is simply what I've discovered when trying to write software based on the data provided by the Dexcom.

As a software developer, the thought of the data collected by the Dexcom is exciting. The Dexcom iOS app works well but isn't perfect. That's okay as long as there's access to raw data. In theory, access to all of the readings off of the sensor would allow me to build an entirely custom app for viewing real-time glucose readings on both iPhone and Apple Watch. This theoretical custom app would also include support for my preferred Apple Watch complication, as well as more granular control over notification and particularly the sounds they make. Another possibility would be a custom companion app, so that my parents could check in with my glucose level overnight. There are countless possibilities.


My first thought was to build something that pulls data from HealthKit and work with it that way. The Dexcom app currently writes data to HealthKit at a delay of an almost-perfect three hours. I addressed that in yesterday's post. While that is okay for an app that analyses longer-term data and trends, it isn't helpful for the projects I had in mind for today, with the goal being to use data that's as real-time as possible.

Dexcom API

A quick Google search this morning for "dexcom api" lead me to realise they do have a way for this data to be accessed by third parties, so I decided to play around with it. Many hours later (too many of which spent getting the authentication right), I wondered why the simple app I'd built to return data captured in a given period wasn't working. That's when I came across the following on the Dexcom website.


That explained why today's efforts were failing. It's disappointing as a developer, but I'm sure there are valid explanations as to why. As an FDA approved device, there are processes in place, and lots of regulation they have to adhere to before anything gets done. I can also confirm that this problem can't be addressed by simply changing your Dexcom account address to a United States one.

Where to from here

I'm a little deterred knowing that there isn't a reliable way to access real-time data from the Dexcom sensor. It doesn't matter much - the official Dexcom app works reliably and is enough for most people most of the time. A possible next step is to try and read data straight from the Dexcom sensor via Bluetooth. Some quick searching earlier this evening tells me this may be possible, but that's a project for another day.