Posted by Niharika Arora (X and LinkedIn) – Senior Developer Relations Engineer and Vinisha Athwani – Technical Writer (LinkedIn)

In a world where digital security is becoming increasingly critical, passwords have become a notorious weak link – they’re cumbersome, often insecure, and a source of frustration for users and developers. But there’s good news: passkeys are gaining popularity as the most user-friendly, phishing-resistant, and secure authentication mechanism available. For Android developers, the Credential Manager API helps you guide your users towards using passkeys while ensuring continued support for traditional sign-in mechanisms, such as passwords.

In this blog, we discuss some of the best practices you should follow while encouraging users to transition to passkeys.

Understand authentication with passkeys

Before diving into the recommendations for encouraging the transition to passkeys, here’s an overview of the fundamentals of authentication with passkeys:

• Passkeys: These are cryptographic credentials that replace passwords. Passkeys are associated with device unlocking mechanisms, and are the recommended method of authentication for apps and sites.
• Credential Manager: A Jetpack API that provides a unified API interface for interacting with different types of authentication, including passkeys, passwords, and federated sign-in mechanisms like Sign in with Google.

How do passkeys help your users?

There are several tangible benefits that users experience in apps that allow them to use passkeys to sign in. The highlights of using passkey for users are as follows:

• Improved sign-in experience: Users get the same UI whether they use passwords, passkeys or federated sign-in mechanisms like Sign in with Google.
• Reduced sign-in time: Instead of typing out passwords, users use their phone unlock mechanisms, such as biometrics, resulting in a smooth sign-in experience.
• Improved security: Passkeys use public-key cryptography so that data breaches of service providers don’t result in a compromise of passkey-protected accounts, and are based on industry standard APIs and protocols to ensure they are not subject to phishing attacks. (Read more about syncing and security here).
• Unified experience across devices: With the ability to sync passkeys across devices, users benefit from simplified authentication regardless of the device they’re using.
• No friction due to forgotten passwords!

Underscoring the improved experience with passkeys, we heard from several prominent apps. X observed that login rates improved 2x after adding passkeys to their authentication flows. KAYAK, a travel search engine, observed that the average time it takes their users to sign up and sign in reduced by 50% after they incorporated passkeys into their authentication flows. Zoho, a comprehensive cloud-based software suite focused on security and seamless experiences, achieved 6x faster logins by adopting passkeys in their OneAuth Android app.

What’s in it for you?

When you migrate your app to use passkeys, you’ll be leveraging the Credential Manager API which is the recommended standard for identity and authentication on Android.

Apart from passkeys, the Credential Manager API supports traditional sign-in mechanisms, simplifying the development and maintenance of your authentication flows!

For all of these sign-in mechanisms, Credential Manager offers an integrated bottom-sheet UI, saving you development efforts while offering users a consistent experience.

When should you prompt users to use passkeys?

Now that we’ve established the benefits of passkeys, let’s discuss how you should encourage your users to migrate to passkeys.

The following are a list of UX flows in which you can promote passkeys:

• User account registration: Introduce passkey creation prompts at key moments, such as when your users create their accounts:

Contextual Prompts during account creation
• Sign in: We recommend you encourage users to prompt passkeys in the moment after a user signs in with an OTP, password, or other-sign in mechanisms.

Prompt passkey creation during sign-in
• Account recovery: The critical user journey (CUJ) for account recovery is one that historically presents friction to users. Prompting users to adopt passkeys during account recovery is a recommended path. Users who adopt passkeys experience a familiar account recovery experience as during sign-in.

Account Recovery flow
• Password resets: This is the perfect moment to prompt users to create a passkey; after the frustration of a password reset, users are typically more receptive to the convenience and security passkeys offer.

Create a passkey for faster sign-in next time

How should you encourage the transition to passkeys?

Encouraging users to transition from passwords to passkeys requires a clear strategy. A few recommended best practices are as follows:

• Clear value proposition: Use simple, user-centric prompts to explain the benefits of passkeys. Use messaging that highlights the benefits for users. Emphasize the following benefits:
• Improved security benefits, such as safety from phishing.
• No need to type out a password.
• Ability to use the same passkey across devices/platforms.
• A consistent authentication experience.

Passkey prompt with clear value proposition
• Provide a seamless user experience:
• Use the unified UI provided by Credential Manager to show all available sign-in options, allowing the user to choose their preferred method without having to remember which one they used last.
• Use the official passkey icon to build user familiarity and create a consistent experience.
• Make sure that users can fall back to their traditional sign-in methods or a recovery method, such as a username and password, if a passkey is not available or if they are using a different device.

• Provide users with clarity about credentials within your app’s Settings UI: Make sure your users understand their authentications options by displaying helpful information about each passkey within your app’s settings. To learn more about adding credentials metadata, see the Credential Manager documentation.

Passkey Metadata on App’s Settings screen

• Educate users: Supplement the messaging to adopt passkeys with in-app educational resources or links that explain passkeys in detail.
• Progressive rollout: Consider a phased rollout to introduce passkeys to a subset of your user base to gather feedback and refine the user experience before a broader launch.

Developer Case Studies

Real-world developer experiences often highlight how small design choices—like when and where to surface a passkey prompt—can significantly influence adoption and user trust. To see this in action, let’s explore how top apps have strategically surfaced passkey prompts at key moments in their apps to drive stronger adoption :

Uber

To accelerate passkeys adoption, Uber is proactively promoting passkeys in various user journeys, alongside marketing strategies.

Uber has shared : “90+% of passkey enrollments come from promoting passkey creation at key moments inside the app as compared to onboarding and authentication CUJs“, underscoring the effectiveness of their proactive strategy.

Key learnings and strategies from their implementation:

• Offer passkeys without disrupting the core user experience: Uber added a new account checkup experience in their account settings to highlight passkey benefits, resulting in high passkey adoption rates.

User Account checkup flow

• Proactively bring passkeys to users: They learned not to wait for users to discover passkeys organically because relying on organic adoption would have been slower despite observed benefits like faster sign-ins and increased login success rates for passkey users.
• Use additional mediums to promote passkeys: Uber is also experimenting to promote passkeys through email campaigns or banners on a user’s account screen to highlight the new sign-in method, making their next sign-in easier and more secure.
• Respect your user’s choice: Recognizing that not all users are ready for passkeys, Uber implemented backoff logic in critical flows as sign in, signup screens and, in some contexts, offers passkeys alongside other familiar authentication methods.

Here’s what Uber has to say:

At Uber, we’ve seen users who adopt passkeys enjoy a faster, more seamless, and more secure login experience. To help more users benefit from passkeys, we’ve added nudges to create a passkey at key moments in the user experience: account settings, signup, and login. These proactive outreaches have significantly accelerated our passkey adoption. 

