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!

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

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/

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. 👨🏻‍💻☁️🌌

I've been building TUFF, a native macOS app for running local LLMs, and the inference engine is written from scratch in Swift with Metal 3.2+ — it doesn't wrap llama.cpp or MLX.

The interesting part from a Swift-engineering angle: it keeps the shared parts of a mixture-of-experts model resident in memory, then streams the experts it needs from SSD through a bounded cache, reusing them across requests. That's how a 61 GiB checkpoint can run on a 16 GB MacBook Air without touching swap. Requires macOS 15+ and Swift 6.2+ to build.

Just shipped 3.0.0: rebuilt the chat interface around a unified conversation model (images persist across turns, files attach as typed objects rather than raw text), added two new Gemma 4 variants, fixed architecture-based routing for optional image packs, and squashed several catalog/stability bugs.

It's Apache-2.0 and started as a fork of drumih/turbo-fieldfare. Source: https://github.com/rexmhall09/TUFF — site: https://rexmhall09.github.io/TUFF/

Happy to talk through the Metal/Swift side of the inference engine if anyone's curious — and if you find it interesting, a star helps.

This literally never worked properly for me since its existence, multiple computers, multiple xcodes, that’s why i never use it, first thing i do in a new project is to hide the preview column. But today i wanted to and it pissed me off. First, if it works, i basically wait for the whole app to compile, then i either get an error, either the preview. I change something, i wait again for the whole app to compile, actually i can launch the app faster than i wait for the preview to come with a result or an error. It is freaking slow and it barely works, sometimes.

I am making a simple game. Image 1 has to move towards image 2. Image 2s movement is random (not relevant to my question).

Is there a way to get image 2s coordinates so that I can update image1s position with .position(x: ,y: )? Or am I approaching this problem the wrong way?

Coding agents (Claude Code, Codex, Gemini CLI) work best unattended, but giving them that freedom on your own machine is the risk. I wanted VM isolation with a real enforcement boundary, in Swift, open source — so I built it.

The core trick: Apple's Containerization package exposes a public VZInterface protocol. Instead of the stock NAT attachment (which gives the guest a real route out), sandbox supplies a conformer returning VZFileHandleNetworkDeviceAttachment — a virtio-net device whose wire is a datagram socket held by the sandbox process. The VM gets exactly one network device, so every TCP dial, DNS query and UDP datagram terminates at a userspace gateway enforcing a default-deny allowlist. Root inside the guest changes nothing, because the enforcement is outside the guest.

API keys never enter the VM either: the agent sees a sentinel value and the gateway injects the real credential at the TLS boundary, only for verified upstreams.

Numbers, measured not guessed: ~60 MB of host processes per sandbox, ~0.5 s warm starts, and zero marginal disk (rootfs is an APFS copy-on-write clone — starting a sandbox changes free space by nothing).

Apache-2.0, early (0.1.x) but verified by ~165 end-to-end acceptance tests against live VMs. Would love feedback from anyone who knows Virtualization.framework's darker corners.

Repo: https://github.com/satishbabariya/sandbox

I’ve found a way that Xcode can deploy remotely to an iPhone instead of being limited to local Wi-Fi. Please check out my repo on GitHub:

https://github.com/zjz-connect/xcode-deploy-link-deploy-beyond-local-network

If you have better ideas, feel free to leave comments!

Found this while fuzzing my encrypted messenger.

XCTest installs a global observer on every throw, making it 40x slower (16.8s vs 0.42s). try?does NOT avoid the cost.

Full breakdown, minimal reproduction code and fix here: https://github.com/MagicYassin/xctest-throw-cost

Do check the numbers on your own machine. 👨🏻‍💻☁️🌌

I’ve found a way that Xcode can deploy remotely to an iPhone instead of being limited to local Wi-Fi. Please check out my repo on GitHub:

https://github.com/zjz-connect/xcode-deploy-link-deploy-beyond-local-network

If you have better ideas, feel free to leave comments!

I always keep my @.State private but this was interesting to know.

Source: https://x.com/pointfreeco/status/2093052971890229285?s=20

