DEV Community: niixolabs

We shipped a camera app where you record the shutter sound yourself

niixolabs — Wed, 24 Jun 2026 23:04:33 +0000

Voicame (ボイカメ) is a camera app we published for iPhone. Here's the honest account of what it does, how we built it, and where it falls short.

The idea

The starting point was simple: what if the shutter click was yours to choose?

iOS 17.2 shipped AVCaptureEventInteraction — an API that lets apps hook into the hardware shutter button event. We used it to play back any recorded audio at the exact moment of capture. So instead of the default click, you hear whatever you recorded: a name, a word, a short clip.

Recordings export via AirDrop. We kept coming back to one use case while building this: recording a child's name, then passing that recording to a partner's phone in a couple of taps so both phones make the same sound.

The symmetry side

The app also has six real-time symmetry modes — horizontal, vertical, diagonal, quad, kaleidoscope, and swirl — applied to both photo and video with a live preview. Under the hood: CoreImage's CIKaleidoscope, a Metal rendering pass, and AVAssetWriter for video output. Everything runs on-device; no frames or audio leave the phone.

What we'd change

Symmetry cameras are not a new idea. Kaleidoscope and mirror camera apps already exist in the App Store. The differentiator here is the audio customization, not the symmetry alone.

Shutter volume is tied to the system media volume — there's no separate slider in the app. That's a friction point we haven't resolved yet. The app also requires iOS 17.2+; no Android version exists.

Pricing

Free to download. Symmetry effects unlock with a one-time ¥250 in-app purchase.

App Store: https://apps.apple.com/jp/app/id6768058856

We built an app where the AI invents its own generators — MakerMaker by Niixo

niixolabs — Tue, 23 Jun 2026 23:03:13 +0000

The core idea

Point your camera at someone. MakerMaker returns a fictional 'Corporate Operations Manual v3.2' about them — AI-written text formatted like a real document, paired with an AI-generated image. That's the first of three hand-crafted generators in the app.

The second produces a fake product spec sheet with fabricated stats. The third writes a mock breaking-news article. All three run the same pipeline: photo → Gemini 2.5 Flash for text → Pollinations.ai for image → displayed in a themed document skin.

The part we didn't plan

After shipping those three, the obvious question came up: what if the AI designed a new generator itself?

So we built a fourth mode. Tap it and the AI invents a brand-new generator on the spot — selecting genre, tone, output format, and color palette from a parameter space that works out to roughly 95 million combinations. Each run feels different from the last.

What we're honest about

About 30% of outputs are flat. Generative variance is hard to tune out entirely, especially for entertainment where the success condition is 'make someone laugh' rather than 'return the right answer.' We surface this rather than overselling.

The UI is Japanese-only. MakerMaker targets the Japanese market, where this flavor of absurdist corporate parody has an audience. Expanding to other languages isn't on the roadmap yet.

Photos aren't stored. Firebase Functions (asia-northeast1) process each request and drop the image immediately — no reason to accumulate strangers' faces for a joke app.

Stack

Text: Gemini 2.5 Flash
Images: Pollinations.ai
Backend: Firebase Functions, asia-northeast1
iOS 17+

Pricing

Free download. Point packs from 10pt / ¥100. Premium pass at ¥480/month.

https://apps.apple.com/jp/app/id6762560561

Off By One: a calm puzzle about finding what's slightly wrong

niixolabs — Mon, 22 Jun 2026 23:03:17 +0000

The problem we were solving

Most puzzle games are anxiety games in disguise. The mechanic is fine, but a timer layer, a combo meter, or a decaying score turns what should be observation into a race. You stop looking and start rushing.

We wanted to build the opposite.

What the app does

Off By One shows a grid of geometric shapes. They all look identical — but one is slightly off. A different form, a subtly different decoration, a slight rotation. Your job is to find it and tap it.

No timer. No countdown. No penalty for being slow. Just observation.

There are 35 stages across Easy, Normal, and Hard difficulty. Shapes and decorations are procedurally generated from about 133,200 combinations, so the board stays varied across sessions. Built on SwiftUI's Canvas API, iOS 16+. Game Center is integrated with 17 achievements — structured to reward progress without leaning on score pressure.

What we learned shipping it

The hardest part wasn't the procedural generation. It was the App Store preview. You get a few seconds of footage to convince someone to install, and a near-static puzzle screen that's deliberately calm is genuinely difficult to sell in motion. The appeal lives inside the experience, not in watching it scroll by.

We also haven't implemented IAP yet. The app is free with reward ads only — which puts a ceiling on how we reach puzzle players who'd pay to remove ads. That's on the list.

