How to Hire a Mobile App Developer: Video Roundtable

hi I'm James McGuire editor of data mation and our topic today is how to hire a mobile app developer to talk about that we've got three industry experts uh with us is Tim Connor president of Cloud City development hello to you Tim hey how's it going good good so you are in San Francisco right yes we're based in San Francisco on the western end of Soma like 11th admission and and what sort of work do you typically do what kind of pro we do we do web and mobile apps design and development mainly for startups not entirely we have some Enterprise clients um off an early stage sometimes scaling it up all around the range of basically you need to get something built we can build it great also with us is rupin Patel he is the CTO and managing director of mercurium hello to you rupin hello James how are you and and I we see Atlanta in the background right that's very hip that is part of Atlanta we are to become the next Silicon Valley I believe it what sort of work does mercurium do uh so I'm a I've got a company that basically does Consulting CTO work we work across the Spectrum with SAS application development SAS product application development as well as mobile development and as things have moved on through time almost every web-based product development shop needs a mobile app as well so we always think of it in terms of companion applications and additional functionality that maybe the mobile form factor to provide that the web form factor doesn't provide also with us is Alex Kira a principal consultant for parallel Minds hello to you Alex hi James how are you good good and you're also based in San Francisco correct uh yes we're out of San Francisco s area uh and what sort of work do you typically do so we're kind of a small uh full stack uh shop we basically do uh for mobile applications we do iOS apps as well as hybrid apps and then we also you know work with the normal web web and backend apps mostly uh Ruby based applications uh but we work with kind of across the gamut startups as well as bigger companies as well so kind of cover that great so getting started I mean I'm thinking there's a company out there who's you know very successful as a company they realize that having a mobile app would be a competitive Advantage but they know nothing about mobile apps I mean they they know their own business but they don't know mobile applications at all so they've decided hey we need one of those things what kind of advice would you give that company I mean how did they get started in the process of hiring a mobile development team you know what what what are some of the first steps Tim what's your sense of that how would a company get started with that I think some of the most important things they can do aren't actually just on the development side Pro product and design is really where it all comes from so before some of the most important steps start even before really defining the problem knowing knowing how expensive development is where tens to hundreds of thousands to Millions when involve scaling up so really wanting to solve their business goals and come in know who your users are we tend to drive everything Lan you ex style from user studies so we we can help you through the process but it definitely is useful if before you even get started you know this is our business goal we're trying to get funding or we're trying to get to this number of users here's the type of users we have here's all of our existing stuff the more you can bring to the table the more we can intelligently discuss us what we can help you build after that it's really finding developers you can find a trust and rapport with that you work day-to-day very closely with ring your sense of how a company would get started what what what are some things they need to be thinking about um now I Echo a lot of Tim's sentiments I would I would start with definitely the business use cases uh understanding whether the user the target users of this application are really interested in cont content are they interested in entertainment uh you know gaming that sort of thing is it a very socially connected application just kind of uh having a good idea of the target user and then designing the application around that Target user base and also on the business side understanding what's going to maximize the benefit to the to the entity producing that application it's a consumer products oriented or consumer software oriented company like video gaming company you know they are going to get Revenue through engagement on that application day in and day out if it's a SAS business platform they're going to get um application kudos for having that in their portfolio so really the business motivation has to be taken into account Alex what's your sense I mean if if a company's going to be hiring a development team what are some questions that um they want to ask I mean obviously there's there's many development teams out there how do you pick the the one that really fits for your business or your product what are some sort of questions that allow you to cut through the Clutter sure and I think uh you know definitely agree with you know uh what what rupin and Tim said uh you know you definitely need to do your homework and the more information you have before you approach a development company the better off you're going to be so you know figuring out your customers your target audience and then you know kind of figuring out maybe their personas are they going to be using a desktop application at one place with a mobile app in another place you know kind of what the uh different strategies are and then you also might want to start thinking about what platform you're going to Target uh because depending on what platform you're going to hit you know different uh development shops are going to have different skill sets so uh you know are you going to be doing a native IOS app or native Android app you know or you can get into the hybrid hybrid apps using phone Gap or or you can just go for you know pure uh responsive web design application as well so depending on which one you're going to pick you know that's probably going to affect your choice of uh which development shop you're going to use as well uh the other thing I think that uh would be great is if you knew kind of what data for especially for Enterprise what data you going to leverage out of your uh your systems and how is that data going to be accessible uh because a lot of times you know that the getting the data out of the apis defining those apis could be even more work than some of the mobile development work that you're going to be doing so basically having all that information ahead of time is going to uh be able to ask you know so then you can ask the each shop that you talk to what their skill set is and what experience they have in your chosen platform that you're going to be targeting essentially yeah I mean you're talking about you know getting the data out it's sort of like does the company need a backend rebuilt or built or they really just need a mobile app or do they need both those things this the product could could pretty could scale pretty well really quickly could scale really largely really quickly yeah exactly that's going to determine the cost you know if you're just need someone to develop your mobile application and you already have the API defined maybe you have the project management skills as well the ux resources that's going to be a lot different where you know the Shop's going to have to do everything including API project management ux all themselves so that's going to be it's gonna look like completely different you know equation essentially so right Tim what what questions if you were if someone hired you just just to hire you know the the perfect web development team or if you actually own the business yourself you're going to hire another web development team what sort of questions would you ask them to see if they really knew their stuff or if they were a good fit for your company so there's not going to be one magical question that you can ask that's the problem otherwise otherwise our jobs would all be a lot easier like Google and Microsoft famously used to have trick questions where if you get the trick then you get the job and if you don't you don't right it's more and any developer if you're hiring unless you're super technical and you're possibly not listening to this talk because you already know it all the answers the developer is going to be able to out talk you on the tech side anyways so they could they could unless you really well educated they could be feeding you a line so it's more than just a question is sit down talk through the process with them talk through how they built similar things what the working relationship will be like how how committed to this whole thing are you we we work very hand inand with our clients as partners every day delivering value so we try to say that within the first week if you're not seeing results and you keep hearing how much longer it'll take their problems so you actually put you actually put a one week time you thrw out the figure one week well within the first day something should be done okay some of that might just be designed so if we're doing design then how are you liking the design process is the how is the relationship working all of the best projects that go the best have very good relationships most of our work comes from word to mouth referral because people are happy with us and that social proof does make a even better working relationship so can you picture from your discussion of how they help how we help talk you through what you're trying to build how long it'll take what the technology choices are what the day-to-day working will be like I mean you certainly will ask lots of questions about technology why they justify it what their portfolio is but there's not you could you could ask infinite questions but there's not like one easy one that solves it Ruben is there is there a magical question that you would recommend like oh if if I get a good answer to this particular question I they know they really know this stuff uh no I mean you know it's the Practical reality is these things are fairly complex and as Tim said if if it were that easy uh there would be a lot of people in technology without jobs um so but practically speaking I think a good place to start is to look at their resume if you will uh and today your resume is really online you have applications that you've built if you're a developer that are out there you can have a look at the quality of those apps you can ask questions about the team structure uh on that on that that project to build the app were they to lead were they just you know one contributing member of the team what do they actually do um you can do reference checks I mean these are standard things you would do for any employee uh reference checks are always great right especially if they've done work for any other clients uh you can ask them for three references give them a call and see see how good of a job they did um but I think frankly before you get into all the details of qualifying uh potential developer for your project you should just decide what type of product you're building if you're building a game and you're going to primarily a business development application firm um you may not get exactly the results that you want even if they get good references because that's not their specialty right and potentially vice versa so first understanding the type of app and then targeting the developers that kind of built apps in that domain is is a good start and then you can do all the typical reference checking and um you know checking out their portfolio their skill sets all that stuff and if if you're looking at a project I'll add if you're looking at a project or product that's going to be longlasting it's not just a one-hot app you'd also want to consider that has this development shop or team been around with clients for a long time or do they just do short engagements get in and get out um because that'll leave you an alert later on so you want a partner that will kind of be with you for the duration of your product development life cycle can I actually jump plus one what Ruben just said there sure so many people don't think about what comes next and I'm always encouraging my clients to be hiring And discussing what happens when we wrap up with you and transition on is very important not just for the selecting selecting that they're they're a Dev shop that cares what happens after and works with you on that but it's it's the probably number one most being used is we're getting away from the web has long since proven agile and mobile development is a little slower development cycle but it is still a continuous process so it's not like you ship an app and it's done and out there it's more you shipped an app and now you're getting more feedback so if you haven't already started getting feedback and considered that you were basically buying a baby you have something now for the rest of your life of us who will do great work and then think okay now I'm done and I don't have any budget left and we've launched it and if any developer puts you in that spot then they've left you high and dry right definitely talking how they work with clients after the fact how they how we help train up your engineers on the job like that what about typical pitfalls or like problems that often happen I mean Alex what have you seen out there like oh it you know this always goes south or this this misunderstanding is really typical I mean what kind of common pitfalls do you see in terms of hiring a mobile app developer sure yeah I mean I think the one of the you know things that could go wrong is you developed the wrong product so I'm kind of a big fan of the uh kind of Lean Startup approach where you kind of do some experimentation you launch your MVP and then you refine from what you learn from that mvp versus you know uh spending six months to a year launching a huge product and then kind of realizing that you know that you've built the wrong product um and you know depending on what kind of Outsourcing you're talking about you know you hear stories about people you know in uh uh Elance and some of those things where you know they don't you know they the project never finishes or they don't get access to the codebase and things like that so you kind of you know do do get what you pay for uh in that term so you know you just need to make sure to have uh kind of a development shop that's going to write uh maintainable code uh you know unit test your code uh so basically have a long-term you know view of things where you can kind of not just shoot out an app and then leave you leave you hang hanging it's you know write an app in well uh well well based uh best practices manner that you can kind of maintain in a long run and then you know pair program with your team if you're team's going to be taking over that you know PA program with them uh so that you know that you know the the essentially the app doesn't go over budget you know it's not uh not the wrong product there's no uh bugs things like that so that's kind of some of the pitfalls that you can that can go wrong and then the one other thing that I would mention is that you know to Echo Tim make sure to insist on working software all the time so you know the first couple weeks you should start seeing software uh in your hands versus having to wait you know six months and then that's going to be the wrong the wrong product that you weren't envisioning in the beginning of the process you're saying it would be a partially working prototype within a few weeks yeah and you should definitely communicate with your with your uh shop and frequently you know in agile Bas methodology you can have you know daily standups uh have working software at the end of the Sprints that you can actually have on your phone and play with and that's very important versus having to wait you know end of the uh project and then you you realize you've gotten the wrong product developed a prototype's a little different but yeah you should be getting some of your features working like if you want us to build a prototype we'll build do something more throwaway all of us but even if you're not building a prototype if you're not seeing something delivered what's going on what are they doing and really common with outsourc particularly offshore you could be months in and they've just piled up all this code that doesn't quite work and then you're stuck with this pile and they expect you to pay the bill I think Alex and I it sounds like we've cleaned up after some of the same before that the biggest Pitfall I think is when Outsourcing is thinking that cheap saves you money rather than cheap costs you a whole lot of money so I definitely that going with like an independent who seems will quote you lower is going to cost you a lot more when you're when you get press mentions and your site is down and you come to us and you spent your budget and you're like now fix it and we're like like okay rupin what sort of horror stories have you heard or what are some typical misunderstandings the companies need to be aware of before they go out and spend their money on on a mobile app um well I mean I think it's all the stuff that uh Tim and Alex have been talking about I think the the post so there's there's two I guess categories I would say one is the experience that you have with the development shop while the app is being built are you getting feature drops regularly are you getting status updates regularly are you getting what you thought you were buying um so there there are a lot of cases where you're not getting anything close to what you thought you were buying and you end up having to abandon with that shop and move on to another shop but I think the most horrifying stories are the ones that happen after the app's been released and you actually have paying customers um because at this point you don't have the luxury of just simply picking up and going to another shop you've got a working codebase out there and so I had a client not too long ago who I'll I'll leave unmentioned um but they had an app in production with thousands of users out there and um their previous developers had decided to go off and do something else and uh simply said they weren't interested in in helping do any more development sure we all change our mind yeah yeah and and it's particularly problematic in these days and age this day and age where there's so many new technologies and there's a lot of competition for developers and developers can just get tied or burnt out decided to take a trip to Europe for half a year so um that can leave you as a business in a bit of a a problem and essentially in this case what ended up happening is they took all the keys with them if you will so uh all the update the application also were not uh properly handed over to company company didn't know to ask for that uh they also used old versions of libraries that needed to be upgraded for camera access things like that so uh four stories probably have a wide range I think the worst are probably after an app has been successful and and uh and you need to change it or update it or piix some bucks right you definitely need access to the uh make sure to ask access for the source code as well as any you know App Store uh permissions and things like that that you would need you know because there's definitely horror stories of people uh having developed a product and not have not getting access to their soci code and being held ransom for that then they say oh well I have this app and you're like well where's the code and they're like what does that mean don't actually have an app you have like someone else bu an NA and you have to get that from them so so it's the exact opposite of Open Source not only is his proprietary only the developer him or herself know knows the source code and the worst Horror Story I've seen in this has actually happened repeatedly enough to become a Trope that the developer actually had a nervous breakdown and went like severely unbalanced like while developing the code one of them like he kept writing so it was it was like it was love crafty and code he went off his meds in the middle of the project what was that he went off his meds in the middle of the project yeah I don't like don't not well I don't want to shame mental mental health issu like under I think what happens is under the under the stress of a un technically skilled uh product person a independent developer who doesn't have the is Alone by themselves just sort of and they're behind the ball and they can't quite get done and someone's asking unrealistic amounts right you just start hedging and hedging and the pressure they just break under it but yeah this project had it had it was relying on syntax errors to run like invalid code it was like and it then for developers after Independence trying to like spend as little as possible to fix it like layered on and tried to fix it you justed from place to place right saying like be careful cheap can be very expensive and yeah we've definitely seen if if it is after you have users as Ruben said that's re it's really bad when you've had press good press and your site is breaking right super sad what what about the idea of cost and I know you know companies really you know are concerned with that but the problem is it's very hard to throw in a dollar figure because it's sort of like um it could cost you know several thousand or or tens of thousands or hundreds of thousands how can companies be prepared for cost and is a separate question take your pick which one you want to answer is it a good idea to for a company to to to see an app if they like and and emulate it and say how much would it cost to build that particular app so they really specific idea so but the general question is is is cost Alex what's your sense what do you tell people about cost sure I mean I think there's no kind of rules of thumb you know it's it's absolutely depends on your specific situation um I think the one thing is the more information you can have on on what you're trying to build you know the better someone's going to be able to estimate your cost so you know if you have you know there's apps that you can build prototypes in you know such as Envision app and different ones like that where you can kind of come up with a pretty good feel for what your app's going to look like and then um kind of try to approach someone and for them to kind of be able to estimate that as well um I think the other thing I think I mentioned is basically depends on the uh overhead and what your uh kind of team structure is are you going to be just hiring a single developer or are you hiring a whole team and depending on that you know the the cost is going to be definitely different uh as well um one other you know factor is the platform I mean let's say for example you're you're going to be targeting iOS but also doing Android I mean that's almost going to double your cost because you're not going to be able to share much of the uh mobile code uh the back end you'll be able to share but the mobile code you won't so you know it's just depends I mean you know smaller apps you know anything from 20 to $40,000 can get you started but it can go up to you know hundreds of thousands to Millions so it's very hard to kind of come up with an example um I would say I mean looking at other apps uh is a good idea just to be able to kind of get ideas on what the app should look like and the functionality and you kind of get get ideas they can kind of apply to your own specific situation and that's definitely not a bad way to go um rupin what do you tell people about cost is there is somewh to give it a ballpark figure um well I think think I think we should start with just in general software estimation whether it's for a mobile app or for any other application uh estimation is is part art and part science uh the the art part of it is based on all the unknowns with any kind of platform so you're dealing with a new version of iOS you're dealing with a new language you're dealing with a new device you're dealing with any anything that are sort of unexplored in you and that part is really hard to estimate Because unless you've done some prototyping or done some work with it you kind of don't know what you're getting into so let's leave the art part aside and focus kind of on the science side so on the science side the first question is do you have a clear idea of what your requirements are if you do now you have a shot at getting a reasonable estimate if you don't I it it's sort of a guessing game uh you one way of guessing is by analogy you know certainly is there another application that's 90% 99% of what we want you could use that as an analogy but you would still need to know how much cost to have that other app built in order to be even able to compare um most of the time I find that people don't have a clear set of requirements it's just the nature of doing new things and in that agile is sort of a way to deal with that you know you say We'll chunk this up into X week iterations and this is going to be the cost per iteration and this will be the scope per iteration so you're essentially spreading your risk out over an extended period of time um I would definitely avoid anybody who tries to you know give you a lowball fixed cost estimate for what is obviously um it's it's sort of like is this deal too good to be true if it is it probably is too good to be true well yeah it gets back to what Tim was saying in terms of it's you build it but of course that's actually only step one building the entire thing and getting it live in the field is only step one that then it becomes you know updating it and what the costs are for that so it's a whole another question yeah and and you know along with cost you've got quality you've got timeline right so you may get an app it just may not be very good uh or it may not come out in the timeline that you expected um and as Alex pointed out you know are there things outside of the application that they have forgotten to estimate um many times for a mobile application people forget the actual backend or the web services that have to be built in order to support that mobile application and they kind of assume that the app developer for the mobile app is going to build those um so if you you need to build a back end that can pull in feeds content from other places and clean them up and display them and capture user input and store it and maybe even display it on the website you know that's almost like building a second app uh except it's running on the website so it's it's very important for whoever looks at your project kind of systematically break it down and and kind of think through how they're estimating it and have them explain to you how they came up with their estimate what they basing that on and what are some of the things that they think are are gotas or uh areas that they can't estimate because they don't have enough information Tim what do what do you tell people about cost and and is there a way for you to throw out you know not necess your own shop but but you say I've seen this kind of an app done for this amount or this kind of an app done for this amount it's a Cadillac it's a Toyota that's the only part that works it's a loose ball bark even if they come to me with those specs their specs are wrong uh building the trick about building software is50 50% of the way through you actually know what you're trying to build unless you're actually trying to clone something and that's a certainly different case like the that we're not the sort of developer to go to to build an exact clone um you're you're exploring what the product is and so it's very challenging to estimate which is why you can get a rough ballpark of hey how much would it cost to build an app like this or of this scale and even though they're like oh it's e-commerce it'll look like an e-commerce one they're really just big buckets of are you trying to do an MVP P are you trying to do a first version that has real users are you trying to do the full version that scales up a little more like it's a it's a spectrum around how much money you have and time and the features and even those are kind of Loosey Goosey because we've worked with people with similar scope projects where we estimated 40K and got it done in 22k for an MVP yeah okay we' seen people where we tell them hey 50 isn't is going to get you there and that's not even beginning to start a lot of it is the discipline when you say MVP it's a very complicated word break down minimally viable product does different things to different people part of my a lot of my job is to tell a product people you can't have all that you can't have all that and a lot of the discipline the discipline of how willing someone is to not be attached to their idea but to solving the problem and refine it really affects that scope right so what I'll end up doing is giving you large ballparks of this would be about what you would get in that and then over time we refine what features are in or out I say trying to trying to hit a exact exact price goal per feature is like trying to dock with the space station by turning on off all your all your steering dusters and hitting go you're like we're gonna get to 150 and we're gonna have this feature set you're wrong 60 to 80% of software projects fail and part of why agile helped that was it said hey rather than rather than defining success as this exact spec sheet on this exact budget let's get into it and collaboratively figure out how long it'll take right if you're working with people that know what they're doing they'll delivered enough projects that they can tell you we can deliver a working version of this with some of these features for this sort of range which exact features are in we should actually not turn now anyways right because it's much different once you have in your hands and you're have in your user's hands and they're using it and if this feature that takes 30% of the budget isn't the one that anyone cares about why would I want to spend the time building it right drive it from user study Drive everything from Real Real Results driver from a user study determine this is the feature we should spend our time on so anything other than time and materials agile based work for Consulting I think is is doing a disservice to the developer and the and the client actually what about sort of a natural Gap there between you know engineering and design in this because you know how how can you bridge that Gap um seems like it's one of the biggest gaps in there uh you have a sense of how do you how do you put these two worlds together of engineering and design and mobile app so we're Yeah so basically I think there's they work actually together pretty well it's just like when you you build a house you need somebody to kind of take your high level rough ideas and translate them into something visual that you can then react with uh the fact of the matter is the human visual system is probably the most developed part of our brain so we do consume information much better visually so I think the first step is take ideas and words that are kind of running around in your head work with a designer or if you're working with a development shop usually they know a good designer or maybe they have a good designer in house uh and sit down and at least get some rough ideas some rough wireframes some rough sketches just get something thing on paper visually before you write a single line of code um that's your cheapest way of I think drisking your project write at the outset uh and it's something that I find that some people wait too long for or they think they don't want to spend the money on design up front and they end up spending you know 10 times as much on development later on so is that your thing about getting stuff on paper you me a flowchart you made a literal interface what what what are they you start the the simplest things to start with are wireframes so if you come in with just a basic rough idea the first step you want is wireframes wireframes are very low resolution ideas of the screens involved the the rough cuts of the functionality involved and gives everybody sort of an idea of what the app needs to do uh the Second Step you can do is do a little bit of a higher Fidelity prototype you could do Photoshop files omn graph Envision any of these tools there's so many of them out there uh depending on what your designer is most familiar with and comfortable with they can use that to put a little color a little style a little look and feel to those wireframes uh just very much again like an architect you know he's gonna he's going to draw the sticks lay them out give you a rough idea maybe do a little bit more High Fidelity prototype on the computer if need be so same same process and then you go and build where obviously the cost is going to get a lot higher when you start constructing so I say in my opinion I think Design's very critical uh and I think it should be done upfront at the very least uh once if not continuously throughout the project but at least you should invest in it at least once in the beginning um even if very minimal simply you can view it as a drisking uh but more realistically you can view it as a way of making sure that your products actually usable to your end users um so I I think it's vital to do that up front and then go into development Tim I know this is a subject that's close to Your Heart Right bridging that gap between design and Engineering I mean how do you how do you make that big Grand Canyon jump between those two worlds and how do you keep Engineering in its place sometimes so I everything Ruben said is definitely spot on um I think there's a little history that's important here people been doing design a long time successfully upfront so upfront design had had a Heyday and then it was part though of waterfall development and so people design everything out and then you can get very good over your specs there but that doesn't really work how the actual software works so then agile won for the last decade and you shipped a design to your development team and they ripped it apart into these little feature stories and it was thrown over the fence and they implemented all the parts but one tenth of them and the important parts and now your pro your product vision and your design is a shambles design really is like the product voice in the process so then lean ux which just come up between all of us a couple times came around and said hey how do we sort of return iteration throughout this whole process get iteration in earlier for one thing the design is far cheaper to iterate on than the development so definitely do as Ruben said do that do that design up front start exploring the idea the the thing that needs to be done then is don't stop keep that iteration through your user cycle use the design to inform the development and keep communication through back when I get started doing this 15 years ago we would just sit a designer down with a developer and work through a project and lately in the last sort of decade of agile that almost started to feel revolutionary that what you would just pair a designer and a developer and they collaborate but that's so inefficient for the developer so I'm willing to be less efficient for the developer on the simple Vector math of if it's 60 60 mil hour this way versus 100 miles hour this way I'll take that 60 if it's the right right direction right which one is typically 60 and 100 just so I'm saying like the designer slowing down developer to do the right thing you're only going 60 miles an hour but you're going the right direction versus oh perfect agile the developer it's it's driven by development cost so you're going 100 miles an hour but you're not going in the right direction right so there are a lot of techniques that we could talk through about living style lifestyle guides like everything being built from like boot bootstrap and Foundation started to popularize this and starting to depr privilege a little the engineering challenge and more move it back into design driven in in this case though you still the challenge is you have to have sort of as a as a foundation solid agile practices and you have to have solid design practices and then put them together so I I get tired of hearing I heard at a large consultancy a while back oh we did everything the client asked for it was a technical Tech success I me no one wants the product and it wasn't designed but it was a technical success great never to hear that again I've always I've always felt like this so we'll just go off and make sure we do it perfectly right and there were some years of learning uh there that to have a bridge those it was it was non-trivial designers designers think developers are just sort of making up how hard everything is and developers think designers or padas that want things in these challing ways for no good reason so right you just get to you have to have a team that works well together that has techniques and experience bridging that gap which is one reason to consider going with a shop that can do both of them that has a lot of or even if not can do both of them has a lot of experience working closely between design and development in a continuous iterative process the whole way if you just do the design up front which is super important and then the designer off I think it's a failure makes sense don't get enough design done up front I don't think it works well either what about and Alex if you can like you know one one last question I think is important for us if if we look to the Future for a second when we're talking about mobile applications you know two to four years from now how is this process going to be changing and if we had the same conversation say you know several years or a few years in the in the future what we'll be talking about in terms of mobile application development sure yeah I think you're already starting to see this I think one one kind of important pattern is you're going to be having a lot more uh smaller interactions maybe across different types of devices versus you know one one device one application you're going to open and just stay in that application so you know you're even starting to see that with iOS application you I have the extension capability where different apps you can kind of sew together and experience through all these different applications that kind of call call each other uh uh through the uh interaction essentially so it's not just one one major app um and you and as well as you know wearables and things like that that will kind of enhance this as well so you can kind of start start interaction maybe on the iPhone and then go to your watch and then go to a smart home so more and more of these types of devices are going to start proliferating so you're gonna have to kind of think of it as a system perspective not just an app perspective how do you tie together all these different um interactions I mean another example is you know beacons uh kind of location specific uh technologies that kind of kind of you know will tie in to where the location where inside your ad and then tie that into your app as well um so I think we're starting to see that um too um so that's one one thing you know that I don't think anyone's mentioned is you don't want to uh kind of start with you know um for example your web applications you don't necessarily want to translate that directly to your app and this is going to be more and more important as these types of interactions you know start happening is that you don't want to just take your web page and and build a direct application with that you want to think of what the user going to be doing what the tasks the goals are and how they're going to be interacting across all these different uh types of devices um so that's one thing and then I'm curious to see how the um different Technologies play out because right now you have to you know when you're writing a native app you have to write one in you know Android iOS and could be all different type of technology so I think you know I see some things that are more um Technologies are familiar to it more people like Java JavaScript and react native that are coming out so hopefully there'll be kind of an easier uh experience to develop the apps across you know the different platforms um not necessarily right once you know run many but just uh where you can kind of uh be familiar with you know one technology and and kind of write all these different aspects of it yeah yeah it's it's crazy isn't it there are these you know two two major competing platforms that that need different code it's sort of like it says this whole technology is very much in its infancy we need one platform somehow like I said it's it's a larger philosophical discussion which which we can't today I think we're actually going to be talking about the same question in two to four years and the battle is still kind of ongoing between HTML 5 versus native apps and that's I don't I think it's obviously trade-off but you know I think it's it is becoming easier and easier to do that so hopefully that Trend will continue uh in the future as well Ruben what does the future hold where are we going looking into your crystal ball what what's going to be know 36 months from now a long a huge amount of time from now in the world of mobile apps well I think it's always dangerous to try to predict the future especially in technology where everybody's trying to change it every minute but I mean I could tell you just near term uh you know some of the higher quality applications out there have a strong consideration for the offline experience um so if you if you look at apps a lot of apps are built with the assumption that the cellular networks available everywhere and a simple example is you walk into a elevator in a large building in the app is off now what does it do how does it behave so I think just simply better ways of dealing with the offline experience um bringing that more into the platform level rather than having each app deal with it individually uh I think that'll be sort of a key area people will continue to evolve and and develop um certainly as Alex mentioned all of the additional devices that are now sort of using the app on your phone as a hub uh I think that is a really interesting space we've got we've got things like the watch smart watches which get a lot of press as companion devices but I think you can you can think of a lot of other things that are more stationary and embedded in your everyday life uh your television your thermostat your lights your your car you know all of these things and um all every single one of those things I mentioned has multiple multiple companies investing lots of money and making them uh full-fledged computers that can run their own apps so now you have to start thinking of an app not as a standalone thing but as a participant in an ecosystem of other apps and they all have to communicate with each other and synchronize with each other and kind of work together so your app has to know you got home and let you know that now you can turn on your TV or you know all of these kind of intelligent things so I think that's an area uh that as the infrastructure gets built out we'll we'll see a lot of implications for everyday app developers to consider um and then lastly I think the um and I don't I won't go into the crossplatform issue because Alex covered that pretty well but I think also another area is uh the international market and designing for different languages different cultures and different form factors of phones that are accepted around the world and sort of crosscultural um pollination of applications WhatsApp is a great example of an app that was able to to do really well because they figured out what the different kinds of phones are feature phones in different countries and optimize and develop for that but I think as we exhaust markets over here you know in the west we'll start looking East to see if we can impro you know get into those markets that's going to cause a little bit of um growing pain for us and potentially vice versa makes sense I I think you know sometimes my my phone wants to call my refrigerator those two things are going to have a convers I don't know what they're talking about but they seem to be communicated constantly uh T Tim the future you know a few years now what are we going to be talking about when we talk about mobile both both were thinking not conservatively enough and not like liberally enough at the same time always do predict the future that you're not you're not going to get away from two platforms you're gonna have an explosion of platforms I mean the internet of things as as the power processing power develops that the limit ations of the phone stop being limitations and they become more and more supercomputers simultaneously then we have an explosion of form factors of watches and and devices getting powerful enough not to be firmware but almost approaching real osses I mean they have been for quite a while now but but we're talking serious platforms between IOS and Android in real major platform before between in addition to those two well I'm saying like the all the internet of everyone trying to win the internet of things and then then iOS is EXP loading into that so even if Android and iOS are the the big mobile ones for a while even those continue to get more complex and at the same time as you have extensions and you have use cases that make your phone more of a true computer you start getting new devices where it's again different form factors that are limited and how does your car work and how does your phone work and none of the no one wants this no one in the last 20 years has wanted to seed the living room so there's not an easy Internet of Things answer everyone wants to be the Hub everyone wants to connect all these so there's just platforms fighting it out and apple obviously has its slow moving entry where it creeps iOS into everything methodically and then Android does its approaches and then all the manufact like the Asian manufacturer Samsungs all try to do their approach so I certainly do not predict you seen there be any less Platforms in the near future the definition of mobile might start to get a little cludy right when that's why people talk about touch a lot because the interfaces are what matter like whether or not it's mobile is more is is touch at a certain size and connectivity and and what's the interface of you're watching what's the interface of your car is your car a mobile um it's the the the the original most mobile of mobiles but you say programming for it is a mobile not right now but what happens when there is IOS on your car what does that look like right so the platforms even if they just stayed those two big winners which they aren't um they're going to explode in complexity of how you build for them so the definition will start to become what do you mean by mobile there's going to be plenty of work to build phone apps though for the foreseeable future and just like internet 6 stayed around forever the phones stay around for long enough that there it's what's your base case of your lowest level model of your phone that you're worried about so there will be quote unquote mobile developers but there will also be whole new Realms of what that actually means and yeah don't forget that there were feature phones but within two days of your phone getting stolen it's almost actually shipped somewhere else um it Africa and some other developing nations like the smartphones are going everywhere and when they when you sell them they end up everywhere that it won't be feature phones everywhere this is this is a lot of the world's like computer and web browsing experience right if you don't think that will explode in ways we haven't yet figured out that Silicon Valley is sort of my opic view of it needs has figured out yet then then I I think we will be surprised interesting okay I think one other thing that um I don't think we mentioned is kind of the Enterprise I think that's one unta market that we're going to see a lot more mobile adoption in as well and and building kind of more mobile based apps that Target your your Specific Enterprise I think that's that's another huge Trend that's going to happen and a lot more work you know available for that I have long been a proponent of Enterprise developers and Enterprise people being people too so we need to save them from net and like old old like J2 I've definitely taught like Ruby seminars at at Giant Enterprises before and that the the level of tooling that exists is such that it's recently flipped on its head when pivotal did their relaunch and Rebrand they said consumer grade applications or for the Enterprise or something like that where rather than talking about Enterprise grade everyone's finally admitting the Enterprise is so far behind on the consumer experience that there's just we definitely have some clients that we're doing a lot of work on in the Enterprise for like modern ities in their their sales tools for a tablet experience for the showroom floor for instance interesting well there are clearly many many changes and I think the word is explosion I think Tim you I agree with that word explosion that there be no Simplicity is not in our future that that I can guarantee you um gentlemen I I greatly appreciate expertise I I'll I'll send you the link we can all tweet about it and uh we can all you know view it on our smartphone and uh thank you very much all right thank

This transcript was generated automatically from the video's captions and may contain errors.