Uncategorized

Introduction

As a developer who has built a released application in Flutter, I’ve recently started exploring Kotlin Multiplatform (KMP) for a new project. After building codefrog.app – a macOS developer tool in Flutter – I’ve been evaluating KMP for similar functionality. Even in the early stages, the differences in how these frameworks handle asynchronous programming are immediately apparent. This article explores why KMP’s async programming model appears superior, especially for native platform integration.

The Core Difference: Coroutines vs Isolates

Flutter’s Isolate Model

Flutter uses Isolates for concurrent execution. Isolates are separate memory spaces that communicate via message passing – essentially separate processes that can’t share memory.

// Flutter isolate example
import 'dart:isolate';

void isolateFunction(SendPort sendPort) {
  // Heavy computation
  sendPort.send(result);
}

void main() async {
  ReceivePort receivePort = ReceivePort();
  await Isolate.spawn(isolateFunction, receivePort.sendPort);
  var result = await receivePort.first;
}

Key Limitations:

1. No Shared Memory: Isolates can’t share objects – everything must be serialized
2. Message Passing Overhead: All communication requires serialization/deserialization
3. Platform API Restrictions: Isolates can’t directly access many platform APIs
4. Complex State Management: Sharing state between isolates requires explicit message passing

KMP’s Coroutine Model

KMP uses Kotlin Coroutines – lightweight threads that can suspend and resume without blocking.

// KMP coroutine example
suspend fun fetchData(): Data {
    return withContext(Dispatchers.IO) {
        // Network call - suspends, doesn't block
        api.getData()
    }
}

// Usage
viewModelScope.launch {
    val data = fetchData() // Seamless async/await
    updateUI(data)
}

Key Advantages:

1. Shared Memory: Coroutines share the same memory space
2. Zero Serialization Overhead: Direct object access
3. Full Platform API Access: Can call any platform API directly
4. Structured Concurrency: Automatic cancellation and resource management

The Secure Storage Problem

Flutter’s Isolate Limitation

While building codefrog.app, I discovered that isolates cannot access secure storage APIs on macOS. This became a significant issue when porting to Windows, where the app would hang – a problem that doesn’t occur on macOS. I’m still working through the multithreading issues on Windows, which has proven to be very time-consuming.

// This DOESN'T work in an isolate
import 'package:flutter_secure_storage/flutter_secure_storage.dart';

void isolateFunction() {
  final storage = FlutterSecureStorage();
  // ❌ CRASHES: Secure storage requires main isolate
  await storage.write(key: 'token', value: 'secret');
}

Why This Happens:

• macOS Keychain access requires the main thread/isolate
• Isolates run in separate processes without proper entitlements
• Secure storage plugins are designed for the main isolate only
• Workarounds require complex message passing back to main isolate

I discocered the macOS app had no problems doing everything on the main thread not using isoaltes, but when trying to port to Windows it hung, meaning I would have to use isolates on Windows in order to release a Windows Version using Flutter.

KMP’s Seamless Access

In KMP, coroutines can access secure storage directly because they share the same memory space and thread context.

// This WORKS perfectly in a coroutine
suspend fun saveCredentials(token: String) {
    withContext(Dispatchers.Main) {
        // Direct Keychain access - no restrictions
        keychain.save("token", token)
    }
}

// Can be called from any coroutine
viewModelScope.launch {
    saveCredentials("secret") // Works everywhere!
}

Why This Works:

• Coroutines can switch dispatchers (threads) seamlessly
• Dispatchers.Main gives access to UI and platform APIs
• No serialization needed – direct object access
• Full platform entitlements and permissions

macOS Sandbox Restrictions

Flutter’s Sandbox Challenges

macOS sandboxed apps have strict security requirements. Flutter isolates face additional challenges:

// Sandboxed app trying to access file system from isolate
void isolateFunction() async {
  // ❌ May fail: Isolates don't inherit sandbox entitlements properly
  final file = File('/path/to/file');
  await file.writeAsString('data');
}

Issues:

1. Entitlement Inheritance: Isolates may not properly inherit app entitlements
2. File System Access: Sandbox file access can be restricted in isolates
3. Network Permissions: Some network operations require main isolate
4. User Permissions: System dialogs (file picker, etc.) must be on main isolate

KMP’s Native Integration

KMP coroutines work seamlessly with macOS sandboxing:

// Direct platform API access with proper sandbox support
suspend fun saveFile(data: String) {
    withContext(Dispatchers.Main) {
        // Full sandbox support - uses app's entitlements
        val panel = NSSavePanel()
        if (panel.runModal() == .OK) {
            data.writeToFile(panel.url.path)
        }
    }
}

Advantages:

• Coroutines use the app’s main thread context
• All entitlements and permissions are inherited
• Direct access to NSFileManager, Keychain, etc.
• No workarounds needed

Window Management: A Performance Nightmare

