Ambient background image.

The work and times of the app development team at Steamclock.

Follow @steamclocksw or our RSS Feed or explore our archives.

Release Radar: WealthBar

Once upon a time, saving for retirement was daunting. People had to either pay high fees for their bank’s mutual funds, or learn how to manage their investments directly on the stock market.

Luckily for savers everywhere, there are now services like WealthBar that make this easy as pie. WealthBar invests your savings in world-class index funds, and then does the important work of keeping your portfolio balanced and healthy.

While WealthBar has been building steam for years now, they recently decided it was time to Get Serious™ about their mobile apps. While their existing cross-platform React Native apps were functional, they weren’t great. That’s where we came in.

This spring, we designed and built fully native iOS and Android apps for WealthBar. We dug in to what WealthBar’s clients were asking for in an app, then went beyond that to consider what kind of features and presentation could actually help users save more, and be more successful at building wealth. A lot of investment apps focus on the day to day – or even hour to hour – of the stock market. Evidence shows that real wealth is actually built on the long term decisions, so we designed an app with that focus.

Of course, performance and usability are paramount for consumer-facing apps like WealthBar’s, so for this project we went the full-native route. Using Swift and Kotlin, we were able to build high-performance apps that make navigation a breeze. Native development also helped us integrate well with features like Face ID and password managers. These additions make good security hygiene easier than ever.

Meanwhile, a visual refresh brought the apps into 2018, adding a bit of personality to the UI while keeping things clean and clear.

The result? Two darn good apps, according to WealthBar clients:

Well thanks, uniquenickname72526185! Of course, it also matters what the team at WealthBar thought of our work. Luckily for us, WealthBar wrote about our collaboration on their blog, extensively quoted us, and called our team “the best in the west”. So overall, pretty great!

Of course, as with any “.0” release, there is much more in store. We have some great features on the roadmap – time to get back to work. 💰

You can get the new WealthBar app on the App Store for iOS, or the Play Store for Android.

Vancouver Xcoders

On May 9 we hosted the first-ever Vancouver Xcoders! Xcoders is a speaker series about development on Apple platforms. If you’re interested in attending or speaking at an Xcoders event, we’d love to see you at our next event. We’re aiming to have one every 2-3 months.

Xcoders is the next iteration of the VanCocoa event we’ve run since 2013. While we’re still keen on providing a platform and gathering place for the city’s experienced Cocoa developers, we’ve taken a page from our namesake group Seattle Xcoders in broadening our mission to reaching out to the wider iOS and Mac development community here in Vancouver.

There are a lot of folks doing great work on excellent apps right here in town, and we’d like to bring more of that community out of their shells and offices, and into casual communication about how to make great apps.

Also, our new logo features a sweet whale – how could you resist joining now?

Saving Money by Paying for Design

When we founded Steamclock, our primary focus was development. While we did do design work when needed, our clients’ teams typically led the design effort while we focused on the software engineering side of things. Since our clients often have in-house design talent, this seemed like a reasonable way to manage costs.

Over time though, we noticed a concerning trend. Projects where a client wanted to save money by doing app design in-house turned out to be more likely to go over budget. On the flip side, projects where we also took on app design were more often on or under budget. What was going on?

Perhaps unsurprisingly, we’d learned a lot in our years of designing and developing mobile apps. Just as designers with a deep background of building web apps get better at designing web apps, designers with a lot of experience in mobile excel at designing mobile apps. This experience makes mobile designers adept at avoiding common pitfalls or complexities on these platforms.

With these lessons learned, we can often eliminate problems at the design stage before they become costly. Usability issues, “scope bombs”, failure to make use of “free” platform features, unnecessarily expensive UI customizations, and insufficient user testing are just a few problems that can be remedied at the design stage by a team that knows mobile development well.

In the same way that a designer can create a week of developer work in an hour of design time, a designer can instead save a week of developer work in just a few minutes by asking the right question, proposing a more elegant solution, or making use of a hard-won lesson from a previous app we’ve shipped and iterated.

Having learned those lessons, I wanted to share some design elements that we’ve learned to recognize as signals – flags that a proposed app design could save a substantial amount of budget from a mobile-centric design and refinement pass.

1. Non-native UI conventions

Native iOS and Android component libraries provide a lot of navigation functionality for free, and adhere to the platform conventions users already understand. If a design uses dropdowns, radio buttons, “hamburger” menus, or other UI elements that are common on the web but not ideal for mobile apps, that’s often a sign the design needs a mobile-centric revision. Even sizing can be a big clue here: when we see designs that have drawn system controls to be slightly different than their standard sizing, there’s often an opportunity to save a lot of development time with a design pass focused on making better use of the platform.

