Email me course alerts
You'll soon be able to view this page in a print-friendly format

Android and iOS App Development, an Interview with Daniel Bradby


 

Interviewer: Tim Martin, December 2013.  Episode #04 from the NET:101 podcast.

 
 

Podcast Transcript

 

TIM: Welcome to another episode. With me today I have Daniel Bradby, who is the Director/Co-founder of jTribe, who builds apps.

 

DANIEL: Hi, Tim.

 

TIM: Welcome. Now, tell us firstly, bit of background story of jTribe, how that came to be and what it does.

 

DANIEL: Sure, jTribe builds apps for clients. As soon as we could, as soon as the App Stores opened and Apple said we could start making apps and Google said we could start making apps for people, we started building apps and putting them on the stores. That’s been a journey of about 5 or 6 years since that’s opened.

 

TIM: So solely apps, across iOS and Android?

 

DANIEL: Yeah, definitely. We chose to look at both of those platforms. In the early days, there was murmurings about “why don’t you build something on Blackberry or Windows Mobile?” But we’re focused on those two platforms. I think that’s been a winner for us.

 

TIM: That process of building an app, we’re going to dig down into that in a minute. But just generally speaking, what does jTribe do? Do agencies who build apps all fundamentally do the same thing, or…

 

DANIEL: A digital agency, a full-service digital agency might actually take you through right to a marketing process when you build an app as well. We really focus on taking a concept and submitting it to the store. But in terms of nurturing a business model or a marketing aspect around apps, that’s probably not our strength. Our strength is delivering complexity through simple user interfaces on mobile platforms.

 

TIM: Right, okay. Now, what I want to get into today is a scenario where an organization wants to increase their visibility, online or just generally speaking. An app is now an option. They may have somebody from upstairs that thinks it’s a great idea to get an app, or maybe they found a use case for an app. What do they do? Do they just go into the app pages and try and find app developers and sit down? How does this work?

 

DANIEL: Yeah, generally we get approached by a lot of organizations who have got I guess an idea, where they’ve thought “I’m using my phone; how could I use that in my business or how could my clients use that in the way they interact with their business?”

So generally, we get a lot of people, a lot of very diverse businesses reach to us and say “We’ve got an idea for an app that may be useful for our clients. Can you help us build it?” Obviously the first question is how much does it cost. I think there’s a lot more to talk about before we get to the cost. It’s about process and doability and business case validity and all those sort of things.

 

TIM: Or maybe how much does it not cost? If I turn up and I’ve got $2,000 in my pocket, am I going to get an app?

 

DANIEL: No. You could if you went overseas. Generally, for us, apps are complex. They look simple, but for an app that actually provides value and is interesting and worthwhile doing as an exercise, apps are going to at least cost $5,000 to $10,000 at a starting point.

 

TIM: Okay, I’ve got this great idea for an app. Maybe I could monetize it, maybe there’s going to be fantastic value add for my community, my members, clients, whatever it may be. To what extent do you put the sanity filter in place? If I came to you and I’ve got lots of money – that’s not an issue, but I’ve got fundamentally a bad idea for an app, is it your responsibility to tell me that?

 

DANIEL: Look, it’s not, but we certainly do ask a lot of questions that I think perform self-realization on that for a client. When someone comes to us, we start with a conversation and just go backwards and forwards about what they’re trying to achieve, what they want to build, what are the features they want to build.

Then we guide them through a process of putting together a pretty simple two-page brief. We’ve got a form on our website where we ask questions that will get them thinking and questions that we need answers to so we can actually respond to that brief. Some of those questions really tease out “Do you have a business case for what you’re doing, or do you just have too much money and an idea that you thought up on the couch on a weekend?” We really want to make apps that do actually provide value for the people we’re building them for and have impact.

One of our values at jTribe is impact, so we evaluate any of the work we do against that. So if someone approaches us with an app that is essentially “We’ve got a website; we’d like to have an app that has all the information from our website,” we’d probably shy away from that, or advise the client “Perhaps you’ve got some different aspects of your business that you want to use the mobile use case for a bit more.”

 

TIM: Yeah, it would be a mistake to just try and replicate your website in an app format.

 

