Tiempo Talks Episode 4 – Building a Mobile App with Confidence

Enjoy this episode? Subscribe to our podcast on your favorite platform to be notified when a new podcast goes live:

Apple Podcast

Published Tue, 4/14 5:33PM • 108:32 Minutes


mobile applications, application, users, project, feature, app, tests, testing, development, mobile, user experience, platform, developers, developing, mobile platforms, run, technology, release, problem, android


Perla Gomez, Paul Estrada

Perla Gomez  00:05

Hello, and welcome back to tempo talks. I’m your host fellow. We’re still working from home. So I’m recording in my house again. But we do have a great show for you today with our guest posts. We’re going to be talking about mobile app building and strategies for keeping development fast and steady as your team grows and shipping features. Hi, Paul, welcome to the show. Hi, Pamela. I’m glad we are talking today. And I’m really excited. First of all, do you mind introducing yourself to our audience, please?

Paul Estrada  00:33

Sure. Well, as you know, I am Paul and I’m a software engineering lead here at tempo development. I’ve been working here for a little bit more than three years now in different mobile development projects. And before that, I have for over 13 years of experience seen many software development companies and different projects. And

Perla Gomez  01:06

thank you, Paul. I’m really glad to have an extra like em for today’s episode to talk about mobile applications. We wanted to talk about this topic because we all interact with different apps every day. And there’s so many that I’m sure most people must think they’re just super easy to create. And that’s not really the case. So what would you say makes developing mobile applications so difficult?

Paul Estrada  01:26

Yeah, no, that’s a really tough question. And I will say, from my experience, I think that that is direct consequence of having two competing mobile platforms. And well, that that will be Android and iOS, in today’s technology, environment. And well, to understand why I think we can compare it to front end web developments. For example, if When you’re building a website, or web application, you are what you’re doing is you’re building for a single platform. And that is the web platform. And like it or not, you will end up using technologies like HTML, CSS, and JavaScript. Because I mean, those are just tender core programming tools for doing that kind of software development. Now, to be fair, the web is a bit tricky because and you need to support different web browsers. And you know, like Google Chrome, or Safari and Firefox and a lot of other browsers, but ultimately, what you what you do is that you can do everything, develop everything using the same tools for any compliant browser. And things are a bit different for mobile because we have four on one side, we have Android. And then we have iOS as both mainstream mobile platforms. And the problem is that each one, each platform has their own set of tools. For example, for Android, you you would use Java or kotlin as a programming language. And for iOS, you will use either swift or Objective C in and things doesn’t stop there, because you need to learn the Android SDK and you need to learn the iOS SDK and each of them have their own set of API’s different patterns to use guidelines for implementing user interface. interfaces and so on and so on. And, well, these are just technical aspects, but they directly affect they affect how you assemble a development team. And who will you hire based on the required skills, and also how your team will organize and collaborate, to keep building that, that same application for the two different platforms. So in the end, building a mobile and mobile application, I think is challenging, not because of the technical landscape alone, but but because you need a team or a team working in harmony to produce the same, the same output and the same set of features in both platforms at the same time, and I think, at least on the web, that that is a bit easier. than in mobile,

Perla Gomez  05:02

right, of course, because having to work with multiple platforms, in turn multiplies the difficulty. And you also mentioned having to work with different sets of tools. But considerations, should organizations planning to develop a mobile application? Make them deciding on a technology stack? How should they select which one is the right one for their application?

Paul Estrada  05:22

