Hybrid Mobile Apps

Mobile App Development


In this episode of the App Business Podcast, David talked about hybrid mobile apps.

This is a technology episode but one that is also relevant and interesting to non-technical, non-developer folks as well. Listen in as David share his thoughts on how relevant and a viable opportunity this is for everyone building mobile apps and why app publishers should consider using  this framework.

  • Comparison between a native app and a hybrid app
  • Definition of a hybrid mobile app
  • Limitations of using web-based technology
  • Advantages of creating hybrid apps
  • Cordova and PhoneGap
  • Why aren’t more people using hybrid apps
  • Available tools and resources for building hybrid apps

Resources and Links Mentioned


Transcription:

Chris: Hi guys, welcome to another episode of the App Business Podcast. It is David Pfahler week. David’s back and he’s got a bunch of topics and I think this is a really great one. So welcome David, what’s going on man?

David: Yeah I’ve been preparing some of those episodes this week and the reason why I did this is because I just came back from vacation with so much energy and really was dying to get back on the podcast. And that’s why I did this.

Chris: And you know were in the middle of you know, we got a lot of projects but it’s not just that we’ve got this businesses that are starting it’s that were building so much right now. And it’s really fun and exciting. It’s like were not just managing stuff and optimizing stuff, we’re like building it like what do we  wanna do with this, what do we wanna do with that, how we want this to work. We need a form on our website, all this kinds of stuff. So it’s really – yeah it’s a weird time for you to go on vacation just cause we’re it’s like right in the middle of all this stuff but yeah sometimes it’s great to get away and take a breath and then come back with all this energy. So let’s the little warning real quick. This is a technology episode. This is a David special. But I think this is really relevant or interesting to non-technical, non-developer folks as well. So don’t turn off just yet.

David: Oh yeah this is relevant for everyone building mobile apps.

Chris: It is right? Yeah so the topic is should you build hybrid mobile apps? And that essentially is defined as native + web technology? David you better describe what that is. How would you describe a mobile app or a hybrid mobile app?

David: Okay so the definition is actually a little bit tricky because the term isn’t well defined and there’s a couple of different things floating around but usually it means that taking a step back that “normal” apps are written in Objective-C for iOS and in Java for Android. And those are both programming languages that are compiled or in case of Java it’s running in Virtual Machine but basically we can think of them as compiled languages. And there are also a bunch of other compiled and interpreted languages that you can now use to write for this different platforms. But usually you always write an entire codebase for one platform. And that’s what I would characterize as a “native” app. Though if you define it very purely, a native app on iOS needs to be written in Objective-C or what’s the new programming language now, I forgot the name. Swift in iOS and for Android it needs to be written in Java.

Now what’s a hybrid app then? So between the native app on the one maybe extreme, the other extreme would be the web app, the traditional web app which means it’s actually a website that you navigate to and that website loads the code, the JavaScript code and the HTML and CSS and that then displays something that looks very much like an app but still running inside Safari or Chrome on Android. And that is delivered from a web server. So that’s a web app and between those two so to speak, there’s the hybrid app space. And a hybrid app in that sense really is just an app that’s written in JavaScript for the business logic and often uses HTML and CSS as for the user interface but it’s wrap in a native code wrapper for each platform so that you can deploy it to the App Store. So in the core, it’s running JavaScript, it’s using HTML and CSS so it’s more like a website but on the outside it looks like an app so you can still submit it to the App Store and don’t have to download it from a web server and don’t have to use Safari. It actually gets it’s own space on the home screen. It looks like a real app, it works like a real app but in the core it’s using web technology behind the scenes so to speak.

Chris: Before we jump in to all the specifics of or maybe this is the biggest question to start with in this decision is, “Does Apple have any track record for denying apps because they’re not native?”

David: Not really. There have been some concerns in the beginning but it turned out that Apple really never was denying the apps because they were not written on Objective-C and now we have much more precedent and we know that a large percentage of apps is written in hybrid, in a hybrid way. So that’s not a concern at the moment.

Chris: Okay.

David: And maybe a little bit of background as to why I am talking about and you might notice why I’m a little bit bullish about the web apps and the hybrid apps, I really feel very passionate about the web and thus mobile apps with web technology as well. And that’s actually how I got into mobile. So when I was still in school, I was learning to design websites and to create websites with just HTML and CSS and at the time there wasn’t even much JavaScript involve and right when the iPhone came out in 2007, I started to look at this and experiment with using web technologies to create apps because in the beginning that was all you could do. There was no App Store and there wasn’t even for some time, there wasn’t a jailbreak so there was really no way to get your own apps onto the iPhone other than using web apps.

