The ribl iPhone beta is live! Here’s what we learned building our iOS app

This post was originally published on ribl.co.

We’ve released the private beta version of our iOS app! It’s great to get our iPhone app out to a bunch of test users after a few weeks of hard work.

iOS and Android are the top two mobile operating systems and companies really need a presence on both platforms to be successful. Though we built ribl for Android first, we certainly knew that developing an iOS app would be extremely important.

Throughout our iOS development process, we’ve been able to move fast, squash bugs, and iterate quickly. We’re really excited to expand our user base to find out more about how people will use ribl and what they think of the app.

Here’s how we cranked out our iOS app and what we learned along the way.

Hiring of iOS developer Robert Chen

While our current team had plenty of iOS expertise, we were still iterating on and improving our Android version, so we didn’t have enough time nor resources to dedicate to developing ribl for iPhone. So we started a search for an iOS developer.

That’s when we found Robert Chen, our newest team member.

After ditching plans for medical school, Robert jumped into the technology world by learning software development by himself, which is pretty amazing.

He started his technology career as a Network Administrator for Terrapin Systems. He then learned mobile software development using the Appcelerator platform at Clearly Innovative, a DC-based mobile development agency.

At that point, Robert realized that he wanted to focus more on native iOS development. Lo and behold, the timing was perfect and we brought Robert on as our iOS developer.

Robert has been working really well with our other developers Jeff and Dan and has done a great job building our iOS app. He’s been a welcome addition to the ribl team.

Major differences between iOS and Android

Android and iOS are very different animals. Each platform has its specific design standards and guidelines to which we need to conform, and both take different approaches to app development and testing processes. Here are the major differences we encountered.

Different user interfaces

The first major difference is that the user interface guidelines of each platform are pretty distinct.

Check out these screenshots of the ribl story feed screen:

You can see that the user interfaces are almost completely opposite. On iOS (left), the Browse and Explore buttons (circled in red) are on the bottom, while on Android, they are on top. The Create Story button (circled in yellow) is static on the top right corner for the iPhone, and on Android, it’s floating at the bottom right corner and actually disappears when you scroll down the feed. And the Settings buttons (circled in blue) are on opposite sides of the screen.

These contrasting design guidelines definitely kept us on our toes when developing and testing for each platform, and we had to take them into account for each and every screen we built.

Use of Apple Maps vs. Google Maps

Google Maps was really easy to implement into the Android version of ribl, but it made a lot of sense to use Apple Maps for our iOS app.

First, even though Google Maps is the most popular map app in the world, iPhone users would likely be more familiar with Apple Maps since it’s the default mapping service for iOS. We wanted to provide an interface that makes sense to the users of each operating system.

Additionally, Apple Maps uses MapKit, which is native to iOS, so the implementation is simple and stable. We tried to avoid using third-party libraries as much as possible to maximize the stability of the app.

There was one snag to using Apple Maps.

As you can see above, the stories on the map view are clustered together (the circles with the numbers in them) for better organization and visibility. Otherwise, you would see many pins overlapping each other, which would be pretty ugly.

Google Maps had an extra library that provided this clustering, so we didn’t have to create any extra code for this to happen.

On the other hand, Apple Maps had no such clustering library so we were forced to use a third-party, open-source option. However, that library was written in Objective-C, the older iOS programming language, and not Swift, the more recent language that we used, and it had some performance issues. Robert rewrote the library in Swift, which improved performance but introduced new bugs, which Rob had to fix.

The map clusters on iOS took a bit more time and effort to achieve than with Android, but the end result was a consistent ribl experience that still felt native to the platform.

Different test processes

The test processes for the iPhone and Android apps were a bit different as well, from both our and the end user perspectives.

For iPhone, we actually had to have the test version of our app approved by Apple, which took a day or so, before we were allowed to send out invites to testers. For Android, there was no approval process necessary on Google Play, and we were able to invite testers within a couple of hours after submission.

The process of sending out the emails to testers for each app store differed a bit. For Android, we had to create a Google Group and copy and paste a list of emails separated by commas to send out the invitation to test. With iOS, we could upload a CSV file with everyone’s first name, last name, and email address, which required a little less time and effort.

The nice thing about iOS was that the email to which the invitation was sent didn’t have to match the tester’s Apple ID email in order for the tester to access the app. With Android, the email address had to match the Gmail address being used on the tester’s phone, which caused a couple of issues and necessitated some resending of invitations.

For Android, we were able to send testers a message that included instructions on how to access the app; the iOS process didn’t allow for that.

The end user’s experience diverged as well. With Android, you would click two links and you’d have the app on your phone. With iOS, you have to first download another app called TestFlight and only then you could download the ribl app to your phone.

As you can see, both platforms have their own unique processes and guidelines which we had to take into account when developing and testing our apps.

Want to help us test?

If you’re already helping us test either version of our app, thanks!

If not and you’d like to help test our iOS app, please fill out this form and we’ll invite you to test.

If you’re an Android user, head over to Google Play to download our app!

Conclusion

It’s been a fun and interesting process developing our iOS app. Robert has been a great addition to the ribl team and we learned a lot about the differences between and challenges of developing for both Android and iOS.

We’re really excited that our iPhone app is in the hands of users and we’re eager to learn more about how people are using ribl.

Please let us know what you think about our process, our app, and anything else in the comments.

And if you enjoyed this post, please recommend it!

Thanks for reading!