Okay, okay. Yeah. Yeah, that’s that’s a complicated question, because there’s no, I believe there’s no single bullet proof answer for it. Sometimes what works best for someone might not work for you, and if you don’t have the same circumstances or or resources, so I think I will answer the question based on that. So what when planning to develop a mobile application I think I will ask what technologies tack will give give you an advantage or a better use of of the resources that you have. In starting from that we can make some considerations. For example, you should define your target users in demographics wisely, because that will help you identify which platform you need to target. Let’s take it let’s take an example. If you want, if you want to launch an app in heavy in heavy Android user base or market, you will want to allocate more resources on native Android development and probably leave iOS development for for later or you can decide that you need a US first or maybe both. Maybe you do want to Develop at the same time, your Android application and your iOS application. But that shouldn’t be a decision that you just take for granted that to be based on what your expected user base is. So, you should know first who you are targeting before you start developing your project. So, once once you know your target audience is I think you should consider also the availability of your engineering resources and deciding whether or not you need to hire more specialized mobile engineers or if you can train them, or if you want to get help from from a software consultant company, depending of course depending on on your on the budget that you have for the project in any Just a brief note about this. I think it is no secret for anyone that in today’s in today’s technology environment, there’s a big shortage of, of experienced engineers in the world. So hiring can become difficult, especially if especially if your company is outside of the tech market. You know, I mean, if you’re, if your company’s first line of business is not technology related or software development related, that things can become difficult when hiring. So at least on this part, here, development we can help with this problem. And by providing high performing teams for the mobile app needs it either by building applications from scratch or augmenting your Current stuff. But But as I said before, before you start developing a model project, one of the things that is important to consider is that availability of engineering resources and how you are going to fulfill that part of your team. And yeah, I think there’s a last thing the I think it’s important. And that last thing should be the technology stack. And so Currently, there are many ways to develop a mobile application. You can go fully with fully native development with Android and iOS and their own set of tools. Or you can have you can build them a mobile web or a progressive web application. You can do hybrid development with With with some frameworks like Cordova or ionic or even more newer approach approaches like react using React Native or flutter and that kind of cross platform development. So, he wrote, each approach has, of course, benefits and drawbacks, but the most important thing is to analyze which of those benefits will give you a better use of your resources without letting those drawbacks become a problem for your project. And in their, their case, case studies already on the web by some companies are using React Native flutter flutter and other cross platform tools in but then they they also have been going back and forth to tender Android and iOS development in that that is not necessarily a bad thing. Because it you know, depends on the project that your project needs. Some some teams are successful by committing to native development and other projects can be just as successful embracing web technologies or, or those kind of cross platform frameworks. So there’s no single roof technology stack. It all depends on what you’re trying to achieve. In the Yang summary, I think those are some of the considerations that we need to consider.

Perla Gomez  11:44

Do you think that some of that back and forth and sometimes even failing comes from following trends instead of a more thorough decision making process?

Paul Estrada  11:52

Yeah, yeah, I will. I will say so because it is somewhat Common that once some new technology starts getting some popularity, everyone tries to at least test how that works. And then they try to incorporate into their existing projects without stopping in analyzing first if, if it really makes sense to start using that. And that comes back to what I just said a bit earlier about analyzing the benefits and the drawbacks that that new technology will be introducing to your project. So I would say yeah, you, you should try to ignore technology trends to some degree of course, and choose your mobile approach based on your project needs. And at times, that will be a real lagging. On a standard tools for Android and iOS, or using React Native or any other technology, and now I think there are, there are some aspects to consider to decide when to follow or not those kind of trends. For example, what are some of the things that you can think about when developing your break is how much hardware support does your app need? In the end, I mean, things like GPS, or location, ability, location sensing, sensing ability, using the camera or any other sensors that modern mobile phones can use. Or for example, you can ask You yourself if your application is going to be graphic intensive like a video game, and is it a video game or not? There are certain tools that are best suited for some kind of development and others are referred to do like more generic applications in that that are that do not need that many graphic intensive code. So other things to consider are for example, if you are expecting for your application to work offline. So, I mean, what happens if you if your users suddenly lose the internet connection or if they are in some market where there’s low quality connect a wireless connection? So all those kind of details can help you to analyze and decide if some kind if some specific technology or framework is useful or not for the project, these details are you should be used for to inform that decision. And in here in in tempo development, we have experience precisely doing that we’ve been building different mobile projects. And we can definitely help to figure this out together on future projects.

Perla Gomez  15:37

Yeah, it makes total sense to gather all the information you can about the product you want to create before jumping on a train. Because if it turns out it wasn’t right for you, you might, you might end up doubling your workload to fix any mistakes that could have happened. And talking about mistakes from your experience. What are some of the most common ones you see organizations make when designing, developing and deploying mobile applications.

Paul Estrada  16:02

