Pathify
I’ve been into running, bicycling, hiking, maps - and writing apps! - since I was a little kid. These interests come together in the form of my latest app, Pathify. I’ve used Pathify to track all sorts of adventures, but building Pathify has been a journey of its own. I have some insights to share, but first, here’s Pathify for iOS on the App Store:
What is Pathify?
Pathify is many things at once. It’s a personal location tracking app that offers total privacy. It’s also a free app, with no in-app purchases, no subscriptions and no ads (or revenue!)
I designed and built Pathify solo, and the source code is up on GitHub as a demo of my app building prowess. I learned plenty that will affect how I approach my next app. Read on for more.
Pathify is proud to stand out from the pack. It’s not a clone of the popular running apps. It’s a UX experiment that asks: what if we inverted the model of the typical activity tracking app, centering the user experience around the map, instead of just one activity at a time? What if we visually overlay past and present activities on the same map?
The second part of this vision is the timeline below the map. Pathify renders chronological activities on a timeline as well as a list, while synchronizing the timeline, the activity list, and the map. Slide the timeline, and your former position scoots along your former path. Slide the activity list, and see your activities light up one by one on the map, as the timeline stays in sync. Check it out:
With the addition of the timeline, Pathify is a new kind of map, a map with a memory.
Does it do everything every other app does, in the first version? Definitely not, but it succeeds as a minimalist tool to track your own location. If you have an iPhone, please do check it out. Over time, you may notice additional features it could use, but that’s a good problem to have.
I view the experiment as a success, a novel user experience that enables other innovations and even hints at future possibilities with XR. I have many insights, learnings and wisdom to share from this project, which won’t all fit here.
Why Pathify?
Over the years, I ran through all the popular running apps, but the same things kept frustrating me. And I wasn’t sure I could trust any of them with my personal location data.
The frustrations are many. They used to be usable in the free form, but now they are barely so, constantly nagging for signups and subscriptions. It’s now beyond a mere air of desperation; these apps are now basically interactive ads for their paid versions.
The UI of all the popular activity trackers is cluttered with features, buttons, and tons of visually heavy navigation, most of which could be eliminated with some changes to the design. These apps are visually noisy, and the experience of using them on the go in the real world requires too high of a cognitive load. It’s counter to the meditative aspect of trail running and hiking.
Neither the maps nor the apps themselves seem suited for organic trip planning. The map is often out of sight, buried within the features for activity tracking or activity review. The maps themselves are missing many trails, don’t highlight stairs if you want to seek them out or avoid them, and don’t visually distinguish a public park from a private golf course. I love running, but I didn’t love any of the running apps.
I wanted to take an alternative approach to building an activity tracking app. I wanted to build an app that is so far from a clone of a Strava or a MapMyRun that it exists in a category by itself. I wanted to question basic design assumptions inherent in basically all of them, and see where that design journey would lead.
In a world full of surveillance capitalism and a never-ending stream of data breaches, I wanted to build a location-tracking app with total privacy. In Pathify, your data never leaves the device, and there are zero social media features. Sharing can be a great and empowering thing, but sharing location data should happen in a way that puts the power back in our own hands. More on that later.
Why React Native?
I’d used React Native before and found it easy to get started with, but I was motivated to master it. I wanted a test bed where I could develop my own best practices. I conceived the project before SwiftUI hit the scene.
I came away from this experience with a lot of nuanced opinions on the scenarios in which React Native is the best fit, versus, say, an approach built around SwiftUI, or any of many other approaches for Apple and Android platforms.
But let me cut to the chase: React Native is awesome, and I would use it again, but under a tighter set of circumstances than before. For an app like this, in 2023, I would attempt to build the whole thing in SwiftUI, for many different reasons. I may yet do that with Pathify.
I was drawn to React Native originally because (1) It’s cross platform, targeting Android and iOS with a single codebase, or at least one that is mostly shared, and (2) React Native leverages TypeScript and all the web technology I spent years learning and practicing.
With sound engineering, you can produce a highly performant app that is pretty much indistinguisable from a native app in many ways. React Native is extensible and composable. You can put native components in an RN app and RN components in a native app. It’s architecturally well-designed. It’s fun to use. The documentation is good, the community is strong and it’s open source. It works.
The touted benefits are real, and of course they come with some costs. Accessibility and animation are two areas where it’s tough for RN to keep up with native frameworks. And once you look beyond the phone to the rest of the mobile ecosystem, from watches to TVs to Matter devices and all the like, you are looking at a lot of cross-talk between native and non-native sides, and the complexity of your app and your development experience starts going up.
The biggest gotcha is that React Native does not really allow you to avoid having native expertise. Far from it! It actually provides a smooth entry to gaining native expertise because you will spend a great deal of time in Xcode and the other native tools before all is said and done. You will actually end up having to understand three platforms, in order to target two (React Native, in addition to iOS and Android.)
SwiftUI, without Swift
My own approach to state management evolved to resemble SwiftUI, before SwiftUI, using React-Redux and Redux-saga to manage async side effects. Now, SwiftUI elegantly integrates state management into the platform, in a uniform way.