From bug fixes to new features, firmware updates are essential for a device’s evolution. Here’s how to build a reliable update system that keeps your embedded IoT devices running smoothly in the field.

Updating firmware is a critical component in the lifecycle of any embedded IoT device. It provides flexibility during development, but also simplifies support and enables long-term feature evolution. In essence, firmware updates allow these devices to modify their current operational software to fix bugs, improve performance, or introduce new capabilities – like supporting machine learning models that optimize business processes using real-time IoT inputs.

Think of firmware as a program on a computer or a smartphone – except it’s designed specifically to run on embedded systems. Firmware updates can be performed wirelessly when a device is connected via Bluetooth or WiFi. This method is known as an Over-the-Air (OTA) update, or more specifically, Firmware Over-the-Air (FOTA), highlighting its remote and seamless execution.

While beneficial, firmware updates can also impose certain risks. If the update contains a bug, or worse, malicious code, it may cause problems with the device:

It is crucial to approach firmware updates with caution and ensure proper implementation. Otherwise, a poorly executed update might create more problems than it aims to solve.

Enabling firmware updates on a device requires certain memory compromises. The device’s non-volatile memory (Flash memory) should be partitioned into three sections:

The bootloader section can be just large enough to fit the bootloader, while the sections for the current firmware and the update must be equal in size and large enough to store the device firmware. 

To partition the Flash memory properly, a linker script should be used to ensure that the linker does not store parts of the code in the bootloader or update the firmware sections. Additionally, the application code should be compiled to execute from the start of the current firmware section to ensure correct jump addresses when running.

A bootloader is essential for enabling firmware updates on the device. Its primary functions include optional firmware verification, installing new firmware, and jumping to the start of the application code. The firmware verification can be done either in the application code before entering the bootloader or within the bootloader itself. When the device boots, it always goes into the bootloader first.

The bootloader then checks if there is new firmware to install: if so, it performs the installation and eventually jumps to the start of the application code. Different methods can be used to notify the bootloader that new firmware is available, such as reading a specific Flash memory address set by the application after downloading the firmware.

Firmware updates involve several key steps:

There are two ways to initiate a firmware update: automatically and manually. The choice of how to start the update depends on the use case and the device’s connectivity capabilities, which can vary significantly in the IoT space.

With automatic updates, the device takes charge of connecting to the server, checking for new firmware, and initiating the update. Users don’t have direct control over starting the update process. 

This approach is suitable for devices with continuous or intermittent connectivity or those with unstable connections. All that’s needed is to release the firmware update on the server. The device can be configured to start the update based on certain conditions, such as a specific time of day or reaching a particular state.

For a manual update, the user must trigger the firmware update process – highlighting the importance of designing clear, user-friendly interactions in IoT interfaces. This can be done in various ways. It could be initiated by the device itself, using some form of user input available. Alternatively, another device could be used to start the update, or an external device might be employed to initiate the process. This type of update works for all types of devices, regardless of their connectivity, ranging from always connected to never connected.

Manual updates require user intervention to start the firmware update process. There are several ways to initiate this process:

The advantage of manual updates is their versatility – they work with all types of devices regardless of connectivity status, from always-online devices to those with no regular network connection.

Devices that are only connected on demand can be updated through Bluetooth connectivity solely for firmware updates. In this scenario, the device advertises itself and waits for a connection. The user can connect the device to a smartphone via Bluetooth, download the firmware update file to the smartphone, and then transfer it to the device to start the update.

Non-connected devices can also be updated manually using wired protocols like UART or CAN, or external storage devices like an SD card. The device can have a specific user input that triggers the firmware reception from the UART, SD card, or other wired protocol. If using UART, CAN, or any other wired protocol, there must be an external device to communicate with the main device being updated and to contain the firmware file.

Security is enforced primarily during the firmware validation step. The main goal is to ensure the received firmware is legitimate and free from tampering. Several essential steps fall under this category, including integrity checks, firmware decryption, and firmware signing checks. Some of these operations may involve asymmetric encryption, with the keys needing to be securely stored in encrypted Flash memory or protected against unauthorized access.

