SwiftUI is powerful, but it still lacks many native components that are common in other UI frameworks. A floating action button with a compact, expandable menu is one of those missing pieces. That gap is what motivated me to build FloatingMenuButton: a lightweight, SwiftUI‑native FAB that expands into a clean list of actions.

Why FloatingMenuButton?

A FAB is a strong UI pattern for “primary action.” But apps often need more than one action. FloatingMenuButton lets you present a small list of actions right where the user expects it — no extra sheets or menus.

It’s designed to be:

• Simple to integrate (Swift Package Manager)
• Customizable (colors, fonts, icons)
• SwiftUI‑native
• Flexible (supports both SF Symbols and xcassets)

Installation (Swift Package Manager)

In Xcode:

File > Add Package Dependencies...

Repository:

https://github.com/andr3a88/FloatingMenuButton

Quick Usage Example

Here’s a snippet:

import SwiftUI
import FloatingMenuButton

struct ContentView: View {
    var body: some View {
        ZStack(alignment: .bottomTrailing) {
            Color(.systemGroupedBackground).ignoresSafeArea()

            FloatingMenuButton(
                items: [
                    FloatingMenuItem(
                        title: "Video",
                        subtitle: "Add a video",
                        systemImage: "video",
                        color: .red
                    ) {
                        // handle video
                    },
                    FloatingMenuItem(
                        title: "Photo",
                        subtitle: "Add a photo",
                        systemImage: "photo",
                        color: .green
                    ) {
                        // handle photo
                    }
                ],
                fabText: "Add",
                fabTextColor: .black,
                fabColor: .orange,
                fabIcon: "plus",
                fabIconExpanded: "xmark"
            )
        }
    }
}

This snippet shows a basic FAB with two actions, custom colors, and SF Symbol icons .

Use xcassets Icons Too

If you prefer custom icons from your asset catalog:

FloatingMenuItem(
    title: "Profile",
    subtitle: "From xcassets",
    assetImage: "CustomIcon",
    color: .purple
) {
    // handle tap
}

You can even swap the FAB icon with an asset:

FloatingMenuButton(
    items: [...],
    fabColor: .orange,
    fabAssetIconExpanded: "CustomIcon"
)

Wrap‑Up

FloatingMenuButton keeps things small, SwiftUI‑native, and easy to customize — ideal when you want a FAB with multiple actions without the overhead of a full menu system.

If you want to try it or contribute:

GitHub - andr3a88/FloatingMenuButton: A SwiftUI Floating Action Button that expands into a menu with multiple items when tapped.

An example app is avaiable in the repo:

github.com/andr3a88/FloatingMenuButton/tree/main/Example

You can connect me on:

X (Twitter) — @andrea_steva

Linkedin — https://www.linkedin.com/in/stevanato-andrea/

The Problem

Several time we have to deal with different representation of date and time, depending on the service or API we are integrating.

A special case occurs when the same API or service returns an array of objects with ISO 8601 dates that use different representations for the fractional seconds.

ISO 8601

ISO 8601 is an international standard covering the worldwide exchange and communication of date and time-related data

Below the different cases of fractional seconds in ISO 8601:

2024–04–18T21:54:22Z // not fractional
2024–04–18T21:54:22.000Z // fractional milliseconds
2024–04–18T21:54:22.000000Z // fractional nanoseconds

Using JSONDecoder with dateDecodingStrategy = .iso8601 allows you to enable option fractional seconds, but decoding will fail with the error “Expected date string to be ISO8601-formatted” if the JSON contains both fractional and non-fractional dates.

"Decoding failed: dataCorrupted(Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "events", intValue: nil), _CodingKey(stringValue: "Index 1", intValue: 1)], debugDescription: "Expected date string to be ISO8601-formatted.", underlyingError: nil))

Solution — A cascade approach

A first idea is to ask whoever supplies us the API to normalize the format of the seconds using a single approach to represents the seconds, but as we well know, most of the time we have to adapt our code and find a solution.

Our goal is to use a single JSONDecoder to handle a JSON response containing multiple representations for the “second” component of the date:

{
    "events": [
        {
            "id": 1,
            "timestamp": "2025-09-05T13:25:41Z"
        },
        {
            "id": 2,
            "timestamp": "2025-09-01T09:53:38.2492Z"
        },
        {
            "id": 3,
            "timestamp": "2025-09-18T21:54:22.923456Z"
        }
    ]
}

