Chapter 2: Exploring Platform-Specific Considerations

We will now spend some time exploring the various target platforms that are natively supported by Adobe Animate. To be successful with Animate, you must understand the underlying technologies involved in each platform and when to use one over another, as they each have their strengths and weaknesses. This understanding enables sound decisions when selecting a target document type when starting a new Animate project.

We'll begin with an overview of the major platforms supported natively as publish targets within Animate. Following this, we can then explore the variety of document types that support and target different aspects of these platforms for a greater understanding of why you might use certain document types over others.

Objectives for this chapter include the following:

• Understand the set of platforms native to Adobe Animate.
• Learn the purpose of and best practices around ActionScript 3.0, HTML5 Canvas, and AIR document types.
• Understand recommendations around beta document types, including both Virtual Reality (VR) and WebGL (standard and extended).

Technical Requirements

You will need the following software and hardware to complete this chapter:

• Adobe Animate 2021 (version 21.0 or above).
• Refer to the Animate System Requirements page for hardware specifications: https://helpx.adobe.com/animate/system-requirements.html. The CiA video for this chapter can be found at: https://bit.ly/3cike51.

Exploring Animate Document Types

While Flash Professional was, for years, focused entirely on the Flash platform, Adobe Animate seeks to define itself as a platform-agnostic software application. This basically means that any target platform is welcome to be part of the publish pipeline – even those not traditionally associated with the software.

Even though Animate seeks to play well with any platform that wants in on the game, it does support a number of important platforms natively:

Figure 2.1 – Publish targets native to Animate

Today, Animate comes pre-packaged with a number of target platforms for common usage. These include ActionScript 3.0, AIR for Desktop, AIR for iOS, AIR for Android, HTML5 Canvas, VR 360, VR Panorama, and WebGL glTF (in both standard and extended flavors). Some of these target platforms are still based on Flash Platform technologies, but most newer platforms that have been added target native web technologies such as the HTML canvas element with JavaScript and include specifications such as WebGL and glTF to achieve some pretty neat stuff!

You can see all available document types by choosing File | New from the application menu or by choosing Create New or More Presets from the Home screen and then choosing the Advanced category of the New Document dialog:

Figure 2.2 – New Document dialog – Advanced presets

The Advanced category of presets allows you to create a new document based upon a specific publishing platform, while the other category presets tend to only allow the choice of ActionScript 3.0 or HTML5 Canvas.

Tip

Within the New Document dialog, document types are listed under Platforms and Beta Platforms. You may need to scroll down to see them all. Any third-party platforms that have been enabled will show up even farther down the stack.

We'll next proceed through an overview of the major platforms available in Animate today. These are all based upon the Flash platform runtimes, native web technologies, and a set of beta platforms that extend these technologies.

Flash Platform Runtimes

As we detailed in the previous chapter, Animate was once only able to author Flash Platform technologies. You could create content to publish as a .swf to be executed using Adobe Flash Player in the web browser. For a long time, that was pretty much it! Of course, Flash content was absolutely huge during that time and Flash Platform designers and developers had no problem with this popularity.

The Flash Platform covers two main runtimes: the web-based Flash Player and the Adobe Integrated Runtime (AIR):

Figure 2.3 – The Adobe Flash runtimes: Flash Player and AIR

Both publish targets are based upon ActionScript 3.0, but in Animate terminology, the ActionScript 3.0 document type publishes a .swf file for use with Flash Player or other external mechanisms.

With all major web browsers – and even Adobe – no longer supporting Flash Player in the browser, we've come to a very interesting point in time. Even with web browsers no longer supporting Flash Platform content, the .swf format and other files published in various forms using the platform are still highly usable for many purposes. These purposes include the format's role as a motion graphics interchange format for other software such as Adobe After Effects, as packaged projector content, and most importantly, as an application development platform in Adobe AIR with the ability to target macOS, Windows, iOS, Android, and more!

Branching Out to the Native Web

In 2011, Adobe began an experiment with converting documents created with Flash Professional to HTML5. The project was codenamed Wallaby and only existed for a few years until other technologies and superior workflows took its place. Wallaby required an existing .fla for conversion and only included about 50% of the capabilities of a Flash .swf file.