When both firmware encryption and firmware signing are in place, the following keys are typically found on the device:

The integrity check step ensures that the received firmware is error-free during communication, detecting potential issues like bit-flips. The device calculates the hash of the received firmware using methods like md5, and compares it with the hash received along with the firmware. A match indicates that the received firmware is intact and uncorrupted, allowing the device to proceed to the next validation step. This step is crucial for preventing the installation of corrupted firmware that might lead to unexpected behavior.

Firmware encryption is the process of encoding the firmware information to prevent unauthorized access to its content. When encrypting the firmware, the device’s public key is utilized. Upon receiving the firmware, the device uses its private key to decrypt the firmware for further processing.

Firmware signing involves encrypting the firmware with the manufacturer’s private key, which confirms that the firmware comes from the manufacturer. However, it is not practical to encrypt the entire firmware with the private key. Instead, only the firmware hash is encrypted, and cryptographic hash functions like SHA-256 are commonly employed for this purpose. This way, the device can validate the authenticity of the firmware by decrypting the hash using the manufacturer’s public key.

As technology advances, digital services constantly evolve. With the continuous introduction of new products featuring the latest technologies and improved features, you can enhance your existing devices by simply updating their firmware, enabling your older hardware to keep up with the latest capabilities.

This article is adapted from our Guide to Successful IoT Implementation, where we cover the technical foundations and strategic considerations behind building modern IoT solutions. For more insights, download the full guide.

WWDC 2025 didn’t bring the loudest fireworks in AI. But make no mistake: Apple just pulled a strategic move that every product leader should pay attention to.

While headlines are locked on GPT-4o, Gemini 1.5, and the escalating cloud model race, Apple is taking a different route — one that’s deeply integrated, privacy-centric, and highly relevant for anyone building digital products inside its ecosystem.

The star of this shift? Apple’s new Foundation Models Framework.

At its core, Apple’s Foundation Models Framework gives third-party iOS developers access to Apple’s own generative AI models directly on-device.

Here are some of the key specs:

Apple isn’t competing directly with GPT-4 or Claude here. Instead, it’s delivering a highly optimized model specifically designed for real-world iPhone and iPad apps. The developer tooling is where things get especially interesting because Apple is making AI integration far more predictable and production-ready than many off-the-shelf open-source models.

Put simply: Apple isn’t just delivering a model — it’s delivering an entire AI operating layer baked into iOS.

For full technical details, Apple’s official WWDC 2025 developer documentation is a must-read.

On-device AI isn’t exactly new as a concept. But Apple just made it radically easier to adopt.

Think back to when apps first got access to cameras, GPS, or push notifications. Foundation Models mark a similar inflection point. Developers now get direct access to powerful generative AI inside the iPhone’s operating system, without the need for complicated APIs, server costs, or compliance headaches.

In effect, Apple is turning every iPhone into a personal AI computer.

Data never leaves the device. For product teams building in highly regulated sectors like finance, healthcare, and enterprise SaaS, this is a major advantage. You can now build AI-powered features that analyze personal or sensitive data while keeping everything securely on-device.

While many teams are willing to invest heavily in AI innovation, the long-term economics of AI operations can still influence product roadmaps. With Foundation Models running on-device, teams avoid paying ongoing fees for third-party APIs, cloud infrastructure, or dedicated inference servers. AI capabilities become part of the app itself, simplifying budgeting and allowing companies to scale features to larger user bases without costs ballooning unpredictably over time.

Since models run directly on the device, AI features become instantly responsive. There are no network delays, no dependency on server round-trips, and full functionality even when users are offline. Whether someone is flying, commuting underground, or traveling through areas with poor connectivity, the experience remains smooth and fully available. For many apps, this level of instant responsiveness doesn’t just improve UX — it unlocks entirely new product possibilities where speed and privacy are non-negotiable.

There’s a couple of months before iOS 26 becomes publicly available, so the real-world applications for Apple’s Foundation Models are yet to materialize. In theory, these opportunities cut across multiple industries, each with their own relevant on-device AI use cases. Let’s break it down:

