Are you all sick of hearing about #applehealth yet? 😏 Today I had a couple of bug reports about an un-Apple Health-related crash, so I fixed that and sent out an update. But then it was back to the #sleep beta to debug some weird behaviour. #healthkit seems to be calling my app with “new data” over and over in the same minute and I can’t work out why. There’s no new data, either. When I go looking, I keep getting the same results over and over. It did that maybe a couple of times to me during testing, but I’ve seen some beta user logs with 20 or 30 calls exactly the same within a minute.
Seems like #exist for #ios is updating #healthkit data in the background fairly regularly now. Fingers crossed it stays that way. After a little more testing to make sure the updating works well I’ll send it out to beta testers for the first round of #applehealth #sleep testing.
Left #exist for #ios alone over the weekend to see how well my #healthkit background updating would work. Today I had a look at the logs and it looks like all my data is updating without me opening the app, but not as often as I’d like. A change I made to stop duplicate updates occurring seems to be stopping a lot of non-duplicate updates getting through, so I had to try a different approach to de-duping the updates. I also noticed the app is getting a lot of “Network connection lost” errors when trying to send requests. Not sure what that’s about yet, as I haven’t been able to reproduce those errors to debug them. Still, getting closer and closer to releasing the #applehealth #sleep update to beta testers!
Aaaargh #applehealth! I’ve had the majority of the #sleep integration in #exist for #ios done for days now, but I’ve been fighting with getting the background observers working. I can’t watch the logs run in realtime, because I’m testing for #healthkit waking up my app in the background and telling it to send new data to Exist, and it won’t do it every time I add new data, because it wants to save battery. So I’m stuck adding data and waiting an hour or so before grabbing the log file to see if anything happened.
Fixed a bug in #exist for #ios today that was causing the app to crash when users turned on location tracking for the first time. Also continued some refactoring of #healthkit code in an effort to get background observers working for #applehealth #sleep and other HealthKit data. The idea is that iOS will notify my app when the user syncs new data to Apple Health, rather than me checking for it regularly. Still trying to get that working for activity data, but it seems to be working well for sleep so far.
Today I figured out a way to filter out duplicate #applehealth #sleep samples from the same app. I’m using Sleep++ (among others) for testing, and it’s duplicated all my sleep records for the past few days. Although the Apple Health app handles merging and de-duping data for the user, when a developer queries HealthKit, it just returns whatever it has, so you have to de-dupe it and all that good stuff yourself.
Woo! Got #customtracking working in a hacky way in #exist #android. Solved some minor issues with that on the server side, and then verified all works as it should. The next step will be to actually make a nice UI for adding and tracking various custom habits and events, and at some point I’ll deploy the backend stuff to the live server so we can test it for real with some beta testers.
First pass of the #exist #customtracking backend done today. Didn’t get time to make the custom Android client that can talk to it, ended up spending the evening helping @belle sort out some sleep logic for #healthkit stuff in #ios. Healthkit is like a dumb database returning low-level records, rather than giving a nice daily summary, so it’s much more akin to the crappier APIs I’ve had to integrate (cough-withings-cough) than the lovely ones like Fitbit’s. We’ll also have to implement custom de-duplication as healthkit won’t prevent multiple apps adding overlapping sleep records. Super fun times!
More #healthkit refactoring! Good ol’ Josh spent a long time with me today helping me reason through the best approach to managing different types of HealthKit data. Different types of data have to be handled in specific ways, and it’s all asynchronous, as is acquiring the attributes and updating the attributes via the Exist API, so there’s a whole lot of chaining completion blocks going on. Josh figured out a good approach for me, so now I’m trying to get that implemented so I can get back to testing #applehealth sleep data.
Still slogging away at #HealthKit refactoring in #exist for #ios as well as adding sleep data from Apple Health. Got some help from @josh to help me figure out the best ways to make my HealthKit code as generic and simple as I can, and after implementing his suggestions I’ve probably cut about half the code involved in the Apple Health integration. I’m expecting lots of bugs to work through, but really happy about cleaning this up, as it’s definitely been the most complicated, messy code in the app.
My passion for working on #exist for #ios has been reignited! I sent out the latest update including lots of new Apple Health data (workouts, nutrition, active minutes, heart rate) to the App Store this week, so I’m just waiting for it to be reviewed.
For some reason we had a bunch of users all asking us for menstrual tracking over the past week or so, and it’s something I’ve always planned to get from #healthkit but haven’t gotten to yet. So after sending out that update I was really motivated to explore getting menstrual data from Apple Health. Exist doesn’t support it yet but I’ve started working on getting the data anyway. I think my motivation really wanes when I’m working on bug fixes. It’s a very slow, difficult, lonely process for me, and I often struggle to replicate bugs and feel like updates just get stuck in limbo for ages while I worry about how to fix all the bugs. But starting a new feature is always fun and exciting—and a lot faster these days than it was a couple years ago!
Ahh keep forgetting to log lately! Here’s what I’ve done over the past couple days:
- Sent an #exist for #ios update to the #appstore that includes #location tracking. Finally! I’ve been working on this for months, so I’m relieved to have it released. #milestone
- Sent an Exist for iOS update to beta testers that syncs more data from #healthkit
- Started drafting one of three #client #content articles due this week
- Did my personal #monthlyreview for October
- Sent out my weekly #newsletter
HUGE day of #exist for #ios today. I made a new settings screen to handle all the new #healthkit data I’ve been adding, made some changes to how I get HealthKit data to make it more generic, fixed some bugs, and added a bunch of new constants to replace hard-coded values.
I also sent a new build of the #location branch to #TestFlight for beta testers, and took up a big chunk of @josh’s day trying to figure out why I kept getting intermittent 412 errors from the Exist server. (Turned out to be an issue with the default cache policy of
After playing with #healthkit in #exist for #ios yesterday I was on a roll, so today I tried adding some code to the app that makes HealthKit tell me when data updates, so I can do a better job of keeping user data in sync, which has been really tricky so far.
Also tried adding weight data from HealthKit, but we decided it’s better to leave that until the infrastructure changes @josh is working on are done, as it’ll be easier to keep it updated then. But after removing weight, I did add heart rate, active minutes (they weren’t available when I first added steps), and workouts!
I also did some good work along the way to make my code more generic, which should make it more stable and easier to diagnose bugs in the future. Down with magic numbers!
Phew. Plenty of testing still to be done but I’m really happy with how much I got done this weekend.
I made the notifications show what step count was being sent from #healthkit to #exist, because I was worried I was sending zeros sometimes (seems I was wrong). The side effect has been that I’ve actually enjoyed seeing what my step count is without having to open the #exist app throughout the day, so I’m experimenting with making these notifications part of the app for real today.
So far I’ve added the percentage of my step goal as well as my current step count, and I’ve added an extra notification for when my priority 1 insight is updated—that’s the one that’s always showing under steps, that says stuff like “today’s goal is higher than average for you” or “with a bit of effort you can still hit your step goal”. Wondering if these will be more interesting/useful if they’re actively “pushed” to the user.
Back to working on adding #location tracking to #exist for #ios, now that the #healthkit version is released. Today I made an adjustment so location doesn’t update too often, and I fixed a bug where the OS-level permission request for location was disappearing too quickly for the user to tap
cancel. Oh, and I created and then (much later) fixed a bug in laying out the dashboard/today screen.
Getting ready to finally submit #exist for #ios to the App Store with #healthkit integration! I have so many conflicts, though, because I’ve been doing little bug fixes and improvements to the App Store version while testing the #healthkit stuff. Poor @josh is going to get roped into helping me fix those today so I can submit the app for review.
Also added an alert to explain the limitations of Apple Health that might make it seems like the integration isn’t working. I have a #blog post in the works about this, but basically the limits of the #healthkit api mean if the user doesn’t approve my app in the Health app properly, or if they have no data in Apple Health, the connection won’t work and they probably won’t understand why. Hoping this little alert will help.
Spent most of today working on #bugs in #exist for #ios. The version I submitted to the App Store recently with some small bug fixes was rejected because I’d introduced a bug into the login process. Tracked it down a couple days ago, but only figured out how to fix it today, so finally submitted that again for App Store review.
And in the #healthkit beta branch I’m still working on this nightmare bug that’s affecting multiple testers, which I can’t reproduce at all. @josh reviewed my code today, in case I was overlooking something obvious, but didn’t find anything. I ended up changing my approach for storing/retrieving the data that keeps getting lost, since I can’t figure out what’s causing the bug. Fingers crossed this will fix it so I can finally send the #healthkit version to the App Store!
Sent a new version of #exist for #ios to the App Store for approval. It includes some fixes for localising numbers that were causing issues for users with languages other than English on their phones.
Also tried to figure out a bug that’s affecting some of my beta testers but I’m totally stumped. I can’t replicate it but it’s happened multiple times to two different users. It’s the only thing holding me back from releasing the #healthkit integration to the App Store, so I’m annoyed I can’t figure it out.
- Stopped merging dev branches into master before uploading to App Store, so master version doesn’t match what’s in App Store.
- Added bug fixes for App Store version into latest dev build in-between working on #healthkit and location monitoring. Health and location aren’t ready for App Store release yet, so neither are those bug fixes.
- Committing lots of different changes at once, making it hard to find when/where/how I fixed bugs previously in order to replicate in a different branch.
Bad, bad habits. I’m very annoyed at myself.
Now that a new version of #exist for #ios with #healthkit is out to beta testers, I’m working on adding #location again. I was trying to add too much all at once and getting overwhelmed by all the bugs I’d introduced so I removed it temporarily. Seems to be working alright now. Only issue is getting background fetch to run often enough, since I have pretty much no control over that.
Had an appointment with my doctor this morning to check up on my shingles treatment. The plan now is to finish up all the medication I have currently, and then only keep going with the pain meds if I’m still in pain when I run out. Definitely feeling better these days, and hoping I’ll be back to normal by EOY.
Workwise, @josh and I had a call with our accountant today to sort out some stuff for #HelloCode. I spent the rest of the day working on fixing #bugs in #exist for #ios. Still feeling a little like whack-a-mole, but definitely making headway and finding fewer and fewer issues to fix. Hopeful for another beta release this week to get #healthkit well and truly tested by users.
Also working on some tweaks to my latest beta branch of #exist for #ios. The #onboarding has become really complicated now that I’m asking for permission to update mood, location, and activity data (via #healthkit). The user gets bombarded with messages asking for permission or indicating successful updates, so I’ve decided to use a #cocoapods library to set up an onboarding process that goes through all of these actions before the user gets into the app itself. Much easier to handle everything in one place, rather than having conditional code showing modal views scattered throughout the app.
Had a good chat with a #Ghost colleague today about our company culture and managing remote work. Also did a little bit of follow-up with #Ghost team members who are blocking me getting some stuff shipped, and finished off a draft of a blog post announcing the Ghost Magazine project.
This morning @josh tested my #exist for #ios app again and I fixed the last couple of issues we found before sending a new version to beta testers. Really hoping to be able to launch the #healthkit integration version to the App Store before long!
My new App Store build of #exist for #ios is stuck in “processing” inside iTunes Connect, so I spent some more time trying to improve the settings page for the latest beta version with #healthkit integration. I think I’ve pretty much got everything hooked up as it should be, but no doubt when I let @josh have at it he’ll find lots of ways to break it 😏
Not feeling great today, but hoping that if I rest a bit now I’ll feel up to doing some #Ghost work this afternoon. It’s been nice to not have to work while I’ve been sick, but the deadlines don’t really stop looming even if you have a good excuse for not working.
Yesterday I was feeling better than I have in a while. I uploaded a new beta version of #exist for #ios with #healthkit integration and started to upload a new App Store version with the Today/Goals screen. Got stuck with the App Store because it’s asking for iPad screenshots. It’s never asked me for those before, and the app isn’t designed to be used on an iPad, it just happens to be technically compatible, so I’ll remove iPad support today and retry submitting for review.
My beta version had a very clunky settings page, so I worked on fixing some issues noticed by testers and improving the experience on that screen overall. Still a bit more work to do, but hoping to release a new beta version today.
Got some feedback on my first #Ghost magazine essay today, so I’ll have a go at incorporating that tomorrow. Overall very positive response from the boss, which is nice :)
Did some #research for my second Ghost magazine essay, which is about interview techniques (the journalistic kind, not the hiring kind). I’ve been trying to figure out what the best in the field know that I don’t about doing great interviews.
Also spent some time on #exist for #ios today. Finished off some layout stuff this morning, including replicating one of my #storyboard view controllers in code. Storyboard is the worst. The less I have to deal with it the better. A couple of small adjustments were a nightmare to get right in storyboard, but so simple once I switched to laying it all out in code. Probably mostly just my lack of familiarity with storyboard, but I find it very opaque compared to the transparency of coding layouts.
And the rest of today’s code was just a lot of #healthkit debugging. Much more to go.
I can’t believe all the pain and time I wasted on my background fetch not working. So annoyed that I didn’t realise #healthkit data isn’t available when the phone is locked, so the background method couldn’t get any data. No idea why it worked a couple of times, but ignoring those weird flukes, background updating is a no-go for people who lock their phones.
Guess that means I’ll be implementing a background update on opening the app to grab healthkit data instead. #ios
Background fetch is driving me nuts. I’ve added a bunch of local notifications to #exist for #ios so I can see when the fetch is being triggered and which points it’s hitting in the fetch method. Seems like I’ve figured out the issue - I’m using
AFOAuth2 for OAuth 2 token management, and it stores tokens in the keychain with its own security settings, regardless of what I’ve set for the keychain overall. It uses the default, which is only available when the device is unlocked, so background fetch can’t access the token in the keychain to send the #healthkit data to Exist.
Couldn’t find any clear examples of what to pass in to change the security settings, but @josh and I did come up with a possible fix so I’m testing that now. Such a pain to have to wait for hours until the OS decides to run background fetches.
Still struggling with background fetch in #exist for #ios. Sometimes it works perfectly, other times it starts but doesn’t complete—but no errors are returned either. It seems to just stop. And it seems like anytime I run the app on my phone via #xcode it puts off background fetching for a while, so I have to wait hours to test it again.
In the meantime I’m working on the logic for #healthkit data handling. Since Apple won’t let me find out whether or not I have read access to particular data attributes (apparently that protects user privacy by preventing sensitive data leaks), I have to assume that if I’m receiving zero values for every day in the past week, the user didn’t grant me access to that attribute.
Also need to generic-ise my code, since I’m prone to writing very specific methods and replicating them with minor changes. I know it’s terrible, but I’m also terrible at figuring out how to make a generic method that will work for a variety of situations. #code
My background refresh isn’t working in #exist for #ios so I tried to debug that today. Still haven’t figured it out. Everything works fine when I use code to simulate a background fetch but in the real world it never seems to get triggered.
Also did some debugging for a very specific user bug I’ve been stuck on for ages and did some more work on updating my settings screen so I can add #healthkit settings.