One of the first music streaming services and the #1 radio network for electronic music fans, Digitally Imported’s laser focus on UX and mobile quality helps them retain their competitive edge and keep users coming back for more. The team has grown from one developer and one app to a global team supporting five (near five-star) music genre apps, available on Android and iOS, and millions of users.

Today, we’ve invited Jo Friedman, DI’s VP Product Development, and Andrew Simpson, DI Mobile Architect, to share how their technology choices and mobile DevOps processes, including Visual Studio for Mac, Xamarin Test Cloud, and HockeyApp, free their extremely distributed team to collaborate, hand off work, ensure high quality with every commit, and release updates every two weeks.

Tell us about your company and your roles.

[Jo Friedman (JF)]: Digitally Imported creates 100% human-curated radio experiences, and our flagship product DI.FM has streamed electronic music to fans since 1999. In addition to DI.FM’s 90+ unique electronic music channels, as a company, we’ve expanded to even more music genres, and now offer five different streaming services (Rock, Jazz, etc.).Digitally Imported on iPhone

Our customers are music lovers who want to listen to the newest, best music in a “lean-back” radio experience. To make this possible, our staff and volunteer music enthusiasts (spread across the globe) sort through and select content submissions, so we play only the best music on each channel.

As DI’s VP Product Development, I manage and prioritize our development, UX, and QA teams for all of our web and mobile services, and I’m constantly identifying ways to enhance the listening experience and roll out new exciting features to our listeners.

[Andrew Simpson (AS)]: I’m a Mobile Architect, and my main role includes helping create technical requirements and implementation specs for new features, sharing and ensuring we uphold development best practices, and developing our apps alongside the rest of the team. We’re a small, fully remote team, split across eight time zones and ten countries, and we’re always improving our multiple apps: adding great new features that our users want or fixing any bugs.

[JF]: While I’m not a developer myself, I’ve worked on product management, user experience and product development teams for my entire professional career (20 years!), creating and bringing mobile apps to market since the earliest “smart devices” in 2000 (Palm Pilots, then pocket PC’s and J2ME or BREW devices, years before the iPhone).

[AS]: I’ve developed software professionally for over seven years. I instantly fell in love with programing in high school, and, after getting my Bachelor of Computing Honors degree, I joined a boutique app agency. I learned mobile development for BlackBerry OS 3.x (which was the “smartphone” at the time), and clients were soon requesting iOS and Android apps. It was a fairly small company, so I had to learn to develop native apps for each platform: a fantastic and challenging experience.

Tell us about your apps and what prompted you to build them.

[JS]: Our apps are all about enabling listeners to listen to the best music available in their preferred genre and style. We provide a very deep experience; I mentioned this before, but rather than offering everything and relying on users to find songs, our music is fully human-curated.

Music listening and mobile go hand-in-hand. Today, somewhere around 60% of all music streaming is done from mobile (Spotify for Brands report, 2016). We’ve seen a major shift over the last five years, with over 50% of our users currently experiencing DI for the first time via mobile. We have over nine million app downloads, and mobile accounts for a large percentage of our revenue.

Why did you choose Xamarin?

[JF]: In 2015, it became clear that we needed to develop Android and iOS apps for all of our music services, and to do it quickly, but our team was almost entirely web and backend developers.

Digitally Imported on AndroidOur one (very talented) mobile developer suggested Xamarin, because it would make the most of our small resource pool and allow us to share as much code as possible across platforms. Today, we’re actively developing five Android apps and five iOS apps with Xamarin, and we’ve grown the team considerably.

[AS]: While I wasn’t on the team, I started looking at Xamarin for this position, and immediately saw the appeal. I’d always loved native development; having 100% control over what you can do with the app and device is great. Even though it takes a lot of extra, duplicative effort to ship apps for both platforms, I’d found it worth it to get a great end product.

Xamarin was an easy win to me: I knew Obj-C, Java, and C#, and Xamarin gave us access to native features, while code sharing reduced the effort. Between a single platform (Android or iOS), we’ve architected our apps to be very similar, with only 10% of the “look and feel” code different across brands. But, Xamarin allows us to do something unique: share business logic across platforms. For reference, we currently share over 20,000 lines of code, or 40% of our total code for each platform, across all of our Android and iOS versions.

What does “native app” mean to you?

[AS]: An experience that tells you “this is a quality app,” not a mobile styled website. As a developer, this means: (1) uses core platform features to the fullest extent (2) properly takes advantage of built-in hardware and operating system frameworks and (3) renders a UX with smooth animations and instant UI feedback.

I used to think “native” equaled writing from scratch for each platform. Xamarin surprised me: full access to underlying OS features, just as if you were writing an Android app in Java. Every function and feature was there and ready to be used immediately.

We integrate with things like Bluetooth and create efficient media systems, and our customers appreciate our high quality audio. Not only are our users happy with the performance, other developers are surprised to learn that our apps aren’t “truly native” (i.e. written from scratch for each platform in Obj-C and Java).