DANIEL: Absolutely. In fact, there’s heaps of reasons why you wouldn’t do that. The best thing about having all your content on your website is it’s searchable, as you know, Tim. But when we see a lot of people trying to put a lot of content within apps, we say Google’s not going to find that. When people are trying to find your business or search for something that you provide, they’re going to Google it, and the content within your app doesn’t actually get found by Google. All that content just stays within that app itself.

 

TIM: What can an app do that a website can’t do?

 

DANIEL: That’s when you need to think about the people that interact with your business or your organization, what do they need to do and how do they need to interact with your business when they’re mobile, when they’re out and about, when they’re not plugged in next to a power point? Maybe they’re moving between the car, maybe they’re on the public transport, just mobile I guess in general.

A lot of good use cases get teased out of just thinking at it from that point of view. If you’ve got a whole product around CRM, say, perhaps replicating a whole CRM tool on the phone is not a great idea. But what do salespeople need to do while they’re mobile with the CRM? Perhaps they just need to quickly look up a customer’s phone number, or perhaps they need to quickly update the status of a CRM lead or something like that.

So really thinking about what snapshot of your whole business process makes sense for your customers in a mobile use case.

 

TIM: As somebody out of a marketing space, how am I supposed to know what my options are? Obviously I don’t know what I don’t know. Do you find a level of education – if somebody comes in and they’ve got a fairly good use case for an app, and it all makes sense, but there’s features or functionality they didn’t even know existed.

 

DANIEL: Yep. Perfect example recently is we had a council approach us with some really adventurous ideas around augmented reality for some things they wanted to do. We think those things are great, but we had some other ideas that we thought we could present them as well. So we really do need to respond and say “Okay, augmented reality in your use case is perhaps a bit adventurous,” but we wanted to present them with some other alternatives as well.

So that’s why the conversation, the face-to-face stuff, is really important for us. We actually go out there, talk to them, listen, hear about what they’re really trying to achieve, not just hear about the features, and then we can actually propose solutions that are probably maybe a bit more cost efficient.

Anything that we can implement in an app that’s I guess out of the box, as opposed to doing something hyper-custom, is so much more efficient for everyone involved.

 

TIM: On my website, built Ruby on Rails, there’s gems essentially that the work has been done by somebody else before. We don’t have to reinvent that wheel. Essentially just plug it in. That sort of dynamic plays out within apps?

 

DANIEL: Yeah, there’s a lot of out of the box stuff you get from Apple or Google as part of their platform, but there’s a lot of third party components that we plug into and use as well that are actually quite powerful. For example, things around computer vision, detecting shapes and objects. People don’t know we can actually plug that in and use that stuff and do some really interesting things, pretty much for free.

 

TIM: You have some clients that would want to monetize their app, no doubt. So it’s not a service for their members or their customers; they actually want to go out into the marketplace and they want to sell it for 99 cents or $29, whatever it may be. Does that pose a different level of challenge?

 

DANIEL: Definitely, definitely. We really don’t often see the building of a spoke app having enough payback to sell a 99-cent app. There’s a lot of work beyond just the initial development to actually support an app beyond 99 cents.

Making an app that you want to sell directly in the store firstly involves giving 30% of that away to the Apple platform or to Google, as I guess a privilege of being on their platform. So you keep 70% of those revenues. And then you need to think about how you actually want to keep users engaged and keeping them perhaps purchasing items.

The most common way for people to make money with that sort of paid model in the store is with something called in-app purchase. That’s when you give the app away for free, you allow someone to use it, show them some cool features, but at some point they may want to get some more value out of it. That’s perhaps when you suggest “Okay, for $1.99 you can unlock some more cookbooks or unlock some more features of the app.”

I think that’s a model that does work. What doesn’t work is when clients come to us and want to make a completely spoke app and sell it for $2.99. It’s not going to pay back enough money for the investment you’re going to pay into it.

 

TIM: So we’ve got a paid app, we’ve got in-app purchase. Is advertising an option?

 

DANIEL: Not really. We’ve tried it ourselves just to make sure it doesn’t work. We’ve seen clients use it as well. Putting ads in your app doesn’t give you the payback, really, that you need. The most successful apps we do are apps that provide an alternative channel into an existing business model for a customer’s clients. That’s when it really, really works.

 

