SwiftUI is a modern UI framework for building iOS, iPadOS, watchOS, and macOS applications. Introduced in 2019, it offers a declarative syntax that enables developers to write concise, efficient, and easy-to-read code. SwiftUI has quickly become the go-to framework for developing user interfaces in the Apple ecosystem, and its popularity continues to grow. In this article, we will discuss the features of SwiftUI, best practices for using it, and common bottlenecks that developers may encounter.

Features of SwiftUI

Declarative syntax

SwiftUI’s declarative syntax makes it easy to describe a user interface in a concise and expressive way. Developers simply declare what they want the user interface to look like, and SwiftUI handles the rest. This approach is in contrast to the traditional imperative approach, where developers have to write detailed instructions for how the user interface should be constructed.

Live preview

SwiftUI includes a live preview feature that allows developers to see the changes they make to the user interface in real-time. This feature makes it easier to experiment with different design choices and to catch issues early in the development process.

Cross-platform support

SwiftUI is designed to work across multiple Apple platforms, including iOS, iPadOS, watchOS, and macOS. This allows developers to write code that can be used across multiple platforms, reducing development time and effort.

Customizable views

SwiftUI allows developers to create custom views and reuse them throughout their application. This feature makes it easy to create complex user interfaces that are consistent across an application.

Best practices for using SwiftUI

Use @State for mutable state

SwiftUI uses the @State property wrapper to manage mutable state within a view. When a property is marked as @State, SwiftUI automatically handles updates to the property and updates the view accordingly. Using @State can simplify code and reduce bugs caused by mutable state.

Use @Binding to pass state between views

@Binding is another property wrapper that is used to pass state between views. When a view is passed a @Binding, it can update the state of the original view. This can be useful for sharing data between views or for creating reusable components.

Use ForEach for dynamic content

SwiftUI’s ForEach view can be used to dynamically generate views based on a collection of data. This can be useful for displaying lists of data or for creating complex user interfaces that change based on user input.

Use GeometryReader for layout

GeometryReader is a view that provides information about the size and position of its parent view. This can be useful for creating complex layouts that adapt to different screen sizes or for positioning views relative to each other.

Use ZStack for layering views

ZStack is a view that can be used to layer views on top of each other. This can be useful for creating complex user interfaces that require multiple layers of views.

Bottlenecks in SwiftUI

Performance issues with large views

SwiftUI’s declarative syntax can make it easy to create large and complex views. However, large views can cause performance issues, particularly on older devices or devices with limited memory. Developers should be mindful of the size of their views and should consider breaking them down into smaller, more manageable pieces if necessary.

Issues with animation

SwiftUI’s animation system is powerful and easy to use. However, it can be challenging to create complex animations that are performant and visually appealing. Developers should take care to optimize their animations and to test them on a range of devices.

Difficulty with custom layouts

While SwiftUI’s declarative syntax makes it easy to create simple layouts, it can be challenging to

Swift is a powerful and efficient programming language, widely used to develop applications for iOS, macOS, and other Apple platforms. It is known for its safety, speed, and expressiveness. Since its first release in 2014, Swift has seen consistent updates and improvements. The latest release, Swift 5.8, introduces several new features and enhancements, making it easier and more efficient to develop Swift applications. In this article, we will take a comprehensive look at all the new features and improvements of Swift 5.8.

Concurrency

Concurrency is a key feature of modern programming languages, and Swift 5.8 provides developers with powerful support for writing concurrent code. The new release introduces two new language constructs, async and await, which simplify the writing of asynchronous code. The async keyword allows developers to define asynchronous functions, while the await keyword enables the blocking of code execution until an asynchronous task is completed.

Swift 5.8 also introduces the Task API, which provides a lightweight mechanism for creating and managing tasks. Tasks are a low-level construct that allows developers to write code that can be executed concurrently, making it easier to write efficient and responsive code.

Improved error handling

Swift 5.8 provides enhanced support for error handling, making it easier to write robust code. Previously, developers had to handle errors explicitly by writing code that caught and handled errors. With Swift 5.8, developers can use the try? operator to automatically handle errors and return a nil value if an error occurs. This makes error handling more concise and less error-prone.