And later then of course came the App Store and hybrid apps took kind of a back seat because they were – the web technology in the iPhone, the browser in the iPhone itself just wasn’t there yet. And so it was slow and ugly and also people just hadn’t figured out how to really write apps with web technology yet. And now it’s kind of making a comeback because of the advent of some very good frameworks and because the browsers in the iPhone and on Android have matured so much that they are very very good and performed very fast and capable. And so that now they are no longer slow nor are they ugly because you can use all those good frameworks for your user interface. And that’s why I’ve basically walk through all of this from the beginning of the first iPhone to now this making a comeback and really makes me very happy because I’ve been predicting that this will be a major player and it has taken for my taste a little bit too long but now were starting to get there.

By definition we use JavaScript in HTML and CSS and stuff like that and so obviously one of the obvious benefits is that you can use those skills if you already have them either yourself or in your team while creating those apps. And you know that’s why obviously it needs to be considered and it’s not for everyone so if you’re a hardcore Objective-C developer, I don’t think if your time would be widely spend learning JavaScript and learning HTML and CSS just to create an app that you would otherwise just create on iOS. But if you already have some web skills or if you’re not a developer yourself and you just hire someone to do this, you should definitely consider what your requirements are and if they fit.

So what you should know is what your app requires. So what kind of functions or features doe it require. Does it require heavy 3D modelling or very very performance in intensive calculations or stuff like that, then you might be better off with native technology then you should really look at it. But if not we can pretty much handle almost everything with web technology today. Another category where you need to dig a little bit deeper is games. So if you have 3D games, that’s something that’s still a little bit hard to do in web technology or very very intensive 2D games you might wanna check if you can do that or real time games with real time multiplayers. It’s still something that is possible but definitely a little bit harder to do.

Chris: And real quick why is that? With multiplayers specifically, let’s say it’s not 3D or even 3D. Is it because the engines like Unity or Cocos are better or made specifically for Objective-C? And that’s why it works better than whatever is working for the web. Why can’t you use those same engines like Unity or something for the web app that you could, for an Objective-C app?

David: So first of all if you’re using something like Unity, you probably.. I have never really used Unity myself by the way. I think it works is you can just compile it to many different platforms. So if you’re using Unity you could compile to iOS and Android anyways and then you would just compile using the native functions because that’s just always gonna be faster. You know there’s no real benefit for you to compile to JavaScript or HTML even if they offered that. That would not make sense in the mobile space. It would just make sense that you also have a web version that you could offer on a website. But to your question more is it’s really a technical issue. There’s just not the necessary, I mean I shouldn’t say there is not but the API’s you need for these kinds of technologies just start to make their way into the browsers and just start to make their way into web technology. And certainly you can patch this with native plugins but at some point there’s diminishing returns because you just need to patch so many things with native plugins that you might just have better written it yourself in native code. But for example with real time networking, there’s just not a way for you to get with JavaScript to get to necessary underlying networking API so you can open your own socket or something like that. So you always have to just ask the browser to do requests for you and that’s just way slower than working on the networking layer yourself.

Chris: So when you say multiplayer, you mean like maybe two characters on the same screen against each other where it’s like a street fighter or something like that, right? But turn-based?

David: But turn-based is not a problem at all because latency there isn’t a problem. Like if you have like 50 milliseconds more latency in a turn-based game you’re not gone notice. Because the other player might take several seconds to even make a move, right? So that’s not a problem but if you have like a real time events where the entire like 10 different players play on the same map and everything happens at the same time and in real time and then you probably couldn’t do this in web technology. So maybe something like Clash of Clans would be something that would have a very hard time to do with web technology.

Chris: Okay you know why I’m asking is because as we build out the economy games that we’re interested in that’s gonna be something that we’ll think about but I imagine that’s gonna be turn-based and not everyone operating on the same board at the same time.

David: Yeah basically about the networking thing it’s really just about where it’s time critical, where it’s about milliseconds. You know did you press the button, 20 milliseconds before or later can make a difference between hitting a punch or not. Or having someone in the scope of your rifle and you press fire and that takes 50 milliseconds or 100 milliseconds more to go over the network, then it’s gonna be miss rather than hit, right? This kind of things.