Flutter’s Engine-Per-Window Model

One of the most painful experiences building codefrog.app was implementing File → New Window. Flutter’s architecture requires a separate engine instance for each window.

// Flutter: Creating a new window
void createNewWindow() {
  // ❌ Must create entire new Flutter engine
  final engine = FlutterEngine();
  await engine.run(); // Expensive initialization
  
  // ❌ Black screen while engine initializes (1-2 seconds)
  final window = await engine.createWindow();
  
  // ❌ Each window has separate memory footprint
  // ❌ No shared state between windows
}

Problems:

1. Engine Initialization: Each window requires full Flutter engine startup (1-2 seconds)
2. Black Screen: Visible delay before content appears
3. Memory Overhead: Each engine instance consumes significant memory
4. State Isolation: Windows can’t easily share state
5. Complex Implementation: Requires platform channel setup for each window

Real Experience from codefrog.app:

• New windows took 1-2 seconds to appear
• Black screen was visible to users (poor UX)
• Memory usage increased linearly with window count
• Had to implement complex state synchronization between windows
• File menu → New Window required significant platform channel work

KMP’s Native Window Management

In KMP with SwiftUI, window creation is trivial and instant:

// KMP/SwiftUI: Creating a new window
func openNewWindow() {
    let window = NSWindow(
        contentRect: NSRect(x: 0, y: 0, width: 800, height: 600),
        styleMask: [.titled, .closable, .resizable],
        backing: .buffered,
        defer: false
    )
    
    window.contentView = NSHostingView(rootView: ContentView())
    window.makeKeyAndOrderFront(nil)
    // ✅ Instant - no engine initialization
    // ✅ No black screen
    // ✅ Shared framework instance
}

Advantages:

1. Instant Creation: Windows appear immediately (milliseconds)
2. No Black Screen: Content is ready before window appears
3. Shared Framework: KMP framework is loaded once, shared across windows
4. Native Performance: Uses platform-native windowing APIs
5. Simple Implementation: ~10 lines of code vs. hundreds in Flutter

Real Experience:

• New windows appear instantly
• No visible delay or black screen
• Memory overhead is minimal (shared framework)
• State can be easily shared via shared ViewModels
• File menu → New Window: 5 minutes to implement vs. hours in Flutter

Async Programming Comparison

Flutter: Futures and Streams

Flutter uses Dart’s Future and Stream for async operations:

// Flutter async
Future<List<Data>> fetchData() async {
  final response = await http.get(url);
  return parseData(response.body);
}

// Stream for reactive updates
Stream<Progress> generateProgress() async* {
  yield Progress.started;
  await Future.delayed(Duration(seconds: 1));
  yield Progress.processing(50);
  yield Progress.completed;
}

Issues:

1. Isolate Restrictions: Can’t use platform APIs in isolates
2. Serialization Overhead: Passing data between isolates requires serialization
3. Complex Error Handling: Errors must be serialized across isolates
4. No Structured Concurrency: Manual cancellation and cleanup

KMP: Coroutines and Flow

KMP uses Kotlin Coroutines and Flow:

// KMP async
suspend fun fetchData(): List<Data> {
    return withContext(Dispatchers.IO) {
        val response = client.get(url)
        parseData(response.body)
    }
}

// Flow for reactive updates
fun generateProgress(): Flow<Progress> = flow {
    emit(Progress.Started)
    delay(1000)
    emit(Progress.Processing(50))
    emit(Progress.Completed)
}

Advantages:

1. Full Platform Access: Can use any platform API from coroutines
2. Zero Serialization: Direct object access, no overhead
3. Structured Concurrency: Automatic cancellation and resource management
4. Seamless Bridging: Coroutines bridge to Swift async/await automatically

Performance Comparison

Memory Usage

Flutter:

• Each window: ~50-100MB (separate engine)
• Isolates: Additional memory per isolate
• Total for 3 windows: ~200-300MB

KMP:

• Shared framework: ~20-30MB (loaded once)
• Each window: ~5-10MB (just UI)
• Total for 3 windows: ~35-60MB

Window Creation Time

Flutter:

• Engine initialization: 1-2 seconds
• Black screen visible: Yes
• User-perceived delay: High

KMP:

• Window creation: <50ms
• Black screen visible: No
• User-perceived delay: None

Async Operation Overhead

Flutter:

• Isolate communication: Serialization overhead
• Message passing: ~1-5ms per message
• State synchronization: Complex and error-prone

KMP:

• Coroutine context switch: <1ms
• Direct memory access: Zero overhead
• State sharing: Native Swift/Kotlin objects

Real-World Use Case: codefrog.app

The Flutter Experience

Building codefrog.app in Flutter revealed several pain points:

