DEV Community: Sendbird

SwiftUI vs. UIKit: What is the best choice for building an iOS user interface in 2024?

Sendbird Devs — Sat, 10 Feb 2024 00:44:48 +0000

SwiftUI vs. UIkit: What you need to know

As an iOS engineer, you've likely encountered SwiftUI and UIkit, two popular tools for building iOS user interfaces. SwiftUI is the new cool kid on the block, providing a clean way to build iOS screens, while UIkit is the older and more traditional way to build screens for iOS. SwiftUI uses a declarative style where you describe how the UI should look, similar to Jetpack Compose in Android. UIkit, on the other hand, uses a drag-and-drop development style, which is relatively similar to Android XML.

So, if either tool can get the job done, do you have to be concerned about choosing SwiftUI vs. UIkit?

The short answer is yes. Your biggest concern is the iOS versions you'd like to support: SwiftUI only supports iOS 13 and later. If you intend to support lower versions, you're limited to UIkit. But that's not the only factor you should consider before committing to SwiftUI vs. UIkit.

Let's look into a comparison of SwiftUI vs. UIkit so you can choose the optimal framework for your application. Here's an overview of the differences:

An overview of SwiftUI vs. UIkit

UIkit: The traditional approach for building iOS user interface elements

Let's start with UIkit. It's the oldest UI framework, but it's matured a lot along the way.

UIkit was launched in 2008 to provide pre-built components for developers to handle inputs, touch events, and other user interactions on iOS apps. It was built with Objective-C, an improvement of the C programming language, that adds support for object-oriented programming.

UIkit was initially designed to build a UI for the iPhone's small touch-based screens, but it has evolved to support various devices over the years, including tvOS apps. UIkit has added numerous features over time, like auto layout, dynamic types, collection views, and drag-and-drop functionality, to make it a more powerful and user-friendly framework.

Key components and design patterns

To build high-quality and responsive user interfaces for their iOS apps, developers can utilize UIkit's wide range of UI components while following certain design patterns, as you will see below:

View controllers

As the name suggests, view controllers are objects used to manage UI views by responding to user input. They handle events such as button taps, gestures, and passing data to the views. They also act as an intermediary between the app's data model and the views, as well as coordinating with other objects in the app.

Here's an example of an Objective-C skeleton view controller:

Interface Builder and storyboards

Interface Builder is a visual editor embedded into Xcode (an IDE for Apple platforms) used to create and design user interfaces for iOS apps. Storyboards are visual representations of the app's user interface, representing the screens, their order, and the transitions between them. In simpler words, Interface Builder refers to the part of Xcode that lets you view and edit storyboards, which are a collection of views and screens.

Storyboards and Interface Builder

Delegates and data sources

Delegates and data sources is a common design pattern in UIkit for iOS app development. It entails having a data source---an object responsible for providing the data displayed in a view---and a delegate---an object responsible for handling events or actions occurring in a view.

3 advantages of UIkit

The traditional approach, UIkit, has been the go-to framework for iOS developers for a long while. Its continued popularity is due to quite a few factors.

A mature and stable framework

UIkit has been around since iPhoneOS 2.0, so it has had a huge head start. It has also managed to evolve well over the years, with integrations with other iOS core frameworks for graphics and animations. These steady, gradual improvements have led to a stable and reliable framework.

A wide range of UI components

UIkit has gained a robust set of pre-built UI components---think of buttons, search bars, and tables---that solve most challenges developers face when building iOS UIs. This limits the need to create custom UI design elements. Most of them are simply already present.

Extensive documentation and community support

UIkit's widespread adoption and its long existence have seen it gain a large and active community of developers. The documentation and resources available to you are considerable, beginning with Apple's official documentation and going beyond to YouTube tutorials and other blogs.

2 disadvantages of UIkit

Still, nothing is perfect. While UIkit has been a reliable workhorse in iOS development for a long time, there are still some drawbacks to consider.

Verbose code

As your app becomes more complex, the UIkit code that controls and manages the views can be harder to maintain. The more screens in your app, the harder it is to manage the app state and control flow without overusing the view controllers.

However, proper code modularization and organization can help you avoid this pitfall and develop less buggy code.

Lack of built-in support for modern design patterns

Modern design patterns like reactive programming and dependency injection aren't natively supported in UIkit. Developers must come up with custom solutions or depend on third-party libraries for design elements like these that are common and even expected for modern apps.

SwiftUI: The modern approach for iOS user interface elements

SwiftUI is a more recent framework built by Apple, released in 2019 with version 13 of the iOS SDK. It's particularly attractive for developers who want to create beautiful and responsive UIs in a declarative way. It's built on top of the Swift programming language and is intended for building UIs for applications across Apple's ecosystem, including iOS, macOS, tvOS, and watchOS.

