Runtime shipped a few months ago and its gotten a great response. Its been featured on the App Store's Best New Health and Fitness Apps for nearly two months now. Its very exciting to see many people are actively using it. Ive gotten some great feedback from folks which has been the driving force behind the new update to 1.0.4.
One of the earliest feature requests I got was for exporting GPX files. Initially I only supported KML files because thats what Google Earth uses, and naturally I assumed this was the standard for GPS route file formats. It turns out thats not really the case. GPX files are much more widely used for all sorts of things, ranging from adding routes to a backpacking GPS device to geotagging your photos.
Fortunately, adding support for GPX files was very straightforward because I had actually already built this for myself :) Xcode supports simulated location tracking using waypoint-based GPX files, so I had already written a GPX file exporter for my own testing purposes while building the app. I just hadn’t chosen to publish it as a feature.
Many other apps (including some popular geotagging apps) use a track-based GPX file. So I ended up adding support for both waypoint-based and track-based files. You can now export your Runtime routes as a waypoint file for use with Xcode location simulation, or as a track file for use with many popular geotagging utilities.
Another request I got was to add a privacy policy to the app. Runtime uses very basic analytics to see how certain features are used in an anonymous way. This is a pretty common practice that helps developers better understand ways to improve their app. I was very careful not to record any personal information. Locations are the most sensitive and they are not recorded at all, and neither are names of run locations, notes, etc. What is being recorded is data about how often each feature is used.
Here’s an example to give you an idea of what happens with this data. I know that less than 5% of users are using the interval timer feature. I was thinking about spending some time working on that feature when I got some requests for GPX file export support. It was easy to use those requests to make the decision to build that feature, instead of spending time on intervals, because I knew the interval timer wasn’t being heavily used.
Another feature I added is one that I created mostly for myself, but which I imagine will delight many people. About a month ago I went for a hike and I pulled my phone out to take a picture. Runtime was recording my hike in the background. When I opened the Camera app my phone crashed and restarted itself. As a result my entire hike (which was about half way over) was lost.
I felt pretty bad about this, not just because I had lost data, but because I knew if this frustrated me it would definitely frustrate other people. There’s plenty of reasons an app could close in the background. Lets say someone was going on a 12 hour hike, and their phone ran out of power at 12:01. Its not fair to them to jettison all of their data from the last 12 hours because their phone turned off. Users don’t expect for an app to lose their data, no matter what happens.
To address these issues I implemented a form of State Restoration in Runtime. Runtime will now continuously record your route and save it to disk periodically in the background while you run. If the app is closed during a run, the half-saved route is detected when the app next launches, which gives you the opportunity to either save what you have, or resume from where you left off.
For the technically curious, this feature uses a separate Core Data persistent store for the route thats in progress. That way, if the user cancels their route, you don’t have to do any management of your primary store to remove that data; you simply throw away the temporary persistent store. When the user saves their route, the objects get migrated over from the temporary store to the main one. This is a practice that was highlighted this year at WWDC which seems to work quite well.
I’m just as proud of this feature as I am some of the little UI flourishes in the app. Its something most people will never notice, but that if they do will prevent them from being heavily disappointed.
The last thing I changed is fairly minor, but bears mentioning. Initially I had the Tweet and Facebook sharing options include an @mention to the app’s Twitter account or Facebook page. I decided that this bit of self-marketing is kind of silly, and unnecessary, and so I removed it. The Facebook and Twitter sharing options should really be all about what the user wants to share: the run they just went on. I still want a way for people to tell others about the app, so I added a new “Share Runtime” option in the menu. If people like the app, they can use this to specifically tweet or post about it. I also added a link next to it for writing a review, so that if people like the app they can easily do that too.
Runtime 1.0.4 is now available on the App Store. Please check it out, and if you like it tell your friends and rate it on the App Store. If you'd like to try it for free before you buy, feel free to check it out here at app.io.