TIM: Now, do I have to be around both Android and iOS? I’ve got the idea for my app, it makes sense; do I have to pay twice to get it across those two platforms?

 

DANIEL: In a way, if it does make sense. It depends on your demographics of who you’re building the app for. Android users and iOS users are different. There is some overlap between them, but generally these days, we build an app for both Android and iOS. We do build the app essentially twice.

What we see is if we build those apps in parallel, at the same time, we get efficiencies, because we understand the business flows, we’ve done the analysis, we know how to connect to your databases, all of those things. So if you build for one platform, generally the other platform takes perhaps 80% of the time of the first one. If you’ve spent $100,000 for your iOS app, you’ll spend $80,000 on your Android app, or vice versa. If you build them in parallel.

 

TIM: Wow, that could add up, though.

 

DANIEL: It does, it does. And that’s why you need to think carefully about who you’re trying to support. There is also a lot of misinformation, I guess, or misguided information out there about the two platforms.

To be clear, in our organization at jTribe, I really take the role of the Android advocate. My business partner Armin takes the role of the iOS advocate.

But we see a lot of stats out there that say that smartphone sales, Android is outselling iPhones by a lot. We know the reality, the most important feature is actually how engaged those user are in your apps. And what we see is that iPhone users are four times more engaged than Android users. So for every four users of your iPhone app, you’ll see one use of your Android app. That’s not too bad, but it’s just the realities you need to be aware of when you elect “Okay, I’m going to build on both platforms.”

There is also the cost of I guess unhappy customers if you don’t build on that platform. Okay, you may get that less engagement, but imagine you’ve got your group of customers and you announce to everyone one day, “We’ve built an app. Here it is on iPhone.” You’re going to very much annoy those 30%, 40% of your users who are on Android.

 

TIM: I know the ABC annoyed a lot of people, including me, on a few occasions in that their iView app, their most popular app, brilliant app by a country mile, for a number of years – literally years – was only on iOS.

 

DANIEL: Yes. Yeah, I was exactly about to bring up that example. It caused a lot of pain, and yeah, really bad sentiment towards the brand ABC and iView from that Android community. Today, that app’s actually out there, iView, which is great. But when you look at it was created on iPhone in 2010 and we’re 3 years later and now it’s on Android, it does take awhile.

But to be fair to them, they’ve had to wait until there was enough business value for them to actually build that app and make that investment on the Android platform. And I guess they made that decision probably 9 months ago, probably a year ago, to start building it, and probably spent that 9 months actually building it. That would be a big project to go through.

 

TIM: Yeah. Now, if I were to commission an app that was for my sales force [inaudible 00:15:41] part of CRM process, then it becomes a moot point as to what platform it is, because I just tell my salespeople “you’re all using iPads.” Don’t have to worry about Android at all.

 

DANIEL: Yep. Yeah, absolutely. There is, of course, the option and a lot of benefit for just making an app for internal use as well. We built an couple of apps for Southeast Border for their internal staff to use and to manage their inventory, the location of their staff, to maintain their safety.

Yeah, in that respect, you can build an app; you don’t have to get Apple to review it, you don’t have to put it on the iTunes Store, and of course, you don’t have to give away revenue anyway, because it’s free. So you get a bit more freedom if you actually just make an app that you just distribute internally.

 

TIM: Right. What’s the distribution process then? I’m only used to downloading an app off one of the stores. If it’s for internal use, you just download it off a server?

 

DANIEL: Yeah, there’s a few different ways to do it. One is you can use services like TestFlight or HockeyApp. These are services that usually manage the deployment of apps during say beta testing, if you just want to send it out to a select group of people, usually under 100. You can send it out to that group and manage it that way.

If your organization has sent iPhones out to all their staff, you can actually manage what’s on that device as well, so you can actually send that app to their phone without them actually getting it, and actually send updates to it as well. They wouldn’t have to go to the iTunes Store or enter in their Apple ID or anything like that. You can actually manage that device yourself.

 

TIM: Do the two stores, iTunes and Play, do they essentially operate the same way? I know the commission model is the same, but from a client perspective or your perspective, are they equal parties to deal with?

 