This was followed in 2012 by Toolkit for CreateJS, an extension that would allow Flash Professional users to export to HTML5 directly from the software without having to produce an intermediate .fla file. The problem with this mechanism was that it was an optional extension that users would need to install, and it was still not tightly coupled with the authoring environment in the way that users would expect, and so was limited when compared to producing Flash content. The Flash Professional Toolkit for CreateJS ran as an extension and appeared as a panel within the interface – very different from the normal publishing process.

Eventually, with the maturity of the CreateJS libraries, coupled with a more platform-agnostic approach to publishing within the software, Flash Professional made CreateJS a native document type within the software through the use of the HTML5 Canvas document type.

Since that time, Adobe and the CreateJS team have expanded capabilities and integrations to the point where HTML5 Canvas is one of the primary document types within Animate. For interactive, web-based content, HTML5 Canvas is the go-to document type.

In addition, Animate can publish to the native web beyond the use of CreateJS through the use of the WebGL standard alongside the additional WebGL and Virtual Reality JavaScript runtime engines. We'll also explore some basic information around these additional native web-based target platforms in a bit!

Open to Custom Platforms

We mentioned previously that Adobe Animate is a platform-agnostic software application. This is a pretty major change in the software since, for most of its existence, Flash Professional produced content that ran exclusively within Flash Player.

We've explained a bit about expanding to additional platforms with CreateJS and related standards such as WebGL, but Animate actually goes even further by opening up the entire publishing API for anyone to incorporate their publish target platform of choice into the software:

Figure 2.4 – Animate custom platform SDK

Leveraging the Custom Platform Support Development Kit (CPSDK), anyone can create an extension that allows Animate users to target the platform of their own choosing. The CPSDK extends the power of Animate to new platforms such as Google AMP and LottieFiles. We'll look more deeply into different examples of extending Animate in Chapter 13, Extending Adobe Animate.

Note

Animate can be extended in three ways. It includes a JavaScript API (JSAPI) to automate actions in the user interface and the CPSDK to extend the power of Animate to new platforms.

In this section, we had a brief introduction to the three main target platform types supported by Adobe Animate: Flash/ActionScript-based targets, HTML/JavaScript-based targets, and custom platforms. Coming up, we'll have a look at the particulars around using ActionScript 3.0 documents.

Understanding ActionScript 3.0 Documents

It makes sense to first explore what was at one time the single target platform supported by Animate for most of its existence: Flash Player and the .swf file format. Since Flash Player is a runtime, it exists to execute a packaged set of assets and data in order to run a program. The .swf file format is basically a compressed little bundle of creative assets and code that Animate can publish for this purpose.

Note

ActionScript 3.0 used to be used to produce all sorts of rich, interactive content. With the deprecation of Flash Player in the web browser, however, the role of .swf has become more focused.

There is a bit of confusion around the naming of this document type within Animate, as you won't find a document type that targets "Flash Player" or "SWF" but rather "ActionScript 3.0" instead:

Figure 2.5 – The ActionScript 3.0 document type

Newcomers are often confused by this terminology and expect that, if creating an ActionScript 3.0 document, they will be writing code. While you can absolutely write full applications using this document type, it isn't necessary to do so.

ActionScript 3.0 documents are ideal for working in Animate when exporting to video or even for integration with After Effects and other compositing software. ActionScript 3.0 is the document most often chosen for creative, non-interactive content today, even over any sort of Flash Player. If you want to create interactive content for the web or other platforms, Animate can do those things too! You'll want to use other document types such as HTML5 Canvas or AIR for these purposes.

Okay, let's dig deeper through an overview of the technologies behind ActionScript 3.0 documents in Animate by exploring Adobe Flash Player, the SWF file format, and the ActionScript programming language.

Adobe Flash Player

There are a couple of different versions of Flash Player to know about. There is, of course, the once-ubiquitous web browser plugin that was finally deprecated on December 31, 2020 after years of being a staple web technology and even being built into major browsers such as Google Chrome and Microsoft Internet Explorer due to its status as a de facto standard.

Adobe announced that Flash Player in the web browser would be deprecated way back in 2017 and we should assume from now on that no user will be able to run such content through the browser plugin.

The reasoning behind this decision was stated that native web standards such as HTML5, WebGL, and WebAssembly had reached a point of maturity that they could now be relied upon to serve the same (or similar) needs that Flash Player in the browser had fulfilled in years past, thus making Flash Player redundant.

Important note

For more insight into the thinking behind this, I suggest you have a look at the Adobe Flash Player EOL General Information Page at https://www.adobe.com/products/flashplayer/end-of-life.html.

