Categories
Blockchain Discipline Finance Financial Services Insurance Resources Sector Software Technology

The State of DLT Report 2025

Categories
Blockchain Financial Services Other Software Technology

What is the LF Decentralized Trust?

Monday, 17.09, marks an exciting milestone for decentralized technologies with the official launch of the LF Decentralized Trust by the Linux Foundation. This new initiative is kicking off with over 100 founding members and promises to drive innovation in blockchain, decentralized identities, smart contracts, and more. But what exactly is this trust, and why is it so important for the future of technology?

We have an entire video covering the LF Decentralized Trust.
You can watch it here:

How does the LF Decentralized Trust work?

The LF Decentralized Trust is a collaborative effort that brings together a global community of experts and organizations to work on decentralized technologies. These technologies enable systems to interact directly without relying on a central authority, offering more transparency, security, and control.

By focusing on areas like blockchain, decentralized identities, and cryptographic tools, the trust aims to create open-source solutions that industries across finance, healthcare, and government can adopt for more secure and transparent operations.

Why Decentralization Matters

In today’s digital world, industries are rapidly moving towards decentralized systems. Whether for Central Bank Digital Currencies (CBDCs) or national digital infrastructures, the need for neutral and secure systems is growing.

Technologies like zero-knowledge proofs, multi-party computation, and tokenization offer game-changing potential. By enabling interactions without a single controlling entity, these innovations ensure that systems remain open and accessible for future generations.

Open Governance and Vendor Neutrality in the Trust

One of the core principles of the LF Decentralized Trust is its focus on open governance and vendor neutrality. This means that everyone involved has a say in how the technologies are developed, and no single company or organization can dominate. This way we can ensure that the technologies remain flexible and trustworthy, which is crucial for long-term projects like CBDCs and national infrastructures.

Expanding on the Hyperledger Foundation’s Work

The Linux Foundation Decentralized Trust builds on the foundations laid by the Hyperledger Foundation and other Linux Foundation projects. With over 17 Hyperledger projects focused on real-world applications, this new initiative will further expand decentralized technologies’ reach across multiple industries.

Why The LF Decentralized Trust Matters for Your Industry

As more companies and governments adopt decentralized technologies, the opportunities for open-source collaboration will only grow. Whether in finance, healthcare, supply chain, or retail, decentralization offers a future of transparent, secure, and scalable systems.

Categories
Software Technology

Read this to avoid a no-code headache

Introduction

In recent conversations, if you somehow manage to escape the buzz around AI, you might bump into no-code and low-code platforms. Some developers, especially juniors, can’t help but feel a pang of FOMO, wondering if they might be left behind in this rapid shift.

Are low-code tools easy to use? Can you finally build complex software without programming skills?

To find out, our Software Developers Kacper & Wojtek decided to build 3 Open Banking MVPs of a personal budget tracker, using a variety of technologies:

  1. No-code: Bubble & Airtable
  2. Low-code: Bubble
  3. Traditional development: React & Node.js

Additionally, we tested Retool – a viral no-code platform. 

We want to take you backstage so you can see how they compare.

If you want to, once and for all, understand the difference between no-code & low-code vs traditional development, then this guide is for you.

When to use no-code?

Pros and cons of no-code

When to use no-codeWhen to avoid no-code:
Prototyping: quick concepts without codingComplex applications: custom functionalities
Simple web applications: basic websites or portfoliosSecurity: sensitive data
Internal tools: HR forms, dashboardsDeep integrations: specific APIs
Automated workflows: email campaigns, data processingHigh performance: real-time tasks
Table 1. A table highlighting when to use and avoid no-code solutions.

Key considerations for using no-code

  • No-code solutions can limit control over data and security.
  • These platforms often require premium accounts for advanced features.
  • Platforms like Airtable offer quick onboarding and simple integration with only some external tools.

These lists themselves don’t paint the full picture. If you want to learn how we came to these conclusions, join us for the ride.

First things first, what is no-code?

What exactly is no-code? No-code is another iteration of Rapid Application Development tools. Some developers might remember tools like C++ Builder or Delphi, which allowed us to build working applications.

No-code platforms don’t provide a programming interface because, theoretically, you can configure it through the user interface. This allows anyone to easily create and automate applications or business operations, that are happening behind the scenes. The interface works similarly to cloud services like AWS or Azure, where you select ready-made solutions and combine them like Lego bricks.

Since we can set it up ourselves without coding, we don’t need developers*. However, this is a theoretical approach, and the bottom line is that we can deliver cheaper and faster.