Try it

Free on the App Store: https://apps.apple.com/jp/app/id6762133251

Hard difficulty is harder than it looks in the first few stages. Curious whether that curve lands right.

Why Chromium/CEF apps render a black window under Wine (and how to fix it with macOS IOSurface)

niixolabs — Mon, 22 Jun 2026 06:49:32 +0000

The problem

I was trying to run a Windows-only Steam game on an Apple Silicon Mac using a self-built Wine + DXMT (D3D11→Metal) stack — no commercial CrossOver. The last wall: the window opens, but its contents stay completely black.

The same symptom shows up with the Steam client itself and with many apps that embed CEF (Chromium Embedded Framework). This post explains why it happens and the idea behind fixing it with macOS IOSurface — focused on the "why" and "what to bridge," not full code.

Symptom: the window appears, the contents stay black

The window frame is created, but the inside is black. No crash. No fatal error in the logs. "It runs but doesn't render" — that's what made this hard to track down.

Root cause: the process that draws and the process that owns the window are different

Modern Chromium/CEF is designed to always run GPU compositing in a separate process
The GPU process draws; the browser process owns the window
They need a "present path" to transfer the composited frame between them
But mainline Wine has no equivalent of this cross-process present, and the D3D→Metal layer (DXMT) returns "cross-process swapchain not supported"
Result: the window is created, but no frame ever arrives → black

Why `-cef-disable-gpu` is a cop-out

Disabling GPU compositing falls back to software rendering, which does show something. But performance tanks and it's unusable for a game. I decided to build the frame-transfer path properly instead.

The fix: bridge the processes with IOSurface

macOS has IOSurface, which lets processes share GPU memory. The approach:

GPU process: blit the composited frame into a Metal texture backed by an IOSurface
Pass a global IOSurfaceID between the processes (via IPC/file)
Window process: IOSurfaceLookup(id) to get the surface, attach it to the visible layer's contents
Put a ~16ms (60fps) poll timer on the consumer side and call setNeedsDisplay

Settings that mattered

Set IOSurfaceIsGlobal = YES in the IOSurfaceCreate dictionary — without it, another process cannot Lookup the surface
On the producer side, key it by the root HWND from GetAncestor(hWnd, GA_ROOT) — keying per child window mismatches

The transparency wall

By default you get opaque compositing and overlaps break. I had to flip the opaque flag to non-opaque in three places across DXMT and winemac.

How "unusual" is this, honestly

This isn't a finished product and has known limitations. CrossOver is genuinely well-engineered — this was an exercise in "how far can you get without paying for it."

Full patch and build steps

This post sticks to the concept. The full patch, self-built Wine steps, launch scripts and staged verification are written up in detail (in Japanese, but the commands/configs translate cleanly):

Concept article (free): https://zenn.dev/niixolabs/articles/wine-cef-cross-process-present
The full story (free): https://zenn.dev/niixolabs/articles/m1-mac-steam-wine-story
Complete step-by-step (paid book, ¥800; 3 of 7 chapters free): https://zenn.dev/niixolabs/books/m1-mac-steam-wine-build

We built a mahjong tile-danger predictor calibrated on 4.97M real discards

niixolabs — Sun, 21 Jun 2026 23:04:01 +0000

The idea came from a specific moment at a real mahjong table: one tile in hand, not sure if it's safe to discard. OkkanaiPai is the app Niixo built for that.

How it works

Open the app, swipe to the player you're reading, tap in their discards. The app color-codes all 34 tiles by danger level — no numbers to parse under pressure, just color.

The model is rule-based danger logic calibrated against actual Tenhou Houou-takujo data: 16 days, 4.97 million discards from the top tier of Japanese online mahjong. The calibration coefficients ship as a JSON file bundled with the app. No ML engine runs at inference time. Fully offline.

On the accuracy number

AUC 0.83 on the test set. Mahjong danger prediction has a noisy label problem — "ron" is the only ground-truth signal, and a tile can be dangerous but never called. The number is honest but it has a built-in ceiling.

What it doesn't cover

East round / East seat only — hardcoded, not a config option. Meld (furo) efficiency is out of scope. Three-player (sanma) isn't supported. These are scope decisions. One well-defined setting working reliably comes before expanding coverage.

Why not on-device ML?

We considered CoreML. The coefficient-in-JSON approach is simpler, faster to load, and easier to audit. The tradeoff: calibration is static — it won't adapt to shifts in playing style without a new release. For a reference tool, static and transparent beats dynamic and opaque.