Ryan O’Laughlin

Senior Software Engineer, Uber

Economic Times

Economic Times, part of the Times Internet ecosystem, used a seamless user experience as the primary motivation for users to transition to passkeys.

After introducing targeted nudges, Economic Times observed ~10% improvements in passkey creation completion rate within the initial rollout period.

Key learnings and strategies from their implementation:

• Strategic passkey generation prompts: Initially, Economic Times was aggressively prompting passkey creation in multiple user flows, but it was observed that this approach disrupted business-critical journeys such as subscription purchases or unlocking premium features and was leading to abandoned carts.
• Refined approach: Economic Times made a deliberate decision to remove passkey generation prompts from sensitive flows (such as the subscription checkout flow) to prioritize immediate action completion.
• Targeted prompts: They strategically maintained passkey generation in areas where user intent to sign-in or manage authentication is high, such as initial sign-up flows, explicit sign in pages, or account management sections.
• Positive outcome: This refined deployment resulted in improved passkey generation numbers, indicating strong user adoption, without compromising user experience in critical business flows.

Passkeys Management Screen

Conclusion

Integrating passkeys with Android’s Credential Manager isn’t just about adopting new technology; it’s about building a fundamentally more secure, convenient, and delightful experience for your users. By focusing on intelligent passkey introduction, you’re not just securing accounts–you’re building trust and future-proofing your application’s authentication strategy.

To provide your users the best, optimized and seamless experience, follow the UX guidelines while implementing passkeys authentication with Credential Manager. Check out the docs today!

• Sample with UX best practices
• Sign in your user with Credential Manager
• API Reference – androidx.credentials
• User authentication with passkeys
• Google Safety Center – Passkey
• Google Security Blog: Security of Passkeys in the Google Password Manager

The post Best practices for migrating users to passkeys with Credential Manager appeared first on InShot Pro.

Posted by Robbie McLachlan – Developer Marketing

In our latest #WeArePlay stories, we meet the founders building apps and games that power entrepreneurs and business owners around the world. From digitizing finances for micro-merchants in Bogotá to modernizing barbershops in New York, they are solving real-world challenges with intuitive apps.

Here are a few of our favorites:

Lluís and Man Hei’s app Treinta saves microbusiness owners 30 minutes a day by digitizing their sales, inventory, and cash flow.

After meeting at university, Lluís and Man Hei reunited to launch Treinta, an app inspired by Lluís’ experience with small businesses across Latin America. Named after the Spanish word for ’30,’ it helps microbusiness owners save at least 30 minutes a day by digitizing tasks like inventory, sales tracking, and cash flow management. With a recent expansion into the U.S. and upcoming AI tools, they are on track to reach their goal of 100,000 premium members by 2026.

Ying, Yong, Steve, and Oswald’s app Glints uses AI-powered recommendations to make hiring talent quick and easy.

High school friends Ying, Yong, Steve, and Oswald bonded over a shared vision to use technology for good, which led them to create Glints. What began as an internship portal in Singapore evolved into a dynamic hiring app after they saw an opportunity to tackle underemployment among young people in Indonesia. The app streamlines the job search with AI-powered recommendations and direct chat features, creating new career opportunities and helping companies find top talent. Their goal is to expand into more cities and become Indonesia’s leading career app.

Dave and Songe’s app SQUIRE helps barbers manage and grow their business with an all-in-one platform.

Former lawyer Songe and finance expert Dave saw an opportunity to modernize the cash-reliant barbershop industry. With no prior experience, they took over a struggling Manhattan barbershop while developing SQUIRE. The app, which initially focused on appointment scheduling and digital payments, has since evolved into a complete management platform with Point of Sale, inventory tracking, and analytics — helping barbers run their businesses more efficiently. Now, they’re adding more customization options and plan to expand SQUIRE’s capabilities to continue elevating the modern barbershop experience.

Discover other inspiring app and game founders featured in #WeArePlay.

The post #WeArePlay: Meet the people behind apps & games powering businesses around the world appeared first on InShot Pro.

Posted by Matthew McCullough – VP of Product Management, Android Developer

In this dynamic and complex ecosystem, our commitment is to your success. That’s why in our summer episode of The Android Show, we’re making it easier for you to build amazing apps by unpacking the latest tools and opportunities. In this episode, we’ll cover how you can get building for Wear OS 6, boost your productivity with the latest Gemini in Android Studio updates, create for the new Pixel 10 Pro Fold, and even have some fun with the new AI-powered Androidify. (And for Android users, we also just dropped a bunch of new feature updates today; you can read more about those here). Let’s dive in!

Get the most out of Agent Mode in Android Studio with MCP

We’re focused on making you more productive by integrating AI directly into your workflow. Gemini in Android Studio is at the center of this, helping teams like Entri who was able to reduce UI development time by 40%. You can now connect Model Context Protocol servers to Android Studio, which expands the tools, knowledge, and capabilities of the AI Agent. We also just launched the Android Studio Narwhal 3 feature drop, which brings more productivity boosters like Resizable Compose Preview and Play Policy Insights.

Build for every screen with Compose Adaptive Layouts 1.2 beta

The new Pixel 10 Pro Fold creates an incredible canvas for your app, and we’re simplifying development so you can take full advantage of it. The Compose Adaptive Layouts 1.2 library, now officially in beta, makes it easier than ever to build for large screens and to embrace adaptive app development. This library is packed with tools to help you create sophisticated, adaptive UIs with less code. We’re focused on helping you build intuitive and engaging experiences for every screen. This foundational library is packed with powerful tools to help you create sophisticated, adaptive UIs with less code. Build dynamic, multi-pane experiences using new layout strategies like Reflow and Levitate, and use the new Large and Extra-Large window size classes to make your app more intuitive and engaging than ever. Read more about these new tools here.

Bring your most expressive apps to the wrist with Wear OS 6

We want to help you build amazing experiences for the wrist, and the new Pixel Watch 4 with Wear OS 6 provides a powerful new stage for your apps. We’re giving you the tools to make your apps more expressive and personal, with Material 3 Expressive to create stunning UIs. You can also engage users in new ways by building your own marketplace with the Watch Face Push API. All of this is built on a more reliable foundation, with watches updating to Wear OS 6 seeing up to 10% better battery life and faster app launches.

Androidify yourself, with a selfie + AI!

Our journey to reimagine Android with Gemini at its center extends to everything we do—including our mascot. That’s why we rebuilt Androidify with AI at its core. With the new Androidify, available on the web or on Google Play, you can use a selfie or a prompt to create your own unique Android bot, powered by Gemini 2.5 Flash and Imagen. This is a fun example of how we’re building better user experiences powered by AI… Try it out for yourself—we can’t wait to see what you build.

