Menu

Colin Devroe

Reverse Engineer. Blogger.

Creating Summit: The current summit view

This post is the first in a series of posts about my experience building and designing Summit. This post focuses on just one view within the application; the current summit view.

The idea for Summit came nearly 4 years ago as far as I can tell. I’ve hunted around for scraps of paper, digital notes, code snippets to see if I can come up with an exact date but I’ve been unable to. And it has been fits and starts for several years.

When Kyle Ruane and I started on the idea we first thought the UI would be a bit more game-like. I envisioned a 3D model of the current mountain you were hiking that would progress the person up the summit in first-person towards each goal. This was altogether too much work, and far too difficult given my unfamiliarity with the platform. Kyle’s suggestion – again, many years ago – was to use a low poly look. He would craft a low poly representation of the summit and we could allow the user to move around in it, perhaps even spin it around, zoom in-and-out, etc.

I pulled that thread for a very short time before giving up. Remember, we started toying with the idea of Summit before Swift was released. So I was trying to draw this UI with Obj-C. Something I’m even more terrible at than Swift.

Here is what one attempt at drawing progress lines using Obj-C looked like back 4 years ago or so. I took this screenshot in June 2014 and was already labeling it “historical junk” in my files.

The red triangles were goals to meet, the blue line was your path, and the white line was your progress so far. My goal was to overlay this on top of the low poly art that Kyle drew. This was inspired by maps like this. (copied here for archival purposes)

This worked but was not that easy to pull of, introduced more complexity than we needed, and so we quickly shelved the idea until we got more familiar with the platform.

In tandem I began constructing a simple web UI to start cataloging steps from a phone. This was purely to get used to writing code that would track user’s steps, show stats, work on our step algorithm (the code that determines how far up Mount Everest a single step walking in a downtown city parking lot gets you), etc.

It went this way for a few years. I would open up a code editor and begin working on the pieces of Summit; the progress UI, the algorithm, the code to read from a user’s step count or HealthKit or Apple Watch.

In June 2017, when I picked up this project on my own to take on since Kyle had moved away, I decided I needed a simpler approach to the UI. In part because Kyle is the design genius but also in part because I wanted to get as quickly to shipping an app as I possibly could. I prefer to iterate on ideas with user feedback than to work on something in a silo for years. I wanted a way to show the summit, or some visual from the summit, but yet also show one’s progress. And I also still needed multiple goals per summit.

Here are a few drawings from this summer.

See, I’m not an artist. Admittedly, though, this wasn’t an attempt to draw anything beautiful but rather to get a general idea for all of the views I needed to pull off the layout. I needed some labels, some buttons, navigation, etc.

The long goal buttons was really “a punt” on my part. I gave up trying to get Xcode’s Storyboard feature to properly align a changing number of goal buttons (since each summit has a different number of goals) in a way that worked with each device size. It was very frustrating. So I began to go down this path of having them just be full-width, flat buttons.

But then I ran into Brian Voong on YouTube. In most of his video tutorials he suggests forgoing the Storyboard feature and using code to create the UI. Though I didn’t want to lose the progress I had made, I’m so glad that I took his advice. Writing UI directly in Swift is far, far easier (for me)  and seemingly more powerful than using Storyboards.

This revelation allowed me to go back to a drawing I did a month earlier. This one:

On the left, the elements needed, on the right, a rough sketch of a much more minimal and airy design of the current summit view. The goal buttons have varying distances between them relative to how far apart they are in real life (I’m still working on getting this right in the app).

Using Swift I was able to make this happen much easier than Storyboards.

The above is one of the very first swings at this view. It had all of the elements I wanted. And I’ve been iterating on this specific design ever since. I wish I had the hundreds of iterations saved but I don’t.

Here is what the most recent iteration looks like with goal buttons that are easier to determine your progress and other tweaks to make the UI more consistent.

This is the design for this view I’ve settled with for now. I have plans to iterate on this current design for some time before, perhaps, taking a whole new swing at it. Perhaps my skills will grow to the point that I feel confident going back to Kyle’s low poly idea. But, I’m pleased with how it has come along so far.

I can work on anything I want

One of the most enjoyable aspects of working on your own project is that there is so much to do. That may seem strange, why would I want to have so much to do? But if you look at it a different way it becomes a much more enjoyable experience.