* As you’ll read later, this is not always the case.

Test setup

Backend

The backend for the project uses Firebase for user authentication and Plaid for financial data aggregation. These services handle security and connectivity with financial institutions, allowing the application to fetch and manage user transaction data effectively.

Test #1 – Airtable

The first test done in the project was with the Airtable platform. It served as the base for constructing user interfaces and integrating data flows. We leveraged its spreadsheet-like functionality coupled with database capabilities.

Screenshot of an expense tracking report in a no-code platform Airtable showing a pie chart of total expenses by category alongside a detailed transaction list.
Figure 1. Expense tracking report in Airtable

The initial test involved setting up an Airtable base to integrate with the Fintable plugin, which fetched financial data through Plaid. This setup was tasked with:

  • aggregating transaction data,
  • authenticating users (through Google Auth),
  • presenting financial summaries.

Developer experience

Working with Airtable was intuitive and user-friendly, especially for those who aren’t as technically experienced. Setting it up quickly, and integrating with ready-made solutions in the Airtable shop made the process even smoother. However, customisation options for the user interface were quite limited. Although we could filter and automate based on user sessions, we couldn’t personalize the UI much beyond basic colour themes.

Fintable for the Open Banking integration with Plaid

We used an Airtable plugin called Fintable to integrate our financial data using Plaid. This plugin was quite handy as it automated the validation of our database structure, letting us know if any fields were missing. However, we did encounter some limitations. The plugin only allowed access to predefined data scopes, so we couldn’t retrieve additional fields like spending categories from the API.

No-code Airtable validation success message with detailed fields for Accounts and Transactions tables showing required fields including Plaid integration data.
Figure 2. Confirmation screen from Fintable.

Pricing of Airtable

The pricing model for Airtable involves paying based on the number of users and the data load. Additionally, using plugins like Fintable incurs extra costs, depending on the scope of data and the number of records. This pricing structure can make it as expensive as deploying a traditional application.

Airtable no-code pricing plans featuring Free, Team, Business, and Enterprise options, highlighting features like automation runs, data records, and attachment limits.
Figure 3. Pricing options for Airtable (July 2024)

Pricing of Airtable

The pricing model for Airtable involves paying based on the number of users and the data load. Additionally, using plugins like Fintable incurs extra costs, depending on the scope of data and the number of records. This pricing structure can make it as expensive as deploying a traditional application.

Pros and cons of Airtable

Pros of AirtableCons of Airtable
easy to usesecurity flaws
quick onboardingplugins cut data
simple integrationlimited UI customisation
great for one-offs
Table 2. Overview of Airtable’s strengths and weaknesses

Now that we know more about using Airtable for such small projects. Can a more complex, heavily advertised Bubble be a better solution?

Test #2 – Bubble

Working with Bubble was a bit more complex than Airtable. While it provided much greater control and customization options, it required us to handle a lot of low-level details manually. The platform allowed for detailed integration with external APIs, but it wasn’t as intuitive, and we encountered issues with outdated documentation. However, we need to start from the biggest issue of them all – pricing.

(Interesting) pricing of Bubble

The pricing model of Bubble was quite aggressive. We constantly received prompts to upgrade to premium versions, which became irritating. Costs included the platform fee, user charges based on traffic, and additional fees for each external plugin used. For collaborative work, we needed to purchase an agency account, adding to the expenses.

No-code Bubble pricing tiers showing Free, Starter, Growth, Team, and Enterprise options with details on features for app development and testing.
Figure 4. Pricing options for Bubble (July 2024)

Developer experience

There are some things we need to point out.

Working with Bubble involved extensive manual configuration and frequent use of browser developer tools. Designing workflows required separate flows for conditional logic and careful mapping of API responses. Debugging was challenging due to limited console access and reliance on window.alerts. Integrating plugins added complexity, often lagging behind API updates. Users can find many useful Bubble plugins on a marketplace, but they often cost a hefty sum. While customisable, the platform has UI limitations as well.

For instance, many built-in browser functionalities are disabled for unknown reasons. For example, the system blocks selecting the Google OAuth redirect URL from a plugin description, preventing text selection. As a result, you often have to use the browser’s console, which can be particularly challenging (or simply impossible) if you’re not a developer.

Developer tools screenshot showing the configuration of the Ez Plaid Connect & ACH Transfers plugin in Bubble with fields for App ID, API Key, and App Secret.
Figure 5. Google OAuth Plugin Configuration in Bubble