Because SwiftUI adopts more modern programming paradigms, such as declarative syntax, you can use simple and intuitive code syntax to define the UI without having to worry about the underlying implementation details. The framework automatically takes care of how a view should be rendered and how actions related to it can be triggered.

SwiftUI is also more reactive---developers can implement UIs that automatically update when the underlying data changes without additional boilerplate code. You can add modifiers, or properties, to views to change appearance and behavior when certain conditions occur.

With its wide range of built-in views and layouts, SwiftUI simplifies the creation of adaptive and responsive interfaces for all devices on Apple platforms.

Key components and design patterns

SwiftUI boasts a modern framework designed to make the life of an iOS developer smooth. Let's go over some key components that harness powerful features like closures, optionals, and type safety.

Declarative syntax

With declarative syntax, you can describe the desired outcome of a UI rather than the specific steps for achieving it. The framework handles all the necessary actions and implementation details that your view requires, leaving you to only worry about its appearance.

Have a look at the following code that displays an image and text in a column:

State and data binding

State is a property wrapper used to store values that can change over time and whose changes need to be reflected in the UI. Data binding is a method for connecting two pieces of data so that changes to one are automatically reflected in the other.

Together, these powerful concepts greatly improve SwiftUI's state and data management, automatically handling storage, observation, and synchronization. This enables SwiftUI to perform automatic UI updates and keep itself reactive.

Using the Binding property on SwiftUI and the $ prefix on the state variable to bind, you can easily achieve this as shown below:

Previews and live editing

You can see changes in your app's UI in real-time as you write and modify code, thanks to SwiftUI's previews and live editing features. You don't have to run your app on an emulator or a device to see a live rendering of your UI code. This makes the development process faster and more efficient.

Previews and live editing in XCode

3 advantages of SwiftUI

SwiftUI boasts a lot of features that an iOS developer wouldn't want to be without. Let's take a look at a few of the heavy hitters.

Simplified code and easier maintenance

SwiftUI's declarative syntax and reactive model simplify the code needed to build responsive UIs. Since you only need to define the UI and not the implementation details, the amount of code you have to write is minimal and has an intuitive syntax.

Don't forget, as already mentioned, SwiftUI handles updates on data changes automatically. That's even less code that you have to write and maintain.

Improved design-to-code workflow

With preview and live editing features, there's no disconnect between the code you write and the appearance of your UI. You can validate your output in real time. SwiftUI's pre-built components make it easier and faster to implement design into code, providing a more integrated and seamless design-to-code workflow.

Automatic support for dark mode and accessibility

Using SwiftUI's colorScheme property, you can easily switch between light and dark colors on your app's UI. SwiftUI automatically handles the underlying heavy lifting to bring out your desired result. Remember SwiftUI's modifiers that we mentioned earlier? Don't forget that you can use those to alter the appearance of views or add more properties to ease the accessibility of the UI.

2 disadvantages of SwiftUI

Even though SwiftUI is a modern framework with features that lend themselves to simple, up-to-date design, it still has a few drawbacks you should consider.

Limited compatibility with older iOS versions

SwiftUI was introduced in iOS 13. It can't be used on devices running iOS 12 or earlier. That's not an insignificant concern for developers targeting older iOS versions.

Fortunately, SwiftUI can still be used alongside UIkit. Using both frameworks, developers can continue supporting older versions.

Less mature framework with fewer UI components

Developers who need advanced UI components should check carefully that SwiftUI has everything they need. Even though the framework is being actively improved with new components, it's still far behind UIkit.

However, it's easy to build custom components with SwiftUI. It might be easy to sidestep a missing out-of-the-box UI component on your own.

SwiftUI vs. UIkit: What's the verdict?

It's time for a more detailed head-to-head comparison! Let's compare SwiftUI vs. UIkit according to factors such as device compatibility, documentation, required UI components, target iOS version, and a few others.

The SwiftUI vs. UIkit frameworks

Target iOS version and device compatibility

As you know, UIkit has been the household name for building UI on iOS apps. Supporting version 9 and later, it basically covers all versions that any iOS app would need.

SwiftUI can only support version 13 or later, which is only a handful in comparison. Still, as long as the platform is running iOS 13 or later, SwiftUI works with everything Apple, which means watchOS, tvOS, iOS, and macOS. Since you can reuse code across all platforms, development is fast and smooth.

Given recent data that shows only 8 percent of devices connected to the Apple Store use iOS 14 or lower, SwiftUI is a strong candidate in iOS development.