Free, offline, no ads

iOS 17+. No network requests. No in-app purchase. No ads. For a tool you pull out at a table, the friction of an ad at the wrong moment makes it useless.

App Store: https://apps.apple.com/jp/app/id6762544982

We shipped a weather app that learns your personal cold threshold — no ML, just percentiles

niixolabs — Sat, 20 Jun 2026 23:04:31 +0000

There's a gap between knowing the temperature and knowing whether to grab a coat. 14°C means very different things depending on whether you run cold, dress light year-round, or fall sick every season change. Generic forecast apps don't capture that.

Samukunai — 'are you cold?' in Japanese — is Niixo's attempt to close that gap without reaching for a machine learning model.

How it works

After stepping outside, you tap one of three options: 'felt cold,' 'felt fine,' or 'felt warm.' After 10 of those taps, an on-device statistics module we call ComfortEngine computes your personal 75th and 25th percentile comfort thresholds.

From that point forward, your morning push notification shifts from '14°C' to 'on the cold side for you' — or 'about right' — based on where today's forecast lands in your personal range. Processing stays on-device via SwiftData, with CloudKit sync across devices. Weather data comes from WeatherKit.

What we're honest about

Until you hit 10 taps, the experience is strictly worse than a standard weather app. You get less functionality without the personalization that justifies the extra interaction. No home screen widget yet. iOS 26+ only, which is a real constraint given where adoption sits today.

We shipped it anyway. The core problem — cold-tolerance is personal, raw temperature numbers don't capture it — doesn't disappear because the MVP has rough edges. Pure percentile statistics turned out to be a clean enough approach that we could ship without server-side inference or training data.

The stack

WeatherKit handles real-time conditions. SwiftData + CloudKit manages persistence and cross-device sync. ComfortEngine is a local statistics module — the one novel piece, with no external dependencies. The UI runs iOS 26 Liquid Glass.

Free. No ads. No in-app purchases.

https://apps.apple.com/jp/app/id6762537476

We built an app that counts your leg fidgets — the NEAT science and the CoreMotion implementation

niixolabs — Fri, 19 Jun 2026 23:04:46 +0000

Most people have never thought to count how often their leg bounces during a day. We hadn't either — until we built BinBot to measure it.

The scientific premise

Levine's research on Non-Exercise Activity Thermogenesis (NEAT) found that incidental motion like fidgeting can account for up to 350 kcal/day difference between people. Not formal exercise — the constant background micro-movement of someone who simply can't sit still. That number is the reason BinBot exists.

What happens under the hood

The core is CoreMotion sampled at 100Hz, passed through a 3-9Hz IIR bandpass filter. Walking cadence sits around 2Hz; most ambient vibration is above 10Hz. The 3-9Hz window isolates the frequency range where leg-bounce typically lives.

Above the filter, a five-stage rhythm classifier distinguishes three motion types: bounce, jump, and spin. Every session writes its count to HealthKit, so fidget data appears in the same Health app timeline as steps and heart rate. The app also supports Apple Watch, a home screen widget, and Live Activity for the lock screen.

Where it's imperfect

Walking cadence and car vibration occasionally land in the 3-9Hz range and trigger false positives. The filter reduces this but doesn't eliminate it. Watch-to-iPhone sync is currently one-way. Very low-amplitude fidgets may fall below the detection threshold.

We're naming these upfront because the gap between "interesting motion data" and "clinical accuracy" is real. BinBot is firmly in the first category.

Why free with ads

We wanted to see the real variance in fidget counts across different people more than we wanted subscription revenue. Free removes the barrier. The trade-off is ads.

https://apps.apple.com/jp/app/id6760091302

We built a kitten care app where the guidance adapts to your cat's actual age

niixolabs — Thu, 18 Jun 2026 23:04:30 +0000

The problem with kitten care advice online is that most of it is technically correct and practically out of context.

"Feed 3–4 times a day." Sure — but for a 6-week-old or a 4-month-old? "Vaccinate early." When exactly? The answers exist, but matching them to your specific cat's current age, on the day you need them, is the actual friction.

That's the gap we built Nekososdate to close.

How it works

Register your kitten's birthdate. The app calculates their current age and surfaces care guidance calibrated to this stage — not a static checklist, but the information that's relevant right now.

What's inside:

54 care guides across development stages
48 troubleshooting topics
34 breed profiles
A 15-question diagnostic that maps your cat to a personality type and adjusts guidance accordingly
Growth and symptom records

Content is bundled as assets/JSON so it works offline. Built with Flutter and Firebase, subscriptions via StoreKit 2. Free to start, ¥200/month unlocks the full guide library.

