SwiftUI views are values and not objects!
4.4 (8)

Click to rate this post!
[Total: 8 Average: 4.4]

In SwiftUI, views are value types rather than traditional objects 🧐, this design approach is a fundamental aspect of SwiftUI’s declarative programming model and is aligned with the Swift language’s emphasis on value semantics.

As value types, views in SwiftUI are immutable and are copied when needed, resulting in predictable behavior and easy management of state and data flow, this means that when you modify a view, you are actually creating a new instance with the desired changes, rather than mutating the existing view, this immutability allows SwiftUI to efficiently track changes and perform targeted updates to the user interface.

Value types promote a more functional and declarative style of programming, where you describe the desired state and SwiftUI takes care of updating the view hierarchy accordingly, they are also thread-safe by default, as copies are made when passing views between different execution contexts.

Another advantage of using value types for views is that they enable SwiftUI’s built-in animations and transitions, by comparing the old and new values of a view, SwiftUI can automatically animate the changes, resulting in smooth and visually appealing user interface updates.

The declarative programming paradigm is at the core of its design philosophy, declarative programming focuses on describing the desired state of the user interface rather than specifying step-by-step instructions on how to achieve that state, SwiftUI’s view tree engine leverages this approach to efficiently manage and update the user interface based on changes in the underlying state.

You define your user interface using a hierarchy of composable and reusable views. Each view represents a specific part of the interface and is responsible for rendering itself based on the current state, by composing these views together, you create a tree-like structure known as the view hierarchy, the view hierarchy in SwiftUI is immutable, meaning that you define it once and SwiftUI takes care of updating it based on changes to the underlying state, when the state changes, (or even when the view re-appears when scrolling back and forth), SwiftUI re-evaluates the view hierarchy and determines the minimal set of updates needed to reflect the new state, this process is known as the reconciliation algorithm (AKA diffing algorithm).

The reconciliation algorithm is where SwiftUI’s view tree engine shines. It efficiently compares the old and new view hierarchies, identifies the differences, and applies the necessary updates to the user interface, by only updating the specific parts of the view hierarchy that have changed, SwiftUI minimizes the amount of work needed to keep the UI in sync with the state, resulting in optimal performance.

In contrast to UIKit, in SwiftUI view construction and updates are unified into a single code path, views are values rather than objects, described by values conforming to the View protocol, the view tree is transient and can be recreated at any time based on the underlying state, this declarative approach eliminates the need for separate event handlers and manual UI updates like in UIKit, SwiftUI’s view tree engine efficiently reconciles state changes, performs targeted updates, and ensures a reactive UI that stays in sync with the data, by relying on value semantics, SwiftUI can perform granular updates and avoid unnecessary computations, leading to a highly performant and responsive user interface.

By relying on a declarative approach, SwiftUI allows developers to focus on describing the desired end state of the UI rather than worrying about the low-level details of UI manipulation, this shift in mindset 😎 leads to more maintainable and expressive code, as developers can easily reason about the UI based on its desired state.

Another significant aspect of SwiftUI’s view tree engine is its ability to efficiently handle updates. As views in SwiftUI are value types, changes in the state result in the creation of new view instances rather than mutating existing ones. SwiftUI employs a mechanism called “value comparison” to determine the differences between the old and new views, enabling it to perform targeted updates to the UI.

Additionally, SwiftUI’s view tree engine embraces a reactive programming model. Views in SwiftUI are not just passive representations of UI elements but are also capable of reacting to changes in the state, this reactive nature enables automatic propagation of state changes throughout the view hierarchy, ensuring that the UI remains synchronized with the underlying data.

In conclusion, SwiftUI’s view tree engine revolutionizes UI development by embracing the declarative programming paradigm. It provides an efficient and responsive user interface by leveraging value types, value comparisons, and reactive programming.

The ability to describe UI in a declarative manner, combined with targeted updates and optimization techniques, empowers developers to create intuitive and performant user interfaces with ease.

This is why I don’t use GIT GUI tools.
4.8 (4)

Click to rate this post!
[Total: 4 Average: 4.8]

Any seasoned iOS engineer who uses Xcode can see that it lacks a lot of git features, which is OK as it’s not mainly a source control application.

We can see only primitive features there, which may suffice for personal or small projects, but if you are working on a larger team, you will find it very difficult and sometimes impossible to use source control using the IDE only.

Xcode’s Source Control