Okay, so we talking about mistakes. Um, I think recording a little bit on on all the projects that I’ve been involved in the past. I think I can classify some of those some of those mistakes. I will start for with some of the design design related mistakes. So for design, I think the most important thing is the user experience. And I think this is something that is often overlooked by organizations that are developing their first mobile applications. And I will say you can have, you can have fancy designs and beautiful animation In your application, but but in the end, if your users are getting confused by, by so much stuff going on in the screen, when you switch between some parts of your application that is making your users don’t get confused about what’s happening any given time. Your some of the app screens are freezing because the app is too slow, taking more than a few seconds to like waiting for something to complete processing. That could be very annoying from a user point of view. And sometimes they they you said, You know what, I’m just tired of waiting for this. I would just quit using this application and in That is a problem that you don’t want to know, don’t want to have. If users don’t want to use your application, well, you have a very big problem. So design should not deal. Just we shouldn’t be jealous about UI design and things become being pretty on the screen. But it should deal with how the app the application works in general. Like how the app helps or empowers your users and facilitate to perform some tasks and on their phones. Also, another common Another common trend in sign takes is making you’re making your iOS and Android application. Look excellent. Design like an I mean like an accept copy of each other and so that it is not it is indistinguishable if you see both both applications in the in the bowl in the two different mobile phones, and you can see that they are exactly the same design wise in that. The problem with that is that, that the reality is that each mobile platform has their own set of guidelines for user interfaces. And it if you if you have seen me if you have if you use different mobile applications or your phone, you just start to notice some how that how that particular mobile phone system works. And you start to see that there are some common navigation interface partners that are dictated by by the platform, there are things that work that just works the way they do, because the platform vendors have those incorporated into the operative system. And if you start to implement your application by not following those patterns already provided you you run the risk of of confusing users, because they are already familiar with how a phone works. So they Yes, they expect that some things work the same way either, even if it’s a complete different application. And of course, of course, it is always a good idea to have the same look and feel on replication on in all the platforms including Android and Is because that can help in boosting your app identity and branding. But the user experience should be consistent with already defined patterns. Now, talking about software development specifically, there’s a common mistake to and that’s I will take that not taking out to mated testing berries seriously. And then and I will tell you I’ve been that I’ve been a consultant for many mobile application projects. And the most common question I always get from stakeholders in all the projects. It’s is that what why why the developers need to do automatic testing at all because inter eyes doing this work like creating outcomes, creating tests, automatic tests is just like, additional work that that is making development, the development slower. I mean for for developers. And so, so sometimes they prefer to have dedicated resources like QA engineers or manual testing engineers to do that work. And And my answer to that question is always that, yes, I mean, developers could be slower because they now need to test all the things to I mean, they are no longer just implementing features, programming code, but now they need to write some tests and make sure that everything works before they Push the new code to our repository or, or to a new release. And However, there’s something that is often overlooked is that we are not focusing on individual performance. And, and I mean, when you’re working in a project, you shouldn’t focus on your individual performance. But the team performance because that’s what, what’s the most important thing is for to continue delivering features more quickly. And if they will, if developers are adding or out of or adding tests for all the new code that is making your project more robust over time, and that can help mitigating the chance of bugs in while developers will be more confident than that, if they start changing something that can break some someone already implemented the functionality, and we can be very sure that the test will be failing because you are changing something that wasn’t supposed to work that way. So this is that I think that is a very important aspect of delivering software. And that can help to for if you are planning to integrate a continuous integration process in your project. There’s also a another kind of mistake that I want to talk I want to mention, and that is related to software deployment. And I think this is closely related to, to what we just talk. And so for example, in mobile applications, we, we typically don’t have a centralized place to Publish to publish the app. Instead, we rely on the platform publishing channels like the like the Google Play Store, or the Apple App Store, in the How it works is that once you have some part of your project, you can upload your application to to one of those stores, but you need to wait for a revision phase. And this can This can take from just a couple of minutes to over a week, in the worst case scenario. Well, essentially the platform publishers, they are the ones that decide if your application can be made public or not. And this happens anytime you want to publish something new in. And I have witnessed organizations that didn’t consider this or didn’t know about this. And this can be a real bottleneck, because they think have a proper testing process. So sometimes the application is rejected, because there is a problem or some bugs arise. And then you will need to fix the box. And now you need to upload your application again. And now you need to wait for a second revision. So that’s some time that you should be considering because Because that can take a lot of time between diff between different feature release. So because of that I think having automated testing for mobile applications is, is very important, because that will help you in streamlining your development process and to catch bugs earlier. mitigating the chance for your users to get a broken experience once the app is published. And yeah, I think that’s, that’s the main key to two mistakes to avoid.

Perla Gomez  27:42

Now, let’s go back to user experience for a second. So I’m curious how can business leaders ensure that they’re delivering a mobile experience that their users actually want? Instead of going through the whole process and realize after deployment that their users have no need for the product have created?

