Why are Mobile Engineers different from Web?

Mobile Engineers are a mix of software engineers and UI engineers. Here at Enova we work in Java or Swift, with unique build and distribution processes depending on the delivery platform. Mobile engineers have to drive everything to be simple; for one they do not have the screen space that a web page may have.  They also have to account for the hardware in their engineering (i.e. cellular connection, bandwidth, battery usage, lower memory, or lower processing power).

But perhaps the biggest change as you’ll see below is that it’s a new kind of front-end, distinct from our usual desktop and mobile web experiences.

The difference between mobile and software engineers at Enova

Languages

Our software engineers at Enova, work in Ruby or Go for most of their software creation whereas our mobile engineers either work in Java or Swift. We have one team focused on iOS/Swift/Xcode and one that focuses on Android/Java/Android Studio. Currently we have two legacy Apps in the wild (one Android and one iOS — written in Objective-C — with each a couple thousand daily users). We also have two apps in beta, one of each OS flavor.

Last year (2016), we did a review of the hybrid mobile options as well React Native, Progressive Web Apps, and Flutter. Because we are building out multiple Apps from one codebase in iOS, essentially a white label app/factory (Optimus Prime), we wanted a good framework/language for abstractions e.g. not React Native/JavaScript, so we are using Swift.  With Android we will build two Apps and then build out our multi-app platform.

APIs

Our products and platforms are a real mix; most do not have endpoints for mobile.  We are trying out a number of approaches at this time.  One is a Ruby gem (Mobilatron) that sits in our Rails frontends, that creates the necessary endpoints for our mobile clients to talk to. Another is a “brand box” with standard REST endpoints to talk to all its frontends. Another is GraphQL from a brand box that encapsulates business logic. 

Our mobile engineers have to be clear about what they need from our product teams. And be able to advise when necessary on approaches to APIs.

Examples include:

1. Understanding of common API best practices and what to ask for from a good API
2. Understanding of the differences between conventional data formats e.g. query string, form, JSON, XML, etc
3. Proficiency with the design and use of APIs and with considering the real world implications for networking, security and performance

Mobile UX/UI

Not surprisingly the UX and UI is different from web, in part because the control mechanisms are different, the displays are reduced, networking is not reliable and you have limited resources in both power and processing.

Mobile engineers are a combination of your software engineer and a UI engineer. For us at Enova most business logic is implemented by Product teams, so most of our work is frontend.  There is still a level of complexity created by the abstractions needed from our iOS white label/Factory.

Examples include:

1. Can understand and describe the differences between web users, mobile web users and native users, in terms of behavior and expectations
2. Can comfortably describe the design challenges between different mobile devices e.g. screen size
3. Considers the implications of the product, its customers, their cultural differences and technological differences when making technology recommendations e.g. who uses one thumb versus two thumbs for controlling their phone
4. Knows Material Design and/or OS Human Interface Guidelines
5. Creates custom UI elements where needed
6. When do they get to see a customer using a App? Which fingers do they use? what if they have shorter figures?

Mobile Security

It is easy to steal a mobile phone, so we have to think about security in this context as well as everything you would expect from Web and Application Security. People use their phones differently than their laptops; the controls are different, which leads to different potential attacks.

Examples include:

1. Understands the main areas of Mobile Security as defined by OWASP
2. Able to secure the App and protect the customer’s data
3. Understands the main areas of Mobile Security, the main vectors of attack as well as emerging vectors of attack

App Store

The primary distribution methods, i.e. The App Stores, have complex and “special” sets of processes. It also adds a

Examples include:

1. Knows how the App store works in both requirements and processes
2. Experience delivering at least one major iOS/Android application
3. Can coach other engineers in the use of the App Store

Tools/Frameworks

Like most software ecologies there a bunch of tools that can help with productivity in mobile App creation. The foundation are Xcode or Android Studio. Over the next quarter we will be building out CI, as everything is manual.

We are starting to discover that our Mobile teams use Jira in a different way to some of web colleagues. We are still figuring this out.

Examples include:

1. Familiarity with industry-wide best development practices including different ways to build a Mobile App, whether it be HTML5, Hybrid, or Native
2. Work with multiple technology stacks to deliver the right Mobile experience for our customers’ needs, i.e. use the right tool for the right job, whether it be Native, React Native, PWA or even Flutter
3. Mobile Analytics – e.g. New Relic, Adobe Mobile Services, Fabric?
4. Push Notifications – Native or third party service

Mobile Testing

Whilst mobile engineering is growing a culture of testing, it is not comparable to the Ruby community. Mobile Testing is a bit different, the failure cases are much wider. For example, a lazy engineer may only test on a simulator or on a brand new device in a super fast wifi zone and never in poor cellular zone. Most modern mobile engineers will build unit tests, but what about UI Tests or integration tests?

Examples include:

1. Mobile Testing – How do they do it?
2. What testing frameworks do they use?
3. How do they test responsiveness?
4. How do they mimic their customer device and network setup?