For developers already experimenting, some early success stories have surfaced on Reddit’s iOSProgramming forum.

Apple’s approach comes with some trade-offs that product leaders need to navigate carefully.

Apple’s approach comes with some trade-offs that product leaders need to navigate carefully.

In short, this works brilliantly for many domain-specific or app-specific tasks but isn’t intended to replace cloud-based LLMs entirely.

At Infinum, we see this as one of the most important updates for mobile product development in recent years.

Why? Because this isn’t just about adding AI as a feature. It’s about creating differentiated experiences that competitors can’t easily replicate, building trust with privacy-conscious users and enterprise clients, and controlling costs while still delivering highly sophisticated features.

This levels the playing field: you don’t need to be an AI research lab to build intelligent apps. But you do need strategic product expertise, domain-specific prompt engineering, and deep knowledge of Apple’s AI stack.

Apple devices are becoming exponentially more powerful by the year. With each hardware leap, Apple’s AI capabilities are maturing as well. So you can safely expect this quiet revolution to accelerate.

Users will increasingly expect AI assistance as a standard part of their apps, much like they expect biometric logins or dark mode today.

For product leaders, the smartest move right now is to experiment early, build prototypes, and assess where on-device AI can create meaningful value.

If you’re thinking about how to bring AI features to your iOS product roadmap — while staying cost-efficient, privacy-compliant, and future-proof — this is exactly the right moment to start that conversation. 

Interested in utilizing Apple’s new AI model but not sure where to start? This is where Infinum can add real value: advisory, rapid prototyping, and hands-on expertise across AI/ML & mobile.

For those who want to dive even deeper, Apple’s own Machine Learning Research blog offers technical insights into how these models were designed.

Ruby on Rails used to be the hot band everyone wanted to see live. Now it feels more like a cult classic, still good, still playing, but to a smaller, more devoted crowd. And lately, some folks are wondering: is Rails on the path to becoming the next COBOL?

Yes, that COBOL. The 65-year-old language quietly running billions of lines of code inside banks, governments, and systems nobody wants to touch but everybody needs. On paper, the comparison seems extreme. But look closer, and you’ll start to see the shape of a long tail forming behind Rails. One that looks suspiciously like legacy.

Let’s dig in.

COBOL and Ruby on Rails couldn’t be more different in syntax, style, or era. They definitely share one thing though: both were once the default choice for a generation of developers.

COBOL, born in 1959, became the backbone of enterprise and government systems by the ’70s. If you’ve ever withdrawn cash, paid taxes, or waited for a check to clear, COBOL probably had something to do with it. Its dominance was complete, and it stuck — not because developers loved it, but because rewriting working software is expensive, risky, and often unnecessary.

Fast forward to the 2000s. Enter Rails: elegant, opinionated, and built for speed. DHH dropped convention over configuration like a mic, and the web dev world listened.

From 2005 to 2014, Rails was the framework of choice for startups, SaaS tools, and hacker weekends. Twitter, GitHub, Shopify, and Basecamp all bet big on it. For a while, every bootcamp taught it, every founder loved it, and every developer blog had a hot take on ActiveRecord callbacks.

It was a golden era. Until it wasn’t.

Spoiler alert: not like it used to.

Once the backbone of every hot startup stack, Rails has quietly slipped from the spotlight over the past decade. While direct stats about framework usage can be hard to pin down, Ruby’s trajectory helps illustrate the shift. GitHub’s Octoverse reports show Ruby falling from #5 (2014) to #10 (2022) in language rankings. The TIOBE Index recently pushed it to 24th, with its CEO bluntly suggesting Ruby is “likely to go out of fashion.” Ouch.

Community chatter reflects the mood. “Rails is just not what it once was,” wrote one long-time Redditor. “The amount of jobs are way down and the pay is too.” Another chimed in: “It’s not COBOL — nothing that critical was written in it. Rails will eventually die.”

But not everyone’s buying the obituary. Rails defenders argue it’s simply matured. It might no longer be trendy, but it’s still incredibly efficient. It does what it promises. It allows small teams to build and ship real products fast, without the overhead of piecing together half a dozen libraries. In an era where VC money is drying up and lean teams are the norm, that’s a value prop worth paying attention to.