The web browser is only part of the story though. There are also standalone and debug versions of the Flash Player runtime, which can operate outside of the browser environment. A good example of this is the Flash Player that is built into Animate itself. Whenever a Test Movie is performed from an ActionScript 3.0 project, Animate opens a .swf file produced from your project within this version of Flash Player. It's very convenient to be able to test your animated content directly within the authoring software in this way.

The SWF file format

As mentioned previously, when publishing an ActionScript 3.0 document in Animate, a .swf file is produced. The .swf file extension is so named due to Macromedia wanting to extend its Shockwave branding that was being used by another software product, Director, to produce content that would run on the web.

When Macromedia acquired FutureSplash Animator and renamed it Flash, they also named the files it produced Shockwave Flash – SWF!

Figure 2.6 – ActionScript 3.0 produces a SWF file

What made this file format so desirable for use of the web was that it could contain all sorts of media: vectors, bitmaps, sound, video, data, and program code. It did all of this in a very efficient way, as these files were known for being small in size and as such, quite suitable for transfer over the web.

In 2008, Adobe published portions of the .swf file format as part of their Open Screen Project initiative, but since much of the technology is either licensed or strictly proprietary, anyone wanting to build an open source version of Flash Player to interpret .swf files will have a difficult time replicating all functionality.

With the decline of Flash Player and the eventual removal of the runtime from web browsers, it has become increasingly difficult to play .swf files as originally intended. Thankfully, the .swf file format can also be used as a transport format, and other applications such as Adobe After Effects can leverage this as part of an animator's compositing pipeline.

The ActionScript Language

ActionScript is the programming language native to Flash Player and the .swf file format. There are three versions of the language: ActionScript 1.0 and ActionScript 2.0 are very similar to one another and are executed by the same VM (virtual machine) within Flash Player and AIR, while ActionScript 3.0 is a completely new language that runs in its own dedicated VM.

Similar to JavaScript, ActionScript is based upon ECMAScript, and while both languages do share many features, ActionScript 3.0 is based upon ECMAScript 4, which was ultimately abandoned and explains the various differences between ActionScript and JavaScript as they exist today.

A simple example of an ActionScript class is the following:

package com.josephlabrecque.example {

    public class Example {

        public function Example() {

            // constructor code

        }

    }

}

Even with this small example, you can see how organized the language structure and syntax is. Each class exists within a package and requires a constructor function. The language also supports object-oriented concepts such as interfaces and instantiation.

Even with Flash Player in the web browser being a thing of the past, ActionScript is still an excellent language, fun to write, and feature-rich. Even in the present day, we can effectively write applications and games for desktop and mobile using ActionScript and target these platforms with AIR technologies. We'll read more about AIR in a little bit.

Additionally, ActionScript is used when writing code for native web platforms through the integrations available in open source frameworks such as Apache Royale: https://royale.apache.org/. ActionScript is by no means a dead language!

Tip

ActionScript documentation can be found on Adobe's website: https://help.adobe.com/en_US/as3/learn/.

In this section, we explored the technologies involved when using the ActionScript 3.0 document type. Coming up, we'll perform a similar examination of the document type known as HTML5 Canvas.

Understanding HTML5 Canvas Documents

If you want to target the native web using Animate, the most popular option is to use the HTML5 Canvas document type. This is a native document type that is deeply integrated within Animate and produces animated and interactive content that will run in any modern web browser on desktop or mobile.

The HTML5 Canvas document type includes nearly all the capabilities and features that are available in older formats such as Flash, without the need for a separate plugin, extension, or runtime:

Figure 2.7 – The HTML5 Canvas document type

This is a native document type that is deeply integrated within Animate and produces animated and interactive content that will run in any modern web browser on desktop or mobile.

In our explorations of the HTML5 Canvas document type, we'll begin with a look at how Animate leverages both HTML and JavaScript to produce published content, followed by an overview of the canvas element, specifically. We'll round things off with a quick look at what makes all these technologies work together, the CreateJS libraries.

HTML and JavaScript

When publishing an HTML5 Canvas document, Animate will produce a bundle of files that includes HTML, JavaScript, and additional assets depending upon the project. The two main files that will always result when publishing this document type include an .html file and a .js file.

The HTML will act as a container document, while the JavaScript controls what happens within:

Figure 2.8 – HTML5 Canvas produces HTML and JavaScript

