Tag Archives: mobile

Update your G Suite mobile and desktop apps before August 12, 2020, to ensure they continue working

Quick summary

In 2018, we began making changes to our API and service infrastructure to improve performance and security. As a result of these changes, some older versions of G Suite desktop and mobile apps may stop working on August 12, 2020. In particular, versions released prior to December 2018 may be impacted.

To ensure their workflows are not disrupted, your users should update the following Google apps to the latest versions as soon as possible:

Getting started
  • Admins: Encourage your users to upgrade their apps. If you deploy Drive File Stream to your organization, ensure you’re using the latest version.
  • End users: Upgrade the apps listed above to the latest versions as soon as possible.
Rollout pace

Availability
  • This impacts all G Suite customers and users with personal Google accounts.

Unveiling expert insights in our new podcast series: Apps, Games, & Insights

Posted by Lily Sheringham, Global Marketing, Platforms & Ecosystems

This is a cross-post from The Google Keyword blog.

Apps, Games, & Insights illustrated banner with gaming imagery.

Today we’re launching the Apps, Games, & Insights podcast series, bringing together insights, stories, and learnings from industry experts, on some of today's hottest topics surrounding mobile, apps and games businesses, and the wider industry.

Listen to the podcast here!

The series has eight episodes which aim to challenge, provoke thought, and enlighten listeners - from designers and developers, through to product managers and marketers, and those interested in the apps and games industry.

The podcast is hosted by Googlers Tamzin Taylor, who heads up Apps & Games Business Development for Google Play in Western Europe, and Dirk Primbs, who leads the Ecosystem Developer Relations team in EMEA. Together, they have many years of experience working with partners to assist with Android development, mobile, app, game, and business growth. Every week they will be joined by different guests for each of the episodes.

Sneak peek at what’s coming up

Kicking off the series are Judy Chen and Sarah Fuchs from Crowdstar, the developers of Covet Fashion and Design Home. They join us for episode 1 to discuss how to build a long-term games business by taking a holistic approach to the game, its players, and the people who create the game.

Ever wonder if it's worth selling your app or game business, and if so how to approach it? It's not all about pocketing the cash and walking away. For episode 2, game mergers and acquisitions expert Chris Petrovic from Zynga will talk about how acquisition can free developers to focus on what they love: creating great apps and games.

The popularity of subscriptions continues to grow, with developers who used subscriptions earning 4X more in 2018, than in 2016. Holly Ackerman and David Berlin, from the sports streaming platform DAZN, join us for episode 3 to provide some fascinating insights into how they have grown their subscription business in this industry.

Whether you are a startup in search of funding or an established business looking to accelerate your investment, venture capital can often be a good source of funds. In episode 4, venture capital expert Matteo Vallone from Cherry Ventures offers insights into the investment process and how to maximize your appeal to investors.

For episode 5, we have what is possibly one of the biggest topics in mobile and throughout the tech industry: privacy. Bruce Gustafson, CEO of Developers Alliance brings us up to speed on trust and safety, platform value, respecting the user, and ultimately building privacy friendly apps and games.

Successful game developers put players front and center of everything they do. When over 270 million people have played your games, you must be doing something right. Ben Clarke, Senior Global Marketing Director at Jagex, joins us for episode 6 to discuss some of the innovative approaches to player engagement and retention taken in their RuneScape games.

Figuring out how to make your app or game accessible to all can often be a challenge, sometimes both from an organizational and technical perspective. However, many developers have made accessibility a core part of their app development process and company culture. For episode 7, we’re joined by Ceri Lindsay and Rosalind Whittam from the BBC to discover how they address accessibility.

Today, Android is not just about smartphones, Android apps and games can run on a range of devices with larger screens, such as Chromebooks. At the same time, mature mobile game franchises are looking for opportunities beyond mobile. In our final episode 8, we’ll be joined by Maximiliano Rodriguez of Gameloft to talk about the challenge of taking games to big screens and new platforms.

We hope you’ll join us over the next eight weeks to dive deeper and hear what our thought leader guests have to say on each topic.

How to stay tuned in

To listen to our first podcast and find out more about what’s coming, check out our new Apps, Games, & Insights podcast homepage.