We see this play out with companies we work with, many of which are organizations that run massive products on large Rails codebases. One client, with a market cap north of $2 billion, has definitely felt the pull to rebuild in something “modern.” But when it comes to cost and risk, the appeal fades fast. Some functionality is being moved to other stacks where it makes sense, but the core will likely stay on Rails for years. There’s simply no silver bullet waiting on the other side.

To understand where Rails might be headed, it’s worth studying COBOL’s fate.

COBOL hasn’t been hot in decades, yet as of 2017, 220 billion lines of it still powered key systems. Some estimates say 43% of banking platforms and 95% of ATM swipes involve COBOL code. Why? Because rewriting complex financial logic that’s business-critical (and often undocumented) is risky and expensive.

The kicker? Most COBOL developers are nearing retirement. In 2020, some U.S. states literally had to beg for COBOL engineers to fix outdated unemployment systems. And those engineers? They’re making bank.

COBOL is a classic case of technological inertia. As a consequence, it’s created a niche economy where a small number of specialists quietly hold the keys to critical systems. And they command serious salaries for doing so.

Just to be clear: Rails isn’t COBOL. But the trajectory? It rhymes.

Many foundational platforms still run on Rails. Shopify’s massive monolith? Rails. GitHub? Rails. Basecamp? Rails, obviously. These companies aren’t rushing to rewrite their cores in Elixir or Go. Instead, they’re optimizing what works — and contributing back to the Rails ecosystem in the process.

Rails roles are also becoming more specialized. Junior opportunities are scarcer; most open positions are for mid-to-senior engineers with years of experience. But those who are experienced? They’re doing just fine. Stack Overflow’s 2023 survey ranked Ruby as the 4th highest-paying tech globally. Senior Rails engineers in the U.S. regularly clear six figures.

This is where the COBOL parallel kicks in: high compensation, low visibility, and a shrinking pipeline of new devs.

Let’s kill the idea that Rails is frozen in time. It’s not.

Both Rails 7 and 8 are pushing forward with features that sidestep frontend fatigue. Hotwire, Turbo, and Stimulus let you build snappy UIs without reaching for React or Vue. Want realtime updates without drowning in JavaScript? Rails has that baked in.

On the backend, Ruby is still evolving. Turning 30 next year, it’s the same age as JavaScript, and it remains in active development. The Ruby 3×3 initiative, launched back in 2015, committed to making Ruby 3 three times faster than Ruby 2. That milestone was reached in 2020, and the momentum hasn’t stopped. Recent versions continue to bring performance gains through JIT compilers like YJIT and RJIT, as well as improvements to memory efficiency and startup times.

Rails 8 builds on this foundation. It is the version of Rails that remembers why people fell in love with it in the first place: fast setup, clear conventions, and a full-stack story that doesn’t require Kubernetes on day one. It even introduces “Solid Queue” for background jobs — no Redis, no drama.

And beyond the tooling, there’s still joy in writing Rails. As DHH recently pointed out in his post Coding should be a vibe!:

If developers are racing to offload coding to AI, maybe the problem lies in the stack itself.

Rails and Ruby offer a different path. It’s one that doesn’t require hiding the mess. Instead, they strip away unnecessary layers and let you build fast, clean, and human-readable code from day one. In that world, simplicity and elegance aren’t limitations. They’re advantages.

That’s also why we don’t skip upgrades. All of our active projects are already on Rails 7, and a couple have already adopted Rails 8. We use Hotwire and Turbo where it makes sense. Not because it’s fashionable, but because it solves real problems. Staying current gives us access to the latest features, but more importantly, it keeps our clients’ products secure.

So, is Rails becoming the boutique skillset for aging SaaS platforms?

Maybe. And that’s not a bad thing.

Rails still excels at building internal tools, MVPs, and stable CRUD-heavy platforms — especially for teams that value clarity over cleverness. Its “boring is good” philosophy is a feature, not a bug.