Paul Estrada  27:57

Yeah, okay. Okay. Yeah, yes. Oh, Remembering a little bit of what is explained about the user experience, remember that user experience is very important, if not critical for your whole project that can be I will say that can be a life or death decision about in doing a good user experience that can be the life or death of your product if you if you don’t do it, right. So if you don’t have a good user experience, of course, you will want to improve your application to improve the user experience. However, you shouldn’t do that without knowing some things from your user audience that helps you to take some decisions. And what I mean by that is that you shouldn’t expect to continuously add new features or perform changes on your app, if you are not really sure if that’s what your users really want. So that is a problem because now you need a way to know what what what is what your users want. You know what I mean? And so, actually, there’s a technique that you can use for this. So and in user experience research, there’s a technique called a B testing. The idea of this technique is that you can run an experiment to measure and monitor how your users are using some new feature. And once you have some data Time, you can use that to decide if a new features is actually helping your business to achieve a goal before making it available for all all other users. For example, let’s suppose that we want to update our application we a new screen designed for, I don’t know like for searching products, for example. In you can have a way to manage the feature from your server or your API or an API. In the web you’re going to do is that you will, you will choose a population of your current users, like some amount of users, and you you will enable that new feature just to just to those users and so you will end up having users using different variations of, of your feature that typically that that’s called experiment groups. And, for example, we’ll we’ll be having a group A, which is using the existing user experience in Group B that we’ll be using the new user experience. So in both groups, you can collect data from certain events, perhaps how many clicks or searches on the screen are leading to users completing a shipping order or or if they canceled the, the shipping order, or if they are paying with a credit card or all sorts of things. And so after a few weeks, or months, depending On how much data you have collected, you can run statistical analysis to identify if there’s a significant difference in increasing shipping orders following our example. So if the experiment results are positive, you can call it a win. And and now you do you do know that you can enable the feature to all your users, because now there’s some some data that is informing you that it is actually improving things. So AP testing helps you to shape your mobile experience incrementally. And because of that, you can take informed decisions from real real user data. You are not doing changes randomly on your replicates. expecting that something will work you are you’re acting on different designs. And once you know if your users are liking it, or if it’s helping your users to, to improve your, your income or different things, now you know that you should use a new experience.

Perla Gomez  33:28

So what would you say are some common strategies for driving new feature enhancements in mobile applications?

Paul Estrada  33:34

Yeah, so that’s a good question. So following from, from what you what I just explained before, either if you aren’t using AV testing, for your, for your user experience improvements, or if you are developing just an incremental change to your application, there’s a there’s a few strategies that we can use to to help with to make that new to make those improvements smooth smoothly. So one way is using finger flex. And this is a strategy that relies on having having some system in place to allow enabling or disabling if a feature on demand from your own servers. For example, let’s suppose that you have implemented a new feature in your application in that in that has been already published to the Play Store or to the App Store. So your users will be getting the your application update on their phones. But they will not see the new feature. They will not be able to use it. In as a matter of fact, they will Not even that that new feature exists in your application. So what you need to do is that once you publish your app, you will, you will need to enable that feature flag from your feature control system. And that way when your users download some system, some system configuration the next time they open the application in their phones, the application will identify which of those features shall be enabled or are broadly disabled for that particular user. So that that can help you to enable or disable things on demand for certain markets. Another strategy similar to the fetal flex is you is using faced a process called phase releases. And this process means the when when you make some updates to your applications on the stores, instead of, of enabling the new the new update to all your users, the ones you can start rolling out the update in in stages. So this can help you to monitor the app delivery in and decide if you want to continue with a next roll up stage or, or just stop me to post their release. Because in case you do reducers are reporting errors or there is something happening that is preventing your release to continue so you can stop the release. Before completing, so that you don’t have many users affected. And that’s what and that’s one of the goals of these strategies, which is making your delivery and making delivering features as smoothly as possible and mitigate failure scenarios in the case they arise.

Perla Gomez  37:24

Now, earlier, you were talking about the differences and similarities that should exist between an iOS version and an android version of the same app. But going beyond mobile platforms, what is your advice to ensure a cohesive experience between Full Feature applications and mobile applications?

Paul Estrada  37:41