The idea is to define a cascade decoding strategy, trying multiple ISO8601DateFormatter configurations until one matches.

In the extensions below, we define two ISO8601DateFormatters: one that supports fractional seconds and one that doesn’t. This allows us to handle multiple date formats consistently.

We then create a custom JSONDecoder.DateDecodingStrategy called customISO8601Cascade, which tries to parse a date string first with fractional seconds and, if that fails, without. If neither format matches, it throws a decoding error.

extension Formatter {

    static let iso8601: ISO8601DateFormatter = {
        let formatter = ISO8601DateFormatter()
        // This options is the default (can be omitted but but I prefer to make it explicit)
        formatter.formatOptions = [.withInternetDateTime]
        return formatter
    }()

    static let iso8601withFractionalSeconds: ISO8601DateFormatter = {
        let formatter = ISO8601DateFormatter()
        formatter.formatOptions = [.withInternetDateTime, .withFractionalSeconds]
        return formatter
    }()
}

// Custom date decoding strategy
extension JSONDecoder.DateDecodingStrategy {
    static let customISO8601Cascade = custom {
        let container = try $0.singleValueContainer()
        let string = try container.decode(String.self)
        if let date = Formatter.iso8601withFractionalSeconds.date(from: string) ?? Formatter.iso8601.date(from: string) {
            return date
        }
        throw DecodingError.dataCorruptedError(in: container, debugDescription: "Invalid date: \(string)")
    }
}

After that, we can create a JSONDecoder and use the newly created date decoding strategy, and decode our objects.

let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .customISO8601

let response = try decoder.decode(MyResponse.self, from: data)

With this approach you can handle both fractional and non-fractional seconds using a single decoder, without encountering indecoding errors.

Playground

Want to try this out directly in Xcode?

You can find below Xcode Playground with a simple example (tested with Xcode 16.4)

Conclusion

When APIs don’t follow a consistent ISO 8601 format, instead of multiplying decoders or adding manual parsing, you can define a cascade strategy.

This makes your code more resilient to mixed formats while keeping it clean and reusable.

Let me know if you found the article interesting. Thanks for reading.

You can connect me on:

X (Twitter) — @andrea_steva

Linkedin — https://www.linkedin.com/in/stevanato-andrea/

Setting up GraphQL subscriptions in an iOS app can be challenging, especially when dealing with WebSocket connections and authentication.

In this article, we’ll walkthrough how to configure Apollo iOS with an AWS AppSync GraphQL server (Amazon Cognito user pools authorization mode) to handle subscriptions.

Create the WebSocketTransport

The first essential step is to set up a WebSocketTransport with proper authentication header. The code below demonstrates how to create a WebSocket client that connects to the AppSync endpoint.

func getWebSocketTransport() -> WebSocketTransport {
    let webSocketClient = WebSocket(url: URL(stringLiteral: "graphQlRealTimeUrl"), protocol: .graphql_ws)
    webSocketClient.request.setValue("accessToken", forHTTPHeaderField: "Authorization")

    // The custom body creator is required for AppSync's protocol
    let requestBody = AppSyncRequestBodyCreator()
    let config = WebSocketTransport.Configuration(reconnectionInterval: 1.0,
                                                  requestBodyCreator: requestBody)
    let webSocketTransport = WebSocketTransport(websocket: webSocketClient, config: config)
    webSocketTransport.delegate = self
    return webSocketTransport
}

The connection is initialized with the AppSync real-time endpoint, .graphql_ws protocol, and the Authentication header (if you need) is set on the request with the user access token.

The Authorization header is crucial and must be configured according to the AppSync API’s authorization mode, whether it’s API key, AWS IAM, Cognito User Pools, or OpenID Connect.

A custom request body creator, AppSyncRequestBodyCreator, is also required to generate the required payload based on AppSync’s protocol specifications, ensuring the messages are correctly authenticated.

For additional details on configuring your specific case, you can find many useful insights in the official AWS AppSync documentation, that provides in-depth instructions on managing real-time WebSocket operations, including details on endpoints, authentication, and the necessary request formats for correctly setting up the WebSocket client with AppSync.

Request body creator: AppSyncRequestBodyCreator

AppSync’s server protocol is denotated asgrapql-ws on Apollo, and the generic payload using Amazon Cognito user pools is the following:

{
    "id": "subscriptionId",
    "type": "start",
    "payload":
    {
        "data":
        {
            "query": "query in string format",
            "variables": "variables"
        },
        "extensions":
        {
            "authorization":
            {
                "host": "host",
                "Authorization": "accessToken"
            }
        }
    }
}

