Mobile App Team Setups Discussed
I recently had the pleasure of hosting an enlightening discussion about different setups of mobile app teams with André Basse (Managing Director at SPIEGEL Tech Lab GmbH), Fevzi Kahraman (Head of Engineering at Bonial), Kenny Kremerman (Staff Engineer at Bonial), and Rodrigo Silva (Staff Engineer at Bonial).
Together, we explored various setups for native mobile app development teams, thoroughly examining the advantages and drawbacks of each approach. This article aims to break down these setups and provide a comprehensive summary of the invaluable insights shared by our esteemed experts from diverse companies. Join us as we explore the context-specific, optimal configurations for fostering innovation and efficiency in mobile app development.
Setup 1: Progressive Web App (PWA)
Progressive Web Apps (PWAs) offer a web-first approach to mobile app development, utilizing web technologies like HTML, CSS, and JavaScript to provide an app-like experience. PWAs can be a cost-effective solution for companies with strong web development teams, as they do not require separate iOS and Android codebases. This approach can significantly reduce development time and maintenance costs. PWAs are particularly advantageous for companies looking to reach users across multiple platforms quickly and efficiently.
However, PWAs have limitations compared to fully native apps. They may struggle with performance and cannot fully leverage all native device features, such as advanced camera controls or push notifications, especially on iOS. Additionally, while PWAs can provide a seamless experience on modern browsers, they might face compatibility issues on older devices or browsers. Despite these challenges, PWAs can still be a valuable tool for companies prioritizing broad accessibility and lower development overheads.
With the release of iOS 17.4, Apple made significant changes to how Progressive Web Apps (PWAs) function on iPhones in the EU. Following developer complaints and media reports, it was revealed that PWAs were no longer functional, effectively demoted to mere website shortcuts. Apple attributed this change to the new EU Digital Markets Act (DMA), which mandates the allowance of different browser engines. Apple explained that the complexities introduced by this regulation were the root cause of the issue, leading to the disruption of PWA functionality in the latest iOS betas.
After a short time, Apple has reversed its decision to block Home Screen web apps in the EU, but since Apple and Google are in control of their native OS system, you should keep an eye on future limitations.
Setup 1.1: PWA in the App Stores
To increase discoverability and meet user expectations of finding apps in app stores, PWAs can be packaged with a native wrapper. This allows them to be listed in the Google Play Store and Apple App Store, providing the benefits of app store distribution without requiring a fully native app. Tools like Apache Cordova or Capacitor can wrap PWAs, enabling them to be installed and launched like native apps.
While this approach can bridge the gap between web and native experiences, it comes with trade-offs. Wrapped PWAs still face the inherent limitations of web apps, such as reduced performance and limited access to native APIs. Moreover, the user experience may feel slightly off compared to fully native apps, as noted by users who can detect minor inconsistencies in animations or interactions. Despite these limitations, wrapping PWAs for app stores can be an effective strategy for companies needing a presence in app stores without the resources to develop full native applications.
Additionally you should consider the App Review Guidelines from Apple:
4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. [..]
Setup 2: App Team collaborates with Web Team
In this setup, the app development team works closely with the web team, often sharing APIs and backend services. This collaboration allows for a more unified approach to content and feature delivery, ensuring consistency across web and mobile platforms. By leveraging shared resources, teams can streamline development processes and reduce redundant work, as the web team provides content APIs consumed by the app team.
However, this setup can introduce dependencies that may slow down development. The app team may have to wait for the web team to implement or update APIs, leading to potential bottlenecks. Additionally, differing priorities between the web and app teams can cause friction, especially if the web team’s focus diverges from mobile needs. Effective communication and aligned goals are crucial to mitigate these challenges and ensure smooth collaboration between teams.
Setup 2.1 Hybrid-App with HTML content
According to André, Spiegel is taking an even more lightweight variant of this approach, combining native chrome with content rendering in HTML, adopted and provided by the web team. Even though it compromises on usability and does not support an explicit App Use-Case in all areas, it provides a very good hybrid solution with limited native app resources.
According to Andy Kalies, Business Insider is taking a similar approach for their news app.
Setup 3: Cross-functional App Team
A cross-functional app team comprises all the necessary skills — such as iOS and Android development plus Backend development — within a single team. This setup allows the team to work independently, reducing dependencies on other departments. By having all required expertise in-house, the team can iterate quickly, respond to changes, and deliver features more efficiently. Integrating the backend development in the native app team itself, allows optimizing the native app interfaces and shifting as much business logic as possible to the backend, avoiding to have to implement it twice and being able to change it quickly without app releases.
The main challenge of this setup is the increased cost and complexity of staffing. Ensuring the team has sufficient expertise in all areas can be resource-intensive, especially for smaller companies. Additionally, maintaining a balanced workload for all team members can be challenging, requiring careful project management to keep everyone effectively utilized. Despite these challenges, a cross-functional team can significantly enhance development speed and product quality by fostering close collaboration and accountability.
Setup 4: Cross-functional App Team with Server-Driven UI (SDUI)
Incorporating Server-Driven UI (SDUI) into a cross-functional team setup can enhance flexibility and reduce the need for frequent app updates. With SDUI, much of the UI logic is handled server-side, sending predefined widgets to the app for rendering. This allows for rapid updates and changes to the UI without requiring users to download new versions of the app, making it easier to experiment with different layouts and features.
This approach also simplifies the development process by centralizing complex logic on the server, reducing the burden on app developers. However, it requires robust backend infrastructure and careful design to ensure smooth and responsive interactions. SDUI can significantly enhance agility and consistency across platforms, but it demands a strong collaboration between frontend and backend teams to manage the dynamic UI rendering effectively.
Setup 4.1: AppCraft
Zalandos AppCraft is an advanced implementation of SDUI, providing a platform for building native pages through a graphical interface. Managers and non-developers can construct pages by dragging and dropping elements, which are then rendered natively in the app. This tool allows for rapid development and iteration of new features, reducing the dependency on developers for every change.
While AppCraft can significantly speed up the development process and make it more accessible to non-technical team members, it also requires a substantial initial investment in setting up the infrastructure and training users. Additionally, maintaining the balance between ease of use and the flexibility to handle complex scenarios can be challenging. Nevertheless, for companies looking to empower a broader range of employees to contribute to app development, AppCraft offers a powerful solution.
Setup 5: Cross-functional App Team, SDUI and Content Adapters
Combining cross-functional teams, SDUI, and content adapters aims to maximize flexibility and efficiency. At the heart of this setup is a shared widget DSL (Domain Specific Language), which acts as a contract between the domain-specific teams and the app team. This DSL defines the available widgets and their configurations, allowing domain-specific teams to specify how their content should be rendered without direct intervention from the app team, as long as it is displayable with the existing widgets.
This approach promotes specialization and faster development cycles by enabling domain-specific teams to work independently while sharing a common infrastructure. They can focus on their features and functionality, knowing that their output will integrate seamlessly with the app. This setup requires robust coordination and clear interfaces to ensure all parts of the system work together smoothly. The widget DSL must be well-designed to handle various data sources and formats, adding complexity but also allowing for greater innovation. By empowering teams to define their rendering independently, this approach enables quick responses to changing requirements and market demands.
Setup 6: App Core Team and Feature-based Teams
In this setup, a central core team handles the app’s infrastructure and common features, while separate feature-based teams focus on specific functionalities. The core team ensures that the app’s architecture, navigation, and essential services are consistent and well-maintained. Meanwhile, feature-based teams can innovate and develop new functionalities without being bogged down by core infrastructure tasks.
To meet the demands of a distributed, large-scale native app development project, a substantial increase in staffing is essential. This expansion involves not just hiring more native developers but also integrating them into specialized teams. These teams would include domain-specific groups focusing on particular features and functionalities, working in tandem with a central core team dedicated to the app’s overall infrastructure. The core team’s role is pivotal, as it ensures the app’s architecture, navigation, and essential services are consistent and robust, providing a stable foundation upon which the feature teams can build.
This division of labor allows for specialized development and better resource allocation, as feature teams can work independently and focus on delivering high-quality features. However, it requires careful coordination to ensure that all parts of the app integrate smoothly. The core team must establish clear guidelines and maintain robust communication channels to support the feature teams effectively. This setup can balance the need for innovation with the stability of a well-maintained core infrastructure.
Setup 7: Mixed Server-Driven UI & WebView or SDKs
A hybrid approach using a mix of SDUI for some parts of the app and WebViews or SDKs for others offers flexibility in leveraging the best tools for each task. SDUI can ensure consistent, high-performance UI for core parts of the app, while WebViews allow for the rapid inclusion of web content without extensive native development. SDKs can be used for integrating third-party services or adding complex features that require deep integration with native APIs.
This approach allows teams to choose the most appropriate technology for each feature, balancing performance, development speed, and flexibility. However, it can introduce complexity in managing and maintaining different technologies within the same app. Ensuring a seamless user experience across SDUI, WebViews, and SDKs requires careful design and robust testing. Despite these challenges, a hybrid approach can provide a versatile and adaptable solution for mobile app development.
At WELT, we mainly follow this setup with our native apps.
Conclusion
- André Basse (Spiegel) discussed the challenges of integrating web and native technologies, stressing the need for native components in certain high-interactivity areas like push notifications and audio players. He also highlighted the importance of balancing web and native development to meet user expectations.
- Fevzi Kahraman (Bonial) highlighted the importance of native apps for high user engagement and better monetization, particularly in scenarios requiring extensive use of native capabilities. He also stressed the need for innovative features to retain users and enhance app value.
- Rodrigo Silva (Bonial) noted the complexity of transitioning to more advanced setups like SDUI, suggesting an incremental approach starting with cross-functional teams and gradually incorporating server-driven elements. He emphasized the importance of flexibility and adaptability in the development process.
- Kenny Kremerman (Bonial) focused on the practical challenges of different setups, particularly the need for sufficient native development resources and the importance of flexible, maintainable infrastructure. He also highlighted the benefits of a hybrid approach to balance performance and development speed.
There is no one-size-fits-all setup for mobile app development teams. The optimal configuration depends on the specific context, resources, and targets of the organization. Companies must assess their priorities, such as cost efficiency, speed of development, feature richness, and user experience, to determine the best approach. By understanding the strengths and limitations of each setup, organizations can tailor their mobile app development strategies to align with their unique goals and circumstances, fostering innovation and efficiency in their mobile app endeavors.