Project complexity and team experience

Building simple iOS apps with only a few screens is relatively easy to accomplish with SwiftUI. However, building a complex project might require a more mature framework to reduce the risk of encountering unresolved bugs in the framework.

Most experienced iOS developers are already well-versed in the UIkit framework since it's been around for a long time. It also has more educational resources than SwiftUI. However, new learners find it easy to pick up SwiftUI due to its easy-to-understand syntax and less complex code.

Where you're at in your developer journey plays a significant role in your choice.

Required UI components and design patterns

Depending on the complexity of your project, you might benefit from a framework that has certain UI components out of the box.

UIkit has numerous UI components and works well with delegates and data sources that require extra code to manually handle updates.

SwiftUI is still growing its components library, but it's a lot easier to build custom UI components and animations on SwiftUI than on UIkit. SwiftUI relies heavily on state and data binding, promoting a declarative and reactive approach to UI development.

Migrating from UIkit to SwiftUI involves a slight learning curve due to the different coding practices and design patterns between the two frameworks, but it might be worth it to you. Adopting SwiftUI could also mean a huge improvement in the scalability and maintainability of your code.

Interoperability between UIkit and SwiftUI

Can't decide on one framework over the other? You also have the option of using both in a single project.

To integrate SwiftUI views in UIkit projects, you can utilize UIkit's UIHostingController class to manage a SwiftUI view hierarchy.

Want to use UIkit components in a SwiftUI project? That's actually quite simple. Wrappers like UIViewRepresentable and UIViewControllerRepresentable enable you to wrap a UIkit view or view controller in SwiftUI code.

This support for interoperability comes in handy if you intend to gradually migrate a UIkit project to SwiftUI. This way, you can improve your code as SwiftUI evolves while retaining UIkit's mature components. Continue to leverage UIkit's strengths and maturity on a SwiftUI project, and eliminate the need to reinvent the wheel.

SwiftUI vs. UIkit: Making your decision

Depending on your application needs, you might already have an obvious winner for which UI framework you want to use to build an iOS user interface.

SwiftUI's declarative syntax, previews, live editing, and reactive programming definitely make it the future of iOS app development. However, UIkit still shines with its numerous UI components, large community, robust documentation, and support for lower iOS versions.

After you've analyzed the SwiftUI vs. UIkit comparison, consider adding customer communications to your app to enhance user engagement, retention, and CSAT. You can do this with Sendbird, an all-in-one communications API platform for web and mobile apps. Sendbird's highly abstracted APIs empower developers to build robust and scalable communication experiences (for chat, notifications, and in-app calls) across web and mobile platforms, leveraging a real-time, compliant, and global infrastructure. Request a demo, start a discussion on the Sendbird Community, or contact us to learn more!

WebSocket vs. HTTP communication protocols

Sendbird Devs — Sat, 10 Feb 2024 00:31:02 +0000

WebSocket vs. HTTP in a nutshell

Many of your daily activities on the internet—from ordering food to looking up a fact to speaking to a doctor online—are enabled by WebSocket or HTTP communication protocols. As a developer, when building an app, which of these communications protocols should you use? What are the differences when we compare WebSocket vs. HTTP? In a nutshell, WebSocket, a full-duplex communication protocol, is relatively newer and is well suited to real-time applications such as in-app chat, notifications, and voice or video calls. On the other hand, HTTP, a half-duplex communication protocol, has been around for some time and has been the basis of websites since its debut.

In this comparison, you’ll learn more about these two communication protocols, their similarities and differences, as well as understand when to choose one over the other. Let’s dive in!

About the WebSocket connection

The WebSocket protocol describes how a client and server communicate in full-duplex channels. In other words, both the client and server can send and receive data simultaneously over a long-lived connection. This type of communication has less overhead than HTTP polling, giving an application several advantages in real-time functionality.

Advantages of a WebSocket connection

Bidirectional communication

Because both sides of the connection can send messages whenever they want, a WebSocket connection is an excellent choice when you need to move a lot of data back and forth quickly.

Imagine a simple chat room connecting multiple clients. If a WebSocket server moderates their conversation, a client sends a message to the server, which then immediately relays it to all other connected clients. As far as the users are concerned, they can send messages to each other in real time.

This is a simple version of what this looks like:

Adapted from Stack Overflow

Lower latency

A common pattern in an HTTP connection for relatively high-frequency data fetching is polling, where the client periodically requests new server data. Perhaps the biggest drawback of this communication method is latency—you have to compromise between frequent or long-running requests and high latency.

With a WebSocket connection, data is sent as soon as it’s available. The client doesn’t need to keep requesting it. The result is much lower latency with a fraction of the overhead and network traffic.

