1--- 2title: 'Skia in Flutter & Fuchsia' 3linkTitle: 'Skia in Flutter & Fuchsia' 4--- 5 6Skia is used by both [Flutter](https://flutter.io/) and 7[Fuchsia](https://fuchsia.googlesource.com/docs/+/master/README.md). 8 9Fuchsia has a [roller](https://autoroll.skia.org/) that will continuously roll 10latest Skia into that project. Fuchsia uses an XML 11[manifest](https://fuchsia.googlesource.com/manifest/+/refs/heads/master) to 12specify the Skia revision (as well as other third party libraries). 13 14Flutter does not (yet) have a roller, so developers must manually perform rolls. 15Flutter uses [DEPS](https://github.com/flutter/engine/blob/master/DEPS) to 16specify third party dependencies. 17 18Although each project is (almost always) building at a different revision of 19Skia, Fuchsia itself always builds the latest revision of Flutter as one of its 20components. Thus, the versions of Skia being used by Flutter and Fuchsia must be 21"source compatible" -- Flutter must be capable of compiling against either 22revision without any change to Flutter itself. 23 24## Making API Changes 25 26If you need to make a breaking API change, the basic approach is: 27 28- Add new code to Skia, leaving the old code in place. 29- Deprecate the old code path so that it must be enabled with a flag such as 30 'SK_SUPPORT_LEGACY_XXX'. 31- Add that same flag to 32 [flutter_defines.gni](https://skia.googlesource.com/skia/+/master/gn/flutter_defines.gni) 33 in Skia. 34 - Both Flutter and Fuchsia build Skia with a GN argument that enables all the 35 defines listed in that file. 36- Land the Skia change, and test the new API in both Flutter and Fuchsia. 37- Remove the flag and code when the legacy code path is no longer in use. 38