I built AnyDocSwift, a SwiftPM wrapper around Firecrawl’s anydoc https://github.com/firecrawl/anydoc.

It lets native macOS apps convert Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and text-based PDF files into Markdown.

Conversion runs locally on Apple Silicon. SwiftPM downloads a checksum-pinned XCFramework automatically, so consumers don't need Rust, Cargo, an external service, or a subprocess.

```swift

import AnyDocSwift let markdown = try await AnyDocConverter().markdown( from: documentData, fileExtension: "docx" )

```

Requirements:

• macOS 13+

• Apple Silicon

• Swift 6.1+

The package includes typed errors, cancellation handling, input/output limits, and FIFO execution per converter instance.

GitHub: https://github.com/ngutech21/anydoc-swift

This is the first public release, so I'd appreciate feedback about the API, and real-world use cases.

Hey everyone! I’m a final-year Informatics student with a bit of UI design experience. I’ve done a few internships at creative agencies/studios, mostly handling UI for marketing stuff, Dribbble shots, and UI template production. Still pretty light on actual UX or product thinking though.

I’ve known about Apple Developer Academy since my early uni days and have always wanted to join. I’ve applied three times already since 2023 (including the Sep 2025 intake), but I keep failing at the online test stage every single time.

I’m planning to try again for Batch 2 / Cohort 2027, but I’ve only got about two weeks left to get my CV, portfolio, and online test prep sorted. Would really appreciate any advice:

1. Does my background actually help or hurt? I’m an Informatics student with UI experience, but not much real UX/product experience. Does having a relevant background even matter much in the selection?
2. What should I prioritise for the online test? I’m quite weak at logic/aptitude tests, and doing everything in English makes it even harder. Which topics should I focus on most? Logic puzzles, patterns, seating arrangements, pseudocode, basic programming, conditional statements, etc.?
3. Any good FREE resources or platforms? Most aptitude test sites I found are freemium and super limited. What did you guys actually use to practise?
4. Is two weeks realistically enough? If you were in my shoes, how would you split the time between CV, portfolio, and the online test? What would you prioritise?
5. Does the campus or application location affect acceptance chances? I’ve heard BINUS might reserve around 50% of the slots for their own students, but I’m not sure if that’s still true or current. Any alumni or previous applicants who know about this?
6. Any other tips? Especially things you wish you’d known before applying.

Thanks a lot! Any advice from alumni or previous applicants would mean a lot for me🙏🏻

Cycle Status

Character Categories Cycles

• CJK Characters 1 (Every 3 Versions)
• CJK Characters 2 (Every 9 Versions)
• New Symbols 1 (Every 5 Versions)
• New Symbols 2 (Every 12 Versions)
• New Arabic Characters (Every 5 Versions but can be different sometimes)

Amount of Writing Systems and Additions Cycles

Note: The Cycles mean that are not the same as the iOS version numbers. (Example: iOS 4.1 is Cycle 5, iOS 18 is Cycle 20, and iOS 27 is Cycle 22.)

Note: All 2 Writing System Cycles and 1 Writing Systems Cycles must be Living/Modern Writing Systems.

There are 64 cycles. The cycle will go back to cycle 1 every 64 versions/cycles.)

• Cycles 1, 9, 17, 25, 33, 41, 49, 57 (2 Writing Systems and various amount of Large/Small Additions)
• Cycles 2, 10, 18, 26, 34, 42, 50, 58 (2 Writing Systems and 2 Large Additions)
• Cycles 3, 4, 11, 12, 35, 36, 43, 44 (Large Amount of Writing Systems 1)
• Cycles 5, 21, 37, 53 (1 Small/Normal Writing System (not large) but with large amount of Characters that are not Noto)
• Cycles 13, 29, 45, 61 (1 Large Writing System but with large amount of Characters that are not Noto)
• Cycles 14, 30, 46, 62 (1 Small/Normal Writing System (not large) but with only 2 Characters that are not Noto)
• Cycles 6 & 38 (1 Large Writing System but with only 2 Characters that are not Noto)
• Cycles 22 & 54 (No Writing Systems and no Noto but with only 2 Characters that are not Noto)
• Cycles 8, 15, 24, 31, 40, 47, 56, 63 (Large Amount of Additions from Writing Systems from Noto and not)
• Cycles 7, 16, 39, 48 (Large Amount of Writing Systems 2)
• Cycles 23, 32, 55, 64 (1 Large Addition from a Writing System that can be Noto but with many characters that are not noto)
• Cycles 19, 20, 27, 28 (1 Small Addition from a Writing System that can be Noto but with few characters that are not Noto)
• Cycles 51, 52, 59, 60 (2 Small Additions from 2 Writing Systems that can be Noto but with few characters that are not Noto)