1. Secure Storage: Isolates can’t access Keychain – had to use workarounds like SSH localhost for macOS sandbox builds (works fine on main thread)
2. New Windows: 1-2 second delay, black screen, poor UX
3. State Management: Complex synchronization between windows
4. Platform Integration: Limited by isolate restrictions
5. Performance: Higher memory usage, slower window creation
6. Windows Porting: App hangs on Windows due to multithreading issues – still working on this complex problem

Early KMP Exploration

While just getting started with KMP, the initial experience shows promise:

1. Secure Storage: Direct Keychain access appears straightforward, no workarounds needed
2. New Windows: Instant creation in initial testing, no delay, native feel
3. State Management: Shared ViewModels look simple and efficient
4. Platform Integration: Full access to all macOS APIs without restrictions
5. Performance: Lower memory footprint and faster operations in early benchmarks

Conclusion: Why KMP Appears Superior for Async Programming

Based on my experience building production apps in Flutter and early exploration of KMP, KMP’s async programming model appears significantly better for native platform integration:

Technical Superiority

1. Coroutines vs Isolates: Coroutines provide better performance, lower overhead, and full platform access
2. Memory Model: Shared memory eliminates serialization overhead
3. Platform Integration: Direct access to all platform APIs without restrictions
4. Structured Concurrency: Automatic resource management and cancellation

Developer Experience

1. Simplicity: Easier to reason about and debug
2. Performance: Faster operations, lower memory usage
3. Native Feel: Windows and UI feel truly native
4. Less Code: Simpler implementations for complex features

User Experience

1. Performance: Instant window creation, no delays
2. Responsiveness: Smooth async operations
3. Native Feel: Feels like a true macOS app
4. Reliability: Fewer edge cases and workarounds

When to Choose Each

Choose Flutter if:

• You need cross-platform mobile (iOS + Android) with web
• You’re building a consumer app with simple async needs
• You don’t need deep platform integration
• Your team is primarily Dart/Flutter developers

Choose KMP if:

• You need native desktop apps (macOS, Windows, Linux)
• You require deep platform integration (Keychain, file system, etc.)
• Performance and memory usage matter
• You want true native feel and behavior
• You’re building developer tools or professional software

Final Thoughts

As someone who has shipped production apps in Flutter and is now exploring KMP, KMP’s async programming model appears to be the clear winner for desktop applications requiring native platform integration. The coroutine model provides better performance, simpler code, and full platform access – things that Flutter’s isolate model simply cannot match.

For codefrog.app and similar developer tools, KMP’s advantages in window management, secure storage access, and overall performance make it an attractive choice. Based on early exploration, it seems the days of waiting 1-2 seconds for new windows and working around isolate limitations could be over.

I’m still in the early stages of my KMP journey, but the initial signs are very promising. The async programming model alone makes it worth serious consideration for any desktop application requiring deep platform integration.

---

This article is based on real-world experience building codefrog.app in Flutter and early exploration of Kotlin Multiplatform. Performance numbers and observations are from actual Flutter development and initial KMP testing.

Introduction

This article explores how to use Kotlin’s asynchronous programming features in Kotlin Multiplatform (KMP) applications. We’ll cover Coroutines, Flow, async/await, and how they bridge to Swift and other platforms. This guide is based on a real-world implementation in a slideshow generation app.

Table of Contents

1. Understanding Kotlin Coroutines
2. Suspend Functions and async/await
3. Kotlin Flow: Reactive Streams
4. Bridging to Swift
5. Practical Example: Slideshow Generation
6. Flow vs RxJava vs Swift AsyncSequence
7. Best Practices

---

Understanding Kotlin Coroutines

What are Coroutines?

Coroutines are Kotlin’s way of writing asynchronous, non-blocking code. Think of them as lightweight threads that can be suspended and resumed.

Key Concepts:

• Suspendable: Coroutines can pause execution without blocking a thread
• Structured Concurrency: Parent coroutines manage child coroutines
• Lightweight: Thousands of coroutines can run on a single thread

Basic Coroutine Example

import kotlinx.coroutines.*

// Launch a coroutine
fun main() = runBlocking {
    launch {
        delay(1000L) // Suspend for 1 second
        println("World!")
    }
    println("Hello,")
}
// Output: Hello, World!

Coroutine Builders

1. launch: Fire-and-forget, returns a Job
2. async: Returns a Deferred (like a Future)
3. runBlocking: Blocks the current thread (use sparingly)
4. coroutineScope: Creates a scope for structured concurrency

suspend fun fetchData() = coroutineScope {
    val data1 = async { fetchFromSource1() }
    val data2 = async { fetchFromSource2() }
    
    // Both run concurrently, await when needed
    val result1 = data1.await()
    val result2 = data2.await()
    
    combineResults(result1, result2)
}

---

Suspend Functions and async/await

Suspend Functions

A suspend function can be paused and resumed. It can only be called from a coroutine or another suspend function.

suspend fun fetchUser(id: String): User {
    delay(1000) // Simulate network call
    return User(id, "John Doe")
}