Under the hood, we’re using Gemini 2.5 Flash to validate the prompt and Imagen to create your Android bot. And on Friday’s this month, you’ll be able to animate your Android bot into an 8-second video; this feature is powered by Veo and available to a limited number of creations. You can read more about the technical building of the Androidify app here. Try it out for yourself – we can’t wait to see your inner Android!

Watch the Summer episode of The Android Show

Thank you for tuning into this quarter’s episode. We’re excited to continue building great things together, and this show is an important part of our conversation with you. We’d love to hear your ideas for our next episode, so please reach out on X or LinkedIn. A special thanks to my co-hosts, Annyce Davis and John Zoeller, for helping us share the latest updates.

The post The latest for devs from Made by Google, updates to Gemini in Android Studio, plus a new Androidify: our summer episode of The Android Show appeared first on InShot Pro.

Posted by Paris Hsu – Product Manager

Entri delivers online learning experiences across local languages to over 15 million people in India, empowering them to secure jobs and advance in their careers. To seize on the latest advancements in AI, the Entri team explored a variety of tools to help their developers create better experiences for users.

Their latest experiment? Adopting Gemini in Android Studio to enable them to move faster. Not only did Gemini speed up the teams’ work, trim tedious tasks, and foster ongoing learning, it streamlined collaboration between design and development and became an enjoyable, go-to resource that boosted the team’s productivity overall.

Turning screenshots to code—fast

To tighten build time, developers at Entri used Gemini in Android Studio to generate Compose UI code directly from mockups. By uploading screenshots of Figma designs, Gemini produced the UI structures they needed to build entire screens in minutes. Gemini played a key role in revamping the platform’s Sign-Up flow, for example, fast-tracking a process that typically takes hours to just under 45 minutes.

By streamlining the creation of Compose UIs—often from just a screenshot and a few prompts—Gemini also made it significantly easier to quickly prototype new ideas and create MVPs. This allowed their team to test concepts and validate business needs without getting bogged down by repetitive UI tweaks up front.

Entri developers found that the ability to generate code by attaching images in Gemini in Android Studio drastically reduced boilerplate work and improved alignment between design and engineering. Over time, this approach became a standard part of their prototyping process, with the team reporting 40% reduction in average UI build time per screen.

Faster experimentation to create a better app experience

The Entri team has a strong culture of experimentation, and often has multiple user-facing experiments running at once. The team found Gemini in Android Studio particularly valuable in speeding up their experimentation processes. The tool quickly produced code for A/B testing, including UI changes and feature toggles, allowing the team to conduct experiments faster and iterate in more informed ways. It also made it faster for them to get user feedback and apply it. By simplifying the early build phase and allowing for sharper testing, Gemini boosted their speed and confidence, freeing them up to create more, test faster, and refine smarter.

When it came to launching new AI learning features, Entri wanted to be first to market. With Gemini in Android Studio’s help, the Entri team rolled out their AI Teaching Assistant and Interview Coach to production much faster than they normally could. “What used to take weeks, now takes days,” said Jackson. “And what used to take hours, now takes minutes.”

Tool integration reduces context switching

Gemini in Android Studio has changed the game for Entri’s developers, removing the need to break focus to switch between tools or hunt through external documentation. Now the team receives instant answers to common questions about Android APIs and Kotlin syntax without leaving the application.

For debugging crashes, Gemini was especially useful when paired with App Quality Insights in Android Studio. By sharing stack traces directly with Gemini, developers received targeted suggestions for possible root causes and quick fixes directly in the IDE. This guidance allowed them to resolve crashes reported by Firebase and Google Play more efficiently and with less context switching. Gemini surfaced overlooked edge cases and offered alternative solutions to improve app stability, too.

Shifting focus from routine tasks to innovation

Entri developers also wanted to test the efficiency of Gemini in Android Studio on personal projects as well. They leaned on the tool to create a weather tracker, password manager, and POS billing system—all on top of their core project work at Entri. They enjoyed trying it out in their personal projects and experimenting with different use cases.

By offloading repetitive tasks and expediting initial UI and screen generation, Gemini has allowed developers to focus more on innovation, exploration, and creativity—things that often get sidelined when dealing with routine coding work. Now the team is able to spend their time refining final products, designing smarter UX, and strategizing, making their day-to-day work more efficient, collaborative, and motivating.

Get started

Ramp up your development processes with Gemini in Android Studio.

The post Entri cut UI development time by 40% with Gemini in Android Studio appeared first on InShot Pro.

Posted by John Zoeller – Developer Relations Engineer, Loyrn Hairston – Product Marketing Manager, and Jonathan Salamon – Dashlane Staff Software Engineer

Dashlane is a password management and provision tool that provides a secure way to manage user credentials, access control, and authentication across multiple systems and applications.

Dashlane has over 18 million users and 20,000 businesses in 180 countries. It’s available on Android, Wear OS, iOS, macOS, Windows, and as a web app with an extension for Chrome, Firefox, Edge, and Safari.

Recently, they expanded their offerings by creating a Wear OS app with a Credential Provider integration from the Credential Manager API, bringing passkeys to their clients and users on smartwatches.

Streamlining Authentication on Wear OS

Dashlane users have frequently requested a Wear OS solution that provides standalone authentication for their favorite apps. In the past, Wear OS lacked the key APIs necessary for this request, which kept Dashlane from being able to provide the functionality. In their words:

“Our biggest challenge was the lack of a standard credentials API on Wear OS, which meant that it was impossible to bring our core features to this platform.”

This has changed with the introduction of the new Credential Manager API on Wear OS.

Credential Manager provides a simplified, standardized user sign-in experience with built-in authentication options for passkeys, passwords, and federated identities like Sign in with Google. Conveniently, it can be implemented with minimal effort by reusing the same code as the mobile version.

The Dashlane team was thrilled to learn about this, as it meant they could save a lot of time and effort: “[The] CredentialManager API provides the same API on phones and Wear OS; you write the code only once to support multiple form factors.”

After Dashlane had planned out their roadmap, they were able execute their vision for the new app with only a small engineering investment, reusing 92% of the Credential Manager code from their mobile app. And because the developers built Dashlane’s app UI with Jetpack Compose for Wear OS, 60% of their UI code was also reused.

Developing for Wear OS

To provide credentials to other apps with Credential Manager, Dashlane needed to implement the Credential Provider interface on Wear OS. This proved to be a simple exercise in calling their existing mobile code, where Dashlane had already implemented behavior for credential querying and credential selection.

