Produced by experts from a big company: You will definitely not be able to tell the difference between these two Apple controls!

Hello, I didn’t expect the new year to be over so soon. Today I’m going to talk about two confusing things in Apple specifications, action sheet and activity view.

Both components are common components, and the action sheet appeared earlier. The layout of the activity view that appeared later violated some of the design concepts and rules of the action sheet, and Apple's specifications were vague about this, so some students had many questions about how to design a bottom floating layer (or panel). Therefore, today we will talk about their differences based on their development history, and how to view "specifications". It can be said that the evolution of specifications is a process of constantly eating books.

The evolution of action sheets

Action sheets are one of the earliest standard components provided in the design specifications. Compared with other components, Apple has not made many updates to the definition and iteration of action sheets, and its style has not changed much.

In the specifications of iPhone OS 2 in 2008, action sheets, alerts, and modal views were all classified as different types of views. In fact, the term "view" has always been very vague. I guess this term comes from the MVC design pattern, which is a term left over from the era of development and design. Now Apple interprets view as "the basic component of the application user interface." I personally understand view as "page template" according to the atomic system.

From the beginning, action sheets have two purposes:

• Collect multiple operations for the user's current task. This way, you don't have to display all of these operations on the page.
• Before taking any risky action, you can use an action sheet to reconfirm.

Based on these two purposes, the instructions and rules for action sheets in 2008 are as follows:

• There must be a cancel button at the bottom, and at least 2 action buttons in addition to the cancel button
• After clicking the action button, the action sheet will disappear
• There is no explanatory text on the action sheet because it is a page that pops up when the user actively clicks it. The user can infer the function of this floating layer based on the current task and button text.

Based on the above points, we can see that the mobile business model was relatively simple around 2008. The second rule makes the action sheet a temporary and unstable container that can only carry operation buttons. It eliminates the possibility of using the action sheet to perform multi-level complex tasks, and does not mention any solutions related to scalability.

In 2011, Apple further explained the action sheet:

• Explains the purpose of placing the cancel button at the bottom of the page: it encourages users to read all the options before making a choice.
• Use red buttons to emphasize risky/destructive actions.
• Vertical sliding is not allowed because: a panel that is too long may cause users to spend too long thinking about each option; vertical sliding may lead to accidental touches.

Since then, several important specifications of action sheets have been formed. Although the instructions of "the action sheet will disappear after clicking the action button" and "no instructions are written on the action sheet" were cancelled in 2014, making it slightly more extensible, Apple's restrictions on vertical sliding and emphasis on the "Cancel" button show that the action sheet is still temporary and tends not to let users stay too long to complete more complex tasks.

After iOS14, Apple provided a new component menu to store operations, which further restricted the use scenarios of action sheets. The iOS14 version specification classified action sheets into alert warning pop-ups, "only destructive operations can use action sheets, otherwise menus should be used." However, the statement was changed in subsequent version iterations. Now the action sheet is basically used to carry functions directly related to "user-initiated operations", such as reconfirmation before deleting/leaving, and no longer carries the function of "accommodating secondary operations that cannot be placed on the main page."

The evolution of Activity view

Activity view is customized for the "sharing" function. So far, its usage scenarios are basically limited to sharing, and it is rare to see such a layout used in other scenarios, but I personally think it has the potential to expand scenarios in the future.

Apple has always had a "share" feature. This feature was first implemented using an action sheet, and then the icon style was changed from the action sheet in the iOS6 era (but unfortunately, it was not explained why it was changed). In the iOS6 era, Apple did not have a mature inter-app sharing feature. At that time, it only supported a few limited apps such as Facebook, Twitter, and Weibo, so the page design did not consider scalability. After iOS7, Apple made two important feature iterations:

• Allowing a large number of third-party apps in the App Store to access the "Share" function. This results in an uncertain number of operations on the share page.
• The airdrop function has been launched, and probably due to the early promotion of this function, iOS7 allows pictures to be shared multiple times to different people on the current page, so the action sheet that only supports a single operation can no longer meet the demand.

Based on these two important functional changes, the horizontal sliding version of the Activity view that we are familiar with was created.

We don’t know what kind of problems the activity view design is trying to solve, because its specifications are not very detailed. We can only say that from the final effect, there are some changes compared with previous designs:

When the Activity view first appeared in the iOS7 specification, it was a "controller" controller rather than a complete page, which made it possible to add a "Cancel" button to become a modal similar to an action sheet, or as an element on the page with a "Cancel" button in the upper left corner of the page.

I personally think this design is redundant. After the page allows horizontal scrolling, the reason why the "Cancel" button must be placed at the bottom of the page is completely invalid, because the user's line of sight does not necessarily read from top to bottom, but may be from left to right without looking down at all. There is no need to make two sets of layouts with exactly the same functions just to comply with the action sheet specifications.

• The activity view uses a large icon instead of a vertical text list. Judging from the iteration trend, it is reasonable to guess that this is because the recognition efficiency of image icons is higher than that of pure text after connecting to the third-party platform.
• Activity view allows horizontal swiping. This also violates the reason why the action sheet "panel does not allow vertical swiping". Obviously, this is done because the number of apps connected to third-party platforms is uncertain, and only horizontal swiping can ensure that some system operations (copy/screen projection, etc.) can be exposed on the first screen.

Of course, there are some other problems with iOS7's activity view.

Based on these problems, the activity view was revised again, which is the current iOS13 style.

Since then, activity view has completely broken away from the influence of the early action sheet specification. It allows vertical sliding, no longer adds a cancel button at the bottom, and supports users to perform multi-level and relatively complex operations on this page (such as clicking on airdrop to pop up a secondary pop-up window, but not closing this activity view).

In summary, according to current Apple specifications:

• The action sheet is more focused and faster. It does not support multi-level operations and is more often used for reconfirmation scenarios.
• Activity view is temporarily used for sharing scenes. It is more extensible and supports multi-level operations.

"Written at the end"

We have talked about so much about the evolution history above. In fact, we can also see that the iteration of operating systems like Apple is very cautious and slow. It took Apple nearly 10 years to go from action sheet to activity view. And our daily design iteration speed and response time are definitely faster than Apple. Therefore, when designing, don't just copy the operating system specifications, but think about what is more suitable for the scene.