In details we can see:

• The id of the subscription. This id must be unique for each subscription, otherwise the server returns an error indicating that the subscription id is duplicated. This field is managed by Apollo.
• The type of operation send or received: can be start , stop , data , connection_init , connection_ackor start_ack. This field is managed by Apollo.
• The payload depending on the operation type, contains the information relevant to the subscription. This field is managed by Apollo.
• The data object is a stringified JSON object that contains a GraphQL query and variables . This field is setted by our custom RequestBodyCreator.
• The extensions object contains anauthorization dictionary which holds the fields designated for authentication: host where you have to specificy your GraphQL endpoint (without https:// and /graphql) and Authorization with your access token. The Authorization key may vary depending on your API authorization mode. Also these fields aresetted by our custom RequestBodyCreator.

FYI: the type field is the only required in the message; the id and payload fields are optional.

Here is an example of how you can create the AppSyncRequestBodyCreator:

Basically you have to subclass RequestBodyCreator and implement the method requestBody(for:sendQueryDocument:autoPersistQuery:). This method is called upon the ApolloClient creation and ensures that the request body conforms to AppSync protocol

To better understand the message body, I leave you below an example of the payload message sent by the WebSocket to start a subscription.

{
  "id": "1",
  "payload": {
    "operationName": "userOperation",
    "data": "{\"query\": \"subscription onUserChangedSubscription { onUserChanged { __typename userId firstName lastName }}\" }",
    "extensions": {
      "authorization": {
        "Authorization": "<accessToken>",
        "host": "<host>"
      }
    }
  },
  "type": "start"
}

Setup an Apollo Client with SplitNetworkTransport

This step is quite straightforward, basically you need to create an Apollo client using aSplitNetworkTransport. I leave you also the official Apollo iOS documentation.

A SplitNetworkTransport is a network transport layer that allows you to handle both HTTP and WebSocket connections simultaneously. It routes queries and mutations through the HttpNetworkTransport for standard requests, while subscriptions are managed through the WebSocketNetworkTransport.

To set it up, create a SplitNetworkTransport passing the WebSocketTransport configured earlier and a generic HttpNetworkTransport to handle the HTTP connections.

If you need to authenticate your requests for the HttpNetworkTransport, you can create a NetworkInterceptorProvider that conform to DefaultInterceptorProvider, an object that allows you to add an specific headers to each request, for more details follow this steps.

...

func createApolloClient() -> ApolloClient {
    let cache = InMemoryNormalizedCache()
    let store = ApolloStore(cache: cache)

    logger.debug("Create HTTP and WebSocket transports")
    let splitNetworkTransport = SplitNetworkTransport(uploadingNetworkTransport: getHttpNetworkTransport(store: store),
                                                      webSocketNetworkTransport: getWebSocketTransport())
    return ApolloClient(networkTransport: splitNetworkTransport, store: store)
}

func getHttpNetworkTransport(store: ApolloStore) -> RequestChainNetworkTransport {
    let client = URLSessionClient()
    // Intercept the requests and attacch the Authorization header
    let provider = NetworkInterceptorProvider(client: client, store: store)

    let httpTransportUrl = URL(string: graphQlUrl)!
    let httpTransport = RequestChainNetworkTransport(interceptorProvider: provider, endpointURL: httpTransportUrl)
    return httpTransport
}

Finally, create a subscription

To create a subscription use ApolloClient subscribe method, passing in your subscription object and handling the result with a closure.

Below a code snippet that demonstrates how to initiate a subscription and process incoming data. You can cancel the subscription using subscription?.cancel() .

import ApolloWebSocket

var subscription: Cancellable?

func startSubscription() {
    self.subscription = apolloClient.subscribe(subscription: YourSubscription()) { [weak self] result in
        switch result {
        case .success(let graphQLResult):
            print("Subscription data \(graphQLResult.data)
        case .failure(let error):
            print("Subscription error \(error)
        }
    }
}

deinit {
  self.subscription?.cancel()
}

Conclusion

I hope you found this article both useful and insightful. For further details, please refer to the AWS AppSync documentation and the Apollo iOS repository. Additionally, the Apollo iOS Discord channel is a great resource for support and community discussion. If you have any questions or need further assistance, don’t hesitate to reach out to these resources.

Feel free to leave a comment and share your thoughts or any alternative solutions you’ve discovered.

Happy coding!

Resources:

• Building a real-time WebSocket client in AWS AppSync
• https://github.com/lingfengmarskey/NetworkSample
• https://www.apollographql.com/docs/ios
• https://community.apollographql.com/

In this article, we’ll tackle a specific scenario where we have content in the form of an array but with different types in it.

Let’s say we have to send to our backend an http request with the following json array as body, which represents a list of different types of vehicles:

[
    {
        "name": "Petrol Car",
        "manufacturer": "Ford",
        "petrolTankCapacity": 50
    },
    {
        "name": "Electric Car",
        "manufacturer": "Tesla",
        "batteryCapacity": 75
    },
    {
        "name": "Gas Car",
        "manufacturer": "Renault",
        "gasTankCapacity": 50
    },
    {
        "manufacturer": "Ferrari",
        "name": "SF-24",
        "petrolTankCapacity": 90,
        "batteryCapacity": 40,
        "frontWing": true,
        "rearWing": true,
    }
]

As you notice each objects has different “tank” type or additional custom properties (frontWing and rearWing) . At first glance you might be tempted to create a single struct MixedVehicles containing properties name, manufacturer, and the other properties as optional. Then use JSONEncoder().encode(mixedVehiclesArray) to perform the encoding of the the array [MixedVehicles] .

// AVOID THIS APPROACH
struct MixedVehicles: Encodable {
    let name: String
    let manufacturer: String
    let petrolTankCapacity: Int?
    let gasTankCapacity: Int?
    let batteryCapacity: Int?
    let frontWing: Bool?
    let rearWing: Bool?
    let anytherNotCommonProperties: String?
    ...
}

This approach works, but it will lead to design problems as the number of objects to handle grows. In fact, each new object to manage, cause MixedVehicles structure tend to become more cumbersome, increasing the number of optional properties, and making impossible to manage the object in the long run.

Now let’s see how we can solve the problem.

Type erase Encodable with AnyEncodable

The strategy to overcome MixedVehicles approach is to use an AnyEncodable helper structure that acts as a type eraser for our concrete (Encodable) objects.

For example defining AnyEncodable as below,

/// A type eraser to erase the concrete (encodable) types
struct AnyEncodable: Encodable {
    private let encodeClosure: (Encoder) throws -> Void

    init<T: Encodable>(_ value: T) {
        encodeClosure = { encoder in
            try value.encode(to: encoder)
        }
    }

    func encode(to encoder: Encoder) throws {
        try encodeClosure(encoder)
    }
}

let us use an array [AnyEncodable] to wrap all our objects that conform toEncodable.

Let’s continue with our example. Now we have to define the different concrete objects for the Vehicles:

// Define a common protocol for all encodable objects
protocol Vehicle: Encodable {}

struct PetrolCar: Vehicle {
    let name: String = "Petrol Car"
    let manufacturer: String = "Ford"
    let petrolTankCapacity: Int = 50
}

struct ElectricCar: Vehicle {
    let name: String = "Electric Car"
    let manufacturer: String = "Tesla"
    let batteryCapacity: Int = 75
}

struct GasCar: Vehicle {
    let name: String = "Gas Car"
    let manufacturer: String = "Renault"
    let gasTankCapacity: Int = 55
}

struct F1Car: Vehicle {
    let name: String = "SF-24"
    let manufacturer: String = "Ferrari"
    let petrolTankCapacity: Int = 50
    let batteryCapacity: Int = 10
    let frontWing: Bool = true
    let rearWing: Bool = true
}

The next step is to create an array of type-erased encodable objects:

let vehicles: [AnyEncodable] = [
    AnyEncodable(PetrolCar()),
    AnyEncodable(ElectricCar()),
    AnyEncodable(GasCar()),
    AnyEncodable(F1Car())
]

Now we can encode our data using JSONEncoder:

do {
    let jsonData = try JSONEncoder().encode(objects)
    print(String(decoding: jsonData, as: UTF8.self))
} catch {
    print("Error encoding JSON: \(error)")
}

// OUTPUT:
// [{"petrolTankCapacity":50,"manufacturer":"Ford","name":"Petrol Car"},{"name":"Electric Car","manufacturer":"Tesla","batteryCapacity":75},{"name":"Gas Car","manufacturer":"Renault","gasTankCapacity":55},{"name":"SF-24","manufacturer":"Ferrari","batteryCapacity":10,"petrolTankCapacity":50,"frontWing":true,"rearWing":true}]

As you can see, as output we have our jsonData ready to be used on a URLRequest .

Playground

I leave below a playground to let you test the code in Xcode.

Let me know if you found the article interesting or if you know different approach.

Thanks for reading.

You can connect me on:

X (Twitter)— @andrea_steva

Linkedin — https://www.linkedin.com/in/stevanato-andrea/

This article is intended to help you configure Danger Swift with Bitrise. The main goal is to automating the simplest and most repetitive steps of a code review, allowing you and your team to focus on harder problems.

You can integrate Danger into your project using the most common CI services, for a complete list visit the official “Getting started” section.

In my case I used Bitrise, a service I use daily to build and distribute iOS applications, the same procedure may be applied to any other CI service (Teamcity, Jenkins, Travis, etc.)

Note: for simplicity I assume that a basic workflow on Bitrise has already been configured for the project in use.

What is Danger Swift?

Danger Swift is an automation tool that runs after your CI to enforce conventions in code reviews. Danger leaving messages inside your PRs based on rules that you write in Swift.

For example you can write rules that:

• Enforce CHANGELOGs
• Enforce links to JIRA in PRs bodies
• Enforce using labels, reviewers and assignee and any other PR property
• Look out for common anti-patterns
• Highlight interesting build artefacts (additions, deletions, files changed)
• Verify the presence of unit tests or any other specific pattern inside your source files

The core of Danger is the Dangerfile, named by conventions Dangerfile.swift, that contains a collection of rules specific to your project written in Swift.

Danger Installation

Danger can be installed via Swift Package Manager or via Brew. In my case I used Brew:

brew install danger/tap/danger-swift

As mentioned earlier the rules must be specified in a file Dangerfile.swift, these two commands are useful during the development for creating and testing our rules. The first is:

danger-swift edit

that create a standalone Xcode project where you can edit your Dangerfile.swift. The second is:

danger-swift pr https://github.com/your_account/your_project/pull/1

that command allows to test your rules directly from command line without necessarily having to push code into the repository. You should only have an existing PR to link.

Create a personal access token on Github

To allow Danger to work properly on Bitrise, i.e. add comments in your pull requests must be generated a personal access token from your Github account.

Optionally: you could create a bot account (a normal Github user account) used specifically for this purpose.

In the creation form you need to select all the repo scopes like the image below.

After creation keep the access token safe, if you lose it, you’ll have to recreate it again.

Configure Bitrise CI

If you are familiar with Bitrise you will certainly know the concept of workflow, that is the flow of operations that are carried out during a build.

First of all you need to add a new script step at the end of your build process:

the script installs Danger Swift and executes it. A possible implementation is given below:

#!/usr/bin/env bash
# fail if any commands fails
set -e

echo "################### DANGER ######################"

echo "Install Danger"
brew install danger/tap/danger-swift

echo "Run danger"
danger-swift ci

echo "#################################################"

The next step is to allow Danger access your PRs by setting the Github personal token you created earlier. In the workflow editor, select the tab Secrets and add a new environment variable named DANGER_GITHUB_API_TOKEN and valued with the Github personal token.

Remember to enable the options “Expose for Pull Requests?” like the image below.

Create your own rules

Finally you are ready to import Danger into your project. Create Dangerfile.swift on the root of your Xcode project. Below is an example with some simple rules.

Give it a try!

It’s time to try out what’s been done and make sure it all works. First of all create a new branch and push your danger file. Make an empty PR that does not respect the rules you wrote, for example a short title or an empty description. When the build on Bitrise is finished you should have an additional check regarding Danger, like the image below:

In addition, a message should be added to the PR with output generated by Danger:

Next step: Plugins!

Danger is designed to be extended through plugins.

An extension I would like to try and which is now fully integrated in Danger is Swiftlint. More information here.

Another interesting plugin is danger-swift-coverage which helps to display Xcode’s code coverage files in a friendly way.

f-meloni/danger-swift-coverage

Conclusion

I consider Danger an excellent tool to give fast feedback to the team and increase productivity by leaving repetitive task to automation. The integration of this tool should be gradual and the rules created in agreement with the members of the team, create positive rules and celebrate the achievements with 🎉 and 👍.

You can get more information reading the official documentation and find other examples of Dangerfile at these links:

• danger/awesome-danger
• artsy/eigen
• Moya/Moya

Let me know if you found the article interesting. Thanks for reading.

You can connect me on:

Twitter — @andrea_steva

Linkedin— https://www.linkedin.com/in/stevanato-andrea/