For example, Dashlane was able to reuse their logic to handle client invocations of CredentialManager.getCredential. When a client invokes this, the Android framework propagates the client’s getCredentialRequest to Dashlane’s CredentialProviderService.onBeginGetCredentialRequest implementation to retrieve the credentials specified in the request.

Dashlane delegates the logic for onBeginGetCredentialRequest to their handleGetCredentials function, below, which is shared between their mobile and Wear OS implementations.

// When a Credential Manager client calls 'getCredential', the Android
// framework invokes `onBeginGetCredentialRequest`. Dashlane
// implemented this `handleGetCredentials` function to handle some of
// the logic needed for `onBeginGetCredentialRequest`
override fun handleGetCredentials(
    context: Context,
    request: BeginGetCredentialRequest):
List<CredentialEntry> =
  request.beginGetCredentialOptions.flatMap { option ->
    when (option) {
      // Handle passkey credential
      is BeginGetPublicKeyCredentialOption -> {
        val passkeyRequestOptions = Gson().fromJson(
            option.requestJson, PasskeyRequestOptions::class.java)

        credentialLoader.loadPasskeyCredentials(
          passkeyRequestOptions.rpId,
          passkeyRequestOptions.allowCredentials ?: listOf()
        ).map { passkey ->
          val passkeyDisplayName = getSuggestionTitle(passkey, context)

          PublicKeyCredentialEntry.Builder(
            context,
            passkeyDisplayName,
            pendingIntentForGet(context, passkey.id),
            option
          )
          .setLastUsedTime(passkey.locallyViewedDate)
          .setIcon(buildMicroLogomarkIcon(context = context))
          .setDisplayName(passkeyDisplayName)
          .build()
// Handle other credential types

Reusing precise logic flows like this made it a breeze for Dashlane to implement their Wear OS app.

“The Credential Manager API is unified across phones and Wear OS, which was a huge advantage. It meant we only had to write our code once.”

Impact and Improved Growth

The team is excited to be among the first credential providers on wearables: “Being one of the first on Wear OS was a key differentiator for us. It reinforces our brand as an innovator, focusing on the user experience, better meeting and serving our users where they are.”

As an early adopter of this new technology, Dashlanes Wear OS app has already shown early promise, as described by Dashlane software engineer, Sebastien Eggenspieler: “In the first 3 months, our Wear OS app organically grew to represent 1% of our active device install base.”

With their new experience launched, Wear OS apps can now rely on Dashlane as a trusted credential provider for their own Credential Manager integrations, using Dashlane to allow users to log in with a single tap; and users can view details about their credentials right from their wrist.

Dashlane’s Recommendations to Wear OS Developers

With their implementation complete, the Dashlane team can offer some advice for other developers who are considering the Credential Manager API. Their message is clear: “the future is passwordless… and passkeys are leading the way, [so] provide a passkey option.”

As a true innovator in their field, and the preferred credential provider for so many users, we are thrilled to have Dashlane support Credential Manager. They truly inspired us with their commitment to providing Wear OS users with the best experience possible:

“We hope that in the future every app developer will migrate their existing users to the Credential Manager API.”

Get Started with Credential Manager

With its elegant simplicity and built-in secure authentication methods, the Credential Manager API provides a simple, straightforward authentication experience for users that changes the game in Wear OS.

Want to find out more about how Dashlane is driving the future of end-user authentication? Check out our video blog with their team in Paris, and read about how they found a 70% in sign-in conversion rates with passkeys.

To learn more about how you can implement Credential Manager, read our official developer and UX guides, and be sure to check out our brand new blog post and video blog as part of Wear OS Spotlight week!

We’ve also expanded our existing Credential Manager sample to support Wear OS, to help guide you along the way, and if you’d like to provide credentials like Dashlane, you can use our Credential Provider sample.

Finally, explore how you can start developing additional experiences for Wear OS today with our documentation and samples.

The post How Dashlane Brought Credential Manager to Wear OS with Only 78 New Lines of Code appeared first on InShot Pro.

Posted by Fahd Imtiaz – Senior Product Manager and Miguel Montemayor – Developer Relations Engineer

With new form factors like the Pixel 10 Pro Fold joining the Android ecosystem, adaptive app development is essential for creating high-quality user experiences across phones, tablets, and foldables. Users expect your app’s UI to seamlessly adapt to these different sizes and postures.

To help you build these dynamic experiences more efficiently, we are announcing that the Compose Adaptive Layouts Library 1.2 is officially entering beta. This release provides powerful new tools to create polished, responsive UIs for this expanding device ecosystem.

Powerful new tools for a bigger canvas

The Compose Adaptive Layouts library is our foundational toolkit for building UIs that adapt across different window sizes. This new beta release is packed with powerful features to help you create sophisticated layouts with less code. Key additions include:

• Powerful new layout strategies: The beta introduces new layout strategies like reflow and levitate, designed to help you build dynamic layouts that look great on both the outer and inner displays of a device like the Pixel 10 Pro Fold, Galaxy Z Fold7 and Z Flip7.
• New Window Size Classes: The release adds built-in support for the new Large and Extra-Large window size classes. These new breakpoints are essential for designing and triggering rich, multi-pane UI changes on expansive screens like tablets and large foldables.

For a full list of changes, check out the official release documentation. Explore our guides on canonical layouts and building a supporting pane layout.

Engage more users on every screen

Embracing an adaptive mindset is more than a best practice, it’s a strategy for growth. The goal isn’t just to make your app work on a larger screen, but to make it shine by becoming more intuitive for users. Instead of simply stretching a single-column layout, think about how you can use the extra space to create more efficient and immersive experiences.

This is the core principle behind dynamic layout strategies like reflow, a powerful new feature in the Compose Adaptive Layouts 1.2 beta designed to help you build these UIs. For example, a great starting point is adopting a multi-pane layout. By showing a list and its corresponding detail view side-by-side, you reduce taps and allow users to accomplish tasks more quickly.

This kind of thoughtful adaptive development is what truly boosts engagement. And, as we highlighted during the latest episode of #TheAndroidShow, this is why we see that users who use an app on both their phone and a larger screen are almost three times more engaged. Building adaptively doesn’t just make your current users happier; it creates a more valuable and compelling experience that builds lasting loyalty and helps you reach new users.

The expanding Android ecosystem, from foldables to desktops

This shift toward adaptive design extends across the entire Android ecosystem. From the new Pixel 10 Pro Fold to the latest Samsung Galaxy foldables, developers have the opportunity to engage a large and growing user base on over 500 million large-screen devices.

This is also why we’re continuing to invest in forward-looking experiences like Connected Displays, currently available to try in developer preview. This feature opens up new surfaces and interaction models for apps to run on, enabling true desktop-class features and multi-instance workflows. We’ve previously shared details on how you can get started with the Connected Displays developer preview and see how it’s shaping the future of multi-device experiences.

Putting adaptive principles into practice

For developers who want to get their apps ready for this adaptive future, here are a few key best practices to keep in mind:

• Take inventory: The first step is to see where you are today. Test your app on a large screen device or with the resizable emulator in Android Studio to identify areas for improvement, like stretched UIs or usability issues.
• Support optimized layouts: Use libraries like Compose Adaptive Layouts to build UI that adapts to different window sizes and device postures. Your app should work well in both portrait and landscape, without restricting orientation.
• Think beyond touch: A great adaptive experience means supporting all input methods. This goes beyond basic functionality to include thoughtful details that users expect, like hover states for mouse cursors, context menus on right-click, and support for keyboard shortcuts.

Your app’s potential is no longer confined to a single screen. Explore the large screen design gallery and app quality guidelines today to envision where your app can go. Get inspired and find design patterns, official guidance, and sample apps you need to build for every fold, flip, and screen at developer.android.com/adaptive-apps.

The post Unfold new possibilities with Compose Adaptive Layouts 1.2 beta appeared first on InShot Pro.

Posted by Garan Jenkin – Developer Relations Engineer

This post is part of Wear OS Spotlight Week. Today, we’re exploring the wonderful world of watch faces.

At Google I/O ‘25 we launched Watch Face Push, a new API aimed at enabling watch face marketplaces for watch and phone. Watch Face Push is now available to develop with and use on Wear OS 6 on devices such as the recently-launched Pixel Watch 4.

In this blog post, we’ll show how Watch Face Push (WFP) can be used in a whole host of other ways, including:

• Dynamically theming a watch face from a photo
• Presenting rich data or photos from online or connected data sources
• Complementing a phone app to drive engagement

The first example we’ll focus on is building a watch face with an accompanying phone app. It can apply a color theme based on a photo taken on the phone – perfect for matching your watch face to your outfit! And it’s perfect for demonstrating how Watch Face Push allows developers to bring dynamic data to the watch face.

Let’s go through some of the main techniques which combine together to make this possible:

The default watch face – bringing components together

A powerful feature of Watch Face Push is the default watch face feature. This allows the developer to provide a watch face that’s installed onto the Wear OS device at the same time as the overall app. This watch face is bundled as an APK and placed in the assets directory in the app.

The system checks for the presence of this APK as the app is being installed, and it checks for the validation key in the app’s manifest.

This enables you to deliver a single package that contains both the watch face and app components, whether that’s a full Wear OS app, where the app is the primary focus, or app components such as complication providers, where the watch face is the primary focus.

In our project structure, we define two modules, wear and watchface. By using a unified versionCode across both, we can keep the app and watch face versions in sync. We use Gradle to build the watch face and generate the validation token. This makes it easy to treat the watch face and the app as part of the same project.

Complication data sources – pipelines for data

Now that we’ve successfully supplied both watch face and app components together, we need a way to provide data.

The watch face is now able to rely on the presence of complication data sources provided by the app. For example, a surfing watch face could bundle with a water temperature complication. This can be set as the default on the watch face using DefaultProviderPolicy and is guaranteed to be present.

Taking it a step further, we can configure the complication to be non-customizable, so that the complication becomes more of a custom data source. We can then use the complication however the watch face may need:

<ComplicationSlot isCustomizable="FALSE" ... >
    <DefaultProviderPolicy
        defaultSystemProvider="NEXT_EVENT"
        defaultSystemProviderType="SHORT_TEXT"
        primaryProvider="<my_component_path>"
        primaryProviderType="SHORT_TEXT" />

   <!-- Rest of complication goes here -->

</ComplicationSlot>

In the case of our watch face, we define a SHORT_TEXT complication service PaletteComplicationService, which sends the following data:

TEXT: <space-delimited list of RGB hex values>
TITLE: CONFIGURED | NOT_CONFIGURED

By using two of the fields on SHORT_TEXT, we’re able to send our color palette to the watch face, along with an indicator of whether the app has been configured (more on why that is important later).

Extracting and manipulating complication data

We’ve demonstrated how using the guaranteed presence of the PaletteComplicationService allows us to ensure the watch face can receive our data, but we still need to define how to use and show the data within watch face elements.

Within the ComplicationSlot element on the watch face, these data items can be accessed as COMPLICATION.TEXT and COMPLICATION.TITLE respectively. The various functions such as abs() and subText() can be used to extract parts of these strings, or convert them into numeric types.

We combine this with the use of REFERENCE to define colors. We can retrieve these colors everywhere on the watch, including outside of the ComplicationSlot:

<ComplicationSlot ...
    isCustomizable="FALSE"
    x="0" y="0" width="1" height="1">
  <DefaultProviderPolicy
      defaultSystemProvider="NEXT_EVENT"
      defaultSystemProviderType="SHORT_TEXT"
    primaryProvider="com.example.palette/com.example.palette.complication.PaletteComplicationService"
      primaryProviderType="SHORT_TEXT" />
  <BoundingBox height="1" width="1" x="0" y="0" />
  <Complication> 

    <!-- Complication data source sends 3 RGB hex values, extract the first: -->
    <PartDraw x="0" y="0" width="1" height="1">
      <Transform target="tintColor" value="extractColorFromColors([COMPLICATION.TEXT], false, 0.0)" />
      <Reference source="tintColor" defaultValue="#000000" name="primary_color" />
      <Line startX="0" startY="0" endX="1" endY="1">
        <Stroke color="#000000" thickness="1" />
      </Line>
    </PartDraw>

    ...
  </Complication>
</ComplicationSlot>

This snippet illustrates creating a very small ComplicationSlot, which will simply serve as a pipeline for our data:

Within the complication, a placeholder PartDraw is created, and the extractColorFromColors() function is used to transform the PartDraw to the first color supplied by the complication. Using the Reference element, this color value is then available to the rest of the watch face as [REFERENCE.primary_color].

In the full example, two more PartDraw elements are used to provide the secondary_color and tertiary_color, simply providing the 0.5 and 1.0 index to the extractColorFromColors function instead of the 0.0 value.

Some of the samples illustrate how you can share different data types beyond just colors, such as numeric values.

Referencing complication data in the watch face

The primary_color, secondary_color and tertiary_color values can now be used elsewhere on the watch face, both in expressions and in transforms. In our example, we use the colors on the watch face hands:

<HourHand resource="hour" x="210" y="75" width="30" height="180" pivotX="0.5"
    pivotY="0.8333" tintColor="[REFERENCE.primary_color]">
</HourHand>

// Similar logic for the minute hand and second hand would refer to
// secondary_color and tertiary_color, respectively.

Keeping the watch face package up to date

A challenge with the default watch face approach is that if the app is updated, the watch face doesn’t automatically get updated with it, even if the new app bundle contains an updated watch face. To address that issue, the app uses a BroadcastReceiver to receive the MY_PACKAGE_REPLACED action. On receiving this, the app can then check whether the watch face is installed and is in need of an upgrade, using Watch Face Push to perform the upgrade if necessary.

For the MY_PACKAGE_REPLACED action to be received, the app must have been run at least once. For this reason, the sample watch faces include an example of ensuring the user launches the app: A “launch app” button is shown on the watch face if the app has not been launched before. This is achieved by using a Condition on the CONFIGURED or NOT_CONFIGURED status described earlier.

For many watch faces, this has an additional purpose: it allows the user to enable additional components, such as a photo downloader in the Photo Album example shown here. You can also use the “first launch” experience to prompt the user to grant permissions or to sign in.

Working with other app components

While the complication data source is the conduit for data, and is the common component in all the examples, the following Android APIs work with complications to achieve the desired functionality:

• WearableListenerService – both the PaletteWatchFace and the FootballWatchFace have phone companion apps, and the Data Layer is used to send data to the watch. Once received by the WearableListenerService, you can proactively update the data on the watch face using ComplicationDataSourceUpdateRequester.
• WorkManager – the PhotoAlbumWatchFace example demonstrates how to retrieve photos from an online photo service. WorkManager is used for this, using Constraints to only download images while the device is being charged.
• ForegroundService – the DeviceDataWatchFace illustrates using a ForegroundService to obtain data from a connected Bluetooth device which is then visualized on the watch face.

Check out the full source for these examples. We look forward to seeing what you can create!

The post Further explorations with Watch Face Push appeared first on InShot Pro.

Posted by Michael Stillwell – Developer Relations Engineer

This post is part of Wear OS Spotlight Week. Today, we’re focusing on creating engaging experiences across the various surfaces available on the wrist.

Developing for the growing ecosystem of Wear OS is a unique and rewarding challenge that encourages you to think beyond mobile patterns. Wear’s design philosophy focuses on crafting experiences for a device that’s always with the user, where meaningful interactions take seconds, not minutes. A successful wearable app doesn’t attempt to maximize screen time; it instead aims to deliver meaningful glanceable experiences that help people stay present and productive while on the go. This vision is now fully enabled by the next generation of hardware, which we explored last week with the introduction of the new Pixel Watch 4.

Wear OS devices also introduce constraints that push you to innovate. Power efficiency is critical, requiring you to build experiences that are both beautiful and battery-conscious. You’ll also tackle challenges like handling offline use cases and catering for a variety of screen sizes.

Despite these differences, you’ll find yourself on familiar technical foundations. Wear OS is based on Android, which means you can leverage your existing knowledge of the platform, architecture, developer APIs, and tools to create wearable experiences.

Wear OS surfaces

Wear OS offers a range of surfaces to inform and engage users. This allows you to tailor your app’s presence on the watch, providing the right information at the right time and scaling your development investment to best meet your users’ needs.

Watch faces display the time and are the first thing a user sees when they look at their watch. We’ll cover watch faces in more detail in other blog posts across Wear OS Spotlight week.

Apps provide a richer, more immersive UI for complex tasks that are too involved for other surfaces.

Notifications provide glanceable, time-sensitive information and actions.

Complications display highly-glanceable, relevant data from your app directly on the user’s chosen watch face. Learn more about building complication data sources for Wear OS.

Tiles (Widgets for Wear OS) offer fast, predictable access to information and actions with a simple swipe from the watch face.

Whilst a variety of Wear OS surfaces let developers to engage with users in different ways, it may be overwhelming to get started. We recommend approaching Wear OS development in phases and scale up your investment over time:

• Improve the wearable experience of your mobile app. You can improve the wearable experience with minimal effort. By default, notifications from your phone app are automatically bridged to the watch. You can start by enhancing these with wearable-specific actions using NotificationCompat.WearableExtender, offering a more tailored experience without building a full Wear OS experience.
• Build a companion experience. When you’re ready for a dedicated UI, create a tethered app experience that depends on the phone app for its core features and data. This involves creating a tethered app that works in tandem with your phone app, allowing you to design a customized UI for the wrist and take advantage of surfaces like tiles and complications.
• Graduate to a standalone app. Finally, you can evolve your app into a standalone experience that works independently of a phone, which is ideal for offline scenarios like exercising. This provides the most flexibility but also requires more effort to optimize for constraints like power efficiency.

Notifications

Notifications are a core part of the Wear OS experience, delivering glanceable, time-sensitive information and actions for the user. Because Wear OS is based on Android, it shares the same notification system as mobile devices, letting you leverage your existing knowledge to build rich experiences for the wrist.

From a development perspective, it helps to think of a notification not as a simple alert, but as a declarative UI data structure that is shared between the user’s devices. You define the content and actions, and the system intelligently renders that information to best suit the context and form factor. This declarative approach has become increasingly powerful. On Wear OS, for example, it’s the mechanism behind ongoing activities.

Alert-style notifications

One great thing about notifications is that you don’t even need a Wear OS app for your users to see them on their watch. By default, notifications generated by your phone app are automatically “bridged”, or mirrored, to a connected watch, providing an instant wearable presence for your app with no extra work. These bridged notifications include an action to open the app on the phone.

You can enhance this default behavior by adding wearable-specific functionality to your phone notifications. Using NotificationCompat.WearableExtender, you can add actions that only appear on the watch, offering a more tailored experience without needing to build a full Wear OS app.

// Prerequisites:
//
//   1. You've created the notification channel CHANNEL_ID
//   2. You've obtained the POST_NOTIFICATIONS permission

val channelId = "my_channel_id"
val sender = "Clem"
val subject = "..."

val notification =
    NotificationCompat.Builder(applicationContext, channelId)
        .apply {
            setContentTitle("New mail from $sender")
            setContentText(subject)
            setSmallIcon(R.drawable.new_mail_mobile)
            // Added for Wear OS
            extend(
                NotificationCompat.WearableExtender().apply {
                    setSmallIcon(R.drawable.new_mail_wear)
                }
            )
        }
        .build()

NotificationManagerCompat.from(applicationContext).notify(0, notification)

Prevent duplicate notifications

Once you build a dedicated app for Wear OS, you’ll need to develop a clear notification strategy to avoid a common challenge: duplicate notifications. Since notifications from your phone app are bridged by default, a user with both your phone and watch apps installed could see two alerts for the same event.

Wear OS provides a straightforward way to manage this:

1. On the mobile app’s notification, assign a string identifier using setBridgeTag().
2. In your Wear OS app, you can then programmatically prevent notifications with certain tags from being bridged using a BridgingConfig. This gives you fine-grained control, allowing you to bridge some notifications while handling others natively in your Wear OS app.

If your mobile and watch apps generate similar but distinct notifications, you can link them using setDismissalId(). When a user dismisses a notification on one device, any notification with the same dismissal ID on another connected device is also dismissed.

Creating interactive experiences

From a user’s perspective, apps and tiles may feel very similar. Both are full-screen experiences that are visually rich, support animations, and handle user interaction. The main differences are in how they are launched, and their specific capabilities:

• Apps can be deeply immersive and handle complex, multi-step tasks. They are the obvious choice when handling data that must be synced between the watch app and its associated phone app, and the only choice for long-running tasks like tracking workouts and listening to music.
• Tiles are designed for fast, predictable access to the information and actions users need most, providing glanceable content with a simple swipe from the watch face. Think of tiles as widgets for Wear OS.

Apps and tiles are built using distinct technologies. Apps can be built with Jetpack Compose, while tiles are defined declaratively using the ProtoLayout library. This distinction allows each surface to be highly optimized for its specific role – apps can provide rich, interactive experiences while tiles remain fast and power-efficient.

Building apps

Apps provide the richest experience on Wear OS. Jetpack Compose for Wear OS is the recommended UI toolkit for building them – it works seamlessly with other Jetpack libraries and accelerates development productivity. Many prominent apps, like Gmail, Calendar and Todoist, are built entirely with Compose for Wear OS.

Compose for Wear OS for beautiful UIs

If you’ve used Jetpack Compose for mobile development, you’ll find that Compose for Wear OS shares the same foundational principles and mental model. However, building for the wrist requires some different techniques, and the toolkit provides a specialized UI component library optimized for watches.

Wear OS has its own dedicated Material Design, foundation, and navigation libraries to use instead of the mobile Jetpack libraries. These libraries provide UI components tailored for round screens and glanceable interactions, and are each supported by Android Studio’s preview system.

• Lists: On mobile, you might use a LazyColumn to display a vertical collection of items. On Wear OS, the TransformingLazyColumn is the equivalent component. It supports scaling and transparency effects to items at the edge of a round screen, improving legibility. It also has built-in support for scrolling with rotary input.
• Navigation: Handling screen transitions and the back stack also requires a component that’s specific to Wear OS. Instead of the standard NavHost, you must use SwipeDismissableNavHost. This component works with the system’s swipe-to-dismiss gesture, ensuring users can intuitively navigate back to the previous screen.

Learn how to use Jetpack Compose on Wear OS to get started, including sample code.

Implementing core app features

Wear OS also provides APIs designed for power efficiency and the on-wrist use case, as well as Wear OS versions of mobile APIs:

• Authentication: Credential Manager API unifies the user sign-in process and supports modern, secure methods like passkeys, passwords, and federated identity services (like Sign-in with Google), providing a seamless and secure experience without relying on a companion phone.
• Ambient: To handle the low-power ambient (always-on) state, we recommend using the AmbientLifecycleObserver to receive callbacks for state transitions. In the onEnterAmbient() callback, adjust your UI for low-power display by dimming colors and hiding non-essential elements. Use onExitAmbient() to restore your app’s full UI. Learn more about always-on apps and system ambient mode.
• Health and Fitness (sensor data): While you can use the standard Android Sensor APIs, it’s not recommended for performance reasons, especially for long-running workouts. Instead, use Health Services on Wear OS. It acts as an intermediary to the various sensors, providing your app with batched, power-efficient updates for everything from heart rate to running metrics, without needing to manage the underlying sensors directly.

Building tiles

Tiles offer quick, predictable access to the information and actions users need most, accessible with a simple swipe from the watch face. By using platform data bindings to display sources like step count or heart rate, you can provide timely and useful information in your tile.

Tiles are built declaratively using the ProtoLayout libraries, which are optimized for performance and power efficiency—critical considerations on a wearable device. Learn more about how to get started with tiles and how to make use of sample tile layouts.

More resources for building experiences for Wear OS

• Wear OS Documentation Hub: The essential resource for developers looking to create experiences for Wear OS, from design guidelines to code samples.
• App design guidance: The official resource to learn how to design for Wear OS.
• Compose starter sample app: A starter project that provides a solid foundation for a new Wear OS app.
• Media sample app from Jetcaster: A sample podcast app showcasing how to reuse code between form factors, updated to Material 3 Expressive on Wear OS.
• WearTilesKotlin sample app: Demonstrates the fundamentals of building a tile but also includes templates for common layouts, letting you quickly bootstrap your own designs while following best practices.
• Compose on Wear OS codelab: A step-by-step tutorial for building a functional app for Wear OS from scratch.
• Tiles on Wear OS codelab: For a more guided, step-by-step introduction to building tiles.

There has never been a better time to start building for Wear OS. If you have feedback on the APIs, please let us know using the issue trackers for Wear Compose and Tiles. We look forward to seeing what you build!

The post Building experiences for Wear OS appeared first on InShot Pro.

Posted by Anoushka Mazumdar – Product Manager, and Adam Soutar – Software Engineer

This post is part of Wear OS Spotlight Week. Today, we’re exploring the wonderful world of watch faces.

Create simple no code watch faces or build complex ones quickly with this Figma plugin

We’re thrilled to introduce Watch Face Designer, a new design tool that can empower everyone, from seasoned designers to passionate enthusiasts, to craft watch faces directly in Figma. This Figma plugin works seamlessly on devices running Wear OS 4 or higher. Say goodbye to complex coding and hello to seamless design!

Watch Face Designer is built from the ground up to integrate with the Watch Face Format for Wear OS. It’s not only for designers looking to bring their visions to life without a single line of code; it’s also a powerful tool for developers who want to rapidly prototype and mock up watch faces before diving into more intricate functionality, such as animations, in Android Studio.

Design at the speed of thought with Watch Face Designer

This initial version of Watch Face Designer has plenty of features to kickstart your watch face design journey:

• Supports core Watch Face Format features: digital and analog time, interactive and ambient mode, custom fonts, complications, automatic theme creation from your Figma styles, and more.
• Intuitive plugin window: The plugin window provides a streamlined interface to preview your designs in real-time and effortlessly edit individual elements to support watch face functionality.
• Flexible export options: Once your design is complete, you can export your design in several ways:
• Direct to Play Store (recommended for designers): Publish your watch face directly to the Google Play Store.
• Export to Android Studio (recommended for developers) or Watch Face Studio: For developers or those seeking to add advanced functionality, seamlessly export your design to Android Studio or Watch Face Studio to build upon your foundation.
• View on device: See your watch face come to life on your actual Wear OS device for a true-to-life preview.

The Watch Face Designer UI displaying a list of export options

Get started today

Ready to start designing your next favorite watch face? Get started with the Watch Face Designer plugin. It can be found on the @androiddesign page on Figma’s Community tab. There you can also find our Playground file featuring sample watch faces, and handy complication templates. We’ve also included a comprehensive overview guide that walks you through the process, from concept to completion.

We can’t wait to see the incredible watch faces you’ll create with Watch Face Designer! Stay tuned for more updates and exciting new features coming soon.

The post A comprehensive workflow from design to device: Introducing Watch Face Designer appeared first on InShot Pro.

Posted by Garan Jenkin – Developer Relations Engineer

This post is part of Wear OS Spotlight Week. Today, we’re exploring how Amoledwatchfaces successfully migrated to Watch Face Format, improving customization, extending battery life, and increasing development speed.

Amoledwatchfaces is a leading creator of watch faces for Wear OS using the Watch Face Format (WFF), known for a distinctive information-rich and crisp style. Now well-established on the platform with over 190 watch faces, we talked to Tomáš Marcinčin, owner of Amoledwatchfaces about their successful migration using the format, and the benefits he’s seen in development velocity and performance as a result.

Creating high-quality watch faces without complex code

In previous years, developing watch faces “took a lot of time,” says Tomáš Marcinčin, owner of Amoledwatchfaces. The AndroidX libraries allowed developers to create watch faces, but Tomáš, like others, was left looking for an “easier way to create watch faces,” and crucially one that shifted the focus from coding and onto design.

“My main motivation was to bring users watch faces that are of the same quality as those that are pre-installed. Users were looking for designs that were not too complicated, yet customizable and looked as if they had been designed for that watch.”

Expressing interest in a customized experience

Like many creators, Tomáš started using Watch Face Studio, Samsung’s watch face creation tool, giving designers and developers an easy way to build watch faces for Wear OS quickly.

While successful, as a developer, he found himself wanting more control, and a solution that was somewhere in between Watch Face Studio and full code – this led him to working directly with the format.

Migrating to Watch Face Format

Amoledwatchfaces already had a significant back catalog of watch faces, and took on the dual task of both converting all his existing watch faces and producing new ones directly in the format. “I wanted to have every old and new watch face design in WFF.” This would ensure that all Amoledwatchfaces’ watch faces would be available to current and future users.

Tomáš started working directly in Android Studio, gradually refining his build process. Android Studio has recently added support for syntax validation – a feature Tomáš fed directly into and helped test as an early adopter.

Once up and running, Tomáš found that some of the most time-consuming tasks of AndroidX were extremely simple in the format. Notably, adding the level of user customization he – and users – wanted “is very easy.”

As an example, some of Amoledwatchfaces’ users wanted different Always-On Display (AOD) styles – some preferred a dimmed view of the active state, whereas others wanted only the digital clock. Using Variant, and configuration options such as ListConfiguration and BooleanConfiguration, it was straightforward for Tomáš to give users the ability to customize their watch face – something which would have required a significant investment using legacy libraries.

<Variant mode="AMBIENT" target="alpha" value="[CONFIGURATION.aod] == 0
    ? 255 : [CONFIGURATION.aod] == 1 ? 165 : 0" />

Overcoming Watch Faces quality and versioning challenges

To shorten the debug cycle and minimize errors, Tomáš uses the WFF validator and memory footprint tools in his Gradle scripts. He also incorporates tools such as PNGQuant into his Gradle builds so that resource usage remains optimized.

However, the biggest challenge is creating different versions of the watch face for the different format versions that devices support. To help solve this issue, Tomáš took advantage of product flavors, which let him define a different build configuration for each version. This way, he was able to support the widest range of users while still using the latest and greatest format features on the most recent devices:

/** Set up flavors for different format versions **/


flavorDimensions += "wff_version"
productFlavors{
   // Wear OS 4
   create("wff1"){
       dimension = "wff_version"
       manifestPlaceholders["wff_version"] = "1"
       versionNameSuffix = "-wff1"
       versionCode = 10000 + (android.defaultConfig.versionCode ?: 0)
       minSdk = 33
       targetSdk = 33
   }


   // … other flavors defined here!


   // Wear OS 6
   create("wff4"){
       dimension = "wff_version"
       manifestPlaceholders["wff_version"] = "4"
       versionCode = 40000 + (android.defaultConfig.versionCode ?: 0)
       versionNameSuffix = "-wff4"
       minSdk = 36
       targetSdk = 36
   }
}

Improving velocity and battery life

Amoledwatchfaces is now seeing their investment in this journey to future-proof their watch faces paying off: “Our watch faces are now simply more customizable and more battery friendly. With 8 custom complication slots where you can combine all different complication types, users can have every possible combination of relevant data at a glance.”

User feedback has been great, according to Tomáš, “people mostly refer to battery life improvements after the switch to Watch Face Format.”

And the format has also had a positive effect on development velocity: “I’m developing watch faces faster and cleaner. Updating projects to newer WFF versions is very easy. Fixing bugs is easy too.”

Making the switch to the format

As announced recently, all developers must migrate to Watch Face Format by January 2026. Amoledwatchfaces has benefitted from being an early adopter and recommends that other developers make the switch early too.

Tomáš adds, “Don’t be afraid of switching to a WFF project, managed completely by you. It may seem hard at first sight but when you learn all the attributes, you can define your perfect progress bar arc or gradient digital clock faster than in other tools.”

He also suggests a hybrid workflow, where you work directly in the format and use other tools and editors such as Watch Face Studio. You can first create your watch face in Watch Face Studio, then extract all the resources from the bundle and continue in your preferred IDE.

This week, we’re also announcing Watch Face Designer, which is a Figma-based plugin that you can use in a similar way: start with your design, then export to your preferred format for further refinement.

What’s next for Amoledwatchfaces?

For Tomáš, the journey hasn’t ended, and he’s continuing to strive to delight users even more with each new creation. “There’s always room for improvement. When there’s a new WFF version or feature which could benefit watch faces and thus users, I’ll be adding that.”

We’re looking forward to seeing the next creations from Amoledwatchfaces!

Getting started the with Watch Face Format

• Documentation for developers
• Watch Face Format guidance documentation
• Watch Face Format reference documentation
• Watch Face Format project samples
• Watch Face Format codelab
• Graphical editors for designers
• Watch Face Studio – standalone design tool
• Watch Face Designer – Figma plugin
• Watch Face Designer guidance
• Migration guidance

We hope this story inspires you to take your next steps with the Watch Face Format.

The post Migrating to the Watch Face Format – Amoledwatchfaces’ journey appeared first on InShot Pro.