Chris: Right. Real quick, I hope this is good with the listeners where and we’d love feedback on this. You know this are real discussions that David and I are having about apps were working on and games and businesses were working on and I think that adds an element of authenticity and realness to what were talking about. So hope it’s not distracting while I’m asking questions like that are specific for what were working on. I actually think, if I were a listener, I think I’d be like oh that’s how they’re talking about and okay I get it. It’s almost like a use case or a case study of exactly what we mean. But so if it is distracting, just let us know and we’ll see if a different waves like bringing or what we’re working on. But these are genuine questions like I don’t know the answers to this. And this really will define what we do with some of our apps that we’re working on together. And I think we’re gonna bring in OptinMobile to this conversation too at some point. David kind of warned me of that but okay that was a quick departure but okay it’s making sense so far. So there are some limitations but really they’re varied like it’s a very specific limitation like where there’s probably a better solution anyways that you wouldn’t use at the web anyways, right? Okay so far sounds good.

David: So what are the benefits then, right? If you have an existing team that knows HTML and JavaScript of course you can reuse those skills. You can deploy to a wide variety of platforms and devices so not just about iOS versus Android, but it’s also much easier and much less painful to create responsive apps that work on an iPad and an iPhone. And you don’t have to mess with auto layout and this kinds of crazy things and XML files on Android, it’s actually pretty straightforward using web technology. But it’s just a  plain advantage and you only have one codebase, you don’t duplicate stuff, you don’t have to import code to another language which is such as stupid numbing task that produce a lot of errors and you don’t have once you’re in the store, you don’t have to update using the review system. And that’s actually something that I don’t know how many people are already doing this because it’s kind a please don’t tell everyone about it but you can host your app like the name code of your app on a server. And once you wanna update it and with a little caveat like as long as you don’t have to update any native code but most isn’t and you can just replace those files like host a new version. And the app will get notified the next time it goes online, the next time it has a connection it will ping your server and ask your sever like hey do you have any updates for me and so it’ll say yeah actually I do have new files here. And the app will download the files and save them locally and now that’s your app. Now that’s your new version of the app and there’s never been approval process, there’s never been any Apple review and you just updated your app. I find this pretty amazing.

Chris: So Apple is way aware of this but the question is given the Apple review process and given the Apple, meaning that it’s seven days at least right. And most cases are on average let’s say, 7 days. And then the lack of until recently ability to really like do the A/B Testing and optimize specific screens or change buttons or make minor fixes that would otherwise require a code upload. I guess the question is why don’t more people, why aren’t more people using hybrid?

David: You’re really getting me off of my tracks.

Chris: Am I getting ahead?

David: That’s no problem. I mean this is a really genuine conversation so that’s what I really like about it. I think it has to do with the bad reputation that hybrid apps still have because they used to be not as native like. You could just tell that they didn’t have the same look and feel, they didn’t respond very fast but we have a new technology now, we have better frameworks and that really is a thing of the past. And you know people just need time to catch up to that new reality.

Chris: And whose people? Developers? Because users shouldn’t know if it’s hybrid or not, right?

David: No, users don’t need to catch up. Users don’t know it’s the developers and the decision makers which is necessarily the developers themselves so maybe the developer already knows that they can use this technology but they can’t convince their manager or who is making the decision or the clients or whoever it is.

Chris: So you can build an app that works better on various devices because you can create it responsibly, right? And you can, it’s easier to create for iOS and Android and then of course Amazon Store. So you can export to different stores more easily and different types of devices more easily. You can leverage your existing in-house talent assuming that you have HTML5 talent. Basically forget that you have talent in-house, it’s cheaper to find JavaScript and HTML5, or sorry HTML5 and what else? What’s the other skill they need?

David: So HTML5 is a buzzword covering a new set of standards.

Chris: Okay just HTML just let’s say that.

David: Yeah basically what we’re talking about is the new holy trinity is the HTML, JavaScript and CSS. And they should have some expertise with hybrid apps specifically because it is not totally the same thing as writing website for example. But I would go into that with my technology stuff later so let’s postpone this a little bit. Alright?