How Suspend Functions Work

1. Compilation: The compiler transforms suspend functions into state machines
2. Continuation: Each suspend point stores its continuation (where to resume)
3. Non-blocking: The thread is freed when suspended, allowing other work

Bridging to Swift

Kotlin suspend functions automatically bridge to Swift async functions:

Kotlin:

suspend fun createSlideshow(topic: String): Slideshow {
    // ... implementation
}

Swift:

let slideshow = try await kmpBridge.createSlideshow(topic: "Travel Tips")

The Kotlin compiler generates the necessary bridging code automatically!

---

Kotlin Flow: Reactive Streams

What is Flow?

Flow is Kotlin’s answer to reactive streams (like RxJava’s Observable). It’s a cold stream that emits values over time.

Key Characteristics:

• Cold: Doesn’t start until collected (lazy)
• Coroutine-based: Built for Kotlin coroutines
• Backpressure: Handled automatically
• Cancellable: Can be cancelled via coroutine cancellation

Flow vs Other Approaches

Feature	Flow	RxJava Observable	Swift AsyncSequence
Hot/Cold	Cold by default	Hot by default	Cold
Threading	Coroutine-based	Thread-based	Async/await
Backpressure	Automatic	Manual	Automatic
Cancellation	Coroutine cancellation	Subscription	Task cancellation

Creating a Flow

import kotlinx.coroutines.flow.*

fun numbersFlow(): Flow<Int> = flow {
    for (i in 1..5) {
        delay(100)
        emit(i) // Emit a value
    }
}

Collecting from Flow

suspend fun collectNumbers() {
    numbersFlow().collect { number ->
        println(number) // Prints 1, 2, 3, 4, 5
    }
}

Flow Operators

Flow provides many operators similar to RxJava:

flowOf(1, 2, 3, 4, 5)
    .map { it * 2 }           // Transform
    .filter { it > 5 }         // Filter
    .take(2)                   // Take first 2
    .collect { println(it) }   // Collect: 6, 8

StateFlow and SharedFlow

• StateFlow: Holds a single value, emits updates (like LiveData)
• SharedFlow: Hot flow that can have multiple collectors

val stateFlow = MutableStateFlow(0)

// Collect updates
stateFlow.collect { value ->
    println("Current value: $value")
}

// Update value
stateFlow.value = 1 // Triggers collection

---

Bridging to Swift

Suspend Functions → Swift async/await

Kotlin suspend functions bridge seamlessly to Swift:

Kotlin:

suspend fun searchImages(query: String): List<ImageResult>

Swift:

let images = try await kmpBridge.searchImages(query: "nature")

Flow → Swift AsyncSequence

Flow doesn’t bridge directly, but Flow.collect is a suspend function:

Kotlin:

fun generateProgress(): Flow<Progress> = flow {
    emit(Progress.Started)
    delay(1000)
    emit(Progress.Processing(50))
    delay(1000)
    emit(Progress.Completed)
}

Swift Bridge:

func generateProgress() -> AsyncThrowingStream<ProgressModel, Error> {
    return AsyncThrowingStream { continuation in
        Task {
            do {
                let flow = appModule.useCase.generateProgress()
                try await flow.collect { progress in
                    let model = progress.toSwiftModel()
                    continuation.yield(model)
                    
                    if progress is Progress.Completed {
                        continuation.finish()
                    }
                }
            } catch {
                continuation.finish(throwing: error)
            }
        }
    }
}

Swift Usage:

for try await progress in kmpBridge.generateProgress() {
    updateUI(with: progress)
}

---

Practical Example: Slideshow Generation

Let’s see how we use these concepts in our slideshow app:

1. Suspend Functions for Single Operations

// Repository layer
interface ImageRepository {
    suspend fun searchImages(query: String): List<ImageResult>
}

// Use case layer
class CreateSlideshowUseCase(
    private val imageRepository: ImageRepository
) {
    suspend fun createFromTopic(topic: String): Slideshow {
        // Sequential execution
        val images = imageRepository.searchImages(topic)
        val music = musicRepository.suggestMusic(topic)
        
        return Slideshow(
            title = topic,
            slides = images.map { createSlide(it) },
            music = music
        )
    }
}

2. Concurrent Execution with async/await

suspend fun createFromTopic(topic: String): Slideshow = coroutineScope {
    // Launch multiple operations concurrently
    val imagesDeferred = async { imageRepository.searchImages(topic) }
    val musicDeferred = async { musicRepository.suggestMusic(topic) }
    val slideContentDeferred = async { aiRepository.generateSlides(topic) }
    
    // Await all results
    val images = imagesDeferred.await()
    val music = musicDeferred.await()
    val slideContent = slideContentDeferred.await()
    
    // Combine results
    Slideshow(
        title = topic,
        slides = combineSlides(images, slideContent),
        music = music
    )
}