Listen to our first episode here, or on Spotify, Apple Podcasts, Google Play Music, Google Podcasts, Deezer, iHeartRadio, and also on LibSyn. Keep an eye out on @GooglePlayDev and @AndroidDev on Twitter where we will be announcing the launch of the new episodes each week.

How useful did you find this blog post?

New Android management client for devices registered after September 16, 2019

What’s changing 

On September 16, 2019, we’ll begin gradually rolling out a new Android management system called “Android Management API.” Apps managed through the new system will also use a new on-device management client, Android Device Policy, which will replace the existing Google Apps Device Policy client.

While the new client has mostly similar features, there are some differences in management and usage that will impact G Suite admins and end users. The changes will make it easier for admins and users to set up and manage Android devices for work.

You will receive an email notification before it impacts your domain 
The rollout will be conducted in stages, and could take several months to reach all domains. We will email your organization’s primary admin around 3 weeks before it will reach your domain with more specific dates for deployment.

See below for more details about the changes.

Who’s impacted 

Admins and end users

Why you’d use it 

The new client will have closer ties to the Android infrastructure, allowing us to quickly add new features and more easily develop updates for increased security. It will also provide a more seamless experience for end users, with fewer apps to manage and more integrated functionality.

How to get started 


  • Admins: Familiarize yourself with the changes outlined in this post, including the additional details section below. Let your users know about the changes they can expect. 
  • End users: No action needed. 


Additional details 

Devices that will use the new Android management client 
Once this change has been deployed to your domain, newly registered devices that meet the following requirements will be automatically managed using the Android Management API:

  • The device is using Android M or above. 
  • The device supports a work profile and company-owned (fully managed) device mode. 
  • The user account is under advanced mobile device management. 

This will not impact previously enrolled devices; they will still be managed through the legacy Android management client.

How managing devices is different with the new client 
In the Admin console, most of the functionality will remain the same. All devices will be displayed and managed through the same interface at Admin console > Device management.

There will be some changes, however, for devices managed through the new client.

The following features will not be supported:
  • Device admin mode
  • Option to disable Work Profile setup (If you don’t want to use Work Profiles in your organization, you can instruct your users to set up devices without enabling the feature) 
  • Wipe Account for company-owned devices or devices in fully managed device (device owner) mode (Wipe Device will still be available) 


The following new features will be available:


The following features will change:
  • If you manually choose to Wipe Device, you’ll have a new option to either retain the factory reset protection settings or clear them along with the complete wipe. 
  • The Auto account wipe setting will perform Wipe Device for devices in fully managed device (device owner) mode. In addition to being applied when devices fall out of sync, Auto account wipe will be triggered when devices fall out of some policies (for instance, when a more restrictive passcode policy has been enforced by the admin). In both cases, the user will be given a grace period and notifications to correct the issue prior to the wipe taking place. 
  • Device management rules will initiate a device wipe instead of an account wipe for devices in fully managed device (device owner) mode. 


You can see which client is managing a device in the Admin console at Security details > User agent. Devices using the legacy client will have a version of Google Apps Device Policy, while devices using the new client will have a version of Android Device Policy. Use our Help Center to learn how to view mobile device details.

How using a device is different with the new client 
The main end-user visible changes include the following:

  • Users will have an updated enrollment experience. 
  • After the new version is deployed, users will no longer see a Device Policy app in their app drawer. The new management system and Android Device Policy app will be integrated with Android for a more seamless experience. 
  • Users won’t be able to use My Devices to manage their device (for the time being, they can use Find My Device). 
  • If your organization enforces a strong password, the password will require a symbol in addition to the letter and number previously required. 


Users will experience a slightly different setup flow when registering new devices. 


Migrating from the legacy system to the Android Management API 
Once this change has been deployed to your domain, you can manually migrate users and devices to the new Android Management API in the following ways:

  • Factory reset and re-register any eligible device. 
  • Provide a new device and register it. 

In the future, we’ll add options and tools to help you migrate existing devices to use the Android Management API. Check out the G Suite Updates blog for the latest changes and migration updates. 

Availability 

Rollout details 
  • All domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on September 16, 2019. The rollout will be conducted in stages, and could take several months to reach all domains. 
  • Primary admins will be notified by email around 3 weeks before it will reach your domain. 