2. Flowing text

Web and print designers are used to a text layout engine that makes it easy for text to flow around images, buttons, and other page elements. While this is possible in native apps, it’s often a lot more work than in web apps, and is a common signal that an app was designed with a web or print mentality.

3. Novel navigation

Some apps, such as Snapchat, distinguish themselves with a novel navigation scheme. Most often, however, it’s best to leverage users’ familiarity with native tab bars and drilldowns. Luckily, there are a lot of engaging ways for an app to distinguish itself visually from the competition without incurring great usability and discoverability costs.

4. Offline sync

Having built apps for eight years, we’ve seen almost every kind of requirement you can imagine. By a significant margin though, offline sync capability is the most frequent feature we see proposed for 1.0 that is best deferred to later. This is sometimes truly needed – for example, an app that is primarily used in the wilderness – but it comes at a substantial cost when you consider the additional development and design work to handle conflict resolution, error handling, sync status reporting, and all the other details that come out of a bullet point as simple as “offline mode”.

5. Welcome tours

A common issue we see in designs proposed by teams that are new to mobile is attempting to mitigate overly complex or unclear functionality by offering a “tour” on first launch. While it may seem like less work to throw up a tour before folks start using your app, text-filled screens are typically glossed over or not retained. Given that, tours don’t tend to fix most usability problems, and the work required to make sure every interaction is clear and understandable will still be necessary.

Shipping better apps

All that said, no matter how new your team is to designing mobile apps, you surely have a huge amount of insight and product knowledge to offer the process. Designing a new app is all about collaboration, especially for teams with a background in print or web work. If your app design work is hitting any of these issues, we’d be happy to help bring them to the next level!

Return of the Map of the Internet

Four years ago, we built a 3D map of the internet for Peer 1 Hosting. That was a really fun project – it’s not every day your app is featured on CNN. With over 100,000 downloads and an average rating of almost 5 stars, the Map of the Internet was one of the most-loved apps we’ve built. The visualization was used in various other mediums, including an exhibit at London’s Science Museum. It was really cool.

Soon after the app’s launch, our client Peer 1 was acquired by Montréal-based telecom Cogeco. It seems the key to getting your company acquired is launching a cool app with Steamclock! In the resulting shuffle though, the app got out of date, and eventually it disappeared from the App Store.

When the app went “out of print”, so to speak, we got a surge of fan mail about it. Folks wrote in from around world, asking for information on the data, permission to use the visuals in other work, and whether the app would return. We also got some requests to open source the code, so people could help update the data and continue to support new OSs and devices, which was great to see.

Well, we’re glad to announce that we’ve teamed up with Cogeco Peer 1, who have been great to work with, and brought the apps back to life!

This fall we brought Map of the Internet up to date to support iOS 11, iPhone X, and current versions of Android. The updates are now live on the App Store and Google Play. The new apps feature new data through 2017, and some UI updates and refinements over the original versions too.

Even more exciting is that the folks at Cogeco Peer 1 have agreed to open source the apps! Now, community members can check out the internetmap github repo, propose improvements, and submit pull requests. If you’re down with Objective-C++, we have the project for you! 😘

Thanks so much to the folks at Cogeco Peer 1 for making this project possible, and for all the fans of the app who wrote or tweeted that motivated us to get this done.

Bluejay: Reliable Bluetooth in Swift

Building apps that reliably talk to Bluetooth hardware can be tricky. Apple’s Core Bluetooth APIs are pretty low level, and they offer enough flexibility to really make a mess if you’re not experienced with Bluetooth. We’ve built a lot of Bluetooth apps in recent years, ranging from medical apps to solar lighting apps, and learned a lot about what does and doesn’t work well with Core Bluetooth.

Using those lessons, we built a framework for building reliable Bluetooth apps. We call it Bluejay, and its first public release is now available! 🎉

Bluejay is a simple Swift framework for building Bluetooth LE apps that are reliable. It makes properly queuing Bluetooth communications easier, helps coordinate background operations, and takes advantage of Swift idioms with a callback-based API.

We’re staying modest by numbering this week’s official public release 0.1, but Bluejay is already working in three apps we’ve built for our clients, so with luck it will be a good fit for your apps too. We’re going to keep iterating and are open to the community’s input as we move towards a 1.0 release.

We’re eager for feedback, though of course Bluejay is MIT-licensed, so code contributions are encouraged but optional. If you do build Bluetooth apps, or are even just curious, we’d love for you to take a look and let us know what you think!