Trying out Blogo.
Trying out Blogo.
Apollo is built by a former Apple employee with feedback from thousands of Redditors to sculpt the best client possible. It features a beautiful, native iOS design, smooth, customizable gestures, fast loading pages, a supercharged Media Viewer experience, a powerful, full Markdown editor, a Jump Bar for lightning-fast navigation, and so much more. You have to see it to believe it.
This is easily one of the best iOS apps I’ve ever used. Even if you don’t use reddit often it is worth having for wasting time on reddit.
One of the great things about iOS 11 is the multitasking capability, and with it the emergence of so-called ‘shelf’ apps.
I had never heard of the term “shelf apps” until I read Des’ post.
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.
Random iOS 11 bug: type 1+2+3 quickly in the stock calculator app, see what happens. Bet it won’t say “6”.
Portrait video compilations made easy—that’s what SnapThread is all about.
Like SnapChat without the network. I’ve long held that SnapChat and Instagram have the best UIs but it is a shame they aren’t just an app. Apple tried to solve this with Clips but that is only square-crop. This app could be very useful.
Introducing Microsoft Edge for iOS/Android and Microsoft Launcher for Android, two apps designed to make it easy to move what you’re working on between your phone and PC.
Great move. Likely tons of Surface users that also have iPhones and definitely have Android devices.
The Launcher is an interesting move. I’m anxious to see if they continue to improve it. Facebook made one years ago and gave up on it in very short order.
iPhone users, well, there’s still great stuff there—Do Not Disturb When Driving is going to make the world safer—but it’s a bit less of a world-shaker.
Not a world shaker? This isn’t a ho-hum, hum-drum update for iPhone. This is going to save a ton of lives, injury, heartache, and money. I wish every single review led with strong advice to turn this feature on immediately.
I cannot stress enough that people turn this feature on today. Please please please.
Tom Dale, Senior Staff Software Engineer at LinkedIn and co-creator of Ember.js, in a post where he argues that compilers are the new web frameworks:
Native code tends to have the luxury of not really caring about file size—a small 40MB iOS app would get you laughed out of the room on the web. And AAA game titles accept minutes-long load times in exchange for consistent 60fps performance, but I shudder to think what a 30 second load time would do to the conversion rate of your e-commerce site, 60fps or not.
While I agree with most of his post, that compilers are becoming increasingly more a part of a web developers workflow and thus becoming very important to learn, this particular bit isn’t a fair one-to-one comparison in my opinion.
Web apps do not need to pre-load every single asset onto the device prior to running. If you were to weigh a fully native app next to its counterpart web app* you’d likely get a very similar result. It is just that a native app is downloaded mostly all at once and a web app can be loaded as needed.
But his point remains, more and more web apps are looking more like native apps. They are compiled, loaded, and completely obfuscated from the source code they originally started out at. I’m not sure if I feel this is good or bad for the web. But I do know that the barrier to entry in web development is higher than ever.
* Most web apps that have a direct counterpart on a mobile platform share lots, if not all, code these days so these comparisons are getting tougher and tougher to do fairly.