iOS accessibility, from a developer’s point of view, refers to the set of tools, technologies, and guidelines provided by Apple to ensure that iOS applications are usable and inclusive for people with disabilities, as a developer, incorporating accessibility features into your iOS app involves considering the diverse needs of users with visual, auditory, motor, cognitive, and any other impairments. (see table below for a list of most common impairments and disabilities)

Many developers and businesses do not prioritize making their applications accessible for several reasons, first, there is often a lack of awareness about the significance of accessibility and the benefits it brings to a broader user base, second, some developers perceive accessibility implementation as a complex and time-consuming task, leading them to prioritize other features instead, there are also other concerns about additional costs, limited resources, the assumption that their target audience does not include people with disabilities can deter developers from investing in accessibility.

Legal enforcement of accessibility regulations may be weak or inconsistent in some regions, reducing the incentive to comply, moreover, the emphasis on aesthetics over accessibility, inadequate training on accessibility best practices, and resistance to change can further hinder the adoption of accessible design, despite these challenges, raising awareness and promoting the positive impact of accessibility remain crucial in encouraging developers to make their applications inclusive and accessible to all users.

Several countries have enacted laws and regulations to enforce digital accessibility. In the United States, the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act of 1973 outline accessibility requirements for websites, applications, and other digital content provided by federal agencies and entities receiving federal funding.

The Web Content Accessibility Guidelines (WCAG), created by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), are widely recognized as the global standard for web accessibility, these guidelines provide specific criteria for making digital content accessible to individuals with disabilities.

Failure to comply with accessibility regulations and standards can lead to legal consequences. Companies and organizations that do not provide accessible digital content may face complaints, lawsuits, or enforcement actions by individuals, advocacy groups, or government agencies.

Penalties can include fines, legal fees, court orders to rectify accessibility issues, and reputational damage.

Several high-profile cases have set important precedents for digital accessibility enforcement, resulting in settlements or court rulings against companies that were found to have inaccessible websites or applications, these cases highlight the significance of accessibility and the legal ramifications of non-compliance.

Numerous prominent cases have established crucial precedents for enforcing digital accessibility, leading to settlements or court rulings against companies with inaccessible websites or applications. Notably, Domino’s Pizza, Netflix, and Target faced legal issues related to the lack of accessible applications for individuals with disabilities. The Ninth Circuit Court of Appeals ruled in favor of a blind plaintiff, stating that the ADA applies to websites and mobile apps. Netflix settled with the National Association of the Deaf, agreeing to make its streaming content accessible with closed captions. Similarly, Target settled with the National Federation of the Blind, committing to enhance its website’s accessibility.

These cases emphasize the significance of digital accessibility and the legal consequences for non-compliance, prompting businesses to increasingly prioritize accessibility for a more inclusive online environment.

Main types of disabilities and impairments:

Share on Facebook

Tweet

Follow us

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.

Share on Facebook

Tweet

Follow us

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.

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. 🤓

Share on Facebook

Tweet

Follow us