G Suite editions 
  • Available to all G Suite editions 

On/off by default? 
  • This feature will be ON by default for new devices that meet the requirements above.


Stay up to date with G Suite launches

Mobile-First Indexing by default for new domains

Over the years since announcing mobile-first indexing - Google's crawling of the web using a smartphone Googlebot - our analysis has shown that new websites are generally ready for this method of crawling. Accordingly, we're happy to announce that mobile-first indexing will be enabled by default for all new, previously unknown to Google Search, websites starting July 1, 2019. It's fantastic to see that new websites are now generally showing users - and search engines - the same content on both mobile and desktop devices!

You can continue to check for mobile-first indexing of your website by using the URL Inspection Tool in Search Console. By looking at a URL on your website there, you'll quickly see how it was last crawled and indexed. For older websites, we'll continue monitoring and evaluating pages for their readiness for mobile first indexing, and will notify them through Search Console once they're seen as being ready. Since the default state for new websites will be mobile-first indexing, there's no need to send a notification.


Using the URL Inspection Tool to check the mobile-first indexing status

Our guidance on making all websites work well for mobile-first indexing continues to be relevant, for new and existing sites. For existing websites we determine their readiness for mobile-first indexing based on parity of content (including text, images, videos, links), structured data, and other meta-data (for example, titles and descriptions, robots meta tags). We recommend double-checking these factors when a website is launched or significantly redesigned.

While we continue to support responsive web design, dynamic serving, and separate mobile URLs for mobile websites, we recommend responsive web design for new websites. Because of issues and confusion we've seen from separate mobile URLs over the years, both from search engines and users, we recommend using a single URL for both desktop and mobile websites.

Mobile-first indexing has come a long way. We're happy to see how the web has evolved from being focused on desktop, to becoming mobile-friendly, and now to being mostly crawlable and indexable with mobile user-agents! We realize it has taken a lot of work from your side to get there, and on behalf of our mostly-mobile users, we appreciate that. We’ll continue to monitor and evaluate this change carefully. If you have any questions, please drop by our Webmaster forums or our public events.

Instant-loading AMP pages from your own domain

Today we are rolling out support in Google Search’s AMP web results (also known as “blue links”) to link to signed exchanges, an emerging new feature of the web enabled by the IETF web packaging specification. Signed exchanges enable displaying the publisher’s domain when content is instantly loaded via Google Search. This is available in browsers that support the necessary web platform feature—as of the time of writing, Google Chrome—and availability will expand to include other browsers as they gain support (e.g. the upcoming version of Microsoft Edge).

Background on AMP’s instant loading

One of AMP's biggest user benefits has been the unique ability to instantly load AMP web pages that users click on in Google Search. Near-instant loading works by requesting content ahead of time, balancing the likelihood of a user clicking on a result with device and network constraints–and doing it in a privacy-sensitive way.

We believe that privacy-preserving instant loading web content is a transformative user experience, but in order to accomplish this, we had to make trade-offs; namely, the URLs displayed in browser address bars begin with google.com/amp, as a consequence of being shown in the Google AMP Viewer, rather than display the domain of the publisher. We heard both user and publisher feedback over this, and last year we identified a web platform innovation that provides a solution that shows the content’s original URL while still retaining AMP's instant loading.

Introducing signed exchanges

A signed exchange is a file format, defined in the web packaging specification, that allows the browser to trust a document as if it belongs to your origin. This allows you to use first-party cookies and storage to customize content and simplify analytics integration. Your page appears under your URL instead of the google.com/amp URL.

Google Search links to signed exchanges when the publisher, browser, and the Search experience context all support it. As a publisher, you will need to publish both the signed exchange version of the content in addition to the non-signed exchange version. Learn more about how Google Search supports signed exchange.

Getting started with signed exchanges

Many publishers have already begun to publish signed exchanges since the developer preview opened up last fall. To implement signed exchanges in your own serving infrastructure, follow the guide “Serve AMP using Signed Exchanges” available at amp.dev.

If you use a CDN provider, ask them if they can provide AMP signed exchanges. Cloudflare has recently announced that it is offering signed exchanges to all of its customers free of charge.