WebSocket vs. HTTP communication diagram

Adapted from source

Persistent connections

With the traditional HTTP connection, the client makes a request, and after the server sends its response, the connection is closed. If the client needs more data, they have to open a new connection.

Note that although HTTP/1.1 introduced persistent connections that allow for the reuse of the TCP/IP connection, this mental model is still helpful and mostly accurate.

With a WebSocket connection, the client can open and use a single connection for all their WebSocket communications with the server. This persistent connection allows for low-latency, bidirectional messages.

This WebSocket connection can also be stateful. An HTTP connection is stateless—this means that each request is handled in isolation, with no retention of information about the requests that came before it. WebSocket, on the other hand, is stateful thanks to its persistent connection.

Whether or not an application takes advantage of stateful capability is entirely up to the developer and how they use their WebSocket connection.

About the HTTP connection

The HTTP protocol was designed as a request-response protocol. A client, such as a browser, would send a request to a web server, and the web server would reply with a response containing the resources corresponding to the request, such as HTML and CSS files. While HTTP connections are open, they are only half-duplex, meaning communication only goes one way. Once a response has been received, the connection is often closed.

HTTP/1.1 introduced persistent connections that reuse the TCP/IP connection, which allows for some performance improvements. However, the specifics of these persistent connections vary from server to server, and in most cases, they’re closed eventually based on an inactivity timeout. So while it’s a welcome addition to HTTP connection functionality, this is still not a direct comparison to a WebSocket connection.

The HTTP protocol has been very good at what it was built for: responding to requests. However, it wasn’t built to handle the real-time communication use cases, such as chat or live event streaming, that people expect today.

Even so, HTTP still has several advantages over the WebSocket protocol.

Advantages of an HTTP connection

Simplicity and ubiquity

The staying power of HTTP connections comes from its widespread adoption and its straightforward accessibility. Between the three major versions of HTTP, virtually all web servers and web browsers can leverage the protocol in some form:

HTTP/1.1. Around 35 percent of sites are still using HTTP/1.1 or below.
HTTP/2. Used by 39.3 percent of all sites.
HTTP/3. Used by 25.7 percent of all sites.

Stateless nature and caching support

Because HTTP requests are stateless and self-contained, a website’s performance might benefit from caching responses, especially when dealing with static content and assets. Caching can take place at various levels:

In the browser: This eliminates the need to contact the server at all.
At the edge: This uses a server closer to the user’s geographic location, as with CDNs.
On the server: This allows the server to avoid expensive recalculations if the result is the same each time.

WebSocket messages cannot be cached as easily as HTTP responses, given that they’re stateful and usually context-sensitive. These messages would change too often for caching to be helpful in most cases.

Robust security mechanisms

The HTTP protocol’s ubiquity means it has been the subject of multiple initiatives to improve its security posture.

HTTPS

The original HTTP protocol is lacking in one important respect—request and response messages are not encrypted and are relatively easy for malicious actors to intercept and read.

This problem is mitigated by HTTPS, a variant of HTTP that uses Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to encrypt requests and responses. A malicious actor might be able to intercept your packets, but they won’t be able to read their content, thanks to this encryption.

HTTP Strict Transport Security

Another HTTP-related security mechanism is HTTP Strict Transport Security (HSTS). HSTS allows servers to specify policies to help prevent common security problems, such as MITM attacks, protocol downgrade attacks, and cookie hijacking.

A site can leverage HSTS by returning the appropriate header over an HTTPS connection, like so:

When configured correctly, HSTS ensures that the browser will always request the HTTPS variant of the site, even if a user has clicked a standard HTTP link. As a result, the user has a layer of security that protects them from many easy-to-mitigate attacks.

WebSocket vs. HTTP: Choosing the suitable protocol

Before you rally around WebSocket or HTTP protocols, consider what you’re building and why. Note that each communication protocol excels in several areas where the other typically falls short.

Technical tradeoffs between a WebSocket vs. HTTP connection
Understanding the technical tradeoffs between these two communication protocols can give you insight as to which one is the best fit for your project.

Connection setup and management

Consider how you need connections to be established and managed over time.

In the case of WebSocket, the persistent connection is established by a handshake between the client and server. It’s kept open for the duration of the session, even if there is a significant delay between messages.

With HTTP, connections are established with a handshake and then used for the request-response cycle. HTTP/1.1 allows for the same TCP/IP connection to be reused for multiple request-response pairs, which reduces overhead and improves latency, but not to the same extent as WebSocket. The connection will still close in a relatively short period, ranging anywhere from a few seconds to several minutes.

