Q&A: What’s on mobile app builders’ minds in 2024?

Jamie Lynch, Android Engineer: It’s easy to sell a feature, it’s hard to sell clean code. Over time, too many features and not enough tests, maintenance, etc. have the potential to kill a product (and even a company). This usually ends up as a tug-of-war between product and engineering — but it’s important to remember that both sides are right. Yes, it’s important to ship new features and stay ahead of the competition, but some of those features probably won’t get the desired adoption. Yes, it’s important to fix tech debt & have an understandable codebase, but not everything that engineers want to work on is necessarily going to help that aim. The best way to align is for engineers to have the current business situation at the back of their minds, and for everyone else to ask themselves whether they’d fly on an airplane that had been implemented with their current product development process.

Austin Emmons, iOS Engineer: In my experience, engineers are focused on app performance and also code cleanliness. Managers can be focused on releasing new features but don’t concentrate on code cleanliness unless it might affect future development. There is always a push to ship a new minimum viable product (MVP) as quickly as possible but not often are people focused on iterating the MVP and refining its strengths.

The best thing engineering orgs can do to facilitate alignment is to say “no.” It’s important to define the boundaries for the technology you’re building and what problems you’re trying to solve. If a feature doesn’t fit within those boundaries, don’t hesitate to say no. If the team is moving in fewer directions simultaneously, it will naturally align.

JL, Android: Effective triage of bugs is really important. Not all bugs are worth fixing — if a crash happens on one-out-of-a-million devices and doesn’t have an obvious cause, is it really worth spending an engineer’s time to investigate when they could be improving an app’s features instead? This usually ends up as a negotiation between internal stakeholders that creates some sort of triage process that gives a reasonable balance.

Process is also something that ideally a team should be able to ignore and change, with the caveat that there’s good reason to do so. With that in mind, it should be discussed within the team and department first! If rules aren’t working or are slowing things down, then the team should be empowered to remove those obstacles. In practice this can involve quite a few conversations with stakeholders and might not always end with the desired result, but again, it’s a case of striking a balance.

AE, iOS: This is a very tough question to answer as I believe it really depends on the team. Each team needs to figure out how best they work together. The only guidance I can give would be the following:

1) Make sure the channels that are meant for cross team collaboration exist and are being used. It’s important to have discussions in these channels so that people see that they are effective. This means explicitly pushing hallway conversations and/or meeting notes into these channels.

Be sure to ask for feedback, as well. Recently a team member of mine outlined a meeting I wasn’t part of and finished with “Please, if somebody has something to say about this or any decision: this is the right time to speak up, cause time is running out.” It allowed me to immediately take action and provide feedback.

2) It is important to convey urgency when decisions need to be made urgently. Recently, my team was in crunch mode pushing to an open source release of our SDK. We created a “Decision List” of items that are ordered on priority (“Now,” “This Week,” and “Before Release”).

We initially met 3 times a week to review this list. Each decision varied from naming conventions, lint rules, up to architectural designs. We would push ourselves to make a decision on each topic, but if we couldn’t, we at least had a meaningful discussion. As our crunch subsided, we removed meetings from our calendar and now only meet once a week if there are outstanding topics. Be sure to adjust the team calendar often so you aren’t left with recurring meetings just because.

3) Discuss the future. Have the “what if” conversations and allow teammates to discuss the potential of the technologies they’re working with or building. It’s important to allow people to give input on what is possible. If/when people agree that some possibility is useful, it provides a direction the team can move toward. This allows individuals to make the minor decisions align with the high-level direction the team has discussed.

JL, Android: These are all great things to track. ANRs is one key metric that I would definitely track on Android, particularly as it impacts your ranking on the Google Play Store. It’s pretty much impossible to reduce ANRs to zero as on rare occasions lower-end devices won’t have enough CPU to perform even basic tasks. However, it’s important to track this metric and keep below the ANR vitals ‘bad behavior threshold’ — if for no reason other than it’s super frustrating to open an app and for it to completely freeze on you.