Check out our resources like the webmaster community or get in touch with members of the AMP Project with any questions. You can also provide feedback on the signed exchange specification.


User experience improvements with page speed in mobile search

To help users find the answers to their questions faster, we included page speed as a ranking factor for mobile searches in 2018. Since then, we've observed improvements on many pages across the web. We want to recognize the performance improvements webmasters have made over the past year. A few highlights:

  • For the slowest one-third of traffic, we saw user-centric performance metrics improve by 15% to 20% in 2018. As a comparison, no improvement was seen in 2017.
  • We observed improvements across the whole web ecosystem. On a per country basis, more than 95% of countries had improved speeds.
  • When a page is slow to load, users are more likely to abandon the navigation. Thanks to these speed improvements, we've observed a 20% reduction in abandonment rate for navigations initiated from Search, a metric that site owners can now also measure via the Network Error Logging API available in Chrome.
  • In 2018, developers ran over a billion PageSpeed Insights audits to identify performance optimization opportunities for over 200 million unique urls.

Great work and thank you! We encourage all webmasters to optimize their sites’ user experience. If you're unsure how your pages are performing, the following tools and documents can be useful:

  1. PageSpeed Insights provides page analysis and optimization recommendations.
  2. Google Chrome User Experience Report provides the user experience metrics for how real-world Chrome users experience popular destinations on the web.
  3. Documentation on performance on Web Fundamentals.

For any questions, feel free to drop by our help forums (like the webmaster community) to chat with other experts.


Consolidating your website traffic on canonical URLs

In Search Console, the Performance report currently credits all page metrics to the exact URL that the user is referred to by Google Search. Although this provides very specific data, it makes property management more difficult; for example: if your site has mobile and desktop versions on different properties, you must open multiple properties to see all your Search data for the same piece of content.

To help unify your data, Search Console will soon begin assigning search metrics to the (Google-selected) canonical URL, rather than the URL referred to by Google Search. This change has several benefits:

  • It unifies all search metrics for a single piece of content into a single URL: the canonical URL. This shows you the full picture about a specific piece of content in one property.
  • For users with separate mobile or AMP pages, it unifies all (or most, since some mobile URLs may end up as canonical) of your data to a single property (the "canonical" property).
  • It improves the usability of the AMP and Mobile-Friendly reports. These reports currently show issues in the canonical page property, but show the impression in the property that owns the actual URL referred to by Google Search. After this change, the impressions and issues will be shown in the same property.

When will this happen?

We plan to transition all performance data on April 10, 2019. In order to provide continuity to your data, we will pre-populate your unified data beginning from January 2018. We will also enable you to view both old and new versions for a few weeks during the transition to see the impact and understand the differences.

API and Data Studio users: The Search Console API will change to canonical data on April 10, 2019.

How will this affect my data?

  • At an individual URL level, you will see traffic shift from any non-canonical (duplicate) URLs to the canonical URL.
  • At the property level, you will see data from your alternate property (for example, your mobile site) shifted to your "canonical property". Your alternate property traffic probably won't drop to zero in Search Console because canonicalization is at the page, not the property level, and your mobile property might have some canonical pages. However, for most users, most property-level data will shift to one property. AMP property traffic will drop to zero in most cases (except for self-canonical pages).
  • You will still be able to filter data by device, search appearance (such as AMP), country, and other dimensions without losing important information about your traffic.

You can see some examples of these traffic changes below.

Preparing for the change

  • Consider whether you need to change user access to your various properties; for example: do you need to add new users to your canonical property, or do existing users continue to need access to the non-canonical properties.
  • Modify any custom traffic reports you might have created in order to adapt for this traffic shift.
  • If you need to learn the canonical URL for a given URL, you can use the URL Inspection tool.
  • If you want to save your traffic data calculated using the current system, you should download your data using either the Performance report's Export Data button, or using the Search Console API.

Examples

Here are a few examples showing how data might change on your site. In these examples, you can see how your traffic numbers would change between a canonical site (called example.com) and alternate site (called m.example.com).

Important: In these examples, the desktop site contains all the canonical pages and the mobile contains all the alternate pages. In the real world, your desktop site might contain some alternate pages and your mobile site might contain some canonical pages. You can determine the canonical for a given URL using the URL Inspection tool.

