The podcast discusses the responsibilities of a mobile development team and how they differ from teams that only focus on writing code. Mobile developers can play an important role by providing expertise on mobile design patterns, technologies, and best practices to help other teams. They also need to work closely with backend developers to ensure APIs are optimized for mobile and address issues like battery life. In addition, mobile teams can help with testing, deployment automation, and even building internal tools to speed up their work. The podcast emphasizes that mobile developers should act as advisors and not just code contributors if they want to fully utilize their skills and provide the most value to their organizations. It highlights how mobile expertise can influence product design and strategy in ways that benefit both business and users.
Key Moments:
[MUSIC]
Hello, wonderful listener. Today you're listening to a new episode of the Brains and Viewers show, where Patrick and Wojciech discuss programming, building teams, workflows and everything else that it takes to deliver great mobile applications.
In this episode, we're going to talk about the responsibilities of a mobile development team and how it differs for just writing code all day.
Hey Patrick, nice to see you again. Hello Wojciech, nice to see you as well, and here you as well. The topic I had in mind for today is something that I have realized recently that is not obvious to everybody, but a mobile development team is a lot different than any other teams in a technology organization. So when our clients hire us and they have already a back-end developers, the web developers, infrastructure team, working with us is often a bit different than for them to work with their existing teams. And I don't mean it in a way that internal versus external teams, but I think mobile teams have a lot of overlap with other departments and there's a lot of value that we bring outside of just writing code. I think that if you are using your mobile developers just to write code, basically you're throwing half of their salary out of the window because there's much more they can do for you than produce lines of code. Just wait one second because perhaps we should give a little bit of a context because otherwise it may sound like, okay, we are mobile developers and we are just saying like, oh, the back-end developers are doing that wrong, or the API developers are doing it wrong or something like that. But the truth is that we came from back-end development and API development especially. We've been working for many years writing Ruby on Rails soft websites and back-ends and these kind of things.
And then we switch to mobile. So we have perhaps a unique, or perhaps we are just old, but let's say we have a unique perspective on seeing the back-end development,
how it's going and where the focus of the back-end developers are. And how is it to be a mobile developer? So it's not like we look only from one side, we are kind of looking at the problem from both sides. And this is what we learned in these last 15 years or something of our professional work with computers and coding. Yeah, that's a very fair point. Somebody might be new to the podcast and don't know our history, but yeah, we've been doing both back-end, also we've been doing web stuff back in the day when it was not called a full stack developer, but a web master. Master, oh my god. That was the title people used back when I started.
Cool. I wanted to structure this conversation in a way that we talked about different overlaps with other teams that the mobile team has, like in different directions. I would start with talking about how we work with designers and what's the overlap there and what's the value that the mobile developers bring there. Then with product, back-ends, infrastructure, stuff like this, to go focusing on each section.
So being a designer is hard. Their work is very difficult because often they are expected to be able to cover the web platform, the mobile platform, which is actually two platforms because you have the iOS and Android. It's not only about the way they would like things to be. So it's not they are coming with a blank slate and designing an interface. They have a lot of constraints on each of the platforms. The constraints are unique to the platform itself. A lot of responsibility that lies on us as mobile devs is to be able to talk with them about what the constraints are, what are current trends in mobile apps, and how people are used to do things. So, for example, I don't imagine all the designers will be up to date on how Apple Pay works and how its customers use it in the apps. But it's part of the job of the mobile developer to know it, to be able to implement it, to know what kind of payment flows we need to be able to handle. Basically, the whole app store rules, how they influence design. It's a huge thing. Starting with the authentication, where it's the mobile developer's job to point out when they're looking at designs, "Hey, I see you have a login with Facebook and login with Google button, but there's no login with Apple, right?" So they have to know that if you offer one of the so-called social logins, or I call them anti-social logins, you have to use the Apple one as well. Or that before you start tracking any analytics events, you need to show this pop-up from Apple that, "Hey, this app would like to track everything you do everywhere and send it to everybody." Also, you should know what are the rules around it, when do you show it, when you don't. All the GDPR stuff, it's different from web, it's different from mobile, but a lot of designers I worked with in the past, they have this concept, "Ah, that's the cookie banner." But it's different than the cookie banner on the web, right? You have your own rules, you also have to understand what happens when you show a website in the web view. Do you have to still show the cookie banner, or you don't? Because by default it's going to probably pop up, and it's up for the mobile developer to look at the early wireframes or design ideas. And be able to point out, "Hey, this is something we're not allowed to do, this is something we have to do." Or there is a way to do this thing that you're doing here, but in a more streamlined fashion. There's like a shortcut you could take. Some kind of live, you can put a live widget on a lock screen. Yeah, I've been talking a lot. Patrick has been nodding. Yes, especially when the designers are coming from the web, and mobile is something which they start to learn. And perhaps there is a notion that you want to have feature parity on web and mobile. Then in many cases, basically the features from the web get copied to mobile, and they are not really working. In most cases, some buttons are squeezed, because the web page is much bigger. And if you want to have the feature parity, you want to have all the buttons from the web. Some of the buttons will be just labels, which are much smaller than 44 pixels, and therefore they are not really clickable on mobile.
This is something up to us to point out, to help out how things should be working as well.
Not copy all the dropdowns which you have on the web, because the user doesn't have a fast way to select things. So you should give them the ways to select something. So basically, knowing what is the trend, as you call it, in the mobile, but as well, what is UX-friendly design for the others. Do you support dark themes in your app? Does your app be able to rotate? No designer probably is going to think about it. What's going to happen when you put your phone into a horizontal position?
What if the people are a little bit older, which are using your app, and they want the size of the phones inside of the app,
inside of the iOS, to make them bigger? How does it look inside of your app? There are a lot of things which usually are not thought about.
This is like things which happen, especially the size of the phones. Other things which are often forgotten are other error cases. Nobody likes to think about the stuff when you don't have internet.
It's totally different to the web pages, which usually are connected one-to-one, even if you open them on the mobile, it's a different feeling than a mobile app, which is meant, or should be meant to work as well, offline. One thing that you mentioned that I think is really important about the errors is, a lot of times designers cannot know whether something is an easier case, like you tap a button, and whether it works or not, you know straight away, or whether it's a more complicated process, and developers know whether it's asynchronous or asynchronous API call. So basically, booking a flight, you know it's going to go through three different services, and you have to have a screen in the middle while your stuff is being processed. Developer knows it, the designer might not know this, so it's our job to identify those cases. And I think there are like two groups there. One is like pre-implementation, and other is post-implementation. So the first part is spotting things that you need to take into account while designing. And the second is helping with testing and verifying, and well basically checking whether what you build is good UX.
And here comes a bunch of things that you mentioned, like checking the landscape mode, checking font scaling, stuff like this, that are non-obvious to designers. I don't think that designers should be expected to prepare a design, "Hey, this is the screen, this is the screen on an iPhone SE, this is a screen on iPhone 15 Pro Max, this is screen on Samsung Galaxy, and this is with font scaling 1.2."
Let's be real, we're going to have like one guideline what to implement, but then it's on us to test all those variations of it, and if we have any doubts how it should behave, we should be the ones who are reaching back to the designers, not the users giving a one-star review that they cannot click a sign-up button on a small phone, because the sign-up button is out of the screen on their screen size, right?
Another thing we could do is to offer a testing workflow that's comfortable for the design team to validate that actually after you've built the feature, you've implemented the designs, is this what they wanted? Is this the behavior that they had in mind? This means either testing builds, like have a comfortable way of working with testing builds. I think we touched on that in one of the recent episodes on JavaScript bundles, how we can do it in a comfortable way. There is one project where we use the end-to-end tests to screenshot every important screen of the flow,
and put the images together in one HTML file, and then put it on S3, and then the designer just gets a link, and they can click without having to click through the whole thing, then can easily take a quick look whether everything seems all right. We did this for the two platforms, for iOS Android, for different screen sizes, and different translations. We did English and German, so you would have like six HTML files to browse through instead of having to install six apps on like six different phones, and change languages, and all that. This idea is not going to come from designers, this is an idea that should come from your mobile team, that hey, we can do it, do you think it's worth the investment? Yeah, that's a telly. I'm talking too fast, but that's because I'm excited about this.
I'm really hoping this episode will be useful to many teams, because a lot of times I feel that we could and we should as an industry, as a group of developers, be doing more for other departments, because we can do a lot of things. So that sounds like instead of getting a quiet developer, which gets the task disappears and brings the task back, you should invest in loud developers, which are vocal about issues and features and so on, so they are first correctly made before even somebody starts coding them. This is the way how you can win happy customers, happy users for your applications, you know, like making the right app in the least expensive way, instead of, you know, like programming, programming, programming, and then single, this is a bunch of crap. You know, like you should spend time and talk to people who knows how make mobile application before writing a lot of code. I totally agree. I think it's this old mentality of development where you get the Jira ticket and then you implement it and you throw it over the wall to the QA team that you never see. New way is trying to use the tools that are available to us to have as short the feedback loop as we can to be able to iterate faster and better. So like there's no faster iteration than discarding an idea while it's still being considered.
How changing it. Yes. Because when you think about it for 10 minutes, it can sometimes save you 10 hours of development and testing. Apart from tools like Microsoft Code Push that lets you deploy changes faster, like we should also take advantage of the tools that are in our heads and make sure that we communicate clearly. We were on the same page about the features we want to build and what's the best way to deliver them. Yeah, but apart from that, also business is important, right? So it's not just about the design and the user experience. The product team also deals with business constraints and there are things that we can offer there as well. So one thing that is tricky sometimes on the mobile is getting paid. The easiest way to get money from the user is using in-app purchases or have a paid up stuff like this.
But this is not the best way from the business perspective because of Apple's Commission.
As a developer, you have to know what the rules are. Why does booking a car on the app is fine? Because you'll get all the money that the passenger pays for the ride.
But if you want to sell an ebook, then you have to be ready for the cut from Apple, right? And how big the cut is, what are the conditions and so on. Because this is a conversation where the mobile developers can be consulted on that. There are things you might want to do, but they are not allowed. Like you link to the website where you can pay by the content and Apple doesn't like it and so on. So yeah, there are some technical constraints with such a seemingly business oriented decision about pricing. That's another thing where we can help. There is also for the product a bunch of tools we can do for testing and validation. The whole setup for how to get the testing built out to everybody on your team that should get it.
You can build custom testing tools like your on the staging build, you shake the app and some secret menu pops up where you can track latest analytics events to see if the tracking set up correctly or report bugs directly to Jira or switch branches to validate different tickets. There's a lot of technical solutions we can offer, right? For me, what we have to bring to the table is the knowledge of the ecosystem and of the iOS and then Android. Because it is impossible for product people and so on to follow all the changes which happen every year on iOS and Android. There are basically too many new things, new APIs, new features added on the yearly basis.
No product person is going to have time for this. This can sometimes transfer your business in some very interesting ways. For example, if you want to sell tiles or paint for some do-it-yourself changes in the home, then you can tell the user, "Please use the measure tape and measure the wall you have or the whole room in your house." Then we give you this nice calculator which was copied from the web where you can put all the measurements and we're going to tell you how many liters of paint you can buy, which is fine. It's like improvement. It's like everybody does it, right? Yes, but this is what you have on the web and that's why you have it on the mobile. But if you have a really true mobile first experience, then you would use new SDKs and new APIs which are available in iOS to measure the room automatically just by pointing your phone on four walls. You will have all the measurements excluding all the openings like windows, doors and so on. Done in seconds, you don't have to even clean up your room to make the measurements, which is pretty convenient.
If you implement this, you can have a game changer in the way that you can sell more stuff, but as well you can market yourself as a more technically advanced company comparing to the competitors. This is things which has to come from us because most of the people are not going to be able to keep up with all the changes in iOS and Android. This is where your company can get a huge value from mobile first developers. True. That's a great example how we can help influence the product in a way that is beneficial for the user.
Another direction where we could expand our mobile team, I think would be the marketing. What I'm thinking about is mostly app store listings.
It shouldn't be in a way that developer uploads the build into app store and that's it because there is still you should write a change log and who knows what changed better than the developers, right? So maybe a first draft should come from us and then somebody from marketing, a copywriter or a product manager decides how deep to go into descriptions of what fixes we did and what features we've implemented.
Just one question because I never ask you about it. Are you a person who reads the change log of the applications?
Perhaps I answer first so you're not on the spot. So I do read them and I like them if they are funny, but I like them as well if they are totally technical. I hate those which is like, oh, we just work as usual on some minor improvements and minor bugs and nothing else. I hate those things. For sure you've done something you could write if you update the app once in two weeks or something like that. For sure you've done something otherwise you wouldn't push it. So please like give us some extra. I think I mostly read those that other people have read and found them funny and put them on Twitter that I like look at what a funny update there is. And then I actually check if it's real, like if it's an app I use. But sometimes I do look at them and usually I'm disappointed because it says bug fixes and performance improvements and that's it. I think like the users deserve better and I understand that a lot of teams don't put attention to it because it seems not important. But yeah, it's part of the user's experience in you might have more important things to spend your time on. But also keep in mind that like this should be done. It should be somewhere on your priority level. And at some point of development of your app when you take care of the obvious things, you get to a level where this becomes important enough to to care. Another thing is screenshots.
There is like those word rules from Apple about screenshots that they have to be real and from a device. But a lot of app they have screens from the design on like a background with some text on it, which is obviously against the rules. But they pass the review somehow. Oh, it spreads across three or four screenshots stretched. That's the typical. It's not allowed. But yeah, a lot of people do it and those people get away with it. I don't know if Apple is more lenient on it. Me personally, I still have an app that is like in the limbo on the app store because I tried to update it. I used the screenshots from the emulator. They rejected the update, but I cannot build it anymore because we've done with some super old libraries to take me hours to get the development stack working so that I can build it again and get accepted. And only then I could like pull it from the app store because if it's in the rejected state, I cannot even delete it. But yeah, those screenshots, for example, Apple would like you to do them on iOS, do them on the iPad and so on. And that's something that we could do automatically. Like you could set up a script to transfer them to an test and prepare them and resize them into proper dimensions. You don't need to give this job to a marketing intern, right? Yeah. Yeah. So you could do, I don't know how many marketing teams do it, but like you can do a B test in the app store. I think it depends because sometimes they be tested. It's a domain of product and not marketing. I mean, a B tests not within the app itself, like not only within the app itself, but also within the app store listing. So check whether this screen should work better than this or that the description is better. OK, so those are things you can do and not many people know about it. Right.
And yeah, the whole analytics tracking kind of warms, something that I dread this conversation on every single app, because then you have to explain the rules about like, what are the Apple's rules? What are the GDPR rules? Why are showing one banner for the GDPR purposes? You still have to show another banner for Apple, like all those things. It's on the mobile developer to explain it or offer alternatives, how we can like track without discounting us as tracking. Right. Because we talk about tracking and Apple is about sharing this data with third parties and so on. So all those tiny details is some kind of overlap of legal developer and I know marketing because you have to ultimately understand what data, what this data will be used for. So you need to make it user friendly and useful. I think you have another thing about Beck and maybe you should talk about it because I yeah, my relationship with Beck and developers is full of often disappointment.
I have high expectations and then I get the swagger API documentation that does not reflect what kind of types. Does it return what kind of errors it can throw and then nobody wants to fix it because it's auto generated and it's difficult to make it work nicely. It depends really if you the mobile app is the first thing which consumes API or you're the afterthought of API made from a web, right? Because we basically as a mobile app may want to have different data or wants to consume the data differently. For example, one of the fastest way to drain battery on your phone is to leave the data access on when there is bad coverage because the phone needs to to amp the voltage for the antenna to be able to transfer any data and many times you're going to just get data is going to hit the time out so they have to really repeat the call and so on and your battery goes to ground. As well, the other thing is like how you can drain the battery very fast is if you have like API call, then nothing and then next API and call and then nothing because the antenna stays on a while after you make the call and then just drops later. So if you are like just making the second call just outside of this this gate when the antenna is on, then you have to wake it up again and so on. So sometimes basically the mobile would like to be able to get more data in bulk.
So we don't have so we can kind of save the user from from draining the battery because on some point, you know, you're going to go to settings in the iOS and try to find out what what is killing my battery and perhaps you're going to say, okay, this app, I don't really need this app so much and they can delete your app. Right. And once the API is already existing for web and you are just after thought, then it's really hard to change anything. But this is one of the things you have to kind of think and give this thoughts to the back end developer, you know, like how the mobile wants to consume the data because this is really fast. It can be a game changer on the mobile. You cannot stress enough this antenna example that you had because actually even like not many of the mobile developers know it. But basically, if you set up a polling system where you ask for every 15 seconds or 20 seconds for for data, you think, oh, it's not a problem. Like it's three times a minute. User is five minutes on the screen. Like how many how much data it's going to come over the wire. It's not going to hurt his data allowance. Yeah, data allowance may be not what it means that the antenna never has the time to actually power down. So it's it's on all the time. I think we need a very proactive role with working with the with the back end teams. I think it's very optimistic to assume that they will know what we need because, as you mentioned, they're like, good and bad things, whether you're coming after the web or being developed at the same time. Because on one hand, if there was a web single page application before, there exists an API that you could use. But as you say, it's not tuned necessarily for for what you need.
But on the other hand, if you're the first one, they're building an API for you're going to be facing a lot of issues where they didn't think that you would be able to do that. They didn't think that you would make this API call before the user is created and more something. Or is this available to sign out users and and all those things that would be cleaned up while we're working on the web app? Like now, now you're at the forefront and you're helping solve those issues. Another thing to do, like where you have to play some leading role is that many back end developers won't think about versioning API or basically deprecating calls because for them it's OK. We just deploy a new version. The web will reload and use the new features, new APIs. The ones will be forgotten, but we don't have the same on the mobile because on mobile, an app can live a few months longer than a refresh of the web page. So this is up to us to guarantee that our users won't be cut off from the APIs. So we at least have to talk about it with back end and find out the strategy, how to deal with it. We need to be involved at the level when API is being planned, where the decisions are being made, whether an API call is synchronous or asynchronous, or what kind of data it returns, what kind of errors it can produce, what's the format of errors, stuff like this we need to know about.
Another thing is security. A lot of times teams think of security in a way that, hey, we shouldn't give this option for the user to do it on the mobile. We should hide this button, but they forget that in the end it doesn't matter if the button is there, if the API call is open because anybody can disassemble the app. You might think that nobody's going to do it, but it's enough if one person does it and writes a script and abuses your backend calls and downloads all the events from your database one by one.
So yeah, those are things that we need to help identify when we look at the APIs, right?
We're all in this game together, so a backend security issue is a company security issue.
We're looking at those API docs for a long time in our workflow. We spend a lot of time implementing those. We have a possibility to spot a lot of things that we should bring to light.
Last thing on my list is infrastructure. I would start also on the security angle.
It's our job probably to educate the security team inside the company because a lot of times they are used to looking at the programming security through the lens of backend or web while mobile security is different because a lot of times. For example, if you have a vulnerable dependency on the backend, somebody can use it to, I know, SQL inject something and steal data. They will steal data from the server.
And a lot of times if you have a vulnerable dependency on the mobile app, the user can use it to hack themselves because if they can do something to the app that will trigger an API call to the backend that will extract some data,
the problem is not in the app because the API call can be done without the app, so it's a backend security issue. And a lot of times those vulnerabilities are like the user can hack themselves to extract their own data. Of course, it's a different consideration if you're talking about apps that contain medical data. And we would like to have this data secure even if somebody steals the phone and has like third party access to the phone. But a lot of times we're asked to fix issues that on paper that says, "Oh, it's a critical security vulnerability." But in the end, there's not a single thing anybody can do with it. Fixing it doesn't really change anything. And what helps me with those conversations is to talk about the attack vectors. How can you explain to me how this could be exploited in a practical purpose? For example, this leads to my pet peeve, the depend-a-bot on GitHub, where I think it's useless for React Native repos because in node modules you have tens or hundreds of thousands of dependencies.
And of course, some of them are going to have critical vulnerabilities. But one thing is what we talked about. They are not really critical for our use case.
And the second thing is sometimes they are not easy to solve because what you can or can't update depends a lot on the React Native version you're using. And sometimes it's painful to update. Sometimes you want to wait with the updates so that some of the issues, early issues, are going to be smoothened out by other teams, other people finding bugs. Yeah, it's not mobile friendly. We have to be educated ourselves to be able to have a conversation about the practical aspects of security with the security teams in organizations. Because in the end, what they want is to have a secure infrastructure, secure environment for the users. And we want the same thing. It's just that we need to align on what are the best ways to get there. Yeah, I totally agree. Another thing that I want to talk about is the whole DevOps deployment, shipment, but it's maybe something you can touch on because I think you like this subject. That is something which we can pull out into separate episodes because that's kind of a longer discussion and we already, I think, 43 minutes into the episode.
And it would be sad to just skim over it. But yeah, just perhaps to mention a small teaser. You have to do a lot of tasks when you build an application or you develop an application. So you have to build it, like send to, as you said, to App Store, do some screenshots. And there is a lot of stuff which takes, I don't know, 5, 10, 15, half an hour, which if you do it locally on your computer, you cannot do anything else. Basically, the process is running. So you can offload this to some other machines and do a lot of things automatically.
And this is true. This is what I really like to automate these kind of things. But I think we could talk about it in a separate episode. But basically, this is again something which nobody else is going to tell you to do it. It has to come from you. You have to come to, I don't know, product or some deaf engineers and tell them, okay, we have to optimize this. Otherwise, we're just burning cash and time and we don't have to do it. But yeah, let us tell you how to do it. Yeah, right. There's also a bunch of things around like ops and infrastructure that we touched on before. So the whole design ops movement where you find a way to automate the workflow, working with designers that I know, importing icons from Figma automatically or having a design system where they could define values using some tokens. A flow to automate it, it's going to come from the mobile team. Solutions for backtracking and making sure you get good reports for reproducing bugs that are happening to the users. That also should be owned by the mobile team and all the things around running a software team, how to measure the progress. Because everybody knows it's not in the lines of code that matter. But figuring out what are valuable metrics, valuable KPIs that you can use for a mobile team because it's also specific on the type of work that you do. Finally, there's one thing that applies when you work with a bigger organization and you have the resources for that, is to building tools for developer experience. So if your company is big enough, it might make sense for the mobile team to build servers for themselves, like APIs that help them deliver mobile things by themselves faster.
I know we worked on a team that used Firebase stores to hold data that was too complicated to ask other teams to build them a server that holds it. They were just pushing this to Firebase.
And this might be a solution, but also maybe you should have a tiny, tiny server where you can put things that you just need for your own mobile specific needs. The mobile team should spend the time to figure out what else they can build from outside of their core expertise to help them deliver better software, deliver a ship faster and maintain quality.
Yeah, that comes with the knowledge. You need some people with experience to find out what they need. Basically, you don't know what you don't know. So you need somebody with a few years in programming to go this route. It's not an easy one, but it can be a very fulfilling one. A lot of times it's difficult to spot what you could easily build to make this problem go away. Yes. Yeah, I think we're going to wrap up here. I think our main point is that if you're paying your mobile developers just to write JavaScript code in a GitHub repo, like you're throwing money out of the window because there is much more they can do for you, for your organization, for the product than just like delivery features.
And I think it's different than from the other teams. Of course, the other teams should also influence the product. But I think the difference here is that the mobile team has at the end of the delivery cycle, meaning infrastructure team build servers where the backend team provides services that they put API on top that we use to deliver value to the user. We're like the last border between the company's IT and the final user. So it's our responsibility to make sure everything aligns properly.
And also, we're privileged to be able to influence the user's experience so much. So yeah, we should use this opportunity and make sure we influence the product, we influence the designers for the benefit of the users, and we're not just like code monkeys.
I hope that was useful. And I hope if you're not a part of or if you're not running a mobile team, now you have a bit more clarity on how such a team would fit into your organization, what to expect from a good one, how to judge whether the team you have like need some support. If you'd like some support, or if you like us to help you with your app, don't hesitate to contact us, you know, nowhere to find us. We have a website, you can go there, click hire us. And then we will try to help you. Other than that, have a great week, weekend, depends when this episode is dropped. Tomorrow.
But whatever you're having, make it great.
Enjoy and stay happy and hopefully see you soon. Talk to you soon. Ciao. Bye bye.
things are worth discern to subscribe, check out another video by clicking on this channel. Co lit up and watch me regardless of sound effects, where you can as well give as feedback. Or suggest a topic for the future episodes. We will be very happy hearing back from you. Stay safe and curious. Till the next one, bye.