Swift 5.8 also introduces a new throwsAsync function type, which allows developers to define functions that throw errors asynchronously. This new function type simplifies error handling in asynchronous code.

Property wrappers

Swift 5.8 introduces new support for property wrappers on local variables, which were previously only allowed on properties of structs or classes. Property wrappers provide a way to add additional behavior or validation to properties, making it easier to write cleaner and more concise code. The new feature for local variables is particularly useful when working with UI elements or other temporary values.

Improved diagnostics

Swift 5.8 includes several improvements to the language’s diagnostics. The compiler now provides more detailed and accurate error messages, making it easier to identify and fix issues in code. Additionally, the new release includes improvements to the syntax highlighting in Xcode, making it easier to read and understand code.

Async sequences

Building on the concurrency support introduced in Swift 5.8, the language now allows for async sequences. This new feature provides a way to asynchronously generate a sequence of values. Async sequences allow developers to write cleaner and more efficient code when working with streams of data, such as network requests or file processing.

Improved memory management

Swift 5.8 includes several improvements to the language’s memory management. The new release introduces a new withUnsafeContinuation function, which provides a way to safely pass continuations across asynchronous boundaries. Additionally, Swift 5.8 includes several improvements to the garbage collector, making it faster and more efficient.

Enhancements to the Standard Library

Swift 5.8 includes several enhancements to the standard library. One of the most notable additions is support for a new Zip type, which provides a way to combine two sequences into a single sequence of pairs. Additionally, the new release includes a new partition(by:) method for collections, which allows for efficient in-place partitioning of collections.

Conclusion

Swift 5.8 is a significant release that brings a range of new features and improvements to the language. With improved concurrency support, error handling, property wrappers, async sequences, diagnostics, and memory management, Swift developers have a powerful set of tools to build more efficient and robust code. If you’re interested in learning more about the new features of Swift 5.8, there are many resources available online, including the official Swift documentation and various online forums and communities.

Intro

Developers, in general, tend to write clean, good looking, and efficient code. But the most important thing is the look & feel of the final product — an app in the App Store everyone will adore.

To achieve that, we sometimes need to use 3rd party libraries to ship new features faster. And every piece of code, library, or framework we add to the project counts towards the final binary size of the app.

That’s all great since we usually don’t bother much until the app is still within an acceptable size. I will not discuss what app size is adequate and whatnot since this is a mostly subjective thing. But everyone has its opinion on that.

App Clips

This year WWDC brought as a new little thing to play with called App Clips. Without further explanation of what they are, here is the quote from Apple’s website:

“An App Clip is a small part of your app that’s discoverable at the moment it’s needed. App Clips are fast and lightweight so a user can open them quickly.”

The main thing about App Clips is that they are small. But how small? Really small, and I mean it. It’s not that they are small in terms of a few dozen MBs, but they are tiny. The hard limit for App Clips is 10 MB in size, but that’s not the whole story. Someone would argue, eh, that’s fine, we can remove some chunks of the code, and we are quickly at 10 MBs. Well, maybe. Maybe not. Here is the thing. This limit refers to the uncompressed size, which is the app’s size after it is downloaded and installed on the device.

Does that make a difference? Oh, it does. In reality, it means that the size of the downloaded app is below 5 MBs. That is something.

I’ll not discuss the whole process of app thinning in this article. But in the end, I’ve managed to shrink my app from 36+ down to 9.5 MB of uncompressed binary size.

Measuring the app size

Now that we are set with the requirements and the terminology, let’s see how we can measure the final binary size before it’s deployed to the App Store.

First, you’ll need to prepare an archive of the project.

Tap “Product” → “Archive” and wait until the “Organizer” is opened. If it doesn’t open automatically upon archiving is finished, open it from the menu by tapping “Window” → “Organizer”.

Now follow the next screens below…

You’ll be prompted with a modal sheet to select the location of the archived project. Now navigate to the just saved folder in Finder and open “App Thinning Size Report.txt” file. You should see the report details for all variants that will be distributed to the App Store.

The important thing here is to look at the last entry, named “{Product}.ipa”. In my case, this is “AppClip.ipa”, a universal variant that we should look at.