The record feature mattered more than we expected

We initially thought the growth record was a nice-to-have. Then we thought about the vet visit.

"When did this start?" Most cat owners guess. With a symptom log in hand, you answer with an actual date. That specificity changes what the checkup can accomplish — and it's the kind of thing you only appreciate in the moment you need it.

Honest limitation

iOS only. No Android version. No family sharing — if two people are raising the same kitten, only one device holds the record. That's a real gap for co-owners, and we know it.

Try it

Nekososdate on the App Store

We built a braille camera that never sends your photos anywhere

niixolabs — Wed, 17 Jun 2026 23:05:00 +0000

We built a braille camera that never sends your photos anywhere

A lot of braille translation tools start from the wrong place. You type in the Unicode braille characters, you get a reading. Useful for developers building accessibility pipelines, less useful for someone standing at a train station wondering what the handrail says.

TenjiScan does one thing: point your iPhone camera at braille, get text. On-device, offline, no account, no photo upload.

Why the on-device constraint matters

The privacy consideration wasn't an afterthought. When you're photographing a pill box, a medication label, or something on a person's belongings, you probably don't want those images going to an external API. As of v4.0.0, the entire pipeline runs on-device — nothing leaves your phone.

We built on top of Vision with a custom two-signal pipeline for detecting and interpreting braille dot patterns. The app handles Japanese braille (JIS standard) and English braille (UEB Grade 1) — the everyday kind you find on train handrails, elevator buttons, and product packaging.

What it doesn't do yet

Grade 2 contracted braille — the kind that uses abbreviations to compress meaning into fewer cells — isn't supported. Grade 1 only, standard cell-by-cell transcription.

Accuracy also depends on lighting and angle. Flat surface, even lighting, camera roughly parallel to the surface: that's the sweet spot. Steep angles and harsh shadows degrade results noticeably. We document this in the app description rather than glossing over it.

The actual use case

The people who find it most useful usually aren't studying braille. They're curious. A commuter who's ridden the same line for years and finally wants to know what the handrail says. Someone at a pharmacy wondering what's on the side of the box.

Ambient curiosity about text that's been there all along — that's the use case. Narrow, but real.

Try it

Free to download. One-time ad-removal purchase, no subscription.

https://apps.apple.com/jp/app/id6759526188

We built an app for Japanese neighborhood associations — and the handover notebook turned out to matter most

niixolabs — Tue, 16 Jun 2026 23:04:12 +0000

The problem

Every year in Japan, a small group of volunteers runs the local 自治会 (neighborhood association). They circulate bulletins, collect dues, check in on elderly residents, run votes at general meetings, and maintain the annual schedule. At year's end, they hand the role over — usually with a folder of paper, or nothing at all.

Nobody tracks who did what. Nobody measures the actual workload. So when it's time to recruit the next round of officers, no one can honestly answer "how much work is it?" And the handover is always rough.

That's the loop Musubiba is trying to break.

What's inside

Musubiba covers the full 自治会 / 町内会 cycle in one app: bulletin routing, dues collection, safety checks, general meeting votes, annual schedule, and a handover notebook.

The handover notebook ended up being the feature that resonated most. Officers change annually in most associations — and institutional memory typically walks out the door with them. Making that transition structured means the next person starts from somewhere real, not from scratch.

Members join via QR code. Web-based accounting input is supported for committees that prefer to keep some tasks on desktop. The stack is Flutter (iOS + Android) + Firebase, with Stripe + IAP for billing.

The honest limitation

Musubiba is purpose-built for Japanese 自治会 and 町内会. The workflows, terminology, and community context are Japan-specific — it's not a horizontal tool for HOAs or resident associations outside Japan.

Pricing: free up to 15 members, ¥1,500/month for unlimited.

Where to get it

App Store: https://apps.apple.com/jp/app/musubiba/id6759871374
Google Play: https://play.google.com/store/apps/details?id=com.htor.musubiba

We built a budgeting app that skips the bank login — here's the trade-off

niixolabs — Mon, 15 Jun 2026 23:04:14 +0000

Most budgeting apps open with the same onboarding step: connect your bank account. For a certain group of people, that's where the process ends — not because they can't, but because they won't hand over those credentials to a third-party app.

moneasy is Niixo's attempt to design around that constraint.

Two ways in

The app has two entry points. First: point your camera at a receipt. Apple Vision Framework and Gemini 2.5 Flash handle the OCR — line items, amounts, categories. Second: say "moneasy 記録" to Siri. Apple Speech picks it up, the transaction logs.