The community remains active, too. The main Rails repo has seen over 6,500 commits and 1,500 issues closed in the past year. RailsConf draws a mix of grizzled veterans and Hotwire-happy newbies. Tools like StimulusReflex and view components show there’s still innovation happening, just at a more grounded pace.

The language and framework remain deeply aligned around developer happiness and productivity. Drastic deviations are unlikely to succeed, because what’s here doesn’t just work, it works very well. Newer languages and frameworks have their place, but Rails wasn’t built for the same constraints or audiences.

Rails isn’t a zombie. It’s simply not chasing trends anymore. It’s found its lane, and for the right teams, it’s still a dream to work with.

Ruby on Rails isn’t dying. It’s aging into its next role. Think less rockstar, more session musician. Still sharp, still useful, still quietly keeping the show running.

It might not be the framework new grads rush to learn, and it might not top the charts anymore. But for many companies, Rails is still a pragmatic choice. It delivers. It scales (when engineered well). And in a tech world increasingly obsessed with complexity, Rails dares to stay simple.

Smart engineering teams are well-aware: smart, stable software never goes out of style. So maybe, in 10 years, we’ll talk about Rails the same way we talk about COBOL: a relic, yes — but a reliable one. And in the end, reliability is underrated.

At Infinum, we’re here for both sides of the Rails story. Both if you’re looking to extend the life of a legacy system, or weighing Rails against shinier options for a new build. Check out our Rails Maintenance & Support services if your app needs some love (or a performance tune-up), or reach out if you’re on the fence about which tech stack fits your product best.

With automation tools like Playwright, testing web accessibility doesn’t have to be tedious or time-consuming. Learn how to speed up your accessibility checks using Playwright and axe-core, and simplify the path to building more inclusive digital products.

Ensuring your web page is accessible to all users is becoming increasingly important for businesses. With regulatory pressures mounting and public awareness rising, brands and companies are looking to optimize their digital products to meet accessibility standards.

However, testing a web page for accessibility is a nuanced task, and certain aspects of it can be particularly time-consuming. Fortunately, there are a number of tools available to help testers check web accessibility thoroughly and efficiently, especially by leveraging test automation.

Not every team has the resources or bandwidth to build custom tools, but existing solutions can already achieve a great deal. In this article, we’ll explain how to conduct accessibility testing using Playwright, a very popular tool in the testing community. With just a few simple adjustments, Playwright can significantly speed up and enhance the efficiency of your testing process. 

A significant portion of the population faces challenges when accessing digital resources due to physical, cognitive, and sensory impairments. According to the World Health Organization, approximately 16% of the global population experiences significant disabilities.

If your app or website isn’t built with accessibility in mind, you risk excluding a considerable number of users – not only those with permanent disabilities but also individuals experiencing temporary or situational impairments, such as a broken arm or navigating a digital product in a noisy environment. Accessibility standards ultimately improve the user experience for everyone. 

Beyond ethical considerations, accessibility is increasingly becoming a legal necessity. In the United States, the Americans with Disabilities Act mandates that public accommodations, including websites, must be accessible to individuals with disabilities. Similarly, the European Union’s European Accessibility Act and the Web Accessibility Directive establish clear guidelines for digital accessibility. Non-compliance can lead to significant legal consequences, including lawsuits, fines, and reputational harm.

Accessibility testing is the process of identifying barriers that may prevent users from fully interacting with a website or service. It ensures that people with disabilities can access and navigate the content just as easily as anyone else.

The testing is usually conducted through a combination of automated and manual accessibility checks. It evaluates several aspects, including visual design, interactive elements, content structure, navigation, and multimedia components.

Accessibility testing can be automated to a certain extent. Automation tools can help us identify many common accessibility issues and provide reports that highlight areas needing improvement. These tools can check for issues like missing alt text, poor color contrast, improper heading structures, and missing ARIA attributes – areas frequently overlooked during development. 

However, automated tools are limited to verifying basic accessibility compliance and cannot evaluate how intuitive or user-friendly an interface is. Human testing remains vital for uncovering issues such as confusing navigation, unintuitive layouts, or frustrating interactions, which are all essential if we want to ensure a truly inclusive user experience.

