RubyMotion Success Story: Temple

Temple is a new approach to monitoring and logging your fitness and daily routine. Instead of focusing on mundane details - which many people don’t want to bother entering in - Temple takes a UI-first approach to entering workout and food information.

Temple is the brainchild of Todd Werth and Ken Miller, of InfiniteRed. We decided to sit down with them to learn more about their story.

Can you tell us a little bit about your startup, InfiniteRed?

InfiniteRed is located in San Francisco and was founded by Todd Werth and Ken Miller in April of 2013. We had worked together in the past and discovered that we saw eye-to-eye on software design and philosophy, and decided to create a company that was based on an honest relationship with the people who use our software. We’re trying hard to avoid outside investment or advertising, at least as our main priority, because those things tend to take away from giving the customer’s experience top billing.

We’re thrilled to have a real app, in the App Store, that real people are paying money for, that’s almost 100% Ruby!

Temple definitely embodies that philosophy; it’s unlike any fitness app I’ve seen before!

We’re incredibly proud of Temple, but believe me, it’s just the beginning. We have more product ideas, as well as some open source contributions to announce in the near future. We also take on select clients from time to time, so if you have an idea, feel free to drop us a line.

What are your backgrounds? Are you designers-turned-developers? The other way around?

Todd Werth: I’m fairly unusual in that I’m both a graphic designer and a programmer. I’ve been in San Francisco building products professionally for 16 years. Earlier in my career I was a consultant doing hard-core architecture and programming in everything from Delphi, to Java, to c++.

I then moved into the startup world and focused on UX, design, and front-end, which suits me best. When I write a low-level library, I create a logo first, which is kind of absurd if you think about it, but art and engineering are different shades of the same color to me.

Ken Miller: Professionally I’ve been around since the Dot Com boom in the late nineties, doing mostly backend Java and Ruby and leading teams for the last 10 years, but I’ve been into computers practically my whole life.

My dad is a scientist turned programmer, and my mom is a scientist turned artist, so I guess I just merged all that into a love of making beautiful software. And for me that means both how it’s designed—how it looks and how it works—but also the quality of the code itself. As a backend guy, that’s where I have most input, and that’s why I’m so mad for Ruby: its combination of expressiveness and a sort of practical humility is unlike any other language I’ve tried, and I’m the kind of guy who learns new languages as a hobby. I was an early adopter of Rails, but obviously mobile is a huge part of the future, so when RubyMotion came out, I was ecstatic.

What was the inspiration behind building Temple?

TW: I’m into health and fitness, and I couldn’t find an app that I liked. Most were too complicated [KM: I cook a lot, and I’d end up weighing my broccoli], or had poor design, so I thought up the basic idea of Temple, then Ken and I designed and built it.

The concept is simple, when you do something during the day which is health or fitness related, just tap the portion that’s closest. So if you eat a banana, tap “snack”. If you drink a tall glass of iced tea, tap “bottle”. What you give up in precision, you get back in sustainability and consistency. Then you can track your progress over time. We start our customers out with Fitness, Fluids, and Fuel, but it’s completely customizable, so you can use Temple for any goal you have.

Why did you choose to use RubyMotion over traditional iOS development tools?

We both like Ruby a lot, but more than that, it’s that we’re both pretty die-hard fans of a console-based workflow. We’d rather grow the language to express what we want than rely on an IDE, and we just fell in love with the workflow. Being able to tweak values from the console and see them live is amazingly powerful, much more so than drawing a static, lifeless version in Interface Builder.

What aspect of building your app was the most challenging, and what was the most enjoyable?

Most challenging for us was just that we were learning a whole new platform almost from scratch, and there’s a fair bit of learning curve there. Core Data in particular gave me fits at first, but I like it now.

The most enjoyable… There’s the point where the whole system starts to “click” and you can start riffing, refactoring, teasing out the shared structure, and turning that learning into libraries that will let us, and hopefully others, go faster next time. That’s the real joy of programming for me. But now that the app is out, the positive reactions from users is really what keeps us going.

Were there some open source tools that helped you build your app quickly?

KM: Does Vim count? I’ve been using it for 20 years, so it’s pretty baked into my fingers at this point. BubbleWrap and Teacup got heavy use. We had some performance issues with Teacup, especially startup time, but in terms of its basic mode of interaction, keeping sets of inheritable properties and having fine-grained control over your views, I can’t imagine making an app any other way now.

We’re actually working on a couple of our own, to be announced shortly.

TW: Like Ken said, Vim would be #1. When I’m not in Photoshop or Omnigraffle, I’m in Vim. In Temple we used Teacup, Bubblewrap, and MotionSupport, which all worked well for us. I started developing RMQ (RubyMotion Query - to be announced) in Temple, it’s using about half of it at this time. In the future, for front-end stuff we’ll be using RMQ.

What advice do you have for people who are building apps today?

Start small and get something you can stand behind as quickly as possible. Promoting it is going to be at least as hard as writing it in most cases, assuming you’re going it alone, and you want to get started on that as soon as you can before you invest more time in coding. That’s part of the beauty of RubyMotion. We’re able to move so fast that we can cut down the time from idea to execution and then test it in the market as soon as possible.

What tools would you like to see added to the RubyMotion toolchain?

KM: Integration with Instruments would be nice. So rake profile:simulator would bring the app up connected to Instruments from launch.

TW: I love RubyMotion, however I’d love to have full integration testing built in. Also, exception reporting has sometimes been less than helpful, so we’re excited to see the changes in 2.5.

Thanks guys!