Current Cycles (2007-2026)

• iPhoneOS 1 (2007) (2 Initial Writing Systems (Latin and Cyrillic) and Initial Symbols)
• iPhoneOS 2 (2008) (2 Initial Writing Systems (Kana and Hangul) and Initial CJK)
• iPhoneOS 3 (2009) (4 New Writing Systems (Greek, Hebrew, Arabic, and Thai))
• iOS 4 (2010) (New Writing Systems Update including Devanagari, Tamil and others)
• iOS 4.1 (2010) (1 New Writing System (Cherokee))
• iOS 4.2 (2010) (1 New Large Writing System (Tibetan) and 2 CJK Additions))
• iOS 5 (2011) (10 New Writing Systems (Bengali, Gurmukhi, Gujarati, Oriya, Telugu, Kannada, Malayalam, Sinhala and others) and Initial Emojis)
• iOS 6 (2012) (New Additions, New Arabic Characters, and Extended Symbols)
• iOS 7 (2013) (2 New Writing Systems and introduces Plane 2 CJK Ideographs)
• iOS 8 (2014) (2 New Writing Systems (Lao and Khmer) Extended Devanagari support and Introduces Latin Extended-C and D)
• iOS 9 (2015) (50 New Writing Systems and introduces Noto, New CJK Ideographs, New Enclosed CJK Letters, and CJK Strokes)
• iOS 10 (2016) (12 New Writing Systems (Including Thaana, Myanmar and others) and New CJK Ideographs and introduces Extension E)
• iOS 11 (2017) (1 New Large Writing System (Ethiopic), New Arabic Additions, and New Symbols (Including STIX Math))
• iOS 12 (2018) (1 New Writing System (Chakma) and introduces 2 new additions)
• iOS 13 (2019) (10 New Script Additions, New Symbols Categories (Including Hexagrams, Alchemical Symbols and others) and a few CJK Ideographs)
• iOS 14 (2020) (40 New Writing Systems (Including Osage, Adlam and others) and new Vedic Characters)
• iOS 15 (2021) (2 New Writing Systems (Masaram Gondi and Gunjala Gondi) and 4 small additions for (Nko, Syloti Nagri, Old Italic, and Adlam))
• iOS 16 (2022) (2 New Writing Systems (Yezidi and NP Hmong), 2 Large Additions for Canadian Syllabics and Mongolian, New Symbols, and CJK Additions)
• iOS 17 (2023) (1 Small Addition for Tagalog (3 Characters))
• iOS 18 (2024) (1 Small Addition for Brahmi (6 Characters) and 5 new CJK Ideographs including the Biang)
• iOS 26 (2025) (1 New Writing System (Nag Mundari) and new CJK Ideographs)
• iOS 27 (2026) (No New Writing Systems but adds a Gurmukhi and Devanagari addition)

UPDATE: Thanks all for the feedback! I decided the best way to handle this is to push an update for the existing app with export functionality. That way, the Core Data can be serialized to JSON. Then I will create another update for the app with the new SwiftUI / SwiftData target (using the same bundle ID.) This will have import functionality, and can pull in the old data so the user has no data loss.

ORIGINAL POST:

I have an app in the Mac app store but it hasn't had an update in years. I have put together an update (it's really an entire rewrite) and want to release it, but I don't want to use the same bundle ID because I'm using Swift Data and the old one was Core Data, and I'm worried about migration problems so I figure I would just use a new bundle ID. So if my old name was MyApp I just want to call it MyApp 2.

What's the best way to manage that? I don't really want both of them up there. I think that would be confusing. Do I just need to remove the old one and submit the new one?