Yeah, yeah, I will say that that very important. I mean, some most of the times when you’re building a mobile application, you’re not like starting a new project from scratch. Unless you are a new Business Lang or a startup company. But most of the times, you you also are incorporating mobile application into some existing ecosystem of other systems that you already have that that can be web applications, or API s or all sorts of all sorts of different systems. And not that now you want to connect to a mobile application. So if if we’re thinking about, about adding mobile application to those existing systems, I think we should consider first that phones can provide a more personal interaction in different capabilities than computers. So rather than trying to rather than trying to emulate Every feature from your existing applications, I think we should look into which features could benefit from a newer mobile experience. And in how key how we can we can help to empower users to perform some task from their phones, even if they’re offline. So there’s actually, there are actually a few points that we can apply. And the first thing is, your mobile application should have a look and feel that resembles in some way your current application. And because they will allow your users to identify your brand and existing features and business concepts that they are already familiar with. In your other applications, so that will help your users to become more comfortable using your mobile phone and your mobile phone application. And so that’s the first thing. A second thing would be to consider if you’re transforming an existing user flow into a mobile experience. If you’re doing that, I think you should be you should be wary of changing the name of things. Because some users can become confused. For example, if, if we if you replicate your existing web application used to have an option I don’t know like some some option to export a PDF file. Your users are now expecting to use it on their mobile phone. But you happen to change that, that option in and now it is called site file instead of export PDF. So that can be confusing to users and some of the producers will not even stop to think about if that is the same, the same option. So as we took earlier, and for for this kind of things, we can use a B testing, because that can be helpful to decide whether or not to change this kind of things. And and another thing to consider is that since you already have an application, and probably you already have some business logic in place, so for your mobile applicant You should, you should avoid replicating the same logic for your mobile app. And instead, you can expose an API to access that logic. And then we can make we can make all the applications communicate to that API. And yeah, I think that’s, that’s some of the important things. And well, that last as a last as a last key key point, I think the that it is also important to make, use that to make your users feel that this new application is part of your existing ecosystem. So you should also be planning on enabling features that will be that will allow your users to To continue working from where they left off. So for example, support if we suppose that a user was creating, let’s say, a shopping wish list on their computer, but then she had to run an errand. And then later on, she arrives at a coffee shop. And suddenly, she just remember the there’s a special discount with her credit card. So she opens again, the app in her phone, but the shopping list is not there, because she started the shopping list in the computer. But now she wanted to continue the process in the mobile phone. And that is also it could be worse, maybe there’s no way to pay with a credit card on the application. So those kinds of things should be called Consider when you are trying to connect mobile application to your existing set of applications and features that your users are already familiar with.

Perla Gomez  44:13

Do you think every Full Feature application should have a mobile version? What are some of the unique advantages that they provide?

Paul Estrada  44:20

That’s, that’s actually a good question. So there there are things that that to be consider in more in mobile applications and something that shouldn’t be considered. So for example, on mobile phones, mobile phones are in general, more affordable now than I mean if we if we compare it to traditional computer, desktop computers and laptop computers, and they can be carried to almost every place And you can bring your phone to almost everywhere and in the in the phone can offer simpler user experience than those found on bigger devices. And because of that, I think mobile applications are important for organizations because they can result in new revenue sources for your business, either by becoming an extension of your existing systems, or we explained before or by disrupting the market that we with new features with new mobile experiences. And, and I think this is possible because because mobile applications benefit from all the hardware available on the device. In, in particular, the sensor censoring capability. Also the network infrastructure, the ability to make phone calls camera and other hardware features. So, for example, think if we think about ride sharing apps. Of course, you can request a ride or a taxi. You seen your computer however, using your phone has a more immediate access to your current location. because it uses a mix of sensors and network data that that makes the that makes the right sharing more successful because they they can track you in your driver real time. I mean they can eat them define exactly where the user is position in how the drug and how the driver is getting near your location. So that technically have a really good duty case for a mobile application. And also also think about restaurants. You can you can have a meal and pay your order just by putting your phone near near a supporter terribly now, and there’s nothing Have you seen your credit card directly, or to disclose private information so at least that can help also to do some actions become more secure for your users. So mobile applications provide an opportunity for your organization to to make your juicer lives easier and and to have your business available at all times. times, think about this if if a user finds it that it is very easy to look for a product on your app, or to request a service order for tomorrow, chances are you will start having more sales and orders. Because now your users do not need to go to your facilities or to your offices at any specific time. I mean, they can do it everywhere. And that’s a that’s a really good advantage of using a mobile application. On the other side of things, that there are times when a mobile a mobile experience is not very good idea. And, and we talked about this a bit earlier, but the important thing is you should define your target users early on in your project. If you have an existing system, and you’re planning to make it mobile application, as I say before, you should first identify what is going to be your user base. And or if your user base is using mobile phones at all. Perhaps your user base consists of elderly people, maybe some of them have disabilities or, or maybe you’re trying to enter a market where connectivity is somewhat limited. And I will say you should be informed about all these details before developing any mobile application other otherwise you can run the risk of wasting resources on something that nobody is going to use, and that would be very bad.