Open Banking integration with Plaid was a positive surprise.

The API provider’s monitoring is greatly simplified using the Open Banking plugin in Bubble. Detailed logs and clear error messages helped us efficiently troubleshoot issues such as invalid token formats. Real-time feedback allowed us to quickly identify and fix errors, significantly enhancing our integration experience.

Here’s a look at the final UI:

User interface of a no-code personal expense tracking dashboard in Bubble featuring a pie chart of expenses by category and a graph showing transaction trends over time.
Figure 6. User dashboard displaying transaction data, made with Bubble

Pros and cons of Bubble

Pros of BubbleCons of Bubble
Ad-hoc accessibilityExtremely poor UX
It workedPoor plugin quality
Plugins can be a new source of incomeData mismatch and difficulties with mapping
“I will never have to touch it again” (Wojtek)Lack of consistency between components
Lack of bulk data processing
Table 3. Overview of Airtable’s strengths and weaknesses

If you have some software development experience, stick around to see how we’ve built the app in React + Node.js within just 2 days. Before that, let’s talk about Retool.

Test #3 Retool – a promising future!

We tested this low-code platform for some internal CRUD-style tools. Working with Retool was a refreshing experience compared to Airtable and Bubble. It provided a combination of a UI Builder and coding capabilities. We could create a sophisticated application using both buttons and custom code.

Developer experience with Retool

We wanted to highlight a few aspects. Retool allows you to click through many functionalities in the UI and add custom code, which significantly accelerated development for us. The platform provides direct access to SQL and supports templating, and JavaScript for additional customisation. It is limited but possible.

Retool is very similar to Airtable but much more powerful, Retool’s learning curve is manageable. Onboarding is smooth, and you can start working practically immediately. It’s excellent for building view models for ready-made solutions, such as admin panels and CRUD. This is what you will use it for 80% of the time.

Some limitations exist with external tools, but access to Axios allows for hybrid queries. It’s great because you can fire parallel triggers based on the input.

Screenshot of a content management system interface displaying various draft and published articles, with tools for submitting and editing content.
Figure 7. Retool user interface for managing content

Test #4 React + Node.js

We need to highlight both Wojciech and Kacper are native to these technologies. Therefore it is obvious that we were able to find an easy way to create this MVP in React + Node.js. 

Integration with Plaid

The integration is trivial, mainly because we were already familiar with the token exchange mechanism and how to handle it. Additionally, it was beneficial that Plaid has unambiguous and easy-to-understand documentation, along with a comprehensive list of working examples on its GitHub.

Package for diagrams

As a result, we essentially just had to piece together a ready-made app from blocks, and within one or two days, we had a full-stack application ready, aligned with the initial requirements. To complete it, we only needed a library for displaying diagrams, so we headed to the NPM marketplace and found a suitable package to use. You can see the result in Figure 8.

User interface showing a no-code personalized expense tracking dashboard with a categorized breakdown of expenses and a colorful pie chart, tailored for a user named Wojtek.
Figure 8. Personal cost management app dashboard with React + Node.js

Pros and cons of using React + Node.js instead of low-code

AdvantagesDisadvantages
Easy integration with the SDKYou have to write code
Highest level of API controlYou have to deploy your app – which is much easier in no-code apps
Table 2. Overview of strengths and weaknesses of traditional development

Summary

While no-code and low-code platforms can expedite development for simpler applications, they often fall short of complex systems that require robust security, deep integrations, and high performance. For developers and organisations deciding between these technologies, this guide offers valuable insights into when and how each approach can best be utilised.

Categories
Design Software Technology

SwiftUI vs UIKit – why is declarative programming the future?

As an iOS developer, it’s important to know and understand SwiftUI and it’s predecessor UIKit – a framework used to build graphical, event-driven interfaces for mobile apps. When SwiftUI was announced at Apple’s WWDC event in 2019, it immediately grabbed my attention. It’s a huge release and change in building graphical interfaces since UIKit, which is now over 10 years old. But why, and what makes it so different from UIKit? Its use of the declarative paradigm instead of the imperative paradigm. Now we are in the year 2023. It’s been 4 years since the first announcement and I can tell you that SwiftUI is definitely the future of iOS programming!

Imperative programming

Imperative programming is a paradigm that focuses on describing the specific steps or procedures to achieve a desired outcome. In this approach, developers give explicit instructions to the computer on how to perform tasks and update the user interface. UIKit uses an imperative programming model.

Imperative programming requires developers to manage the state of the application and handle UI updates manually. For example, to display a button on the screen, developers must create the button object, specify its attributes, and explicitly add it to the view hierarchy. As the application evolves and state changes, imperative code becomes more complex and difficult to maintain.

UIkit vs SwiftUI

UIKit has been used as an imperative framework for app development for a long time. While it has served developers well, it has had its limitations and a legacy feel in some areas. As applications became more complex, UIKit codebases often became unwieldy and difficult to maintain.

Making changes or adapting to different screen sizes and orientations required considerable effort. SwiftUI addressed many of these challenges with its declarative approach. It introduced a more natural way of building user interfaces by allowing developers to declare the desired layout and appearance of UI elements.

The framework automatically handles the underlying complexity of managing the user interface. This makes the code more maintainable and scalable. SwiftUI also provides a live preview feature that allows developers to see changes to the UI in real-time as they write code. This significantly speeds up the development process and improves the overall developer experience.

UIKit and SwiftUI view visibility code.
Figure 1. A snapshot of SwiftUI code demonstrating the use of navigation bars and buttons, as compared to UIKit

Examples

Let’s examine a few examples to illustrate the differences between UIKit and SwiftUI in action.

Creating a button

In UIKit, creating a simple button involves several steps, including initialising a UIButton object, setting its properties (such as title, colour, and font), and adding it to the view hierarchy using addSubview(). Any updates or changes to the button’s appearance or behaviour require manual adjustments to its properties and event handling using addTarget().

SwiftUI, on the other hand, takes a much simpler approach. To create a button, you simply use the Button view and specify its label text. SwiftUI takes care of the rest, including handling the button’s appearance and actions. For example:

Differences of button configuration in UIKit and SwiftUI.
Figure 2. A side-by-side comparison of button configuration in UIKit and SwiftUI.

Conditional visibility

When dealing with conditional visibility of views, UIKit requires you to manually show/hide views based on conditions, often involving complex logic and maintaining multiple outlets or references to views.

SwiftUI simplifies this process with its declarative nature. To conditionally show a view, you can use the if statement directly in SwiftUI. Here’s an example where a view is only displayed when a certain condition is met:

Differences in conditional visibility in UIKit and SwiftUI.
Figure 3. A side-by-side comparison of conditional visibility in UIKit and SwiftUI.

Handling lists

Working with lists in UIKit often involves implementing a UITableViewDataSource and a UITableViewDelegate to manage the data and appearance of cells. This requires managing data sources, registering cells, and handling updates explicitly.

SwiftUI simplifies the handling of lists with its own List view. To render a list of items, you simply pass an array of items and a closure that describes how to render each item:

Differences in list handling in UIKit and SwiftUI.
Figure 4. A side-by-side comparison of list handling in UIKit and SwiftUI.

These examples highlight how SwiftUI’s declarative paradigm greatly simplifies the code and makes iOS development more intuitive and efficient compared to UIKit’s imperative approach.

Pros and cons of SwiftUI

Pros of SwiftUI

  • Declarative syntax: SwiftUI’s declarative syntax simplifies UI development, making it easier to learn and understand for both new and experienced developers.
  • Swift integration: SwiftUI is designed specifically for Swift, leveraging its powerful features and type safety, resulting in more robust code.
  • Live preview: The live preview feature allows developers to see immediate results as they make changes to the UI, resulting in faster development iterations.
  • Platform adaptability: SwiftUI code can target multiple Apple platforms (iOS, macOS, watchOS and tvOS) with minimal modification, encouraging code reuse.
  • Animation support: SwiftUI provides built-in support for animation, making it easy to create visually appealing user interfaces.

Cons of SwiftUI

  • iOS version limitation: SwiftUI is available for iOS 13 and above, which means it may not be suitable for projects that require support for older iOS versions.
  • Learning curve: While SwiftUI is relatively easy for developers familiar with Swift and declarative programming to grasp, it may take some time for developers accustomed to UIKit’s imperative style.
  • Limited support for third-party libraries: Because SwiftUI is a relatively new framework, it may have fewer third-party libraries and resources than UIKit.

Conclusion

SwiftUI’s adoption of the declarative programming paradigm has revolutionised iOS application development. Its simpler and more expressive syntax, with live preview, allows developers to create robust and visually stunning user interfaces more efficiently. While UIKit has served the iOS community well for many years, SwiftUI represents the future of iOS programming. As the framework continues to mature and gain popularity, developers can expect further enhancements and improvements that will solidify its position as the first choice for creating user interfaces in the Apple ecosystem.