DANIEL: Yes and no. The biggest difference is that Android allows you to – the Google Play Store it’s called, allows you to submit apps and essentially they’re made available in the next hour or two once you’ve submitted it to the store. The Apple platform actually performs reviews on the apps, so they get sent to someone at Apple.

 

TIM: iOS, yeah.

 

DANIEL: Yeah, iOS. They download it, they run it, they make sure it works, that it’s bug-free, that it supports all their guidelines. And if it doesn’t, the app will be rejected. So before you submit an app, and even before you actually commission an app, you really need to look at Apple’s guidelines and say “Is this going to fit in with what Apple believes is right or wrong on their platform?”

 

You don’t want to be actually investing a large amount of money submitting an app to the store and Apple said “Actually, we don’t allow that sort of app on our store.” They’re within their rights to do that.

 

TIM: Have you seen that happen?

 

DANIEL: Yeah, yeah. We haven’t seen it to that degree in terms of a whole business model being rejected. What we often see is say Apple not liking maybe a privacy policy link, maybe not liking some trademark or something that they feel is violated or shouldn’t be. They’ll just ping the app back to you. So that’s usually a week or two week process for them to do that. They’ll ping the app back to you with the reason, you fix it up, and you resubmit it. In the end, you get there.

 

TIM: What about adult services, as an example, or things that are not completely mainstream? Is Apple open to that, or are they fairly conservative?

 

DANIEL: They’re very conservative. When you submit your app, you need to actually say what’s the appropriate age rating for this app. Their recent changes says that if you say your app is available for children, but you’ve got something in your app that actually collects analytics about the use of that app, you need to have an appropriate child protection policy around your app as well.

Apple are much better than they used to be at this. There’s some really, really good guidelines, in plain English, that say “just make sure you follow all these things, and it won’t be a problem.”

 

TIM: Is Google Play a little more open?

 

DANIEL: Well, funny – they are, they are, but they still do have maturity ratings on things. What they do is not do that sort of proactive checking, but retroactive checking of apps. So if an app is inappropriate, they will remove it from the store.

They do have some specific policies, actually, around online gambling. The Google Play Store won’t allow gambling apps on the store, where Apple’s iOS Store does allow gambling apps on the store. You just need to follow both of their policies.

 

TIM: Let’s go back to the build. I’ve got the idea, I’ve got the use case, you’ve run it through the sanity filter, you’re happy to take the commission. Maybe you’re going to bring me up to speed with some stuff, some features I didn’t even know existed that I could incorporate. Do I have to worry about design elements and the user interface, or is that just part of what you offer also?

 

DANIEL: We do offer it, but we believe it needs to be collaborative. Once a client’s supplied us with a brief that we’ve guided them through, we respond to that brief with just some high level estimates. That’s usually circulated internally to get some sort of sign-off.

 

Once it gets to that phase, we ask the client if they would like to do any – I guess a little bit of upfront analysis, maybe a small piece of work, maybe three or four days’ worth of work where we would do a workshop and understand the intent of the app together, maybe understand the user flows that they’re trying to support.

Once that workshop’s complete, we go away and produce something called wireframes, which are essentially designs that aren’t colored in, and they’re a really good way to describe, in a light way, to describe user flow and I guess elements on the screen without actually getting into too much detail. Once we’ve got those, we get the client back in, stick them up on the wall, and we workshop them again and refine them.

Once we’ve got that refinement, we put that together in kind of a project sizing analysis document. Again, not too large; I don’t think it’s worthwhile at that stage to go overboard, but it gives everyone a real sense of comfort about what we’re trying to achieve, what we think it’s going to look like. And we potentially could start building from there.

 

TIM: Could you give me some insight as to how long all this is going to take? I mean, exceptions excepted, but if it all flowed beautifully and everybody was responsive and did what they were supposed to do, how long is a mid-tier project going to take?

 

DANIEL: Yeah, 13 weeks. I don’t know why, but it’s seemed a quarter of a year every single time we kick off a project to see it live in the store. A medium level project will fit into that 13 weeks in duration. A lot of those first couple of weeks may be that wireframe and that workshop, that backwards and forwards that is not a lot of everyone’s time, but it is in duration.