Perla Gomez  49:56

You mentioned earlier just how critical testing mobile applications Can you provide some actionable insights that can help our audience really get this? Right?

Paul Estrada  50:05

Yeah, of course. And so deploying a mobile application is not a very fast process, as we discussed, because you need to upload your application to a store first, and wait for that store to review your application before it finally becomes public. And because of that, testing is very critical for mobile applications. You will want to catch any bugs or iterations as early as possible before uploading to the store, and in order to mitigate the chances of your app being rejected, because that will just cause delay for the release. And of course, there will be extra work for developers To fix so, I think some practices that can help to make testing easier are for example, first one will be preferring lots of JUnit test to verify your code behavior. Julie, why well, unit tests are very fast and they can be run easily on on continuous integration services. And another thing is that we should try to break your application designs into your into joy components that can be shared in different screens. That way developers can test the components behavior to in isolation. Should from the whole application besides besides those those tests, you can have automated functional tests for for testing complete user flows or features. But, but this kind of this kind of tests, I think they this they should be kept to a minimum or, or only for tests that you need to run at specific times. For example, maybe you want to, you want to run you want to test if your user login is working two times a day or are just performing some other critical testing once every morning. So those kinds of tests are more are best suited for for for functional test boating Everything besides that you prefer to do lots of unit tests, because those will be faster to run. And and another difference is that if you if you want to do only functional tests for your user folks, typically these kind of tests need to run in the end installed the application either on or on a real phone, or on a simulator. And, and this is a slower process. Instead, if you if you only run JUnit tests that can be run on any supported platform, and that will be a faster process. In addition to those kinds of tests, I think it’s important to have a continuous integration server or are a cloud service for building and testing your app for each change that your developers are making, these services can be, can be integrated into your contribute system of choice to it to web hooks or some configuration. And that can be used as a verification step, before merging the code to your repository. So you can be confident that if some tests are failing, your team will be immediately aware of that problem. And the code will not be merged until everything is fixed. So that will help to reduce bugs in your releases.

Perla Gomez  54:49

What would you say are the key differences between mobile application testing and web application testing?

Paul Estrada  54:55

Yeah, so I mentioned earlier that mobile development is challenging, because we need to target two different platforms Android and iOS. And, well, this, this affects testing too. If we look into web development, you can, you can do some testing tools. And you can run your tests on different browsers. But in the end, you’re still using the same web platform. So you you’re only building your testing infrastructure and in your test only once. That is different for mobile applications, because because you have to use different API’s and create tests for each platform. And in some way, that means that that means that you are duplicates. Test. Because Because now you need to test the same functionality for each application in it. So if we suppose that you are developing for for both for Android and iOS. So there are some ways that can potentially help to avoid this problem. But But any non standard form of testing has some disadvantages. For example, if you if you use React Native for your application, you can target Android and iOS with with the same codebase. And well, at least that’s the idea. But now you will have to use the React Native testing tools. So these tools are not part of the mobile platform. So depending on How much functionality your app needs and what you need to test, you can find yourself dealing with unsupported use cases or, or with the problem of waiting for, for the framework developers to incorporate some things that you need today. And, and that can be a broad problem and a bottleneck for your development team. Another way is using cross platform testing solutions. There are some some platforms like APM, or other paid solution. And these tools are also outsiders to the mobile platform. In also they can be slower, they are more oriented to follow more manual and slower QA processes. In a script, so remember that what we are what we want is to make deploying our applications faster. So you might want to think twice about introducing potential testing bottlenecks to your delivery process. So I will say it’s if possible, and of course, depending on on how you are developing your project, we should prefer to use the the tools that are more closer to our, our target platform for that, because that will also make things easier for your developers. Now, not just to finish my point, creating test is for each platform is not really it’s not really bad from a development perspective. It is more important to have a good software architecture for your apps, even even because even the same architecture can be used, used in both applications, sometimes probably the implementation details could be different, but the overall design of the architecture to to support your business will be the same. And in a good architecture can help more to improve testing in the long run. And developers will be able to create this more quickly on each platform.