AE, iOS: Outside of those mentioned, the only one I would consider would be “Idle Time.” This should measure the time a user spends waiting for content to load within the app. Idle Time depends on the structure of the app, but full-page loading screens can agitate users. If these are left too long, the user will get frustrated and quit the app. If these are used often and appear very quickly, it may disorient the user as items they are trying to interact with may be flickering out from under their eyes.

The one component of this “Idle Time” metric that I’d focus on is the app’s startup time. Measure the time it takes from the entry point of your app’s logic up to when the initial content of your app is visible and interactive. It is very common for an app to have an initial “hello” API request or even a series of handshakes with backend services in order to start properly. Monitoring this interaction is key because your first impression is always the most important.

JL, Android: From my experience working on both Android and iOS, Google has a very strong focus on providing excellent developer tooling. It developed Android Studio, various libraries, and has pushed the entire ecosystem to migrate to Gradle in the past. I think that culture has permeated throughout the community and Android engineers really care about saving time. Android itself is also open-source and has a healthy amount of community-maintained libraries — Google has invested the time to make it pretty easy to develop libraries, so perhaps there is less of a barrier here than on iOS?

AE, iOS: This is a really interesting observation. My only guess on why these priorities might differ is the underlying ecosystems these engineers work in have similar priorities.

iOS, being an Apple platform, has strong vertical integration and there are very little choices to make when it comes to core technology. Apple has made it so easy to accomplish common tasks that it becomes the de facto standard for these tools. This is somewhat self-fulfilling: Apple provides a tool which, to some extent, dictates how my app’s tech stack is shaped. When I want to build a new feature, it’s likely I’ll first look at what tools Apple provides so that integration will be simple. This leads iOS developers like myself to mimic a lot of patterns that Apple uses, as doing so means that what I create will be as intuitive as possible for my audience.

On Android, the ecosystem is much more varied. The platform is open source and developers deal with flagship devices from manufacturers across the globe. The technology stack, initially driven in Java, was also incredibly prominent for much longer than “smart phones” themselves. This allowed for existing third-party tools to shift into the Android ecosystem without the authors even knowing! To put this into perspective, one of the most prominent networking libraries on Android, OkHttp, is not developed or maintained by Google themselves. I think this shows incredible collaboration.

JL, Android: Extensibility. I want the ability to add instrumentation to parts of my app that I suspect might be a performance bottleneck, and then to automagically have a backend produce insights based on that data. I’m the expert in how my app works, but I don’t want to waste my time setting up my own data analysis pipeline in most cases. For example, if I have a custom navigation stack, I’d like to track how long transitions take between screens as a span. This then gets me an idea of what the performance is for the average user, and I can filter based on metadata such as power-saving mode to get an idea of what the root causes are of any performance issues.

AE, iOS: I’d say simplicity. I want a tool that tells me what is important and doesn’t leave me out to dry when I need to figure something out. Introduce me to a few baseline metrics, teach me why they are important, and then walk me through creating new metrics that I can use in my app. Adding custom instrumentation should be intuitive. Customizing dashboards to analyze this data shouldn’t take a stats degree. It can be really difficult to keep things simple, but I’d much rather use a tool that keeps me comfortable than one that overwhelms me.

The 2024 Mobile App Builders Report aims to help engineers and technology leaders better understand the motivations and challenges that their peers and teams are facing every day, and hopefully provide some insights that inspire them on how to work more effectively in an increasingly complex and competitive industry. engineering orgs better align, identify key roadblocks, and work more efficiently in an increasingly complex and competitive industry.

The survey asks respondents questions on a wide range of subjects, including:

• Day-to-day priorities and frustrations.
• High-level mobile KPIs.
• Perspectives on tooling, purchasing, and decision making.

Learn more about what’s on mobile app builders’ minds by downloading the report here.