The core development work usually is like an 8, 10 week process. And then of course there’s a couple of weeks on the end where we’re actually doing testing and getting stakeholders to do a bit of testing as well and approval, maybe internal piloting within your organization, and then of course approval with Apple. So yeah, typically 13 weeks, but we’ve done projects that are 8 months in length as well. They can take quite awhile.

 

TIM: Do you quote on jobs?

 

DANIEL: We do quote on jobs. We provide estimates. When we respond to a brief, we give a high level estimate that says “This project will take at least this many days. Based on what you’ve told us, it shouldn’t take more than X many days.” Then we provide a daily rate based on that particular piece of work.

 

TIM: Right. I know within my space, one of the things that’ll always lick down a website build launch is content. Typically the client will always underestimate time and effort to get their content together. Is there an equivalent slowing down process on the client’s side that you’ve experienced?

 

DANIEL: There is, and I guess we allow for that quite a bit. We work with the client pretty closely. But to be honest, if a client struggles to get content together, then the project just gets paused from our point of view. We get everything up-to-date and ask them for what they need, and when it comes in, we put it in the app and out it goes.

A lot of the content may be more than just graphical things. It’s right down to have you got your privacy policy, what description you’re going to have in your app store, have you got your screenshots ready, what tags are you going to use on the store. We’ve got a little [inaudible 00:25:17] sheet that we send out to say “Hey, make sure you get these things ready before we send it out.” But yeah, those delays happen, and that’s fine.

 

TIM: Okay, so we get the app up onto the store, it’s been approved, people are able to download it. That’s not the end of the process, though, is it?

 

DANIEL: No, no. A lot of clients think it is, and I think that’s a real shame. Because they’ve invested quite a bit of money in the app; it’s on the store ready to go, and it’s really important in those first couple of days to monitor the apps, to make sure that they get shaken out in the general public. There’s a lot of devices out there being used in a lot of different ways.

We offer a support agreement with our clients as well, where we offer heightened support during that initial release, where we’re pretty  much on call and pretty much ready to respond immediately with updates to the app if we find some bizarre use of a device in a country that we weren’t expecting that’s causing the app to crash. If it’s starting to cause the app to crash, you’ll find a lot of bad feedback in the store, and very, very hard to climb back from that.

What we find is even if you do have those crashes, responding to it immediately builds up a lot of trust and a lot of loyalty in your app from your users.

 

TIM: So those reviews, good, bad, or otherwise, they are important/ They will sway the market?

 

DANIEL: Absolutely. Yeah, definitely. They sway the market. They sway Apple and Google’s ability to feature you in their stores as well, which is an amazing bump to your downloads, one that you can’t buy or make happen. But certainly one of the things you can do is to make sure that you’re nurturing your app and make sure you’re responding directly to feedback.

One of the things you can do on the Google Play Store is actually respond directly to feedback. So if you see a comment, you can respond back to that comment directly and publicly to everyone, saying “Sorry about that. Why don’t you email this email address with your device details, and we can have a quick look and get that fixed for you?”

Then if you do that and respond to them and then send an update back into the store in the next couple of days, suddenly you’ll turn someone who’s pretty annoyed into a fan of your app.

 

TIM: Right. Am I correct in saying that any reviews that are left on the iTunes Store are only for the country that that store is associated with?

 

DANIEL: That’s right. So when you’re looking at your reviews of your app and making sure that it seems okay, it’s worthwhile just scrolling down to the bottom of iTunes; there’s a little country button, and it might show a picture of Australia or America or wherever you are. Just click on that and change countries, change to the major countries and have a look and see what the ratings are in other countries as well. Because potentially they’ll be quite different. We often see that they are quite different.

 

TIM: Analytics. Do you have the ability to gauge what’s happening?

 

DANIEL: Absolutely, and you should, because you can’t just put your app out there and think you’re going to have it right 100%. You’ve got to follow up with release and you’ve got to make informed decisions about what part of your app is being used and what part of your app is no one touching, and maybe understanding why that might be the case.

So it’s not a big process to put in some analytics. Google Analytics provides some pretty straight out of the box ways to monitor what buttons are being clicked, what pages are being clicked from what country, and to do that in real time as well.