Before

The size of the app before I’ve started thinning it was 16,5 MB compressed and 36,6 MB uncompressed. As you can see, the difference between downloaded and installed app size is quite significant.

After

Here is the size of the app after the thinning process. I call it the new “normal”. Compressed size is 3,4 MB, uncompressed just under the allowed limit at 9,3 MB.

Recap

Whenever you need to lose some size of the app (for the sake of the App Clip or other reasons), this is an excellent way to examine the actual size of the app that will take effect in the App Store. I wasn’t aware of that until I needed it for the App Clip.

p.s.: I need to mention that this size can vary a bit from the size in the App Store since the encryption sums up values a bit.

Now that the final version of Xcode is out it took me only a few seconds to find the setting in the Xcode that proves that this is intended behavior and can be modified or even turned off.

What it does is that Xcode can add an extra space at the bottom of the screen so you can easily edit the code at the bottom of the file, presented in the middle of the screen.

It felt weird at first, but now I like it. I’ve chosen to use Small over-scroll setting.

Imagine an app that will be distributed around the world and needs to be translated in as many languages as possible. Easy right? Yeah, it’s not rocket science, but I’ll give a few tips and tricks on how to manage single or multilingual apps with ease.

As an iOS developer, the main focus here will be a localization of an iOS app. But I’ll give some tips for the Android part also.

iOS and android both have similart ways to handle localizations in apps. On iOS you need to create localizable.strings and on android strings.xml file. You would tipicaly create one of this file per language e.g. if you need to support English and German languages you will create {en,de}/localizable.strings for iOS and/or values-{en,de}/strings.xml . After that you create key-value entries where key is like and identificator for translation and value is an actual translation.

iOS and Android both have similar ways to handle localizations in apps. On iOS, you need to create localizable.string file and strings.xml on Android. You would typically create one of this file per language, e.g., if you need to support English and German languages you will create {en,de}/localizable.string for iOS or values-{en,de}/localizable.string for Android. After that, you create key-value entries where the key is like an identification for translation and value is an actual translation.

Here is an example of localizable.strings file on iOS

/* General */
"title" = "Title";
"subtitle" = "Subtitle";

/* Login *?
"login_button" = "Login";
"login_forgot_password" = "Forgot Password";

And example of strings.xml file on android

<!-- General -->
<string name="title">Title</string>
<string name="subtitle">Subtitle</string>

<!-- Login -->
<string name="login_button">Login</string>
<string name="login_forgot_password">Forgot Password</string>

Now imagine you have 1000+ entries in localization file like above. Again, easy right? Yes, you need to add key/value pairs, and you are good. But what if I tell you that we’ll be supporting German, Spanish, Italian, French and some other languages down the road? You’ll probably just copy/paste this files, renamed them and updated translations right? Well, this is where this article will help you out so you will not end up in a sync-up mess or forget to add/remove translations to/from all files.

The first thing you need to get familiar with an excellent library called Babelish. It is written in ruby and supports conversions for iOS and Android among others. The Babelish main purpose is to pick CSV file with translations and convert it to destination format (strings or XML in our case).

Install Babelish

The easiest way to install this library is to create Gemfile (or update if already exists in the project) with the following lines.

# Project Gemfile
source "https://rubygems.org"

# other gems
gem 'babelish'

After saving a Gemfile, just run gem install bundler and bundle install from the Console.

The next thing is to configure a config file .babelish that Babelish will use for conversion. An example is available on GitHub. Here I am sharing an example from one of my iOS projects

filename: "Project Localization"

langs:
  English: "en"
  German: "de"

fetch: true
sheet: 0
excluded_states: ["SKIP", "android"]
comments_column: 0
state_column: 4
keys_column: 1
default_lang: "ENGLISH"
output_dir: "../Project/Resources/Localization/"
output_basenames:
- Localizable
ignore_lang_path: false
stripping: true
csv_separator: ","

Notice filename and fetch properties. Both are used to load a CSV from a Google Sheets. If you want to load translations from a local CSV file, change the filename to a local file path and set fetch to false. If you are not going to use Google Sheets, you can skip the next chapter.

Creating a Google Sheets

Head over to Sheets and create a new blank document.

Let’s walk you through the document briefly and explain all the columns.

• Section - a grouping key, this is a comment that will separate each group with an empty line
• KEY - localization key that will be used in the app to get out the translation
• iOS/Android - these columns are not needed but are nice to have to know if a key was added to either platform (when using the same translations for both platforms)
• Action - I use this column to define which platform key/value pair should be exported. If you put in iOS, it will be only generated for *.strings file. If you put in Android, it will be only generated for *.xml file. There is another option to put in SKIP. When you put that into the comment column, this line will not be exported for any platform. This is defined in the config with key `excluded_states`.
• Notes - you can put here some extra notes or explanation.
• English/German - a column per language. In this example, we have translations for English and German. When you want a new language, add a new column, name it and put it in the config file under langs.

The magic

Now that we have a spreadsheet ready with all the translations, we need one final step. Create localizable files that our apps will consume.

We need to run the script (below) that will generate files for us. The script should be in the same folder as the config file (or modify the path to the script). Note that config must be set per project. So if you have iOS and Android project, you’ll need to create two configs.

Call ./Localize.sh without params to generate files for iOS platform.

/* General */
"general_success"  = "Success";
"general_continue" = "Continue";