How did you get up to speed with cross-platform mobile development?

[JF]: Most of our developers had some exposure to cross-platform mobile development before they joined the team, whether Xamarin or another platform. Regardless, getting up to speed has been very quick, and our new hires are typically productive within a few weeks.

In an extreme case, a Mobile Architect candidate learned Xamarin in seven days! We had a one week break between his initial technical interview and his hands-on lab exercise, and he went from no experience to coding his lab with Xamarin—successfully earning him the job!

[AS] … I wonder who that could be…

I have a history of learning new programming languages, starting with Java and C in University. I really cut my teeth on Java with BlackBerry; I still remember implementing String.Split() (it didn’t exist in in the early versions of BlackBerry’s Java). Around the same time, I learnt C#/ASP.NET to build our apps’ backend API services, and, from there, I taught myself Objective-C. I shipped my first professional iPhone app for iOS 3.1, and from there, I developed my first Android app (targeting Android Cupcake 2.3). I’ve also written Windows 10 and Windows Phone apps with C# and XAML.

Describe your development process.

Digitally Imported on Android 2[AS]: We have Mac and Windows users, based on personal preference, so we use Visual Studio Tools for Xamarin and Visual Studio for Mac. Architecting our codebase with Xamarin has helped increase code reuse and reduce duplicated effort.

We automate as much as we can. Our developers pull bugs or feature requests from our “inbox” stack and work on a separate branch, and every line of code must pass a round of peer review and QA before being accepted into the master branch. Once a developer thinks an issue is fixed, or the new feature is working, the pull request triggers a code review with another member of the team, and the original developer either gets the greenlight to move to QA, or makes any requested changes and kicks off another round of code review.

We’ve set up Xamarin Test Cloud to augment our manual QA processes; each push kicks off unit tests and UI test suites. Xamarin Test Cloud runs through the “important” user behaviors and stories for every app, and testing the same steps on many different devices, capturing screenshots, and seeing stack traces adds peace of mind.

At the same time, our CI server integrates with HockeyApp to build, upload, and distribute all five brands’ apps builds to our QA team to for internal alpha/beta testing on their devices.

If all tests pass, QA manually reviews to ensure features meet the expected deliverables and no bugs were introduced. Once the change has passed code review, automated testing, and QA, we merge into master.

After we’ve accumulated a fair amount of changes, we double-check the branch, and ship to our users, usually once every two weeks.

I’ve played around with the Visual Studio Mobile Center Preview, and I’m looking forward to having everything fully integrated.

How has Xamarin helped you get high quality experiences into your users’ hands?

[JF]: Xamarin helps us bring new features to market quickly. We’ve structured our team with iOS and Android specialists, with one specialist leading development for a new feature on one platform. While new features are ready for one OS first, the second developer already has 75% of the development work complete and can quickly build for the other platform. This saves time and uses our team’s resources efficiently, allowing us to deliver high quality experience to all of our users.

What have your users said about your apps?

[JF]: Our listeners love our apps, particularly: our channel diversity, ease of streaming, and our intuitive features.

We consistently get high ratings in both iTunes and Google Play, and this recent feedback summarizes what we hear fairly often:

“Perfect, curated music from all electronic genres. I use this predominantly over all other services, as I can be sure whichever channel I choose, usually trance and deep house, the content will be a divine blend of new and old, and never hear any annoying repeats.”

Harry A., June 13, 2017

[AS]: App quality is super important to us, and we pride ourselves on our highly rated apps (4.5+ stars). We always want our users who to have a great experience, and we work hard to make sure that we’re producing high quality apps.

Have you accomplished your goals?

[JF]: We’ve built a quality listening experience: beautiful, usable web and mobile apps across five music genres. This is a great accomplishment, but we’re always striving to meet new, bigger goals, from offering more music and new ways to listen to delivering better usability, performance and user experience.

We have many, many things that we want to build to create the ultimate listening experience. This will involve a much bigger focus on personalization…

[AS]: In addition to building new features, we’re planning to do more public betas. Today, we have a few savvy, invested users who are hugely helpful in testing our pre-release versions and making sure we’re ready for general release.

What advice do you have for mobile developers who are just starting out?

[AS]: The problem isn’t that there aren’t enough good resources, there are far too many good resources! From free university lectures to endless documentation from Apple and Google’s official websites to podcasts, free ebooks, and more. It’s easy to get bogged down, and think you need to know it all before writing your first line of code.

In my experience, being personally invested and interested in your project is the absolute best learning tool. From there, just try to build it. Obviously, when you’re just getting started, limit yourself to something small and achievable, but nothing helps me learn faster than trying to make something work. When I get stuck, I can go look for specific answer, solve my problem, and keep coding.
 
 
Visit xamarin.com/download to get started and explore xamarin.com/customers to get inspired.