Whenever I sit down to work on my pet project, a new iOS app, I can choose what I’m in the mood to work on. Perhaps I’m in the mood to work on the branding, editorial, licensing, or marketing? Or, would I prefer to hunker down into some Swift programming and refine the datastore, algorithms, animations, speed, etc of the app? Or perhaps I’d like to identify key strategic partners for my product launch or look through beta user feedback or do some artwork?

You see the point? Yes, there is a lot to do. And it can seem overwhelming if you allow it to be. But, no matter what type of mood I’m in I can make some progress on the project nearly every single day. And I’m having a ball so far.

Observations on building my first iOS app in Swift

In early June I decided I wanted to learn iOS app development using Swift.

I’ve made a lot of progress over the last month, building two apps that I can use on my own phone, and one app that I’m now in beta testing via TestFlight with a few friends. Over the last month I’ve made some observations on the process of building an iOS app, the Swift programming language, Xcode, iOS frameworks, and the various other bits needed to make an app. I thought I’d take the time to jot those down.

These are in no particular order:

  • Swift is growing on me rather quickly. The idea behind Swift has always interested me, but I hadn’t really given it a try until now. Like any new language you need to work with it for a time before some of the things that you may not like about it, you end up seeing the wisdom in.
  • I’m very glad I waited until Swift 3 before trying it in earnest. The tutorials I’ve come across for earlier versions make it clear the language has matured in a short period of time.
  • Using Storyboards in Xcode is not intuitive whatsoever. I know many people avoid them altogether (from what I’ve seen on YouTube). Unless you watch someone build a Storyboard you’d likely never, ever just figure it out.
  • iOS frameworks are bulky. It is no wonder so many apps are so big. Just including one or two frameworks for my very simple first app ballooned the app to over 15Mb.
  • That being said, iOS frameworks are very useful. With just a few lines of code you can get something working quickly.
  • Playgrounds are very useful to learn Swift.
  • The Playgrounds compiler can become stuck rather easily. Especially if you paste in a bunch of code from your project to mess around with and get it to work. I’ve had to restart Xcode several times.
  • Xcode has crashed on me a few times over the last month. Crashes on macOS (and also most Apple apps) are very rare. So to be working on something so fragile seems out-of-character. Especially with how simple my apps are currently.
  • Auto Layout baffles me still. I have a working UI for one of my apps that works across multiple device screen sizes. But it is far from what I’d want to ship with. I’ve watched a lot of videos on how to use Auto Layout but I still can’t make heads or tails of it. I’m waiting for the moment it clicks.
  • The connection between labels and buttons and other UI elements in your Storyboard and your Controller class is far too fragile. You should be able to rename things, delete things, move them around without completely blowing everything up and starting over. Example: If I CNTRL+Drag a label onto my Controller and create an Reference Outlet for it… I should be able to rename that Outlet without needing to CNTRL+Drag again. I don’t know how, but somehow.
  • Did I mention that Auto Layout baffles me still?
  • Building and deploying an app to iTunes Connect in order to add to the App Store or Test Flight is an entirely un-Apple-like experience. There is no Step 1, Step 2, Step 3 type of workflow. Similar to Storyboards it is not something you can figure out – you must watch or read to learn. It feels like it was never designed by a Product person.
  • Building an app that resides on a device like the iPhone is an amazing experience. While I’ve always been able to load my web apps on a phone, and I’ve built some apps that use a WebView to deploy across multiple platforms, this is the first time I feel like I’m touching my app when I use it. There is nothing that comes close to native UI.
  • Also, building an app that requires no connection to the web has been really fun. It is so fast! I’d like to move forward by trying my best to keep HTTP request at zero or as low as possible.
  • The amount of information an iOS device knows at any given time is pretty amazing. It can know (with the user’s permission) where it is, what altitude it is at, which way it is pointing, how many times the person’s heartbeat that day, what it is looking at, etc. etc. Amazing to play with these features.
  • The Xcode IDE is really incredible to use. You may not remember a framework’s properties but you can just begin typing a reasonable word and expect that Xcode will figure out what you’re trying to accomplish. Also, if you happen to write older syntax because you’re following an out-of-date tutorial, it will automatically convert it to the most recent syntax.

Overall I’ve had a positive experience learning to build an iOS app on my own. Going from having an app in TestFlight to shipping an app feels like preparing to cross a desert on foot. But, I’m enjoying my experience so I’m going to trudge forward to do so.

I hope to ask for public beta testers of the app in a few weeks or a month.