3. Flow for Progress Updates

fun createFromTopicWithProgress(topic: String): Flow<GenerationProgress> = flow {
    // Emit progress updates as work progresses
    emit(GenerationProgress.GeneratingSlides(0, 5))
    
    val slideContents = aiRepository.generateStructuredSlides(topic, 5)
    emit(GenerationProgress.GeneratingSlides(5, 5))
    
    slideContents.forEachIndexed { index, content ->
        emit(GenerationProgress.GeneratingImages(index + 1, 5, content.title))
        
        val image = imageRepository.generateImage(content.imageKeywords.first())
        // ... create slide
        
        // Emit progress for each slide
    }
    
    emit(GenerationProgress.Completed(slideshow))
}

4. Swift Integration

class SlideshowViewModel: ObservableObject {
    @Published var generationProgress: GenerationProgressModel?
    
    func createSlideshow(topic: String) async {
        let progressStream = kmpBridge.createSlideshowWithProgress(
            topic: topic,
            numberOfSlides: 5
        )
        
        // Iterate over the stream reactively
        for try await progress in progressStream {
            await MainActor.run {
                self.generationProgress = progress
                
                if case .completed(let slideshow) = progress {
                    self.currentSlideshow = slideshow
                }
            }
        }
    }
}

5. UI Updates

struct ProgressView: View {
    @ObservedObject var viewModel: SlideshowViewModel
    
    var body: some View {
        if let progress = viewModel.generationProgress {
            ProgressView(value: progress.progress) {
                Text(progress.message)
            }
        }
    }
}

---

Flow vs RxJava vs Swift AsyncSequence

When to Use Each

Use Kotlin Flow when:

• You need reactive streams in Kotlin
• You want coroutine-based concurrency
• You need automatic backpressure handling
• You’re building a KMP app

Use RxJava when:

• You’re in a pure JVM/Android environment
• You need hot observables
• You have existing RxJava code
• You need complex operators not in Flow

Use Swift AsyncSequence when:

• You’re in pure Swift code
• You need Swift-native async iteration
• You’re not using KMP

Comparison Table

Aspect	Flow	RxJava	AsyncSequence
Platform	Kotlin Multiplatform	JVM/Android	Swift
Concurrency Model	Coroutines	Threads	async/await
Hot/Cold	Cold	Hot (default)	Cold
Backpressure	Automatic	Manual	Automatic
Cancellation	Coroutine scope	Subscription	Task
Learning Curve	Medium	Steep	Easy (if you know async/await)

Code Comparison

Kotlin Flow:

flowOf(1, 2, 3)
    .map { it * 2 }
    .collect { println(it) }

RxJava:

Observable.just(1, 2, 3)
    .map { it * 2 }
    .subscribe { println(it) }

Swift AsyncSequence:

let sequence = AsyncStream { continuation in
    for i in 1...3 {
        continuation.yield(i * 2)
    }
    continuation.finish()
}

for await value in sequence {
    print(value)
}

---

Best Practices

1. Use Structured Concurrency

✅ Good:

suspend fun processData() = coroutineScope {
    val result1 = async { fetchData1() }
    val result2 = async { fetchData2() }
    combineResults(result1.await(), result2.await())
}

❌ Bad:

suspend fun processData() {
    GlobalScope.launch { /* ... */ } // Don't use GlobalScope!
}

2. Handle Errors Properly

fun dataFlow(): Flow<Result<Data>> = flow {
    try {
        emit(Result.success(fetchData()))
    } catch (e: Exception) {
        emit(Result.failure(e))
    }
}

3. Use Flow for Multiple Values

✅ Use Flow:

fun progressUpdates(): Flow<Progress> = flow {
    emit(Progress.Started)
    emit(Progress.Processing(50))
    emit(Progress.Completed)
}

❌ Don’t use suspend function:

suspend fun getProgress(): Progress // Can only return one value

4. Bridge Flow to Swift Correctly

// ✅ Good: Use AsyncThrowingStream
func getProgress() -> AsyncThrowingStream<ProgressModel, Error> {
    return AsyncThrowingStream { continuation in
        Task {
            try await flow.collect { progress in
                continuation.yield(progress.toSwiftModel())
                if progress is Completed {
                    continuation.finish()
                }
            }
        }
    }
}

// ❌ Bad: Don't try to use Flow directly in Swift
// Flow doesn't bridge - use collect instead

5. Update UI on Main Thread

for try await progress in progressStream {
    await MainActor.run {
        // Update UI properties here
        self.progress = progress
    }
}

6. Cancel Operations When Needed

// In a ViewModel or similar
private var generationJob: Job? = null

fun startGeneration() {
    generationJob = viewModelScope.launch {
        flow.collect { /* ... */ }
    }
}

fun cancelGeneration() {
    generationJob?.cancel()
}

---

Key Takeaways

1. Coroutines are Kotlin’s lightweight concurrency mechanism
2. Suspend functions bridge seamlessly to Swift async/await
3. Flow is Kotlin’s reactive stream solution, perfect for progress updates
4. Flow.collect bridges to Swift via AsyncThrowingStream
5. Structured concurrency ensures proper resource management
6. Use Flow for multiple values, suspend functions for single values

Real-World Example Summary

In our slideshow app:

• Suspend functions handle single operations (search images, generate content)
• async/await with coroutineScope runs operations concurrently
• Flow emits progress updates as slides are generated
• Swift AsyncThrowingStream bridges Flow to Swift
• @Published properties in SwiftUI react to progress updates

This creates a reactive, non-blocking user experience where the UI updates in real-time as work progresses.

---

Further Reading

• Kotlin Coroutines Guide
• Kotlin Flow Documentation
• Kotlin Multiplatform Documentation
• Swift Concurrency

---

This article was written based on implementation in a real Kotlin Multiplatform slideshow generation application.

A B Rating From CodeFrog

While building CodeFrog’s landing page, we integrated Mailchimp for newsletter signups. However, our security scans revealed a critical issue that prevents us from achieving an A rating: Mailchimp’s validation script violates Content Security Policy (CSP) requirements.

The Security Violation

Mailchimp’s mc-validate.js script injects inline styles dynamically, which requires the 'unsafe-inline' directive in our CSP style-src policy. This is a security anti-pattern because:

1. CSP Bypass Risk: 'unsafe-inline' allows any inline styles, defeating the purpose of CSP protection against XSS attacks
2. Nonce Incompatibility: Even when using CSP nonces for our own styles, Mailchimp’s dynamically injected styles can’t use nonces, forcing us to allow all inline styles
3. Security Rating Impact: Security scanners (like our own Mega Report) flag this as a MEDIUM severity issue, preventing an A rating

The Error

When we removed 'unsafe-inline' to improve security, the browser console shows:

Applying inline style violates the following Content Security Policy directive: 
`style-src 'self' 'nonce-...'`. The action has been blocked.

This error originates from mc-validate.js:164, confirming that Mailchimp’s script requires unsafe inline styles to function.

Why This Matters

Content Security Policy is a critical security feature that helps prevent:

• Cross-Site Scripting (XSS) attacks
• Data injection attacks
• Code injection vulnerabilities

By requiring 'unsafe-inline', Mailchimp forces us to weaken our security posture, which is unacceptable for a security-focused tool like CodeFrog.

What We Need

We’re looking for a newsletter service that:

✅ Free tier (or very affordable) for up to 500 subscribers
✅ CSP-compliant – doesn’t require 'unsafe-inline'
✅ Secure by default – supports nonces or external stylesheets
✅ Easy integration – simple embed or API
✅ Reliable – good deliverability and uptime

Call for Recommendations

We’re reaching out to the developer community for recommendations. If you know of a newsletter service that:

• Respects modern web security standards
• Works with strict CSP policies
• Offers a free tier for small lists
• Provides good deliverability

Please share your suggestions! We’re particularly interested in:

• Self-hosted solutions (if they’re easy to set up)
• Modern alternatives that prioritize security
• Services that use external stylesheets or support CSP nonces
• Any workarounds for making Mailchimp CSP-compliant (if they exist)

The Solution: CSP Hash Instead of Unsafe-Inline

Good news! We found a solution that doesn’t require 'unsafe-inline'. When we removed 'unsafe-inline' from our CSP, the browser console error message actually provided the answer:

Applying inline style violates the following Content Security Policy directive: 
'style-src 'self' 'nonce-...''. Either the 'unsafe-inline' keyword, a hash 
('sha256-iIHQ0a6ntSSQhfMwBwjvXvp+zrKJldURld+iiblnEKo='), or a nonce 
('nonce-...') is required to enable inline execution.

The browser helpfully suggested using a hash for the specific inline style instead of allowing all inline styles. This is a much better security approach!

What We Changed

Instead of using 'unsafe-inline' in our CSP style-src directive, we now use:

style-src 'self' 'nonce-{style_nonce}' 'sha256-iIHQ0a6ntSSQhfMwBwjvXvp+zrKJldURld+iiblnEKo='

This hash is specific to the inline style that Mailchimp’s mc-validate.js script injects. By using the hash, we:

✅ Allow only that specific style – not arbitrary inline styles
✅ Maintain strict CSP – no 'unsafe-inline' directive
✅ Pass security scans – scanners don’t flag specific hashes
✅ Keep Mailchimp working – the validation script functions correctly

Why This Is Better

Using a hash is more secure than 'unsafe-inline' because:

• It’s whitelist-based: Only the exact style with that hash is allowed
• It’s CSP-compliant: Security scanners accept hashes as a valid, secure approach
• It’s maintainable: If Mailchimp changes their script, we’ll get a new error with a new hash to add

Remaining Issue

While we’ve solved the CSP style-src issue, there’s still one security concern:

⚠️ SRI (Subresource Integrity) Missing: Mailchimp’s script is loaded from their S3 bucket without an integrity attribute. This means we can’t verify the script hasn’t been tampered with. However, this is a known limitation because:

• Mailchimp’s script is dynamically generated and changes frequently
• Their S3 bucket doesn’t send CORS headers, which would be required for SRI
• Adding crossorigin="anonymous" would break script loading due to CORS issues

This is a MEDIUM severity issue that prevents a perfect A+ rating, but it’s an acceptable trade-off given the constraints.

Conclusion

As a security-focused developer tool, CodeFrog needs to maintain the highest security standards. We’ve successfully resolved the CSP 'unsafe-inline' issue by using a hash-based approach, which is more secure and CSP-compliant.

The remaining SRI issue is a known limitation with third-party scripts that don’t support CORS, and we’ve documented it appropriately. We’re now much closer to that A security rating!

---

Update: We solved the CSP issue using a hash-based approach! The browser’s error message provided the exact hash we needed. Mailchimp now works with strict CSP without requiring 'unsafe-inline'.

Introduction

Accessibility is not a feature—it’s a fundamental requirement for modern web and mobile applications. Over 1 billion people worldwide live with disabilities, and many rely on assistive technologies to navigate digital products. Beyond the moral imperative, accessible applications reach broader audiences, improve SEO rankings, and help organizations comply with legal standards like WCAG 2.1 and the Americans with Disabilities Act (ADA).

However, accessibility testing remains challenging for many development teams. Manual testing is time-consuming and error-prone, while developers often lack the expertise to identify subtle accessibility violations. This is where automated testing tools become invaluable.

The Challenge: Common Accessibility Issues

Developers frequently encounter accessibility barriers that go unnoticed during standard testing:

• Missing alt text on images, leaving screen reader users without context
• Insufficient color contrast making content unreadable for users with low vision
• Unlabeled form fields confusing users relying on screen readers
• Broken heading hierarchy disrupting document structure and navigation
• Missing ARIA attributes preventing assistive technologies from understanding dynamic content
• Keyboard navigation failures excluding users who cannot use a mouse
• Missing focus indicators making it impossible to track keyboard position

These issues compound, creating frustrating experiences for users with disabilities while exposing organizations to legal liability.

CodeFrog’s Solution: Automated Accessibility Testing

CodeFrog integrates axe-core, the industry-leading automated accessibility testing engine, directly into your development workflow. This powerful integration enables developers to catch accessibility violations early—during development, not after deployment.

With CodeFrog’s Web Testing feature, you can:

1. Test multiple sources: Select a local HTML file, enter a URL (localhost, staging, or production), or test a remote server
2. Test entire sites through sitemap testing: Provide a sitemap URL to automatically test all pages across your entire website, ensuring comprehensive accessibility coverage
3. Run automated accessibility scans powered by axe-core
4. View detailed violation reports with severity levels and remediation guidance
5. Iterate quickly with instant feedback on accessibility improvements

Whether you’re testing a development server running on localhost:3000, a staging environment, a production URL, or an entire site via sitemap, CodeFrog brings accessibility testing directly into your workflow.

What axe-core Detects

axe-core performs comprehensive automated testing across multiple accessibility standards:

Image and Media

• Missing or empty alt attributes on images
• Unlabeled buttons and icons
• Missing captions on video content

Color and Contrast

• Text with insufficient contrast ratios (WCAG AA/AAA standards)
• Color-only information without alternative indicators

Forms and Labels

• Form inputs without associated labels
• Missing or incorrect for attributes on labels
• Unlabeled fieldsets and legend elements

Document Structure

• Improper heading hierarchy (skipping levels like H1 → H3)
• Missing page landmarks (main, navigation, contentinfo)
• Duplicate IDs on page elements

ARIA and Semantics

• Invalid ARIA roles and attributes
• Missing required ARIA properties
• Misused semantic HTML elements

Keyboard Navigation

• Interactive elements not keyboard accessible
• Missing focus indicators
• Keyboard traps preventing escape

Benefits for Your Development Team

Shift-Left Testing: Catch accessibility issues before code review, reducing remediation costs and timeline pressure.

Developer Education: Detailed violation reports help your team understand why issues matter and how to fix them, building accessibility expertise across the organization.

Continuous Improvement: Integrate accessibility testing into your CI/CD pipeline to prevent regressions.

Compliance Confidence: Demonstrate accessibility commitment to stakeholders, customers, and regulators.

Inclusive Products: Build applications that work for everyone, expanding your user base and market reach.

Getting Started

CodeFrog makes accessibility testing accessible to developers of all experience levels. Whether you’re building a new feature or auditing an existing application, the Web Testing feature provides actionable insights to improve your digital products.