If using bitmap assets or sound files, they will also be included in the output within the folders you specify in the document Publish Settings.

Note

CSS can also be used in HTML5 Canvas documents through the use of HTML5 Components. To access these components, choose Window | Components from the application menu when using a document targeting HTML5 Canvas.

The CreateJS libraries themselves can be loaded via a Content Delivery Network (CDN) or can be exported along with your files (it's completely up to you). If you want to view your published files, it is best to transfer them from your local drive to a real web server. Browser security restrictions being what they are, they will likely not allow your canvas-based content to execute properly unless served from a web server.

Tip

When testing your HTML5 Canvas content via the Test Movie command within Animate, the software actually spins up a small, local web server to get around any potential browser security restrictions. It's very convenient!

The Canvas Element

The HTML5 Canvas document type is so named because it heavily leverages the <canvas/> element of HTML in order to provide a dynamic, interactive canvas for content playback and rendering. It basically defines a rectangular "stage" area in which all of our media resides as part of a larger HTML document.

A canvas element in HTML is established in the following manner using HTML Markup language:

<canvas width="1280" height="720"></canvas>

Here, we are only specifying a width and height for our element. You may want to also provide an ID in order to target this element specifically.

Tip

To learn more about the HTML canvas element, refer to the documentation on the Mozilla Developer Network: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas

To interact with and make adjustments to the canvas element and content rendered within, JavaScript is used. Have a look at the following example:

<script>

    const canvas = document.querySelector('canvas');

    const ctx = canvas.getContext('2d');

    ctx.fillStyle = 'darkred';

    ctx.fillRect(440, 160, 400, 400);

</script>

Here, we are defining our JavaScript code within an HTML <script/> tag. We initially set a constant to act as a reference to our canvas element and then set the context to operate in 2D. Following that, we are able to then draw content within this element through the use of the various canvas functions. In this simple example, we draw a red square and center it within the canvas element.

Animate, of course, does all this heavy lifting for us when working in HTML5 Canvas. There is no reason to manually create and manage HTML elements – we only provide these examples here for context.

Note

If you use components within an HTML5 Canvas project, they will be published within a special overlay that sits directly over the canvas element. Such projects will make use of both the canvas element and an additional set of elements representing the chosen components.

The CreateJS Libraries

While HTML and JavaScript establish the basic foundation of an HTML5 Canvas project, the real heavy-lifter for this target platform is CreateJS. This JavaScript library is actually a suite of libraries that includes the following:

• EaselJS: This library makes working with the HTML canvas element a more pleasant experience for those used to developing content using Flash technologies via the abstraction of the underlying APIs.
• TweenJS: We make use of this library to allow tweening and motion through the HTML canvas element and underlying native JavaScript APIs.
• SoundJS: Again, this library makes working with underlying web-native media APIs a more pleasant experience with a focus on audio management and playback for the web.
• PreloadJS: This allows the simplified management of both assets and data when working with other CreateJS libraries.

Together, these individual libraries form the CreateJS suite of tools. They can be used outside of Animate as well, but given that these libraries were designed specifically to emulate the Flash display list, they are a perfect match for Adobe Animate.

In this section, we saw how the canvas element of HTML combined with the CreateJS JavaScript library is used to form HTML5 Canvas documents in Animate. Coming up, we'll look at another important document type, Adobe AIR.

Exploring the Adobe Integrated Runtime

Adobe AIR was a major component of what used to be called the Flash Platform. It was one of two runtimes for the platform – and while AIR is certainly more powerful than its sister runtime, Flash Player, it is perhaps even more misunderstood. People generally understand web browsers and their capabilities and uses, but an installable package that runs similar to a native application on desktop and mobile such as AIR is somehow more difficult for the average person to get a handle on.

There is a lot to cover when it comes to AIR. We'll begin our overview with a look at a general explanation of what AIR is and its relationship to other technologies such as the ActionScript language. An explanation of the relationship between the two AIR SDK providers will follow as we go over recent partnerships between Adobe and HARMAN. To wrap things up, we'll explore the supported AIR document types within Animate: AIR for Desktop, AIR for iOS, and AIR for Android.

Adobe AIR

AIR itself is built upon Flash technology and in most cases, an .swf file is even produced that is packaged as part of the bundle:

Figure 2.9 – The AIR for Desktop document type

For platforms such as iOS that do not support .swf, the entire code base is actually translated into a native iOS application.

The main thing about AIR is that it runs entirely divorced from the web browser environment, while Flash Player was tied to it directly. This allows AIR to be much more powerful due to reduced security restrictions and tight integration with the underlying operating system. It uses the same language as Flash Player for writing interaction – ActionScript 3.0, and so was easy to adopt for the millions of Flash developers when it was first introduced.

Adobe AIR and ActionScript 3.0

Just as with ActionScript 3.0 document types within Animate, AIR makes use of ActionScript 3.0 as its primary programming language. Unlike targeting the output format as a limited .swf though, AIR is a natively installable package and because of this can have deep hooks within the operating system itself.

A great example of this is the Extended Desktop profile, which can be assigned within the AIR Settings dialog:

Figure 2.10 – The AIR publish settings allow deep integrations

When Extended Desktop has been chosen, AIR is then able to tap into the native processes of the operating system and communicate with any available process in order to really extend the capabilities of the runtime. This makes AIR far more powerful than anything targeting Flash Player or the web browser as it runs on the operating system itself and not through a security-restricted web browser prison.

Note

Initial versions of AIR actually supported developers in writing applications using either ActionScript or JavaScript. As the runtime developed further, the focus was placed on the ActionScript workflows, and eventually, JavaScript was dropped completely.

Adobe AIR and HARMAN

With Adobe halting all development on Flash Player in preparation for the December 31, 2020 deprecation event, they began looking for a partner to continue work on AIR, since it is still heavily used in the creation of applications and games and is completely unrelated to web browsers and the restrictions around that platform.

In May of 2019, the decision was made to partner more closely with HARMAN, a division of Samsung, which was heavily experienced in Flash Platform technologies. HARMAN would begin by focusing on an AIR solution targeting Android's upcoming 64-bit requirement and eventually expand to other platforms and systems supported by Adobe's version of the runtime.

Why was this decision made? With the end-of-life announcement of its sister runtime, Flash Player, Adobe had to decide whether they would continue supporting AIR or look to partners in the effort to maintain and grow the technology. In 2019, Adobe transitioned the development and support of AIR over to HARMAN due to their long history as a partner in the development and implementation of this technology for specific, bespoke implementations.

To read the announcement around this transition, have a look at The Future of Adobe AIR at https://blog.adobe.com/en/publish/2019/05/30/the-future-of-adobe-air.html.

HARMAN also released a statement about this new partnership on the same day as Adobe, in which they described the partnership and transition from their perspective. They explained, similar to the message from Adobe, their long partnership together on the AIR SDK and runtimes. The agreement between the two entities allows HARMAN to take on the support and maintenance of both the AIR runtime and the SDK. They also restated their commitment to ensuring the future growth and support of the technologies across various platforms.

Read more about the partnership from HARMAN's perspective in their FAQ: https://airsdk.harman.com/faq.

Since we are now well into 2021 at the time of writing this book, the partnership between Adobe and HARMAN has solidified and it is recommended that a new version of the AIR Software Development Kit (SDK) is acquired from HARMAN. In addition, the Animate team has repeatedly stated that Adobe remains committed to supporting AIR within Animate as part of this partnership, though you can also make use of the AIR SDK as a completely standalone SDK as well!

AIR for Desktop

An often-overlooked target for Adobe AIR is major operating systems through AIR for Desktop. Developers were able to target both Windows and macOS long before AIR became available for mobile systems. Originally, the only way to package and distribute applications built with AIR was through the use of an .air file. The .air format was special because it was completely cross-platform, but because of this, you needed to have the AIR runtime installed separately in order to install and run any AIR program. This was, of course, different from native applications.

As time went on, and the separate AIR runtime became more of a hindrance to users, additional packaging and installation options became available:

Figure 2.11– AIR for Desktop produces an AIR package or application installer

Today, when developing AIR applications, you can still produce .air files that run on both Windows and macOS, but you can also produce operating-system-specific installers that actually have a number of advantages over the .air approach. The first of which is that the user does not need to have an AIR runtime installed separately. The second is that a native installer allows even deeper integrations within the host operating system.

AIR for iOS

If you want to target Apple iOS or iPadOS, you can choose the AIR for iOS document type when creating a new project. This will always produce a native iOS package in the form of an .ipa file:

Figure 2.12 – AIR for iOS produces an IPA file

There are also many settings specific to Apple's platforms that can be configured within your AIR for iOS Settings dialog, but you cannot produce anything other than an .ipa package.

Note

AIR for iOS never had the ability to produce .air files as supported by desktop and Android because of Apple's policies against such things within their mobile systems. Adobe got around this by translating all of the assets and code produced in Animate to native iOS code, which is why the package type is so inflexible.

AIR for Android

Choosing the AIR for Android document type will allow a developer to target mobile devices and tablets running Google Android. The workflow is very similar to working with AIR for iOS, with platform-specific settings available in the AIR for iOS Settings dialog.

When targeting Android, you will produce an .apk file – the native format for Android applications:

Figure 2.13 – AIR for Android produces an APK file

While we have no choice in the output file produced when targeting Android today, the AIR runtime was once also available for this platform in a way similar to how it functions on desktop operating systems. The AIR runtime for Android has since been deprecated and AIR applications must be packaged as .apk, similar to the situation with iOS.

Note

There is now a 64-bit requirement when publishing to Android. Because apps published through Google Play will need to support 64-bit architectures, you must use an AIR SDK capable of this. Be sure to use an SDK from HARMAN since the AIR SDKs from Adobe only produce 32-bit apps.

Because AIR can publish for iOS and Android, platforms related to these two core targets are available as well:

Figure 2.14 – Android TV profile selection in the publish settings

AIR for iOS and AIR for Android can also publish for Apple TV and Android TV, respectively.

In this section, we took a deep look at what Adobe AIR is and how it can be used to build installable applications and games for popular platforms such as macOS, Windows, iOS, and Android. Coming up, we'll take a look at the final set of document types available through a fresh install of Animate, the WebGL glTF and Virtual Reality beta platforms.

Experimenting with Animate Beta Platforms

In recent versions of Animate, Adobe has included a number of new documents that are intended for different use cases. This includes a set of four document types currently marked specifically as beta. They include WebGL glTF (Standard), WebGL glTF (Extended), VR Panorama, and VR 360. These can only be accessed through the Advanced category of the New Document dialog.

Since these document types are still in beta development, we won't spend as much time on them as we have the previously covered document types in Animate, but they are certainly exciting and worth our attention, so we'll give each a quick overview before moving on.

WebGL glTF – Standard and Extended

The two WebGL glTF document types in Animate allow the creation of web-based content as part of a GPU-accelerated experience. WebGL is a cross-platform web standard focused on low-level 3D graphics and the term glTF (GL Transmission Format) is an API-neutral runtime asset delivery format Animate leverages alongside WebGL:

Figure 2.15 – The WebGL glTF Standard document type

The Standard document type does not allow any interactivity, as the WebGL glTF specification does not allow it. This is an example of why you may want to use the Extended document type, though it does break with the established standard to achieve this.

Note

The Extended document type is only meant to run using Adobe's WebGL glTF runtime, while the Standard document type can be played within any standard WebGL gtTF playback – BabylonJS and three.js are examples of this.

VR Panorama and VR 360

These document types include a number of features specific to virtual reality, including the ability to use a 360-degree or panoramic photograph as a texture and a special VR View panel that allows more precise placement of interactive and animated assets within the environment.

Figure 2.16 – The VR Panorama document type

You can design your environment by marking certain layers in your timeline as textures, which, upon publication, get wrapped to the inside of either a cylinder or sphere – creating the illusion of being within the virtual space. Both of these target formats are for pretty specific use cases including museum walk-throughs, real estate, or more creative efforts such as experiments, environmental design, or even the creation of simple games.

Like other web-based documents, the VR betas publish to native web technologies and so you would use JavaScript as the coding language.

Tip

No matter what document type you choose, you can always convert from one target platform to another by choosing File | Convert To from the application menu. This will convert all assets and animation but any code will need to be rewritten as it is specific to each platform.

In this section, we looked a bit into what makes up the various beta platforms under development at Adobe. We'll read more about these platforms in later chapters, of course!

Summary

With this chapter behind us, you should now have a good overall picture of just how vast and varied the supported native document types within Animate are, and this doesn't even begin to touch upon the array of export formats available! We had a look at some history behind the different major platforms Animate supports and then explored many of the considerations and practices around each specific document type involved in these overall target platforms. We will continue to build upon the foundational knowledge established here in later chapters.

In the next chapter, we'll jump directly into Animate to examine the interface and overall layout of the software with a comprehensive look at how to customize the toolbar, timeline, workspaces, and overall preferences of the application.