/* Login */
"login_button"     = "iOS only export";

--------------------------------------------------------------------

/* General */
"general_success"  = "Erfolg";
"general_continue" = "Fortsetzen";

/* Login */
"login_button"     = "iOS nur exportieren";

Call .Localize.sh android to generate files for android platform.

<?xml version="1.0" encoding="utf-8"?>
<resources>

<!-- General -->
 <string name="general_success">Success</string>
 <string name="general_continue">Continue</string>

<!-- Login -->
 <string name="login_button">Android only export</string>
</resources>

--------------------------------------------------------------------

<?xml version="1.0" encoding="utf-8"?>
<resources>

<!-- General -->
 <string name="general_success">Erfolg</string>
 <string name="general_continue">Fortsetzen</string>

<!-- Login -->
 <string name="login_button">Android nur exportieren</string>
</resources>

Conclusion

I’ve seen a lot of projects doing localization wrong. I don’t say it’s hard, it’s just hard to make it right and easy to manage. It all complicates after you start localizing your app for the second, third or even more languages.

I’m using this technique in all projects I’ve been working on for a while now. I use this approach even if the app is monolingual. The main reason I’ve decided practicing this is feasibility to change existing translations or add new ones.

We all know tested code is an essential path to the successful app. It all starts and ends with the code quality.

If you have ever wondered how to test UIKit frameworks, you are not alone. It’s not comfortable nor elegant in any way. However, this is the path we need to follow until Apple does the job and make it friendlier and more accessible to test.

Regardless the words above we can still work around the limitations UIKit impose on us.

Testing gesture recognizers should be easier if we had a proper public APIs. However, until we do, we’ll need to make an extra effort.

What Apple offers us?

Let’s take a look at the UIPanGestureRecognizer public API first to see what is available and what is not.

open class UIPanGestureRecognizer: UIGestureRecognizer {
  open var minimumNumberOfTouches: Int
  open var maximumNumberOfTouches: Int
  open func translation(in view: UIView?) -> CGPoint
  open func setTranslation(_ translation: CGPoint, in view: UIView?)
  open func velocity(in view: UIView?) -> CGPoint
}

UIPanGestureRecognizer directly derives from UIGestureRecognizer which holds many more data like state, allowedTouchTypes, numberOfTouches, etc.

As you can see from the code above we can get some basic info about the gesture itself. Also, more info available from the base class. However, at this point, you are probably wondering how can we get out the info about the target and action/selector that we need for a successful unit test.

Ground work

We need to create a subclass of UIPanGestureRecognizer

import UIKit

class UIPanGestureRecognizerMock: UIPanGestureRecognizer {
  let target: Any?
  let action: Selector?
  
  override init(target: Any?, action: Selector?) {
    self.target = target
    self.action = action
    super.init(target: target, action: action)
  }
}

This is pretty much self-explanatory. We are just overriding designated initializer and exposing target and action we’ll later use in the tests.