Perla Gomez  59:41

And after deployment, what are some strategies to mitigate failure scenarios or critical bugs once the app is released? unlife

Paul Estrada  59:49

Yeah, well, if you’ve been following along with this talk, you will recall we mentioned few things for driving new feature enhancements. And in those strategies include using feature flags and faced releases. And then these strategies can help during the release process to catch errors, while limiting the amount of affected users. And in the event of some critical failure in a new feature Juco could shoot down completely the feature control from your server and that can keep that can give you precious time to start investigating the problem and help your developers to do some research before releasing a bug fix. It In addition to that, I think it’s a good idea to Some event logging and analytics to your app. Because that way once once your app is released in the stores, if something is failing, develop, your developers will have some data to investigate why that particular error is happening. So these are, these are all reactive strategies, but let’s not forget the we should strive to prevent errors in the first place instead of reacting to them. So we should take testing very seriously. As I said before, we should do automating automated testing, and increasing increasing the code coverage of a project in define some code quality guidelines that Your teams will always follow because that will also help to avoid failure scenarios and of course, critical box

Perla Gomez  62:08

for elliptical. I have one last question for you. What qualities should business leaders look for in a mobile app developer?

Paul Estrada  62:15

Yeah, that’s the term. That’s a very good question. So, of course, besides General, software engineering skills, that you should look for any software engineering role, I think mobile developers should have knowledge on on mobile user experience and mobile user interface. We said before the user experience is very important for for mobile applications. So I think it is not enough to know how to program an application in and of course, we shouldn’t expect them to be UX experts. Because that that whole area of expertise, but but they should be at least at least they should be able to tell if a design doesn’t look right for model, and they should be able to discuss some best practices and trade offs with with the designers and UX researchers. And I think this is especially valuable if you are developing your application for Android and iOS at the same time. A second quality will be knowing about knowing about some flagships flagship applications and current trends in mobile development. We talk a bit about about trends in in software development, in particular for mobile, but no And this can be this knowledge can be helpful if you are open to experimentation on the technology stack. Or if you are planning to build variants of your existing services or existing systems. So if you don’t know exactly which technology stack will be better for your project, a mobile app developer that that has experience with different mobile platforms that will be very valuable for your project. And well, on a more on a more technical site. I think testing is very important. As we just said, during the length of this of this talk in a mobile developers should know to how to test code and use all the available tools. testing tools in benefit of the project. The more I think the more a developer knows about different ways of testing, the more that will help you to streamline your release process because that will help to improve the quality and the confidence of your project. And another thing that I think is important is some level of software architecture knowledge that the total are good quality to look for. Since mobile applications are different from web applications, developers you have the ability to identify all of those differences and, and to break down some feature time into into different components that we To make further changes easier, of course, that will depend on the specific role that your developer will have. I mean, depending if he is more junior role, or more senior or elite engineering role, but, but in general, knowing about good software design is a very valuable skill. And so finally, the most important quality that I can think of for someone will be their willingness to keep learning new things. mobile development is is a very highly evolving space. And it is very likely that developers will need many different programming languages for for Android and iOS for quite some time and And as we said before, there’s a lot of different development tools that we can use for your mobile application. So I think it’s very important that someone is open to learn other things outside of their comfort zone, if your project is going to need that. And yeah, I think that’s that’s a very, very important skill to look for.

Perla Gomez  67:30

Thank you so much, Paul, for being on the show and talking to us today.

Paul Estrada  67:33

Yeah, thank thank you. And I’m very glad we have this scope this talk and hopefully, this will help others when developing their model breaks.

Perla Gomez  67:44

Thank you, Paul. And thank you to our audience for listening. We hope you enjoyed today’s episode and make sure to tune in again next month. If you would like to receive updates for future episodes. You can subscribe on Apple podcasts, Spotify, Google podcasts, or most of the major platforms. Each episode will also be posted on a website template app.com not on social media tempo server on Twitter, and a tempo development on LinkedIn and Facebook. You can also email us to podcasts a template. com. If you have any questions, comments, or you have a topic you’d like us to cover next, until the next one, and I will miss it. Don’t miss any templates.