No bank login. No OAuth flow. No third-party service in the data path.

The trade-off

There's no bank API. Transactions don't pull in automatically. If you need that, moneasy isn't the right fit — and it's better to say that plainly than have someone frustrated after paying.

CSV import is the alternative. For people who already manage finances in a spreadsheet, that manual step is probably already part of the routine.

What's inside

Voice input: Apple Speech
Receipt OCR: Gemini 2.5 Flash + Vision framework
Storage and sync: SwiftData + CloudKit (private, device-to-device via Apple ID)
Languages: 25

CloudKit sync keeps everything private — no external server in the data path. The architecture fits the design intent.

Honest take

It's built for people who track spending manually and want to lower the friction, not outsource the decision-making. The absence of bank sync is the feature for the intended user and a dealbreaker for everyone else. That's a fine trade-off, as long as it's stated up front.

¥450/month or ¥5,000/year, 30-day free trial.

https://apps.apple.com/jp/app/moneasy/id6742516728

We made a camera app where the shutter sound is your own voice

niixolabs — Sun, 14 Jun 2026 23:33:56 +0000

The default iPhone shutter click is fine. It's neutral, functional, and completely impersonal. Voicame (ボイカメ) is Niixo's attempt to change that in the smallest possible way.

What it does

Open the app, tap record, say something — a name, a word, a sound that means something to you — and that clip becomes your shutter trigger for every photo and video you take. Recorded sounds can be AirDropped to others so they can use the same clip. Everything runs on-device; nothing is uploaded.

Beyond the voice shutter, six symmetry modes run live in the viewfinder: horizontal, vertical, diagonal, quad, kaleidoscope (built on Core Image's CIKaleidoscope), and swirl. They work for photos and video both, and the preview is real-time so you frame the shot before committing.

Why it needed iOS 17.2

The shutter replacement relies on AVCaptureEventInteraction, an API Apple introduced in iOS 17.2. Before that release, swapping the system shutter sound through official channels wasn't achievable. That API landing was what made the app feasible in the first place.

The honest part

Symmetry camera apps are not rare. Kaleidoscope modes, mirror effects — there's existing competition in the category. The voice shutter is the piece that makes Voicame different, and whether that hook lands depends entirely on the user.

Other limits worth knowing: iOS only, no Android, no Apple Watch support. Shutter volume follows the device media volume — there's no independent in-app control.

Availability

Free to download. A one-time ¥250 in-app purchase unlocks all six symmetry modes. Requires iOS 17.2+.

https://apps.apple.com/jp/app/id6768058856

DEV Community: niixolabs

We shipped a camera app where you record the shutter sound yourself

The idea

The symmetry side

What we'd change

Pricing

We built an app where the AI invents its own generators — MakerMaker by Niixo

The core idea

The part we didn't plan

What we're honest about

Stack

Pricing

Off By One: a calm puzzle about finding what's slightly wrong

The problem we were solving

What the app does

What we learned shipping it

Try it

Why Chromium/CEF apps render a black window under Wine (and how to fix it with macOS IOSurface)

The problem

Symptom: the window appears, the contents stay black

Root cause: the process that draws and the process that owns the window are different

Why -cef-disable-gpu is a cop-out

The fix: bridge the processes with IOSurface

Settings that mattered

The transparency wall

How "unusual" is this, honestly

Full patch and build steps

We built a mahjong tile-danger predictor calibrated on 4.97M real discards

How it works

On the accuracy number

What it doesn't cover

Why not on-device ML?

Free, offline, no ads

We shipped a weather app that learns your personal cold threshold — no ML, just percentiles

How it works

What we're honest about

The stack

We built an app that counts your leg fidgets — the NEAT science and the CoreMotion implementation

The scientific premise

What happens under the hood

Where it's imperfect

Why free with ads

We built a kitten care app where the guidance adapts to your cat's actual age

How it works

The record feature mattered more than we expected

Honest limitation

Try it

We built a braille camera that never sends your photos anywhere

We built a braille camera that never sends your photos anywhere

Why the on-device constraint matters

What it doesn't do yet

The actual use case

Try it

We built an app for Japanese neighborhood associations — and the handover notebook turned out to matter most

The problem

What's inside

The honest limitation

Where to get it

We built a budgeting app that skips the bank login — here's the trade-off

Two ways in

The trade-off

What's inside

Honest take

We made a camera app where the shutter sound is your own voice

What it does

Why it needed iOS 17.2

The honest part

Availability

Why `-cef-disable-gpu` is a cop-out