# Android@Microsoft - Medium #Mobile development articles and news brought to you by #MobileDevs working at @Microsoft - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Distributing big AI models in mobile apps DevFeed: [Distributing big AI models in mobile apps]() Original publisher: [Read original article]() Author: SwiftKey Published: 2025-12-04T15:31:35Z Content type: tutorial Language: en Sources: [Android@Microsoft - Medium]() Topics: [Mobile](), [Android](), [AI Models](), [App](), [Generative AI]() Tags: [ai-model-distribution](), [ai-models](), [ai-on-mobile](), [android](), [android-app-development](), [androiddev](), [app](), [app-size](), [apps](), [generative-ai](), [mobile]() ### AI overview This article explains how the Microsoft SwiftKey team approaches adding AI features to an Android mobile app while controlling download and installation size. It describes the app's size constraints, the components that can make an AI feature large, and the trade-offs teams consider when deciding how to distribute large models. ### Source excerpt This is based on a talk given by Beatriz Viñal Murciano (LinkedIn) at droidcon SF (June 2024, video, slides) and Víctor Julián García Granado (LinkedIn) at droidcon Lisbon (September 2024, video) about how we use AI models in our app. The SwiftKey team is one of the many teams working on Android at Microsoft. We build the Microsoft SwiftKey AI Keyboard app for Android ("SwiftKey" from now on). SwiftKey is a keyboard app that lets you type by tapping on keys or sliding your finger over them, correcting and predicting what you type and learning from your typing. It supports over 700 languages (up to 6 of them at the same time) and it has an ever-increasing number of other features such as emoji, GIFs, clipboard and integration of new generative AI products like Copilot and Designer. As we evolve the product, we've made an effort to keep the app size small. SwiftKey's download size is currently around 20MB and its install size right after installation is around 55MB, although it increases over time. Size matters to our users and partners, who prefer apps that are as small as possible. It matters to us too, because apart from our wish to respect users' data and storage, if the app is bigger users are more likely to uninstall it and partnering with device manufactures is more difficult. We discussed app size at length in App size reduction at Microsoft SwiftKey. We've noticed that an increasing number of the latest feature proposals include some form of AI, i.e. they require some sort of probabilistic model that takes some data as input, does some processing, and returns some data as output. This AI is represented by a green box called "AI feature" in the diagrams to simplify. The box can include one or more models, the engine that processes the models and other related data they need to work as well, which can get quite big (usually due to the model(s) size) and may need to be handled carefully to avoid unnecessarily increasing the app size. How big does an AI feature n ## The Ultimate Guide to Developing High-Quality Android Libraries DevFeed: [The Ultimate Guide to Developing High-Quality Android Libraries]() Original publisher: [Read original article]() Author: Akshay Bora Published: 2024-12-04T08:27:06Z Content type: tutorial Language: en Sources: [Android@Microsoft - Medium]() Topics: [Android Library](), [Library](), [Development](), [API](), [Testing](), [Developer experience]() Tags: [android](), [api](), [build-times](), [consistency](), [documentation](), [error-handling](), [guide](), [libraries](), [library-design](), [mobile](), [quality](), [ui-testing]() ### AI overview A practical guide to developing high-quality Android libraries. It recommends using a dedicated playground or development app for isolated feature development, shorter build times, UI testing, easier replacement of implementations, and better integration references. It also advises maintaining a simple, consistent, well-documented, encapsulated API with graceful error handling. ### Source excerpt In the fast-paced world of software development, creating Libraries efficiently and effectively is crucial to ensure the code reuse across apps. Here are some preferred practices to help you streamline your Library development process and guide you towards unlocking the secrets of building a top-notch Android Library. In Microsoft we do use these guidelines while developing the Libraries like File Picker, Share and Calendar libraries which helped us big time. 1. Create a Playground/Development App When developing libraries, it is advantageous to create a playground or development application that integrates with the library for faster development cycles. This approach has proven highly beneficial, as developers no longer need to build an example Teams codebase to test the libraries, significantly reducing the time required for testing. This approach offers several benefits: Isolated Testing: Developers can test and develop features in isolation, without waiting for integration into the consumer codebase. This leads to faster development cycles. Shorter Build Times: The development app targets specific features, resulting in quicker builds. Developers can launch the feature they want to test with just a click. UI Testing: Run UI tests from the playground app, allowing the consumer or library to focus on integration tests. Feature-level UI tests can be handled in isolation. Easier Replacement: Replace actual implementations with fake ones for UI tests easily. Better Integration References: Provide better integration references in developer documentation and stakeholders to play around before consuming the Library. 2. Cleaner API Surface When developing high-quality Android libraries, it's crucial to maintain a clean and intuitive API surface. A cleaner API surface ensures that your library is easy to understand and use, which can significantly enhance the developer experience. Simplicity: Keep your API simple and avoid unnecessary complexity. Provide clear, concise me ## Scaling Mobile Development at Microsoft-- Mental Model DevFeed: [Scaling Mobile Development at Microsoft-- Mental Model]() Original publisher: [Read original article]() Author: Anand Nath Published: 2024-06-12T14:37:04Z Content type: article Language: en Sources: [Android@Microsoft - Medium]() Topics: [Mobile](), [Development](), [Microsoft](), [App](), [User Experience](), [Android]() Tags: [android](), [app](), [architecture](), [development](), [ios](), [microsoft](), [mobile](), [mobile-development](), [reuse](), [user-experience]() ### AI overview This first article in a series presents a high-level mental model for scaling development across Microsoft mobile applications. It describes separately maintained codebases and overlapping experiences, then discusses High Value Controls such as One Camera and One Player, including problems caused by siloed development such as inconsistency, limited interoperability, and redundant libraries. ### Source excerpt Scaling Mobile Development at Microsoft -- Mental Model In the Scaling Teams Mobile Development series we looked at scaling development in a single mobile code base. Since then, we were at work, looking at up-levelling this problem statement and look at how to scale across mobile applications. Here is a new series which tries to throw some light around this topic. This article is the first of a series, starting with understanding the problem statement and a high level solution. In the following articles we will dive deeper with an example and discuss practical aspects of how we got it done. Let's dive in! Photo by Hans-Peter Gauster on UnsplashShared experiences Microsoft has a suite of mobile applications. Each of these applications are developed in separate code base, has its own release cycles. There are a lot of overlapping experiences across these applications. These experiences are also implemented, tested and maintained independently in each application. Here are some examples: File picking experience across Microsoft mobile apps.Calendar experience across Microsoft mobile apps.File sharing experience across Microsoft mobile apps. In order to drive consistent user experience across these applications, Microsoft is invested in developing "High Value Controls" aka HVCs. For example, there is One Camera which provides camera functionality for most of the Microsoft apps, there is One Player which provides video playback in Microsoft apps and some more. Most of the HVCs are developed in silos without any common considerations or guidelines. Some HVCs are developed inside one of the Microsoft mobile apps and then lifted out to be positioned as reusable. These come with the remnants of the app specific concepts and logic, which does not sit well with other apps. This kind of HVC development lack consistency, coherence and interoperability. This also leads to a series of issues for both the Microsoft mobile apps and HVCs. Issues for Microsoft mobile apps Note: In this ## Spotting Latency Regressions Ahead of Time at Teams Mobile DevFeed: [Spotting Latency Regressions Ahead of Time at Teams Mobile]() Original publisher: [Read original article]() Author: Saumye Srivastava Published: 2024-02-02T18:18:47Z Content type: article Language: en Sources: [Android@Microsoft - Medium]() Topics: [Latency](), [Mobile](), [telemetry](), [Android](), [App](), [Grafana](), [Monitoring](), [dashboards](), [Database]() Tags: [android](), [app-performance](), [dashboards](), [database](), [grafana](), [latency](), [mobile](), [monitoring](), [performance](), [performance-testing](), [telemetry](), [user-experience]() ### AI overview This article describes how the Teams Mobile Android team measures and monitors latency in critical app scenarios using scenario telemetry. It explains how execution time, metadata, device information, status, steps, and correlation IDs are recorded and visualized to detect regressions earlier, while noting that latency graphs alone can make diagnosis and rollout response difficult. ### Source excerpt In the realm of mobile applications, subpar performance not only results in user frustration but also contributes to high user dissatisfaction scores (DSAT), a lower app Net Promoter Score (NPS), and increased uninstallations. Developers continually implement numerous code optimizations in each release, bringing about substantial improvements in App Vitals and critical user scenarios such as application launch, chat loading time, and channel loading time. Our Android codebase sees contributions from over 350 developers on a monthly basis, with a staggering 50+ commits merged into the mainline every day. The pace of innovation remains high, as we introduce more than 20 new features daily to our internal users across the organization and our partners. In this dynamic environment, the need to maintain optimal app performance is paramount, emphasizing the importance of identifying and mitigating latency issues before they have a chance to impact user experience. All code is guilty until proven innocent.-- Uncle BobScenario Measurement & Monitoring We employ a method called scenario telemetry to measure execution time at the beginning and end of critical usage scenarios of our app. The latency telemetry for all usage scenarios is recorded in our database along with user details. The ScenarioContext handle facilitates the transfer of context information related to a user scenario throughout the app, including execution time, metadata, device information, status, steps, and correlation ID. fun onCreate() { val scenarioContext = scenarioManager.startScenario(AppScenarioNames.App.APP_START_WARM_FIRST_DRAW); // do critical work, load screen scenarioManager.stopScenario(scenarioContext); } Creating dashboards at Microsoft is a straightforward process, involving crafting a query on our internal portal that our internal framework executes every minute to chart into graphs. You can send the usage telemetry to your internal or third party Database and host a Grafana instance for ## A Journey from Hackathon to Production DevFeed: [A Journey from Hackathon to Production]() Original publisher: [Read original article]() Author: Chirayu Asati Published: 2023-11-29T14:22:33Z Content type: article Language: en Sources: [Android@Microsoft - Medium]() Topics: [AdventureX 2025](), [Microsoft Teams](), [Mobile](), [Product Management](), [Software Engineering]() Tags: [collaboration](), [engineering](), [events](), [hackathon](), [ideation](), [journey](), [microsoft](), [microsoft-teams](), [mobile](), [product](), [product-management](), [production](), [software](), [software-engineer](), [team]() ### AI overview A Microsoft Teams Mobile software engineer describes how a hackathon idea to simplify scheduling meetings from group chats was developed into a production feature. The article covers the original user problem, reducing the process from more than eight steps to three, and collaboration among product management, design, and engineering using the RICE prioritization framework. ### Source excerpt Hey there, I am Chirayu and I'm taking you on the journey of transforming a mere idea into a fully-fledged, efficient feature that requires a compelling tale of innovation. I'm a Software Engineer at Microsoft Teams Mobile and I had the privilege of being part of this remarkable journey from the beginning. This story is not just about the technical process but the innovation, collaboration, and dedication of the teams to overcome challenges creating incredible impact. It all started when I was feeling too lazy and frustrated to schedule a meeting with folks in my hackathon group chat because I had to go to the meeting scheduler and search everyone by name, add them one by one and then schedule the meeting. Too hectic, isn't it? Is being lazy bad? No way, see this quote from the Gates. So, whenever we are lazy, we have an opportunity to make things easy for ourselves and the world. The Idea As described above, if you want to schedule a meeting while chatting in a group, you would have to: User flow to schedule a meeting from chat in Teams Mobile beforeUser flow to schedule a meeting from chat in Teams Mobile after As you can see in the above image, scheduling a meeting from chat takes 8+ steps in Teams Mobile so the idea is to reduce this to just 3 simple steps: This streamlined approach would save valuable time and simplify the process. This concept sparked the beginning of our journey. About Microsoft Global Hackathon Hackathon is a great way for ideation, innovation, collaboration & fun and Microsoft is renowned for its commitment to hackathons, conducting events like CodeFunDo in colleges and the Microsoft Global Hackathon for its employees. After demonstrating the potential of our hack, it was time to go down the road to turn it into a fully-fledged product feature accessible to millions of people on the planet. R.I.C.E. The initial phase of transitioning from a hack to a production-ready feature involves discussions with the Product Management team to craft a c ## Pull vs push architecture for Mobile DevFeed: [Pull vs push architecture for Mobile]() Original publisher: [Read original article]() Author: Abhishek Kharb Published: 2023-10-10T13:33:07Z Content type: tutorial Language: en Sources: [Android@Microsoft - Medium]() Topics: [Mobile](), [API](), [data](), [HTTP](), [client](), [servers]() Tags: [android](), [api](), [communication](), [data](), [http](), [ios](), [mobile](), [mobile-app-development](), [push-notification](), [request](), [server](), [servers]() ### AI overview This article explains pull- and push-based architectures for keeping mobile application data synchronized with servers. It describes user-triggered requests, short polling, long polling, and server-initiated updates through socket connections or platform push frameworks. ### Source excerpt What is pull vs push architecture for Mobile? Almost all mobile applications need to regularly sync data from servers to be able to show their users fresh information for consumption. Photo by Claudio Schwarz on Unsplash This data sync can be achieved in broadly two ways: 1. Pull based model -- The pull-based model requires apps to initiate an API call in order to fetch the latest data. This call is usually initiated by some user action defined by the programmer. It could be when a user navigates to a particular screen in the app or performs a particular action (like pull to refresh), or it could be based on the polling technique. Broadly, polling can be achieved in one of the two following ways: Short polling: Sometimes referred to as Regular polling or Standard polling, in this case the client makes an HTTP call to the server at regular intervals of time. As and when the data is available, the server returns the data back to the client, until then the server just sends the same old data or empty response depending upon the implementation. One of the major drawbacks of this technique is that since the data is refreshed at regular intervals by the client, it results in redundant calls when no new data is available and stale data if something changes on the server before the next call is made. Short polling-based mechanism for data sync. Long Polling: This technique aims to address the redundant calls made by the client in short polling that return no new data from the server. In this case, the client makes an HTTP call to the server, but the server doesn't immediately respond if there is no new data available. Instead, the server waits until new data is available (or until the request times out), after which the server responds with the data. As soon as the client receives data from the server (or after the request times out), it sends another request (or after a certain cool off period), and the same process is repeated. Long-polling based mechanism for data sync. 2 ## Understanding & Assessing Visual Regression Testing DevFeed: [Understanding & Assessing Visual Regression Testing]() Original publisher: [Read original article]() Author: Nikhita Reddy Eega Published: 2023-07-27T12:58:43Z Content type: tutorial Language: en Sources: [Android@Microsoft - Medium]() Topics: [Testing](), [Jetpack Compose](), [Kotlin](), [Declarative programming](), [ui](), [XML]() Tags: [capture](), [cashapp-paparazzi](), [declarative](), [facebook-sdk](), [jetpack-compose](), [kotlin](), [mobile](), [snapshots](), [testing](), [verify](), [visual-regression-testing]() ### AI overview This article explains visual regression testing for Android UI, focusing on possible visual differences when migrating from the View system to Jetpack Compose. It describes recording baseline snapshots, verifying new snapshots against them, and evaluating VRT tools such as Facebook SDK and Paparazzi for framework compatibility. ### Source excerpt Understanding & Evaluating Visual Regression TestingPhoto by Jessica Ruscello on UnsplashDive into learning about VRT tools like Facebook SDK, Paparazzi and study their compatibility for migration. Since Jetpack Compose was released in 2021, its declarative programming model has offered a modern and intuitive approach to building user interface. Compared to View system framework, Compose promotes cohesion and simplifies state-management. This framework is lightweight because the UI components are built using composable functions as separate building pieces. With this paradigm shift, boilerplate code is lessened, code reuse is encouraged, and the development process is made simpler. Migrating to Compose seems quite appealing. Will there be any regression if we migrate from one framework to another, though? Because Compose is still relatively new compared to the well-established View-based UI, there might be potential challenges faced during the migration period. What about visual regressions? Possible visual regressions can be encountered due to different UI frameworks, view configuration and styling approach. Styling and themes are usually defined in XML resource files which are applied to the views and then rendered. Whereas in Compose, these are programmatically defined in Kotlin and then takes advantage of efficient recomposition. These variances may result in changes to padding, margin, etc. Thus, to maintain a seamless transition and avoid any visual bugs going unreported, visual regression testing can be used. This ensures that the final UI is consistent to enhance user experience. Understanding Visual Regression Testing (VRT): Let us now break down the process into two design approaches -- High level and Low level High-Level Design Approach Consists of 2 steps: 1) Record -- Generating a snapshot and saving it as Golden (baseline/reference snapshot used to compare subsequent snapshots) 2) Verify -- Compares the two snapshots High level design flowLow-Level Design ## How Hydra Lab Empowers Microsoft Mobile Testing DevFeed: [How Hydra Lab Empowers Microsoft Mobile Testing]() Original publisher: [Read original article]() Author: TechHome Published: 2023-07-26T04:12:12Z Content type: article Language: en Sources: [Android@Microsoft - Medium]() Topics: [Mobile Testing](), [Testing](), [API](), [DevOps](), [Azure DevOps](), [Microsoft](), [Open Source]() Tags: [ai](), [android](), [api](), [appium](), [automation](), [azure](), [chatgpt](), [ci](), [devops](), [github](), [hydra](), [integration](), [ios](), [maestro](), [microsoft](), [mobile](), [mobile-testing](), [open-source](), [testgpt](), [testing]() ### AI overview The article describes Hydra Lab, an open-source framework for building a private, self-managed mobile test cloud with a REST API and DevOps integration. It explains the framework's focus on control, customization, cost, device sharing, test automation, and test intelligence, and describes its use in Microsoft mobile-product testing through Azure DevOps pipelines. ### Source excerpt How Hydra Lab Empowers Microsoft Mobile Testing and Test Intelligence Hydra Lab: Intelligent Cloud Testing Made Easy -- microsoft/HydraLab (github.com) What is Hydra Lab? The following video could give you an overview of Hydra Lab on its functionality status and mission. https://medium.com/media/34f0f3cb9ff8eafe8b4c2c90e5d5fa30/href In other words, with Hydra Lab, you can build a private test cloud on your own which provides RESTful API service and support for DevOps system integration. In other words, it's like you can have a private self-manageable "Firebase Test Lab". Why we need Hydra Lab We open-sourced Hydra Lab under github.com/microsoft in 2022 Dec, and its open-source nature ensures better control and customization, removing the following concerns when it comes to the integration of cloud testing platform: [Credibility]: Is it okay to upload your debug app package to a 3rd party platform? Could we trust them? Is there a compliance requirement for using it? [Customization]: Does the 3rd party platform have the compatible real devices to run my test? Is cross-platform scenario supported? [Cost]: Is the pricing of those platforms affordable? [Community]: Could we plug in our devices to the cloud and share them across geos & teams? Hydra Lab is a free, customizable, credible framework built on top of Appium, Espresso, Maestro, XCTest, etc. It has been geared with test integration glue code and scalable designs and test lifecycle definition for further support of new runners and test intelligence. The Hydra Lab team put consistent effort in contributing to the mission of "Intelligent Cloud Testing Made Easy" and designing "Your Intelligent Test Cloud", we have built standardized CI and CD procedures in Azure DevOps with UT and API+E2E acceptance testing as quality gatekeepers and have shipped 27 stable releases so far. How Hydra Lab powers testing in Microsoft After integrating Hydra Lab into our procedures over the past two years, our in-house service now stream ## How Microsoft Teams Android reduced build time with telemetry and Gradle upgrades DevFeed: [How Microsoft Teams Android reduced build time with telemetry and Gradle upgrades]() Original publisher: [Read original article]() Author: Saumye Srivastava Published: 2023-05-03T10:08:11Z Content type: article Language: en Sources: [Android@Microsoft - Medium]() Topics: [build performance](), [Gradle](), [Android](), [telemetry](), [ci](), [Pull Request]() Tags: [android](), [build](), [ci](), [developer-productivity](), [gradle](), [microsoft](), [mobile-app-development](), [modules](), [monitoring](), [performance](), [pull-request](), [telemetry]() ### AI overview This article describes Microsoft Teams Android's efforts to improve build performance in a codebase with more than 300 modules. The team collected Gradle task telemetry across developer environments and reported a 30-40% build-time improvement after Gradle upgrades. ### Source excerpt The mobile industry is an ever-evolving space, with new innovations and updates being introduced regularly. This means that the competition is fierce, and every day counts in shipping features and bug fixes. The time it takes to build an Android app is a crucial factor that impacts developer productivity, which in turn can affect the app's success. The percentage reduction in build time leads to percentage increase in shipping features and bug fixes. At Microsoft Teams Android, we understand this well and have been working relentlessly to improve our Android build time over the past quarter. Photo by Venti Views on Unsplash Our Android codebase comprises of 300+ modules that are contributed by hundreds of developers who run thousands of builds per day, both locally and in our Continuous Integration (CI) and Pull Request (PR) triggered pipelines. 1. Build Telemetry We aimed to start by setting a baseline for our build configuration and execution time on both the project and task levels. To do so, we collected telemetry from all developers in different environments and machines. We started with setting up build telemetry for each gradle task. For this we used TaskExecutionAdapter and BuildListener that sent build telemetry to our monitoring servers by listening via the Gradle.addListener API. Along with the gradle task execution time, we also sent device and development details, branch creation dates, cores, RAM, OS, and the list of modules changed. Shortened output format, {'Build_Time': 82, 'deviceId': '<>', 'modelName': 'MacBook Pro', 'modelIdentifier': 'MacBookPro18,2', 'processorName': 'Apple M1 Max', 'totalCores': '10 (8 performance and 2 efficiency)', 'memory': '32 GB', 'timezone': '+0530', 'task': 'preparekotlinbuildscriptmodel', 'taskData': '{}', 'os': 'Darwin', 'cleanBuild': False, 'totalTaskTime': 0, 'versionName': '1416/1.0.0.2023060799', 'modulesChanged': '["apps/teams", "common/beacon"]'} This helped us collect data and build monitoring on a daily basis ## Scaling Teams Mobile Development -- The Mental Model DevFeed: [Scaling Teams Mobile Development -- The Mental Model]() Original publisher: [Read original article]() Author: Anand Nath Published: 2023-03-03T02:22:43Z Content type: article Language: en Sources: [Android@Microsoft - Medium]() Topics: [Mobile](), [Development](), [App](), [Code](), [interfaces]() Tags: [android](), [code](), [design-patterns](), [development](), [integration](), [interfaces](), [ios](), [mobile](), [mobile-development](), [modularization](), [patterns]() ### AI overview This article presents a mental model for scaling partner integrations in the Microsoft Teams mobile codebase. It describes the existing tight coupling between feature producers and consumer entry points, then proposes decoupling them through interfaces, a producer registry, and a manager that handles feature discovery and coordination. ### Source excerpt Scaling Teams Mobile Development -- The Mental Model In the article Scaling Teams Mobile Development -- Evolving the design pattern we explored how multiple partner teams working on a large code base can be streamlined by employing the contributor design pattern. I decided to write this article as a prequel. In this article we will discuss the problem statement in a more generic way and draw some parallels with popular design patterns. Photo by Xavi Cabrera on Unsplash We started with the following mission statement in mind: Make partner integrations with Teams mobile easier, well segregated, with clear protocols. Teams is a complex mobile application with a LOT of integration points. Partner teams surface their features through these entry points. The following image highlight few entry points available in Teams. Few entry points in Teams mobile app When we looked at the partner integration story in Teams codebase, it became evident that the whole integration story is a Producer-Consumer design pattern which is not implemented correctly. Producer -- Consumer deep coupling Here is the mental model that we built: Entry points are consumers of features and partner teams are producers of features. In the existing method, each partner team directly integrated with the entry point. This meant each consumer had to know the producers directly and when a new producer was added, the consumer had to be updated. This resulted in tight coupling. This is not a scalable model. N x N relationship between Producers and Consumers For the system to scale we need to decouple the producers and the consumers and build strong contracts between them. We wanted to safeguard changes to the consumer. At the same time, we wanted to make the producers independent and able to churn out their features fast. We also wanted to centralize control on producers and its features for deciding their ordering, filtering, enablement etc. So, we evolved this design pattern, where we define multiple Feature in