Chris: Yeah and then so and if you still wanna leverage existing like ad, SDK’s or different bug crashalytics or any of the analytics, plugins, you can still do that natively. So you have as much native as you want to use but you can do a lot of the user interface or the whole user interface with web.

David: Exactly, yeah. I mean that’s the point. You might still need some development time on native development because there are ton of plugins out there for free in open source community but it might not be specifically the plugin you are looking for. It might be exactly doing what you want and maybe you just need the developer, helping you develop the plugin for specifically your use case. So what comes to mind is if you know for a certain ad network that you want to support that doesn’t support PhoneGap or Cordova it is often called which is the tool we’re using to read this hybrid apps and put into the App Store. Then you might just need to create a plugin for the native SDK that they provide but that’s possible. And there are some ad networks that provide this from the get go but you know the community is growing bigger and bigger everyday.

There are more and more plugins developed and added for free and if the worst case happens then you just need to create a higher developer or have a developer in your team create a plugin for this one use case what all the other code can be reused on all platforms. So I think that’s still a very very good deal.

I just mentioned Cordova and PhoneGap, I should probably explain what that is. You can find this at phonegap.com or cordova.org I think and it’s basically the same thing. PhoneGap is just the more commercialized set of things where it’s basically Cordova but plus some extra services that you can use but you don’t have to use them. So for example if you don’t have a Mac, you can use PhoneGap build to build your app in the cloud and then get it back as a completely ready archive that you can upload to the App Store. But that’s just a service and you don’t really need it and that’s why I’m using Cordova because it tends to get the updates a little bit faster and then PhoneGap catches up with the latest Cordova and implements those.

But it’s really the same thing. So you wrap your app inside the Cordova shell so to speak and you can put it on the App Store. And if you add some additional logic, you know a little bit of coding and I cannot go into the specifics on the podcast here because that will take forever but then you can use a web server, deploy your business logic and UI and all that there and the app will go to the web server and whenever there’s something new it will download it. But it’s important to understand and I still can’t believe you need to emphasize this but you ask the same question before so I’m mistaken to think that this is clear, this does not need an internet connection. This is like a normal app, like a native app you were used to using. The only time you need internet connection is when you go to the App Store to download the app like any other app. So this is not dependent on an internet connection specially not a fast one? This works out of the box offline first. And then you can additionally on top of that implement this update functionality that of course only works when you have a connection but a native app can’t even do it. So this is just additional to what native apps can do.

Chris: So it sounds like there’s not really an easy checklist to like, it sounds you need to talk to someone who knows mobile web apps to diagnose if the App ID you have is like a viable candidate for developing via hybrid.

David: Well with all technology choices it’s I think that same thing. So you might wonder should I.. let’s say you only want to do an iOS app you might think should I do this in Objective-C or in Ruby because there’s also some Ruby way to write this in Ruby and then convert it to iOS. I have forgotten the service but there’s some method to do this. And you need to ask yourself the same questions like can I do this or there are available, the necessary API’s available and you know what other benefits. That’s normal. You always have to make a trade-off. You make the trade-off when you choose native. You always choose something and not the other thing and that’s why you get some benefits and some disadvantages. That’s not unique to the web version but some people just default to native and think that everything you do with web is an additional disadvantage but that’s not the case. Of course there’s some limitations as with everything. But you get so much more in return. So let’s look at why we don’t want to do native and you know that’s not always the case as I said but you should look into why shouldn’t we just use native.

And the reason is if you don’t have the expertise to do it, if you don’t have in-house Objective-C and Java developers with nothing to do in their hands. It will be expensive to buy because the agencies that are doing this are not very much looking for work, it’s probably the other way around and the mistakes that you will make because you don’t have expertise in this field is going to cost you a lot of money and time and effort as well. So if you don’t have the expertise, then that’s a disadvantage right there. You don’t have the ability to do this fast updates but you also don’t have the ability to A/B testing and that’s something that we are going to also make use of as soon as we can in OptinMobile where we can just say, wait a minute, if we can do updates from a web server, we can also tell one half of the requests to take this version of the app and the other half through request to take the other version of the app. And then we can have indie application logic request to our Google Analytics tracking that tracks us the difference and tada we have A/B testing. That’s just not possible on iOS, I mean it takes immense foresight to even deploy an app that can display different versions and then to update it you need to file an update to the review process again so it’s really not very effective to do any of the testing.

