Every year, Apple promotes its Worldwide Developers Conference, which this year gathered 6000 atendees from more than 70 countries. Since I am attending, I am using this blog to publish my completely disorganized, not revised, and not-for-public-consumption notes. This is the final post, a bit shorter than the previous ones.

Bulding Custom Views with SwiftUI

.edgesIgnoringSafeArea is a property that allows a view to be placed out of the safe area of the screen, for example, too close to the top or bottom of the screen.

In SwiftUI, there’s no way to force a size upon a view. The parent view proposes a size to the child view, however, the child view is responsible for choosing its own size, maybe by fixing, maybe by stating its aspect ratio.

When using stacks to lay out elements on the app screen, SwiftUI already follows Apple’s design guidelines in terms of spacing between elements on the screen. It is possible, however, to explicitly specify how much space there will be between elements. In addition, it is possible to specify alignment for all the views within a stack. It is also possible to be very specific about how an item will be aligned wrt to the baseline of the stack. Alignment can be vertical or horizontal. Finally, it is possible to define new kinds of alignments (by creating an extension to VerticalAlignment and a biit more stuff).

When laying out visual elements on the screen, it is possible that the text, for example, does not fit the screen space and parts of it will be truncated. SwiftUI makes it possible for the developer to specify the layoutPriority of an item on the screen, so that it is not truncated or is truncated last, after the items with lower layout priority are truncated.

SwiftUI supports drawing shapes, like circles, ovals, etc. It also supports the construction of gradients, shapes that include only a thick border. The drawing primitives seem to be powerful and composable. The presents have shown a really interesting drawing comprising multiple wedges that do not inclue the part closer to the center of the circle, of different sizes, and painted using different color gradients. It does this by drawing the wedge using a Paths.

When drawing multiple animated elements on the screen, it is possible combine them to become a single view. This can make animation smoother.

Optimizing Storage in Your App

Efficient image assets. HEIC is a more efficient alternative to JPG. Up to 50% smaller files when compared to JPG. This means that they take more space, load faster, and trasnfer faster. App size is reduced. It uses lossless compression.

Asset catalogs. Easy way to store multiple resolutions of resources. A resource may even be marked as on-demand, meaning that it will only be downloaded when necessary. It reduces storage space by avoiding the need to store multiple image files. Mooreover, it can also improve performance. It makes it easier to use GPU-based, in other words, hardware-assisted compression and decompression.

File system metadata. On launch, our app reads and updates the plist file. One of the writes is to the file to be update but the other two pertain to filesystem metadata updates. Filesystem metadata is information the filesystem must keep track of about our files, stuff such as name, creating and last update dates, size, etc. Operations such as writing, renaming, or deleting a file has a metadata overhead due to bookeeping. This overhead ranges from 8 to 16K. To reduce this, (i) create a file; (ii) keep it open and unsynched. The bottom line is: making multiple small write operations is expensive.

APFS is copy-on-write by nature.

Serialized data files. Plists, XML, JSON, YAML, and the like. They are inefficient because, basically, each write requires writing the entire file to disk again. If the data one needs to manage is too large or modified too frequently, it is more efficient to use Core Data. It is built upon SQLite and provides the kind of features one would expect from a DBMS, such as connection pooling, schemas. According to the presenter, Core Data also requires writing less code.

If using SQLite databases, use WAL (Write-Ahead Log) mode, instead of delete mode journaling. WAL groups sets of logical writes using the OS cache so that the number of physical writes is significantly reduced.

It is better to use multiple statements within the same transaction than multiple, single-statement transactions, specially if they may end up modifying the same database pages. This reduced the number of syscalls, which reduces time footprint, and the required storage due to reduced bookeeping requirements.

File Activity Instrument. Now supports all Apple devices. Works for both one app and all processes running on the system. It also supports “automated reasoning”. Helps detect symptoms such as excessive physical writes,. failed I/O related calls, suboptimal caching

SwiftUI on All Devices

Although SwiftUI is a technology that can be employed to build UIs for all the Apple devices, that does not mean that one can build a UI for one device and it will work on all of them. A watch is very, very different from a 4k TV. Phones can make calls and location matters a lot to them. For TVs, that is not the case. On the other hand, they have very big screens and require streamlined and agile navigation. Watch versions should focus on notifications and on presenting the information that is the most critical. A Macbook app can provide high (textual) information density, unlike a TV app; smaller click targets and denser controls.