The Google Play Store and iTunes will tell you how many downloads you’ve had, but it’s kind of delayed for a couple of days. You really need to know immediately; as soon as you put your app out there, you want to know in real time how many people are using it, because maybe it’s no one. Maybe you’ve suddenly got spikes of 100, 200, 200,000 people using it. You need to be aware of that and be able to respond to it.

 

TIM: Is there anything on the horizon – I think most people know what an app can do and not do. Have we got to a point of maturity, the market’s settled a little bit? Or are there still brand new things rolling out?

 

DANIEL: It has settled a little bit, to be honest. In those first few years, it was just incredible; every new release that came out of Google and Apple, we would get up in the middle of the night, 3 a.m., to find out what those new releases were and pore over the new features that we could do with these devices.

These days, I guess we still are, but they’re just not as fast as they are were, or they’re definitely not as public about it. The ones that we’re seeing at the moment is Bluetooth low energy devices. These are little button-shaped devices that you can stick anywhere, really.

 

TIM: iBeacons.

 

DANIEL: iBeacons is what Apple are calling them, and they’re a really great way for your app to become proximity aware at a really low level. It can add some context to your app, so you can tell if someone’s standing in a certain department, looking at a certain piece of crockery or something like that, and maybe respond to that client in a certain way and say “Hey, I can see you’ve been here three times. Why don’t we give you 20% off and then we can actually get this transaction done?” You can do that sort of stuff.

 

TIM: And that’s driving through the app. So we’ve got new hardware that’s coming available on the market, but it’s the app that really is driving it.

 

DANIEL: Yeah, absolutely. If you had those little iBeacons, they’re about $20, $30 or so, next to a certain piece of item, the user would need your app to actually be able to respond to that. They wouldn’t have to be running your app, so the app could actually be running in the background or not even listing for this device at all. But when that device does appear next to it, that iBeacon appears next to it, that’s when you’ve got the opportunity to respond and do something for that proximity being there, i.e. give them a bit of a discount.

 

TIM: Fascinating. In summary, a bit of take-home advice for somebody who’s thinking of going and commissioning an app. A common pitfall or just something you’d like to say to people.

 

DANIEL: On our website, we get a lot of people submitting questions like “How much does an app cost?” constantly. We’ve got some links on our site that explain that process, and there’s a really good forum piece where people have said “Look, here’s the Obama app and here’s how many developers it took and here’s the rate, and that’s how much it cost.”

In general, apps are going to cost around $50,000 to build. A good medium ap. That is our #1 question. We don’t want to waste people’s time if they’ve got different expectations about cost. So the cost one is the biggest one. We don’t want to waste everyone’s time; we want to be able to set that expectation early.

So if you contact us through our website, just have a little read around some of the links that we provide before you send that request to us.

 

TIM: Great. What is the URL for that site?

 

DANIEL: It’s jtribe.com.au.

 

TIM: So jtribe.com.au?

 

DANIEL: That’s right. You can contact us there and send us your request, and we’ll get back to you pretty soon.

 

TIM: You’re Melbourne-based; obviously you deal with work outside of Melbourne?

 

DANIEL: We do. We do keep it in Australia. We have clients in Sydney, but most of our clients are in Melbourne. We prefer face-to-face. We either work one day a week in our client’s site, or our client comes and works in our office one day a week, and we find that generates a better quality relationship and a better app as an end result.

 

TIM: Now, jTribe does also run iOS and Android development courses too, right?

 

DANIEL: Yeah, that’s right. We love the technology, and we love a lot of people who are trying to get into it as well. We run a couple of two-day courses; one of them to teach you basically from not knowing anything about iPhone to be able to make iPhone apps, and the same with Android as well. Those training courses are really designed for programmers. They’re really designed for someone who’s maybe built a website before or done that sort of thing before with technology to actually build an app.

 

TIM: Daniel, thank you so much for your time today. A huge amount of insight into the space, and potentially going to save some people out there, I’m sure, time and money.

 

DANIEL: Yeah, great. It was a pleasure.

 

TIM: Excellent. Talk to you next time.

 

DANIEL: Thanks, Tim.

 

TIM: Ciao.

 

 

Shownotes

jTribe website
Augmented reality (def)
Apple App Store
Google Play App Store
Computer Vision third party tools example
Apple Store app submission guidelines
Google Play app submission guidelines
iBeacon (def)
j
Tribe app developer courses