Chris: Yeah the only way, well you could do that right? That’s the hard part about the A/B Testing and the past is if you wanted to like anticipate what things you’re gonna test ahead of time you could like build in the different options, but yeah you’re right it’s not easy. Optimizely came out, we’re on the beta for the Optimizely mobile app SDK and it’s closer to being similar to like web where you can change buttons on the fly and you just have to tag certain elements as being reference in Optimizely but essentially what they’re doing. So you can do some of these in native now, it’s pretty new so I don’t wanna say that you can’t do A/B Testing in native but I would say it’s there..

David: Yeah but you only can do stuff that you had the foresight to implement when you filed for review.

Chris: Yes.

David: And have a change something on the fly and that’s basically the point of A/B Testing. And for something like OptinMobile, this might even be more evolutionary what you could do. Now this is advance. This is not something that someone will, like some random $5 an hour Odesk developer will do for you. But what I’m willing to experiment with is the idea that you could have the different versions of the A/B Testing thing one level above that. You could have a testing that is responding to its results live without any changes. So if you do this correctly, you could test different versions. Have them communicate to your server right to your tracking. Then the tracking tells you which version is performing best and then tells all of the users that are not participating in your testing because usually you only take like a slice of 5% or so for your testing. You tell everyone else to use the configuration that is performing best at the moment. And if you can do this, then you can basically optimize for your KPI’s, whatever that is in your app. Can be in-app purchase sales, can be monetization but can also be mean retention. But you can optimize for a metric on the fly without even your intervention. And it’s something that I think is just a revolutionary idea. It’s not something I’ve seen in the wild, but this is the kind of stuff that’s possible with the flexibility that the web provides.

Chris: Yes this auto optimization stuff where as soon as you have a significant result, it automatically updates everything else or you can code it to do that. I totally agree with especially where it might be a time sensitive thing where they’ve got a call to action or something that lasts 3 days and you don’t have the time to be re-submitting things. You know I totally agree with you and of course were using the usecase of OptinMobile because were testing different calls to action, different pop-ups, different placements and all that kind of stuff. Kind of like lead pages to us. But lead pages doesn’t work in mobile because you don’t have that flexibility to test all this different things like you would with the web.

David: Yeah and lastly you have multiple codebases for your multiple platforms. And that’s just with native. And that’s just the headache in itself that gets out of hand really quickly. We have noticed with OptinMobile how hard it is to even ship for one platform. Now imagining that for 2 or 3 hopefully at the same time because you don’t wanna be half your Android users be behind iOS all the time because that makes them angry but also developing kind of in lock stab would totally kill productivity so you’re really in a dilemma there. And with again with hybrid apps, you can just develop from one codebase and you have a new version to test it and if it works, deploy it to all platforms and you’re done.

Chris: Can you imagine having a different website for Windows and then Macs and then different sizes of screens and everything, that would be crazy. And that situation is what were talking about.

David: Yeah that situation right now. And you know usually someone here in the audience comes up with the response, but Facebook abandon HTML so it cannot work. And there was this famous incident where a couple of, yeah it’s actually almost a year ago something like that but sometime ago Facebook was building a hybrid app. The Facebook app was actually a hybrid app and they couldn’t figure it out. They couldn’t make it perform very well and so you know someday they pulled the trigger and say okay HTML 5 isn’t ready yet, they basically were blaming the technology and henceforth have developed a native apps. They said actually it’s not really true.

The Facebook apps still contains a lot of web views because naturally Facebook content is just very web-centric. But it is not as HTML heavy as it as before. Now to that I can say yes but you are not Facebook, you don’t have the resources that Facebook has and Facebook can simply deploy entire teams of people for each and every individual platform and coordinate them and have management and all that. And then maybe they can manage to somehow release for multiple platforms and somehow stay current, etc. But you can’t do this. And also you don’t have the specific needs of Facebook in terms of performance and handling lots of user data etc. That’s also kind of specific usecase. But most importantly is that Facebook was just wrong. The performance problems they had, and they decided and said you know HTML wasn’t ready yet, were simply a failure of engineering.

There are a lot of blog posts out there from people who pointed this out and some guys at Centra actually implemented the newsfeed which was the biggest problem in terms of performance with one of their frameworks back in the day and demonstrated that it was very very performed and very fast and that this was simply a failure of engineering. So you know even Facebook could make it work if they had put the significant amount of effort in at the time and now it’s even better, now it’s even easier. So for example the problem with newsfeed is one that’s solve out of the box with modern frameworks.