Total traffic

In the current version, some of your traffic is attributed to the canonical property and some to the alternate property. The new version should attribute all of your traffic to the canonical property.


Canonical property
(http://example.com)
Alternate property
(http://m.example.com)
Current

New, based on canonical URLs

Change +0.7K     |        +3K -0.7K        |          -3K

Individual page traffic

You can see traffic changes between the duplicate and canonical URLs for individual pages in the Pages view. The next example shows how traffic that used to be split between the canonical and alternate pages are now all attributed to the canonical URL:


Canonical property
(http://example.com)
Alternate property
(http://m.example.com)

Old

New

Change

+150     |        +800

-150     |        -800

Mobile traffic

In the current version, all of your mobile traffic was attributed to your m. property. The new version attributes all traffic to your canonical property when you apply the "Device: Mobile" filter as shown here:


Canonical property
(http://example.com)
Alternate property
(http://m.example.com)

Old

New

Change

+0.7K      | +3K

-0.7K      | -3K

In conclusion

We know that this change might seem a little confusing at first, but we're confident that it will simplify your job of tracking traffic data for your site. If you have any questions or concerns, please reach out on the Webmaster Help Forum.


Manage and distribute Android apps when using basic mobile management

What’s changing 

You can now manage Android apps for your users when using basic mobile management. Previously, you could only do this if you used advanced mobile management.

Who’s impacted 

Admins only

Why you’d use it 

With basic mobile management you can now:
  • Organize apps in the managed Google Play store 
  • Automatically install apps on users' devices 
  • Create web apps 
  • Create private apps 

See below for more info.

How to get started 

  • Admins: Go to Admin console > Device management > App Management > Manage apps for Android devices, to start to whitelist and manage Android apps
  • End users: No action needed. Users in basic mobile management domains will now see a “Work apps” section in the managed Google Play store. The section contains the default G Suite apps and other apps that are whitelisted from the Admin console

Additional details 


Organize apps in the managed Google Play store: 
To help your users find the apps they need, you can organize apps into collections. These collections appear on devices in the “Work apps” section in the managed Google Play store.

Automatically install apps: 
With basic mobile management you can now automatically install apps on your users’ devices. Use our Help Center to find out how to manage app preferences. Note that preventing users from uninstalling apps, and some other advanced features, require advanced mobile management.

Create web apps 
You can now create and manage web apps in the Admin console. Web apps look like native apps and can make web pages easier to find and simpler to use on mobile devices. You can also distribute web apps the same way you distribute native apps–by adding them to collections in a managed Google Play store or automatically installing them on users’ devices.

Create private apps 
You can now create private Android apps directly from the Admin console. Simply upload the APK and give the app a title. The app will appear in the managed Google Play store within minutes. You can also install the app directly on your users’ devices (see above). Previously, it took several hours to create and publish an app, and you had to create a Play Console account, provide a credit card, and fill in many other fields before the app would be available to your users.


The ‘Work Apps’ tab in the managed Google Play store has the G Suite apps and other apps whitelisted by admins. 

Helpful links 


Availability 

Rollout details 

G Suite editions:
Available to all G Suite editions.

On/off by default? 
This feature will be OFF by default until app management is set up, and can be enabled at the domain, OU, or group level.

Stay up to date with G Suite launches
  • Get G Suite product update alerts by email
  • See the G Suite launch release calendar
  • Subscribe to the RSS feed of these updates
  • Mobile-First indexing, structured data, images, and your site

    It's been two years since we started working on "mobile-first indexing" - crawling the web with smartphone Googlebot, similar to how most users access it. We've seen websites across the world embrace the mobile web, making fantastic websites that work on all kinds of devices. There's still a lot to do, but today, we're happy to announce that we now use mobile-first indexing for over half of the pages shown in search results globally.

    Checking for mobile-first indexing

    In general, we move sites to mobile-first indexing when our tests assure us that they're ready. When we move sites over, we notify the site owner through a message in Search Console. It's possible to confirm this by checking the server logs, where a majority of the requests should be from Googlebot Smartphone. Even easier, the URL inspection tool allows a site owner to check how a URL from the site (it's usually enough to check the homepage) was last crawled and indexed.

    If your site uses responsive design techniques, you should be all set! For sites that aren't using responsive web design, we've seen two kinds of issues come up more frequently in our evaluations:

    Missing structured data on mobile pages

    Structured data is very helpful to better understand the content on your pages, and allows us to highlight your pages in fancy ways in the search results. If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages. This is important because with mobile-first indexing, we'll only use the mobile version of your page for indexing, and will otherwise miss the structured data.

    Testing your pages in this regard can be tricky. We suggest testing for structured data in general, and then comparing that to the mobile version of the page. For the mobile version, check the source code when you simulate a mobile device, or use the HTML generated with the mobile-friendly testing tool. Note that a page does not need to be mobile-friendly in order to be considered for mobile-first indexing.

    Missing alt-text for images on mobile pages

    The value of alt-attributes on images ("alt-text") is a great way to describe images to users with screen-readers (which are used on mobile too!), and to search engine crawlers. Without alt-text for images, it's a lot harder for Google Images to understand the context of images that you use on your pages.

    Check "img" tags in the source code of the mobile version for representative pages of your website. As above, the source of the mobile version can be seen by either using the browser to simulate a mobile device, or by using the Mobile-Friendly test to check the Googlebot rendered version. Search the source code for "img" tags, and double-check that your page is providing appropriate alt-attributes for any that you want to have findable in Google Images.

    For example, that might look like this:

    With alt-text (good!):
    <img src="cute-puppies.png" alt="A photo of cute puppies on a blanket">

    Without alt-text:
    <img src="sad-puppies.png">

    It's fantastic to see so many great websites that work well on mobile! We're looking forward to being able to index more and more of the web using mobile-first indexing, helping more users to search the web in the same way that they access it: with a smartphone. We’ll continue to monitor and evaluate this change carefully. If you have any questions, please drop by our Webmaster forums or our public events.


    Flutter 1.0: Google’s Portable UI Toolkit

    Posted by Tim Sneath, Group Product Manager for Flutter

    Today, at Flutter Live, we're announcing Flutter 1.0, the first stable release of Google's UI toolkit for creating beautiful, native experiences for iOS and Android from a single codebase.

    Cross-platform mobile development today is full of compromise. Developers are forced to choose between either building the same app multiple times for multiple operating systems, or to accept a lowest common denominator solution that trades native speed and accuracy for portability. With Flutter, we believe we have a solution that gives you the best of both worlds: hardware-accelerated graphics and UI, powered by native ARM code, targeting both popular mobile operating systems.

    Introducing Flutter

    Flutter doesn't replace the traditional Apple and Android app models for building mobile apps; instead, it's an app engine that you can either embed into an existing app or use for an entirely new app.

    We think of the characteristics of Flutter along four dimensions:

    1. Flutter enables you to build beautiful apps. We want to enable designers to deliver their full creative vision without being forced to water it down due to limitations of the underlying framework. Flutter lets you control every pixel on the screen, and its powerful compositing capabilities let you overlay and animate graphics, video, text and controls without limitation. Flutter includes a full set of widgets that deliver pixel-perfect experiences on both iOS and Android. And it enables the ultimate realization of Material Design, Google's open design system for digital experiences.
    2. Flutter is fast. It's powered by the same hardware-accelerated Skia 2D graphics engine that underpins Chrome and Android. We architected Flutter to be able to support glitch-free, jank-free graphics at the native speed of your device. Flutter code is powered by the world-class Dart platform, which enables compilation to native 32-bit and 64-bit ARM code for iOS and Android.
    3. Flutter is productive. Flutter introduces stateful hot reload, a revolutionary new capability for mobile developers and designers to iterate on their apps in real time. With stateful hot reload, you can make changes to the code of your app and see the results instantly without restarting your app or losing its state. Stateful hot reload transforms the way developers build an app -- and in user surveys, developers say it makes their development cycle three times more productive.
    4. Lastly, Flutter is open. Flutter is an open source project with a BSD-style license, and includes the contributions of hundreds of developers from around the world. In addition, there's a vibrant ecosystem of thousands of plug-ins. And because every Flutter app is a native app that uses the standard Android and iOS build tools, you can access everything from the underlying operating system, including code and UI written in Kotlin or Java on Android, and Swift or Objective-C on iOS.

    Put this all together, combine it with best-in-class tooling for Visual Studio Code, Android Studio, IntelliJ or the programmer's editor of your choice, and you have Flutter -- a development environment for building beautiful native experiences for iOS or Android from a single codebase.

    Flutter Growth and Momentum

    We announced the first beta of Flutter at Mobile World Congress ten months ago, and we've been excited to see how quickly it has been adopted by the broader community, as evidenced by the thousands of Flutter apps that are already published to the Apple and Google Play stores even before our 1.0 release. It's clear that developers are ready for a new approach to UI development.

    Internally, Flutter is being used at Google for a wide array of products, with Google Ads already having switched to Flutter for their iOS and Android app. And even before 1.0, a wide range of global customers including Abbey Road Studios, Alibaba, Capital One, Groupon, Hamilton, JD.com, Philips Hue, Reflectly, and Tencent are developing or shipping apps with Flutter.

    Michael Jones, Senior Director of Engineering from the Capital One team, says the following about their experiences with Flutter:

    "We are excited by Flutter's unique take on high-performing cross-platform development. Our engineers have appreciated the rapid development promise and hot reload capabilities, and over the past year we have seen tremendous progress in the framework and especially the native integration story.

    "Flutter can allow Capital One to think of features not in an 'iOS or Android-first' fashion, but rather in a true mobile-first model. We are excited to see Flutter 1.0 and continue to be impressed with the pace of advancement and the excitement in the engineering community."

    At the Flutter Live event today, the popular payment service Square announced two new Flutter SDKs that make it easy to accept payments for goods and services with Flutter, whether in-person using a Square payment reader or by taking payments inside a mobile app. Square demonstrated an example of using their payments SDK using an app from Collins Family Orchards, a family farm that grows and sells fruit in farmers markets around the Pacific Northwest.

    The developer of the Collins Family Orchards app, Dean Papastrat, had this to say about his experience:

    "I was blown away by the speed of all the animations and transitions in production builds. As a web developer, it was super easy to make the transition to Flutter, and I can't believe I was able to build a fully working app that can take payments in just a week."

    Also at Flutter Live, 2Dimensions announced the immediate availability of Flare, a remarkable new tool for designers to create vector animations that can be embedded directly into a Flutter app and manipulated with code. Flare eliminates the need to design in one app, animate in another, then convert all of that to device-specific assets and code.

    Animations built with Flare can be embedded into an existing Flutter app as a widget, allowing them to participate in the full compositor and be overlaid with other text, graphical layers or even UI widgets. Integrating in this way frees animations from the 'black box' limitations of other architectures, and allows ongoing collaboration between designers and developers right up to the completion of the app. Such tight integration between Flutter and Flare provides a uniquely compelling offering for digital designers and animators who want to create highly-polished mobile experiences.

    Another partner who has bet on Flutter is Nevercode, a fast-growing provider of continuous integration and delivery (CI/CD) tooling for mobile apps. At Flutter Live, they announced Codemagic, a new tool designed specifically for Flutter to make it easy to automate the process of building and packaging Flutter apps for both Android and iOS from a single automation. Available today in beta, Codemagic allows you to select a GitHub repo containing a Flutter project, and with just a few clicks, create continuous build flows that run tests, and generate binary app bundles that you can upload to the Apple and Google Play stores.

    We put together a short video to highlight the range and variety of the apps developers have been building with Flutter since the beta:

    New Features in Flutter 1.0

    Since the first beta, we've been working to add features and polish to Flutter. In particular, we rounded out our support for pixel-perfect iOS apps with new widgets; added support for nearly twenty different Firebase services; and worked on improving performance and reducing the size of Flutter apps. We've also closed out thousands of issues based on feedback from the community.

    Flutter also includes the latest version of the Dart platform, 2.1, an update to Dart 2 that offers smaller code size, faster type checks, and better usability for type errors. Dart 2.1 also has new language features to improve productivity when building user experiences. Developers who have already adopted Dart 2.1 tell us they're seeing significant speed improvements just by switching to the latest engine:

    While the primary focus of the 1.0 release is bug fixes and stabilization, we're also introducing previews of two major new features for developers to try out in preview mode that we anticipate will ship in our next quarterly release in February 2019: Add to App and platform views.

    Add to App

    When we first built Flutter, we focused on productivity for the scenario where someone is building a new application from scratch. But of course, not everyone has the luxury of being able to start with a clean slate. Talking to some of our larger customers, it was clear that they wanted to use Flutter for new user journeys or features within an existing application, or to convert their existing application to Flutter in stages.

    The architecture of Flutter supports this model well: after all, every Flutter app includes a host Android and iOS container. But we've been working to make it easier to incrementally adopt Flutter by updating our templates, tooling and guidance for existing apps. We've made it easier to share assets between Flutter and host code. And we've also reworked the tooling to make it easy to attach to an existing Flutter process without launching the debugger with the application.

    We will continue to work to make this experience even better. Even though a number of customers are already using our guidance on Add to App successfully, we're continuing to add samples and expand support for complex scenarios. In the meantime, our instructions for adding Flutter to existing apps are on our wiki, and you can track the remaining work on the GitHub project board.

    Platform Views

    While Add To App is useful as a way to gradually introduce Flutter to an existing application, sometimes it's useful to go the other way round and embed an Android or iPhone platform control in a Flutter app.

    So we've introduced platform view widgets (AndroidView and UiKitView) that let you embed this kind of content on each platform. We've been previewing Android support for a couple of months, but now we're expanding support to iOS, and starting to add plug-ins like Google Maps and WebView that take advantage of this.

    Like other components, our platform view widgets participate in the composition model, which means that you can integrate it with other Flutter content. For example, in the screenshot above, the floating action button in the bottom right corner is a Flutter widget that has background color with 50% alpha. This demonstrates the unique architectural advantages of Flutter well.

    While this work is ready for developers to try out, we're continuing to work on improving performance and device compatibility, so we recommend caution if deploying apps that depend on PlatformViews. We're continuing to actively optimize platform views and expect them to be ready for production in time for our next quarterly update.

    Flutter Beyond Mobile

    The primary target for Flutter has so far been iOS and Android. Yet our ambitions for Flutter extend beyond mobile to a broader set of platforms. Indeed, from the outset Flutter was architected as a portable UI toolkit that is flexible enough to go wherever pixels are painted.

    Some of this work has already been taking place in the open. Flutter Desktop Embedding is an early-stage project that brings Flutter to desktop operating systems including Windows, MacOS, and Linux. We also recently published informal details of using Flutter on Raspberry Pi, as a way to demonstrate Flutter embedding support to smaller-scale devices that may not include a full desktop environment.

    This week, at Flutter Live, we gave the first sneak peek of an experimental project we're working on in the labs that significantly expands where Flutter can run.

    Hummingbird is a web-based implementation of the Flutter runtime that takes advantage of the capability of the Dart platform to compile not just to native ARM code but also to JavaScript. This enables Flutter code to run on the standards-based web without change.

    We have a separate blog article on Medium that describes the technical implementation details of Hummingbird. And we'll have a lot more to share on Hummingbird at Google I/O in 2019: hope to see you there!

    Of course, mobile remains our immediate priority, and you can expect to see the bulk of our investment in these core mobile scenarios over the coming months.

    Conclusion

    With the release of Flutter 1.0, we've established a new 'stable' channel, in addition to the existing beta, dev, and master channels. The stable channel updates less often than other channels, but we have a higher confidence in its quality since builds have already been vetted through the other channels. We anticipate that we'll update our stable channel on a quarterly basis with our most battle-tested builds.

    You can download Flutter 1.0 from our website at https://flutter.io, where you can also find documentation for developers transitioning from other frameworks, code labs, a cookbook of common samples, and technical videos.

    We owe a particular debt to the early adopters who have joined us on the journey so far, providing feedback, identifying issues, creating content, and generally shaping the product. The Flutter community is one of our greatest assets as a project: a welcoming, diverse, helpful group of individuals who volunteer selflessly because they also care about this open source project. Thank you!

    Flutter is ready for you. What will you build?