Playwright is an excellent starting point for teams interested in accessibility test automation. It is a widely used, open-source framework known for its ease of setup and strong community support. More importantly, it offers integration with axe-core, a powerful accessibility testing library created by Deque Systems. Axe-core helps testers efficiently detect violations of accessibility standards, such as the Web Content Accessibility Guidelines (WCAG), and provides insights on fixing any issues found.

Playwright and axe-core are a powerful combo – one that helps testers streamline accessibility checks, improving both efficiency and accuracy in their testing processes.

We’ll start by installing Playwright using npm.

You’ll be prompted to answer a few setup questions – feel free to go with the default options. TypeScript should be selected by default, but double-check that it is.

For full installation details, check the official Playwright documentation.

Next, add the additional packages needed for this implementation:

Then, import the necessary modules in your test file:

Now, let’s walk through a practical example using todoMVC. To inspect a page for accessibility issues, we’ll use AxeBuilder from the axe-core/playwright package.  The command new AxeBuilder({ page }).analyze() tells Axe to scan the current page and identify any violations according to established standards, and the results are stored in the accessibilityScanResults variable.

To focus the analysis on specific standards, you can refine the accessibility scan by using the withTags() method. For example, if you’re targeting the most common WCAG compliance levels (WCAG 2.0 and WCAG 2.1, levels A and AA), you can do so as follows:

After performing the scan, we need to verify whether any accessibility violations have occurred. You can achieve this by asserting that the violations array within the results is empty. If any violations are found, your test will fail, prompting you to address the identified issues:

To generate a readable summary of the accessibility scan, we’ll use the createHtmlReport function from the axe-html-reporter package. This function takes in the scan results  we previously stored in accessibilityScanResults. We can also use options to configure the report name and output directory.

Note that createHtmlReport returns an HTML string – it doesn’t create a file by itself. To write the report to disk, we’ll use Node’s fs module:

Testing a single page is a good start, but broader coverage requires more. Let’s modify our test to run against multiple pages by creating an array of objects containing URL/name pairs. The URL field tells Playwright which page to check, and the name field isn’t required, but helps us generate more descriptive report names:

Next, we’ll loop through each URL in our test using forEach:

This setup generates a separate, clearly labeled report for each tested page.

Swift is modern, powerful, and versatile – but real-time coding can get tricky. Meet RTSanStandaloneSwift, our new Swift wrapper around LLVM’s RealtimeSanitizer, designed to help you write safe and effective real-time code.

Developing robust real-time systems brings a unique set of challenges. Real-time code must not only be logically correct but also execute within strict time constraints. Failing to meet these deadlines can lead to system failures, which means that thorough debugging and validation of real-time safety are absolutely essential. 

To simplify this intricate process, LLVM 20 introduces RealtimeSanitizer – a runtime analysis tool designed to detect operations that violate real-time constraints. While RealtimeSanitizer is initially available in the Clang compiler, its foundations are built within LLVM, allowing for broader language adoption. This has already been demonstrated with the Rust wrapper.

Over the past several months, we’ve collaborated with Chris Apple and David Trevelyan, creators of RealtimeSanitizer, to bring this powerful capability to Swift. Today, we’re excited to introduce RTSanStandaloneSwift – a Swift wrapper around RealtimeSanitizer that will enable Swift developers to build and maintain real-time applications more easily.

C and C++ have long dominated real-time development due to their predictable performance and low-level control.

Swift, on the other hand, is a modern, fast, and memory-safe language that is interoperable with C++ and has cross-platform support, making it an attractive option for a wide range of applications. 

While Swift has already demonstrated its capability as a real-time programming language, its high-level nature can make it challenging to reason about strict execution time requirements.

Let’s examine a simple Swift implementation of an audio processor:

Although this example resembles a straightforward C-style loop, it contains several potential pitfalls for real-time performance:

Having a tool that can help us detect these issues would be invaluable.

Similar to AddressSanitizer, RealtimeSanitizer works by intercepting “interesting” functions – in this context, those that could violate realtime-safety guarantees. Typically, these functions involve locks, memory allocation or I/O operations.

For a full list of intercepted functions, check out the implementation details.

In C++ (Clang), real-time sanitizer is activated by annotating a function with the [[clang:nonblocking]] attribute. When such a function invokes a real-time unsafe operation, the sanitizer aborts the process and provides a stack trace for debugging purposes.

RealtimeSanitizer also includes a suite of C functions that give developers fine-grained control over its behaviour.

Leveraging Swift’s interoperability with C, we can invoke RealtimeSanitizer’s C bindings and create a more convenient Swift API.

RTSanStandaloneSwift is a lightweight implementation that introduces a user-friendly Swift macro for annotating functions that are subject to real-time constraints.

Similar to the [[clang:nonblocking]] attribute in C++, RTSanStandaloneSwift provides the @NonBlocking macro in Swift.

For example, we can annotate our earlier process function like this:

Now, when we run this code, RealtimeSanitizer will automatically detect and report any real-time violations:

In this particular example, RealtimeSanitizer detected a lock within the Swift runtime triggered by the copy-on-write behavior during array mutation.

We consider the current version of RTSanStandaloneSwift a transitional solution, and plan further improvements in the next stages:

Currently, RTSanStandaloneSwift ships with a prebuilt version of the RealtimeSanitizer dynamic library. While this approach is functional, it is not ideal in the long term. 

LLVM 20 is officially out, so when the first Swift nightly toolchains targeting LLVM 20 become available, we plan to phase out the prebuilt versions of the RealtimeSanitizer dynamic library. At that point, RTSanStandaloneSwift will rely entirely on the RealtimeSanitizer functionality provided directly in the toolchain.

Ultimately, our goal is to make a pitch for adding the attributes and the sanitizer as first-class features natively integrated into Swift.

RTSanStandaloneSwift marks a significant milestone for real-time programming in Swift, enabling Swift developers to more easily write predictable and safe real-time code.

We’d love you to try it out, share your feedback and contribute to its ongoing development.

Kotlin Multiplatform lets you share core business logic while still taking full advantage of native UI components. We explore practical approaches to integrating Kotlin Compose with iOS frameworks like UIKit and SwiftUI.

Mobile developers often face the challenge of balancing consistent business logic with the unique demands of each platform’s user interface. Kotlin Multiplatform (KMP) is a great choice for tackling this, allowing developers to write shared business logic while retaining platform-specific flexibility. 

When it comes to integrating UI frameworks like Compose with native iOS components (e.g., SwiftUI or UIKit), KMP offers multiple approaches tailored to various use cases. This article discusses the core expect/actual pattern – the foundation of KMP’s platform-specific customizations – and presents two additional strategies: using UIViewControllerRepresentable to integrate SwiftUI and directly accessing iOS native APIs through platform.UIKit.

The expect/actual pattern is the cornerstone of Kotlin Multiplatform development. It enables developers to define shared abstractions (expect) and provide platform-specific implementations (actual). This approach is particularly useful when you want to share as much logic as possible while accommodating platform-specific details, including UI components.

This pattern ensures:

While powerful, this pattern primarily handles business logic or modular UI components. More specialized use cases, such as embedding SwiftUI views or accessing native APIs directly, will require additional techniques.

For developers requiring granular control over native iOS functionalities, directly accessing APIs via platform.UIKit is a powerful alternative. This method uses UIKit directly, allowing you to manipulate UIKit components and system APIs directly in Kotlin.

Again, we’ll start with the first dialog example.

When dealing with existing SwiftUI components, the UIViewControllerRepresentable approach is invaluable. It wraps a SwiftUI view in a UIViewController that Kotlin Compose can embed. This is ideal for scenarios where SwiftUI views need to coexist with Compose.

The interoperability between Kotlin Compose and iOS frameworks offers a wide range of possibilities, each with its strengths:

Choosing the right approach depends on your project’s goals and constraints. Thanks to Kotlin Multiplatform adaptability, developers are not tied to a single solution but can leverage the best of both Compose and native frameworks to build robust, flexible, and maintainable applications.