Let me talk quickly about this  technology stuff that one would use so people have some things to check out and to read more upon. This is perfect stuff that I would use in a modern app today when we started creating something which is something like this or similar. Of course we use Cordova, you know that’s the same thing as PhoneGap which I discussed before. But you would use Cordova, the latest version. I would use AngularJS as the basic JavaScript framework. That’s just something that helps you organize your app. Provides lot of very useful functions, there are many basic JavaScript frameworks out there. This isn’t even mobile specific, this is just a java framework. You could use Backbone.js, you could Ember.js, there’s a lot of different choices out there just like AngularJS. And it also ties in very nicely with a mobile framework that’s specifically made for mobile and that has made big waves because it supports a lot of UI elements, it looks very modern, it’s way stable. It’s called Ionic. And we have also created our own mobile framework, it’s called Bradypodion and you can find this at bradypodion.io. And I would actually use it in conjunction with like together with Ionic. Because Ionic provides a lot more user interface element that Bradypodion does but Bradypodion provides nicest structure and more intelligent defaults than Ionic. So check both of them out and make your choice.

For scrolling, there’s the perfect iScroll library which I love and also I maintained of. Actually not maintain, I just help curate their repository but I know it really well and it’s the best library that helps you scroll very smooth on mobile and that was a problem for web apps for a long time where the scrolling just wasn’t as smooth as some native and you can use that to really fix that.

And for plugins, check out plugins.cordova.io or whenever you’re looking for a native plugin for something that you want to use, then just Google it. You’ll usually find something if you just Google it.

Chris: Awesome.

David: Final note. If you need some kind of data sync for user data, check out hoodie, we had it on the podcast before and it really abstracts the sync, really makes it really easy. So as a summary maybe, I just hope that you have at least considered this when you start your next project and that you maybe have talk to some of your developers about this and that you take this is a real opportunity and real choice. And maybe for your specific project, it is better suited than native.

Chris: Yeah I think this is awesome. I think if I were, which I am but non-technical person listening to this podcast, I would be thinking of the benefits like okay well if I can develop on iOS and Android at the same time, and roughly the same time and all this kinds of stuff, okay that cuts the cost at least 50%, maybe in half. And then save money on design assets because you changed up the way it’s delivered and all these kinds of positives. I would be trying to figure out, okay how can I build my next app with hybrid? You know in hybrid strategy or whatever framework and I think I would be looking for an agency that lead this and I don’t know of any agencies that have adopted this as their like standard or default mobile position or is it all just like hey build a chinese menu app with our framework?

David: I don’t know of any agency that specialize in this besides agencies that used to specialize in web app development anyways. Like big desktop app development and of course they naturally now also include or pivoted to mobile web apps. But I think this is still something that is just on its comeback and making a really nice comeback. But it’s also a silent revolution because you don’t hear that much about it. But it has a giant market share. I made a mistake of not looking it up and it’s also kind of hard to get some numbers on this but it’s in the 2 digit percentage so it’s definitely known by people that have used for a lot of apps. And it’s a viable option.

Chris: Yeah we’ll share more of this because we’ll be doing this for some of our more gamy apps and then we’re evaluating it right now for OptinMobile. We just think it’s a better way of delivering this app than in native code or a 100% native code. So yeah I think this stuff’s really cool. This was one of the big reasons David that I think we connected on OptinMobile is we thought this was a real opportunity for a web app and we find to like get our hands dirty  or at least for me because I know you know this stuff really well. For me it’ll be really fun to like see what we can do and see what the shortcomings are and see if this really is this amazing opportunity that it seems to be and then share that with the audience. So I hope everyone enjoyed. We weren’t yet the top, this is a technical conversation. But I think it was really interesting and it’s definitely stuff that should be on our radars I think as publishers.

David: And we know we have a couple of listeners in the audience who know about this stuff and have opinions and I would like to exchange information and opinions on appbusinespodcast.com, comment on the episode.

Chris: We have two listeners that know this stuff. That can comment, but yeah that would be awesome. Alright man, thanks David. That was awesome and come check this out in the Facebook group, would love to hear your comments and on appbusinesspodcast.com and we’ll catch you on the next episode. Thanks guys.

Tagged under: