
In this blog post, I will share the code for a simple RCTBridgeModule that can write/read key-value from React Native.

The use case for this is to access the data in iOS Share Extension using value set from React Native.

So that the Share Extension can perform API call with sufficient data that was set in React Native, and thus giving user a much better experience similar to other natively built apps. This is a much more complicated implementation and there are much simpler ways to get it done without writing too many native code and that will be for another blog post.

Let's get back and focus on this topic, get and set value in `UserDefaults` that are accesible in Share Extension.
In order to achieve that, we need to use `UserDefaults` with `suiteName` that starts with `group.`.

Before you proceed, please make sure that you have already created Share Extension and updated `App Groups` in the `Signing & Capabilities`.
This is not covered in this post and there are alot of online resources for this topic.

<hr />

<br />

##### 1. First, create a header file in xcode.

I'll name it `SharedUserDefaults.h`

```
#ifndef SharedUserDefaults_h
#define SharedUserDefaults_h
#endif

#import <Foundation/Foundation.h>

#if __has_include(<React/RCTAssert.h>)
#import <React/RCTBridgeModule.h>
#else
#import "RCTBridgeModule.h"
#endif

@interface SharedUserDefaults : NSObject <RCTBridgeModule>
@end
```

<br />

##### 2. Then, create the implementation file.

`SharedUserDefaults.m`

```
#import <Foundation/Foundation.h>
#import "SharedUserDefaults.h"

@implementation SharedUserDefaults

RCT_EXPORT_MODULE()

+ (BOOL)requiresMainQueueSetup
{
  return YES;
}

RCT_EXPORT_METHOD(set:(NSString *)suiteName
                  key:(NSString *)keyName
                  value:(NSString *)value)
{
  NSUserDefaults *shareExtensionDefaults = [[NSUserDefaults alloc] initWithSuiteName: suiteName];
  [shareExtensionDefaults setObject:value forKey:keyName];
  NSLog(@"val written %@", value);
}

RCT_EXPORT_METHOD(get:(NSString *)suiteName
                  key:(NSString *)keyName
                  resolver: (RCTPromiseResolveBlock)resolve
                  rejecter:(RCTPromiseRejectBlock)reject)
{
  NSUserDefaults *shareExtensionDefaults = [[NSUserDefaults alloc] initWithSuiteName: suiteName];
  NSString *val = [shareExtensionDefaults stringForKey:keyName];
  if (val == nil) {
    NSError *error = [NSError errorWithDomain:@"org.reactjs.native.example.Bill" code:0 userInfo:@{ @"message": @"Empty" }];
    reject(@"error", @"error description", error);
  } else {
    resolve(val);
  }
}

@end
```

<br />

##### 3. Next, build and run your app.

And you can use the methods from the native module you've just written.

In your React Native project, you can now get and set key-value pair to UserDefaults via the native module.

```
import { NativeModules } from 'react-native';

const SharedUserDefaults = NativeModules.SharedUserDefaults;

// Usage

// Set
SharedUserDefaults.set("group.org.reactjs.native.example.YourProject", "yourKey", "some string to be stored");

// Get
let val = await SharedUserDefaults.get("group.org.reactjs.native.example.YourProject", "yourKey");
```

In iOS, the value can be retrieved in `ShareViewController.swift` or `AppDelegate.m`.

`Swift`

```
var userDefaults = UserDefaults(suiteName: "group.org.reactjs.native.example.YourProject")

// Get value stored earlier
let storedValue = userDefaults?.object(forKey: "yourKey") as? String

 // Set new value
userDefaults?.set("some string to be stored", forKey: "yourKey")
```

`Obj-C`

```
  NSUserDefaults *userDefaults = [[NSUserDefaults alloc] initWithSuiteName: @"group.org.reactjs.native.example.YourProject"];

  // Get value stored earlier
  NSString *val = [userDefaults stringForKey:@"yourKey"];

  // Set new value
  [userDefaults setObject:@"some string to be stored" forKey:@"yourKey"];
```

<br />

#### End

You are now all set!

Now you can set value from React Native and retrieve it in your `ShareViewController.swift`.

That's it! Hope it helps.

Cheers.

iOS Shared UserDefaults for App Extensions With RCTBridgeModule


In this post, I'll share the practical aspects of what I learned building iOS apps with Compose Multiplatform.

---

## Understanding the Internals

### Project Structure

A typical Compose Multiplatform project structure:

```
project/
├── iosApp/            # iOS-specific code (Swift/UIKit wrapper)
├── shared/            # Shared Kotlin code
│   ├── commonMain/    # Platform-agnostic code
│   ├── androidMain/   # Android-specific implementations
│   └── iosMain/       # iOS-specific implementations
└── composeApp/        # Shared Compose UI code
```

---


### From KMP project template

Here's a generated `ContentView.swift` from project template.

```swift
import SwiftUI
import Shared

struct ComposeView: UIViewControllerRepresentable {
    func makeUIViewController(context: Context) -> UIViewController {
        MainViewControllerKt.MainViewController()
    }

    func updateUIViewController(_ uiViewController: UIViewController, context: Context) {}
}

struct ContentView: View {
    var body: some View {
        ComposeView()
            .ignoresSafeArea(.all)
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

```

This exact code runs natively on iOS without any modifications.


Layer-by-layer view

```
iOS App
 └── SwiftUI
      └── UIViewControllerRepresentable
           └── UIKit UIViewController
                └── Compose Runtime
                     └── Skia / Metal rendering
```

In a Kotlin Multiplatform project using Compose Multiplatform on iOS, the UI is rendered through a layered architecture rather than directly by SwiftUI or UIKit.

SwiftUI acts only as the entry point of the app, embedding a UIViewController via UIViewControllerRepresentable.

That UIViewController is not responsible for laying out views or drawing UI elements; instead, it serves as a host required by iOS to participate in the app lifecycle.

This makes UIKit the structural container, ensuring compatibility with iOS windowing, lifecycle, and event delivery, while remaining largely unaware of how the UI itself is drawn.

Inside this UIKit container runs the Compose runtime, which owns layout, state, input handling, and rendering.
Compose does not use UIKit components like UILabel or UIButton;

Instead, it renders its UI using Skia, a cross-platform graphics engine, which in turn targets Metal for hardware-accelerated drawing on iOS.

Touch and system events flow from UIKit into the Compose runtime, but all visual output and UI logic remain entirely in Kotlin.

As a result, the app achieves a single shared UI codebase across Android and iOS, while still integrating cleanly into the native iOS application stack without relying on a JavaScript bridge or web-based rendering.

---

## The Future of Compose Multiplatform on iOS

Compose Multiplatform for iOS is rapidly maturing. Recent improvements include:
- Better performance optimizations
- Improved IDE support
- Growing ecosystem of libraries
- Better interop with Swift and SwiftUI

JetBrains is actively investing in the platform, with regular updates and improvements.

---

## Conclusion

Compose Multiplatform offers a compelling approach to iOS development, especially for teams already using Kotlin or building cross-platform apps. While it requires learning Kotlin and the Compose paradigm, the benefits of code sharing, type safety, and modern declarative UI make it a powerful tool in the mobile developer's toolkit.

The key is knowing when to use shared code and when to embrace platform-specific implementations. With the right balance, you can build high-quality iOS apps while maximizing code reuse across platforms.

Thanks for reading. Happy coding!


Building iOS Apps with Compose Multiplatform


I build an iOS arcade game called T-Minus Zero: Thrust (hold to thrust, land softly).

It's a solo project, and a lot of the code is written by Claude Code.

The part I've learned the most from isn't the prompting.

It's the loop around it: what runs unattended, what it is forbidden to do, and where I step in.

![The loop: a circular task cycle, then a release path](loop-diagram.svg)

---

## Two ways work gets in

My main features still come from prompting. I describe what I want, work through it in a session, and push.

Improvements go through the loop.

These are the many small things a game needs: new missions, tuning, polish, accessibility passes, tests.

I run a routine called `run-task-cycle` for a few cycles, and it does three things on repeat:

1. **Write a task.** A skill picks the next idea from my roadmap, or a small improvement it finds in the code, and writes a task file to a fixed template: goal, background, requirements, out of scope, acceptance criteria.
2. **File an issue.** Another skill turns that file into a GitHub issue in a `To Do` milestone.
3. **Build it.** A third skill works the open issues oldest first. It makes the change, runs the check scripts, commits and pushes to `dev`, then moves the issue to `For Review` and closes it.

When the queue is empty, the loop is done. Then it runs once:

4. **Push to `github-ci`.** The routine fast-forwards `dev` into the branch that Xcode Cloud watches. It never force-pushes.
5. **Xcode Cloud** builds it and sends a TestFlight version.
6. **I play it on my phone**, and what I notice becomes the next round's tasks.

Features I prompt by hand skip steps 1 to 3 and join at step 4.

Both routes end in the same place: a build on my phone.

---

## The loop is the easy part

Chaining skills together took an afternoon.

What lets me run it without watching is what I forbade it from doing.

Four rules do most of the work.

---

**1. Only bug fixes reach Release.**

Every other change - whether a feature, tuning, content or copy - must sit behind `#if DEBUG` or a flag that is false in Release, until I promote it in a separate task.

The loop can ship all day without changing what the App Store build does.

This is the rule I'd copy first.

---

**2. Park, don't guess.**

If an issue is large, has an unresolved open question, touches a protected area (the landing physics, the in-app purchases, the leaderboard IDs) or needs a manual step, the loop moves it to a `New` milestone with a comment saying why.

It never improvises on the parts of the project I'd hate to get wrong.

---

**3. Checks report, never edit.**

The repo has 43 small check scripts: UK English and no dashes in copy, every shown character exists in the font, product IDs match the code, Debug-only switches are off in Release, docs match code.

They only report.

The loop can't pass a check by editing the check.

---

**4. Generate only when the queue is empty.**

The task-writing skill refuses to run if `To Do` already has issues.

Work can't pile up faster than it ships.

---

All of this lives in written rules, not in anyone's memory.

A `CLAUDE.md` file holds the business rules, the vocabulary and the commit format, and the skills are told it wins over whatever an issue says.

---

## It runs while I sleep

The loop is designed to run in a cloud environment.

That was a deliberate decision, not an afterthought.

It means the loop does not need my machine, my network connection, or me to be awake.

I can kick off a run before bed. By morning, there are commits on `dev`, issues moved to `For Review`, and a TestFlight build on the way.

The rules that make this safe are the same ones above. A loop that runs unattended on my laptop is one thing. A loop that runs while I am genuinely not there has to be more careful about what it is allowed to touch.

The cloud environment is also stateless. There is no half-open file, no half-remembered context from the last session. Each run starts clean, reads from the repo and the issue tracker, and does exactly what the skills say.

That constraint turned out to be a feature. It forced me to write everything down.

---

## The phone is the real test

The loop can build a mission. It can't tell me whether the mission is fun.

Game balance numbers are marked in my own notes as "playtest this", and the loop respects that: it will add the content, but only my hands on a TestFlight build can judge it.

It's also honest about what it didn't verify.

It can't run the unit tests in a simulator, so its reports say "build and tests not run" rather than claiming they passed.

I run the full suite from Xcode, and the final check is the build on my phone.

I'm the verification step at the end of the loop, and I think that's the right place for a person to be.

---

## What went wrong

- **No release tag.** I never tagged releases, so writing release notes meant working out the last shipped version from bump commits and dates. That annoyed me enough to turn it into its own skill.
- **Release notes in developer wording.** Drafting notes from commit subjects gives text players can't read. They need rewriting for players.
- **Saved progress.** Renaming or removing a mission can silently reset players' progress, because the saved key is built from the mission's title. The fix was a separate display name, and the rule is now written down so the loop respects it.

---

## The numbers

Over roughly a year of history there are about 1,000 commits and 212 tasks filed as issues.

Most of that came in the last few weeks, once the loop existed.

---

## What's still left to do

The loop works, but it is nowhere near finished.

A few things I want to add:

**Self-healing.** Right now, if a build breaks, the loop stops. A better version would catch the failure, read the error, fix it, and keep going - without waking me up. The check scripts already report exactly what went wrong. The next step is letting the loop act on that report.

**Agent-based verification.** The loop currently skips simulator tests because it can't run them in a cloud environment. What I want is a separate agent that takes the finished build, installs it, exercises the key paths, and files an issue if something looks wrong. Verification by agent, not by assumption.

**Smarter task generation.** Right now the task-writing skill picks from a roadmap file or spots things in the code. It could also look at crash reports, user feedback, or TestFlight comments and generate tasks from those. Closing the feedback loop automatically.

**Tighter scope per cycle.** Some cycles try to do too much. I want the loop to estimate the size of a task before it starts and skip anything too large rather than parking it mid-way through.

None of these are hard in isolation. The interesting part is adding them without making the loop harder to trust.

---

## What I'd tell someone building their own

- Design the stop conditions before the prompts. Decide what the loop must refuse to touch and write it down.
- Make the safe path the default. Debug-only by default means a mistake costs a TestFlight build, not an App Store release.
- Keep a person at the end of the loop, holding the real device.
- Let the loop do the improvements, and keep the features for yourself.


Designing the loop, not the prompts


## The Goal

I needed a small on-device object detector that finds fingertips in photos.

For an iOS app first. Android to follow.

The requirements were simple:

- Run on-device, no server
- Fast enough for real-time use
- Small enough for phones

---

## Why YOLOX-Tiny

YOLOX-Tiny (Apache-2.0) was the right fit.

Small. Fast. Good enough for a two-class problem.

Fine-tuned from pretrained weights - no need to train from scratch.

One important decision: I used **LibreYOLO** (MIT) instead of Ultralytics for training.

The reason is licensing.

Ultralytics is AGPL-3.0. That creates complications in a commercial product.

LibreYOLO is MIT. Clean.

The model runs at about **6 ms per image on a Mac**.

That is only a rough guide for phone speed, but it is a good sign.

---

## The Data

About **1,500 labeled images**:

- 1,335 for training
- 166 for validation

Two classes: **fingertip** (palm side) and **fingernail**.

---

## The Hard Negative Class

The fingernail class deserves its own explanation.

Without it, the model fires on nails.

A fingernail looks similar to a fingertip from the model's perspective - same shape, same proximity.

So I added nails as a **hard negative class**.

The app ignores class 1 entirely. The model just needs to know the difference.

This was one of the biggest gains in accuracy.

---

## Data Collection Notes

Nail images came from public **CC BY 4.0** datasets.

One important rule: **images from the same person stay in the same split**.

This prevents validation scores from being inflated by person-level leakage.

---

## Training Recipe

- Apple Silicon GPU
- 416×416 input
- Batch 16, 100 epochs, early stopping
- SGD with a warmup-plus-cosine learning rate

Heavy augmentation:

- Mosaic
- Mixup
- Color jitter
- Flips and rotation

Augmentation is **switched off for the last 15 epochs**.

This lets the model settle on clean images before evaluation.

The full 100-epoch run took about **37 minutes on a laptop**.

---

## Results

| Iteration | Change | mAP50-95 |
|---|---|---|
| Baseline | Fingertips only | 0.70 |
| Combined | More data | 0.76 |
| v2 | Added the fingernail class, 100 epochs | **0.77** |

mAP50 is about 0.99 - saturated.

So **mAP50-95** (how tight the boxes are) became the number that matters.

One caveat: the validation set is small.

Differences like 0.757 vs 0.773 may be within noise.

---

## What Actually Made the Difference

More data and the hard-negative class gave the main gains.

The architecture stayed the same throughout.

> The model did not need to be bigger. It needed better data.

Consistent box labeling also matters a lot.

Sloppy labels cap mAP50-95 more than the architecture does.

---

## Shipping

- Export to **Core ML** (with NMS baked in) for iOS
- Export to **LiteRT/TFLite** for Android

---

## Final Thoughts

This project reinforced something I keep relearning.

Architecture choices matter less than I expect.

Data quality and thoughtful class design matter more.

The fingernail hard-negative class was a small idea that had a big impact.

Sometimes the fix is not a bigger model - it is a smarter label.


ios

iOS Shared UserDefaults for App Extensions With RCTBridgeModule

Building iOS Apps with Compose Multiplatform

Designing the loop, not the prompts

How the fingertip detector was trained