Start testing today and join the movement toward truly inclusive web development.

---

CodeFrog: Empowering developers to build accessible, inclusive applications.

The Problem

Implementing native drag-and-drop functionality in a Flutter macOS application that works seamlessly with scrolling and file selection proved to be one of the most challenging features we’ve built. The goal was simple: allow users to drag files into and out of CodeFrog, supporting both local and network (SSH) projects, while maintaining smooth scrolling and file selection.

Initial Attempt: super_drag_and_drop

We started with the super_drag_and_drop package, which provides cross-platform drag-and-drop support. While it worked for basic scenarios, we encountered several issues:

1. Unreliable drag-out for remote files – Files on network/SSH connections needed to be downloaded before dragging, and the async nature of this operation caused frequent failures
2. Gesture conflicts – The package’s gesture recognizers conflicted with Flutter’s built-in scrolling and selection mechanisms
3. Limited control – We needed more fine-grained control over the drag-and-drop behavior, especially for handling remote file downloads

After many hours of debugging and attempting workarounds (pre-downloading files, using virtual files, adjusting gesture recognizers, etc.), we decided to build a custom solution using native macOS APIs.

The Custom Solution: flutter_macos_drag

We built a custom Flutter plugin (flutter_macos_drag) that uses native macOS NSDraggingSource and NSDraggingDestination protocols directly. This gave us complete control over the drag-and-drop behavior.

Key Components

1. MacOSDraggable – A Flutter widget for dragging files out of the app
2. MacOSDroppable – A Flutter widget for accepting file drops from Finder
3. DraggableNSView – Native Swift view implementing NSDraggingSource and NSDraggingDestination

The Challenge: Scrolling vs Drag-and-Drop

The biggest challenge was making drag-and-drop work while preserving scrolling functionality. The native AppKitView needed to be in the widget hierarchy to receive drag events, but it was blocking pointer events needed for scrolling.

Failed Approaches:

• Using IgnorePointer – Blocked drag events
• Using AbsorbPointer – No effect
• Using Listener with HitTestBehavior – Still blocked events
• Reversing Stack order – Drag events didn’t reach the native view

The Solution: hitTest Override

The breakthrough came from understanding how macOS handles drag events vs pointer events:

1. Drag events work at the NSView level and query all registered views directly, completely bypassing Flutter’s pointer system and hit testing
2. Pointer events (scrolling, clicking) go through normal hit testing

By overriding hitTest in the native view to return nil for drop zones, we allow pointer events to pass through to Flutter widgets below, while drag events still work because they query registered views directly.

override func hitTest(_ point: NSPoint) -> NSView? {
    // For drop zones, return nil to let pointer events pass through to Flutter
    // Drag events don't use hitTest - they query all registered views directly
    if acceptDrops && filePath == nil {
        return nil
    }
    return super.hitTest(point)
}

Additionally, we made mouse event handlers return early for drop zones:

override func mouseDown(with event: NSEvent) {
    // For drop zones, don't handle mouse events - let them pass through for scrolling
    if acceptDrops && filePath == nil {
        return // Don't call super - allows events to pass through
    }
    // ... handle drag-out logic
}

Widget Structure

The final widget structure uses a Stack with the native view on top:

Stack(
  children: [
    // Native view on top - configured to not block pointer events
    Positioned.fill(
      child: Opacity(
        opacity: 0.01,
        child: AppKitView(...),
      ),
    ),
    // Flutter widgets below - receive pointer events for scrolling
    widget.child,
  ],
)

Features Achieved

✅ Drag files out – Works for both local and network files
✅ Drag files in – Accepts drops from Finder into any directory
✅ Scrolling – File tree pane scrolls smoothly
✅ File selection – Click to select files works normally
✅ Remote file handling – Downloads remote files on-demand during drag
✅ Root directory support – Can drop files at project root (empty path)

Key Technical Insights

1. macOS drag events bypass Flutter’s pointer system – They query all registered views directly, so IgnorePointer and similar widgets don’t affect them
2. hitTest controls pointer events, not drag events – Returning nil from hitTest allows pointer events to pass through while drag events still work
3. View registration is separate from hit testing – Views registered with registerForDraggedTypes receive drag events regardless of hitTest results
4. Mouse event handlers must return early – For drop zones, don’t call super in mouse event handlers to allow events to pass through

Lessons Learned

• Sometimes a custom native solution is necessary when cross-platform packages don’t meet specific requirements
• Understanding the underlying platform APIs (NSDraggingSource/NSDraggingDestination) is crucial
• The interaction between Flutter’s pointer system and native platform views requires careful consideration
• Persistence pays off – this took many hours but resulted in a robust, maintainable solution

This solution was developed over many hours of debugging and research. The key was understanding that macOS drag events operate at a different level than pointer events, allowing us to let pointer events pass through while still receiving drag events.