We can also override other properties like velocity or translation so we can have broader control over gesture.

var gestureTranslation: CGPoint?
var gestureVelocity: CGPoint?

override func translation(in view: UIView?) -> CGPoint {
  if let gestureTranslation = gestureTranslation {
    return gestureTranslation
  }
  return super.translation(in: view)
}

override func velocity(in view: UIView?) -> CGPoint {
  if let gestureVelocity = gestureVelocity {
    return gestureVelocity
  }
  return super.velocity(in: view)
}

At this point, we can manipulate a gesture recognizer to this point so we can start writing unit tests. Before we do that, let’s set up our base viewController that handles the panning.

import UIKit

class PannableViewController: UIViewController {
  override func viewDidLoad() {
    super.viewDidLoad()
    
    let action = #selector(panGesture(_:)
    let gesture = UIPanGestureRecognizer(target: self,
                                         action: action))
    view.addGestureRecognizer(panGesture)
  }
}

private extension PannableViewController {
  @objc func panGesture(_ gesture: UIPanGestureRecognizer) {
    let translation = gesture.translation(in: view)
    // pan gesture handling code goes here
  }
}

Also, a test case class that executes all tests.

import XCTest
@testable import BaseTarget

class PannableViewControllerTests: XCTestCase {
  private let vc = PannableViewControllerInjector()
  
  override func setUp() {
    super.setUp()
    _ = vc.view
  }
}

private class PannableViewControllerInjector: PannableViewController {
  var gestureRecognizer: UIPanGestureRecognizerMock?
  
  override func viewDidLoad() {
    super.viewDidLoad()
    guard let existingGestureRecognizer = view.gestureRecognizers?.first(where: { $0 is UIPanGestureRecognizer }) as? UIPanGestureRecognizer else { return }
    view.removeGestureRecognizer(existingGestureRecognizer)
    
    let action = Selector("panGesture:") // an Objective-C selector instead because a caller metod is private
    let newGestureRecognizer = UIPanGestureRecognizerMock(target: self, action: action)
    view.addGestureRecognizer(newGestureRecognizer)
    gestureRecognizer = newGestureRecognizer
  }
}

We have mocked our base view controller so we can take control over the gesture recognizer.

First, we have to find out the existing gesture recognizer and remove it.

Second, we create a new gesture recognizer from our mocked class we have prepared earlier and attached it to the view.

Notice how we defined a Selector? Since we need to access the action method behind a private extension, we need to create an Objective-c selector.

If your action method has any of the less restrictive access modifiers set, you can create Swift Selector instead.

Let’s test it

We are ready to start testing recognizer behavior.

func testSetup() {
  XCTAssertNotNil(vc.view.gestureRecognizers?.first(where: { $0 is UIPanGestureRecognizerMock }))
}
  
func testPanBegan() {
  vc.gestureRecognizer?.pan(location: nil, translation: .zero, state: .began)
  XCTAssertEqual(vc.view.frame.minY, 0)
}
  
func testPanDownwards() {
  vc.gestureRecognizer?.pan(location: nil, translation: CGPoint(x: 0, y: 200), state: .changed)
  XCTAssertEqual(vc.view.frame.minY, 200)
}
  
func testPanEndedShouldResetDueToLowVelocity() {
  vc.gestureRecognizer?.gestureVelocity = .init(x: 0, y: 0)
  let offset = vc.view.frame.height * vc.minimumScreenRatioToHide + 1
  vc.gestureRecognizer?.pan(location: nil, translation: CGPoint(x: 0, y: offset), state: .ended)
  XCTAssertEqual(vc.view.frame.minY, 0)
}

func testPanCancelled() {
  vc.gestureRecognizer?.pan(location: nil, translation: CGPoint(x: 0, y: 1), state: .cancelled)
  XCTAssertEqual(vc.view.frame.minY, 0)
}

You can see the whole gist here.

Conclusion

I am pretty happy with the result at the end since I can test out our gesture recognizer with confidence. Sure, we only covered pan gesture, but all other gestures can be tested in a similar fashion.

I still have some hopes and wishes that Apple will bring us some good news in the not so distant future about testability of their frameworks. Until then, I’m good with this.