Data transmission and encoding

Consider how you want data to be transmitted.

A WebSocket connection uses full-duplex two-way communication—either side of the connection can send messages whenever they want. An HTTP connection uses half-duplex communication; only one party can communicate at a time, and the server’s message is always in response to a request from a client.

Both WebSocket and HTTP can send data encoded in text-based formats like JSON, XML, and plain text, as well as binary-encoded data.

Error handling and recovery

Consider which error handling methods would be least impactful to users.

A WebSocket connection can fail for various reasons, including errors in your application code. Clients are sent an error event that they can listen for, and you can handle the error in this listener however you see fit. However, if your WebSocket server is running inside your application code, fatal errors at the application level can dramatically impact the ability of your app to implement graceful error handling.

An HTTP connection can, of course, experience similar circumstances, but certain common architectures can provide benefits when it comes to error handling. HTTP specifies a range of status codes that servers can respond with to broadly indicate whether the request has been successful or not. The 4xx and 5xx ranges are reserved for client and server errors, respectively.

Consider a web application where requests are handled through NGINX as the web server and PHP as the dynamic backend language. Let’s say something in the application logic results in a fatal error or process termination. This doesn’t affect NGINX’s ability to serve a response to the client, which would most likely be an HTTP 503 - Service Unavailable message.

Of course, this separation does depend on your application’s architecture. Consider a similar situation where your application and web server are implemented together in the same process, such as a Node.js Express app. A fatal error here will also terminate the web server, limiting the usefulness of the error that the client will receive.

Scalability

Consider your application’s resource consumption needs.

WebSocket connections are designed to be highly efficient at what they do. They’re event-driven—messages are only sent when there is something to send a message about.

An HTTP connection can achieve something akin to real-time functionality through long polling, where requests are sent and held open until there is something to respond with. This rough approximation of real-time communication has some limitations, especially at scale. HTTP requests can’t be held open indefinitely, which means that the client will need to periodically open a new long polling request. Over time, the overhead of processing all of these long-lived HTTP requests adds up.

With HTTP streaming, a connection is held open indefinitely to facilitate a continuous data stream. This is conceptually similar to WebSocket, but it’s still performed over HTTP and is still one-way—the client cannot send messages to the server via HTTP streaming.

Performance considerations of a WebSocket vs. HTTP connection

Consider your application’s performance expectations.

Thanks to persistent connections, WebSocket benefits from reduced overhead and latency. This leads to better performance, faster real-time updates, and less processing power spent on things like the HTTP three-way handshake, and HTTP-specific application code for managing incoming requests and authentication/authorization.

Because HTTP typically has to deal with multiple connections over a session’s lifespan, it will naturally spend more time and resources compared to WebSocket.

Security of a WebSocket vs. HTTP connection

Consider which is easiest for you to secure.

WebSocket and HTTP connections are similar regarding security considerations. Both have insecure and secure variants, and both can fall victim to several common attacks if not adequately secured. There are also attacks specific to each protocol that you need to be aware of, such as cross-site scripting attacks for HTTP and cross-site WebSocket hijacking for WebSocket.

However, if you configure them appropriately and use TLS encryption, you can mitigate most threats, making both protocols sufficiently secure.

Hybrid approaches to communication protocols

Typically, the recommended approach is to use both protocols for what they’re best at within your system. That means using an HTTP connection for most of your standard web traffic and a WebSocket connection for anything that requires real-time communication, such as notifications, messaging/chat, or video calls.

You might also consider assessing complementary or alternative technologies; WebSocket and HTTP aren’t the only options when it comes to real-time communication, after all. WebRTC is similar to WebSocket, with the key difference being that it’s used to implement peer-to-peer connections without relying on a server. That can be especially helpful for video calls, allowing participants to communicate directly without introducing load to your server.

Communication protocols for secure, scalable, reliable in-app comms

You should now have a solid idea now of how WebSocket and HTTP communication protocols are intended to be used. You’ve seen their strengths and weaknesses, and you can appreciate their tradeoffs.

Fortunately, you don’t need to choose one over the other. The two communication protocols can, and often should, be used together, allowing each to do what it does best. If you need to implement real-time communication and streaming functionality in your applications, check out Sendbird. Sendbird’s APIs and client SDKs handle the technical heavy lifting for in-app chat, calls, and live streaming. Sendbird’s chat service abstracts away the problems (such as running reliably and securely in real-time at massive scale) associated with growing and maintaining a chat system over a long period of time. This means that you can focus on the core aspects of your application.

Want to try it out? Sign up for free—no commitment or credit card required.

Happy in-app communications building! 📱