Some Engineers may also notice that markers near files like “A”, “M” and “C” etc.. are stuck most of the time too, so you wont be able to directly tell about file statuses if they are added, modified, conflicting, etc..

Convincing backend engineers to use the terminal will be easier, because GUI will not automatically update repo’s trunk on a server daily at 1:30 AM, but a cronjob that deals with the CLI can easily do this, on the other hand, convincing a mobile developer about this can be a bit more more difficult, because the need for this is not easily demonstrated.

I will start directly with discussing few real life examples.. I’m sure I can think of dozens of cases, but let’s keep this post small.. I will list the commands I use, so you can have an idea about the more power we can have in terminal.

1- PR Reverts: a feature introduced by Github, PR reverts, say you have an already merged pull request, and you want to revert it before a tight-deadline like a branch cut, using Github’s revert feature will not ask about details of commits to be removed, it most probably will remove commits that were merged in the PR, so you may easily end up removing extra stuff that is irrelevant by accident.

But using such command, you will have fine-grained control about what commit to remove or keep.

git revert --no-commit someHash

2- Submodules: if you have nested git repos (submodules), such feature maybe not be existent in most GUI tools.

I normally have terminal open all day, and I can’t live without it 🧐, I hate to push buttons without knowing exactly what each button does, tools can come and go, the CLI will be always what GUI tools are built on.

It’s convenient to set up install scripts, build scripts, deploy scripts, etc.. when working on a large team, one will have no idea what exactly happens in the GUI based app, and in the old times I’ve seen colleagues do bad things impossible to restore without the CLI 🀦🏻.

I feel several times faster using the command line than clicking through with a mouse.

GIT GUI tools were meant to mitigate complexity, but to me, they seem to add more complexity if the project is large, I once seen non-git standard terminology, which normally makes things harder in general.

PS: the only real use of source control in Xcode is the diffing tools, it visualizes diffs perfectly. πŸ€“

git add
git annotate
git bisect
git blame
git checkout
git checkout -b
git cherry-pick
git clean -fdx
git clone
git clone –single-branch
git commit
git commit –amend -m “New commit message.”
git config
git diff
git diff –check
git fetch
git gc
git init
git log
git log –all
git log –oneline
git log –summary
git log -p
git merge
git pull –rebase
git push
git push –set-upstream origin
git push -u origin feature_branch_name
git rebase
git remote -av
git remote add
git reset –hard
git restore
git revert
git rm
git shortlog
git show
git stash
git stash list
git stash pop
git status
git tag
git worktree
common git commands that I use (sorted alphabetically)

Why I prefer to store my files on a digital ocean space & not google drive or dropbox.
5 (4)

Click to rate this post!
[Total: 4 Average: 5]
Image from Unsplash

This is not directly related to swift or iOS, but thought it’s worth sharing, since I couldn’t find any article that mention such way to backup files.

I’m one of the people who once used floppies to backup html pages, (3DMax Tutorials back then) from internet caf’es back in 2003, then came CDs, then came DVDs, I also remember the first flash drive my father got me as a teenager, it was 128 MB, this was not affordable for most of the people, now more than 1000x sized SSDs are way cheaper.

The common solutions are google drive & dropbox, they offer (2TB plan) that are $10 monthly, but I prefer to use my own mountable drive with a CDN, to distribute my files with ease, the best way I found to store my work, was storing it on a digital ocean space (similar to AWS S3), and use a client (like cuber-duck) on my mac to directly mount it, or on any device I have.

Pros & Cons

Direct links!
Economic, it starts with 5$
Saved bandwidth, Content Delivery Network is easily setup, where you can save big amounts of transfer without crossing the caps.
Total control on meta data and content type of files, etc… for example, you can specify if an uploaded mp4 is streamable or downloadable.
Easily mounted into any device or server.
Your files are served, and not just stored, for instance, you can host an angular website on it, without having load on your server.
You can mask the url, to reflect your domain, which is more professional for clients, when doing demos.
– Can require some technical knowledge at first for some people.
– Most of the desktop clients to mount such drives are not opensource nor free.
– Files cannot be shared with specific people, they are either public or not.

Use cases are infinite:

– for example, if you do scraping, I was able to download few huge youtube channels as a background job on the server, without consuming my internet plan, without keeping some device downloading, and without having to store files locally, they are stored directly there 🧐.

– it works like a NAS (Network attached server), or as a media center.