[TOC]

SwiftUI is a struct-based, protocol-oriented, Domain-Specific-Language developed to describe user interfaces on Apple devices ranging from iPhones to iPads to Apple Watches to the Apple TV and even the Mac.

In that sense, it’s platform agnostic. We give SwiftUI an idea of what we want, and by and large we let it do what’s appropriate when that code’s run on a specific platform. A Toggle view says we want a switch, but how that switch looks and even how it functions differs from iOS to macOS to the Apple TV.

Every custom view we create has a body variable that, when called, returns another view. The returned view might be a primitive view type native to SwiftUI like Text or Image.

[TOC]

This gist is mainly targeting Node.js stack.

• V8-engine (Google)
• JavaScriptCore (Apple)

[TOC]

• MDN
• w3schools

• HTML - Cheat Sheet
• HTML - Cheat Sheet (MDN)

[TOC]

1. Not Running: The app is not yet launched or has been terminated by the user or the system.

2. Inactive: The app is launched, but not yet running in the foreground. This is a transitional state, where the app may become active or go back to the "Not Running" state.

3. Active: The app is running in the foreground and receiving events, such as user input.

[TOC]

SwiftUI provides a modern and declarative approach to building user interfaces on Apple platforms, which solves several problems compared to UIKit:

1. Boilerplate code: UIKit requires a significant amount of boilerplate code to create even simple user interfaces. With SwiftUI, much of this boilerplate code is eliminated, as the framework provides a simple and intuitive way to define user interfaces using a declarative syntax.

2. Complexity: UIKit can be complex and difficult to learn, particularly for developers who are new to iOS development. SwiftUI simplifies many aspects of user interface development, making it more accessible to a wider range of developers.

[TOC]

1. A cooperative thread pool – The new model transparently manages a pool of threads to ensure it doesn’t exceed the number of CPU cores available. This way, the runtime doesn’t need to create and destroy threads or constantly perform expensive thread switching. Instead, your code can suspend and, later on, resume very quickly on any of the available threads in the pool.

2. async/await syntax – Swift’s new async/await syntax lets the compiler and the runtime know that a piece of code might suspend and resume execution one or more times in the future. The runtime handles this for you seamlessly, so you don’t have to worry about threads and cores.

• As a wonderful bonus, the new language syntax often removes the need to weakly or strongly capture self or other variables because you don’t need to use escaping closures as callbacks.

[TOC]

Functional reactive programming, also known as data-flow programming, builds on the concepts of functional programming.

• Where functional programming applies to lists of elements, functional reactive programming is applied to streams of elements.
• The kinds of functions in functional programming, such as map, filter, and reduce all have analogues that can be applied to streams.
• In addition, functional reactive programming includes functions to split streams, create pipelines of operations to transform the data within a stream, and merge streams.