Long-time mobile/product lead here. Looking for outside perspective because I'm now questioning myself after a long argument with my boss.
Context: I work on external client apps as well as our main customer portal app — the one used by the majority of our customer base. Our mobile apps are native, built about 6 years ago:
Android: Java/Kotlin + XML
iOS: Swift + UIKit
Web: React
100K+ users. Zero limitations adding features or maintaining these apps over the years.
What's happening: We have a full revamp of the apps and portal coming up, and we're updating our tech stack too. My plan:
Android → Kotlin + Compose
iOS → SwiftUI
Web → (TBD, staying on modern React-based stack)
I already have multiple Android, iOS, and web devs trained on this stack.
The conflict: My boss wants to consolidate to Flutter — one team, one codebase, covering web/Android/iOS. His argument: if I put 6 frontend devs on one Flutter codebase instead of splitting across native platforms, we ship 3x faster.
My pushback:
We have zero Flutter training on the team right now
Native apps perform better and feel more premium due to platform specific UIs.
We have built Flutter apps before, but only for external client projects, not our own flagship product
He thinks I'm biased toward native because it's my background. Might be some truth to that, but I don't think that's the whole story.
Anyone actually shipped a migration like this — native to Flutter, or vice versa, at similar scale? Did the "one codebase, ship faster" promise hold up? Would love real-world experience, not theory.

Hi everyone. I want to share a project I have been working on called Axiom.

It is a Calculus of Inductive Constructions kernel written in pure Swift. You give it terms and it tells you if they type check. Think of it like a tiny Lean that lives directly inside your iOS or macOS app instead of running as a separate tool.

I built this because I wanted real proof checking on Apple devices without dealing with external programs. You just import Axiom and check proofs right next to your UI or your machine learning models.

The coolest part for me is the AI angle. Local models hallucinate math constantly. Axiom acts as a strict filter for this. The model proposes a proof step, the kernel verifies it, and only the valid math gets through. Right now it handles universes, dependent types, lambdas, inductive types and pattern matching.

On the testing side I tried to hit the things that usually break CIC kernels: universe hierarchy (no Type : Type), strict positivity on inductives, structural termination, capture free substitution with de Bruijn indices, and classic paradox patterns like Girard and Hurkens. I also run differential checks against Lean 4’s kernel on random terms, and so far Axiom has not accepted anything Lean rejects.

I know I am not replacing Lean or Coq with this. But for the Swift ecosystem it is a really solid start. My long term plan is to build a local proof playground. You ask a math question in plain English, a local model turns it into formal math, Axiom checks it, and you get the answer back entirely on device.

Repo: https://github.com/acemoglu/Axiom

Would love to hear your thoughts or feedback!

There's a hackathon running Sept 18–27 with a rule I haven't seen elsewhere: 100% native Swift/SwiftUI, no external dependencies allowed. No Firebase, no third-party UI kits — just Apple's own frameworks.

Solo or teams up to 3, submission via GitHub (no App Store listing needed). Judged on functionality, code quality, creativity, and how well you use Apple's native APIs.

Mostly curious what people build when the safety net of third-party libs is gone — MapKit, Core Data, on-device AI, whatever native tools you'd normally skip.

Here's the link if you want the details / to register: https://acoding.academy/hackaton26/

The latest LocalLM Lab SDK lets your app offer a choice of using Apple's on-device model, Claude or a fully local open-weight model per task in your app. Some of you may have seen an earlier version of this SDK. 1.0.0-beta.1 adds the model layer that makes this multi-way choice possible.

``````swift
let lab = LocalLMLab(configuration: .init(providers: [
    SystemModelProvider(), ClaudeModelProvider(auth: .apiKey(key)), MLXModelProvider(),
]))
lab.models.route(.heavy, to: ModelID("mlx:mlx-community/Qwen3-8B-4bit")!)
lab.models.route(.light, to: .system)
let session = try lab.makeSession(route: quickTask ? .light : .heavy, tools: myTools)

MLXModelProvider handles the download lifecycle (preflight against available RAM before pulling weights, progress stream, a post-download capability probe since not every downloaded model reliably tool-calls) and residency (how many models stay warm at once, eviction events).

Two new reference apps are included: code-buddy, a CLI coding agent using .heavy/.light MLX routes plus Workspace tools and an MCP docs server; repo-qa-local, the minimal version.

More details on Swift Forums: https://forums.swift.org/t/locallm-lab-1-0-0-beta-one-model-calling-api-across-apples-on-device-model-claude-and-local-open-weight-models/89319

Guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md

Feature page: thisbrain.ai/locallm/1.0.0-beta

I’ve been building Reality Prep Pro in Swift for macOS, alongside Reality Prep Preview for visionOS.

The workflow is:
1. Prepare and optimise assets on Mac;
2. Verify the USDZ on Vision Pro;
3. Bring the device-side validation evidence back into the Mac app.

I’d really value feedback from Swift/Apple developers on the workflow, reliability and any edge cases you hit with real assets.

Both apps are intended to be used together.

Reality Prep Pro: https://apps.apple.com/us/app/reality-prep-pro/id6767673652?mt=12

Reality Prep Preview: https://testflight.apple.com/join/ySbVmz6b

Thanks very much to anyone willing to give them a spin.

A few days ago I posted about the hidden cost of throw in XCTest. I didn't stop there and decided to dig way deeper to see what else was lurking behind that hook.

Spoiler: it's not just XCTest. Swift Testing has the hook too (although it's quite a bit cheaper). And the worst part isn't just the slowness, it's that every throw gobbles up ~2.1 KB of memory that isn't freed until the test ends. With millions of throws (like in my Kalego fuzzing), that turns into an instant OOM crash.

In the report (12 pages, 21 experiments) I've got the assembly analysis, the fixes table, and the reasoning behind every result.

Link to the repo with all the reproducible code here: https://github.com/MagicYassin/xctest-throw-cost

A big shoutout to u/ThatGuy739 and u/Dry_Hotel1100 for pushing the research forward in the last thread. You guys are absolute legends. 👨🏻‍💻☁️🌌