Dev Breakfast · 2026-09-12

Shopify's engineering blog has moved its mobile app from React Native back to Swift and Kotlin, with the title simply stating 'back to native', without disclosing the migration scale or roadmap. The manpower saved from cross-platform development might be spent back on bridging debugging and platform differences. Before considering it as a default option, you need someone who can handle the native layer.

Shopify Migrates from React Native back to Swift and Kotlin

Shopify is moving its mobile app from React Native back to Swift and Kotlin, with the official engineering blog stating "back to native". The original text only has this conclusion, without specifying the migration scale, timeline, or whether it's a full rewrite or reverting new features to native. For frontend developers, it's worth first understanding: does the manpower saved from cross-platform solutions ultimately get spent on debugging native bridges and chasing platform differences? React Native isn't unusable, but before treating it as the default option, first consider if your team has someone who can handle the native layer.

Sources:

• Back to Native

Forgejo 16.0.4 fixes an RCE: template repositories can attack the host

Forgejo released 16.0.4, with the first security fix marked as Critical: versions 16.0.3 and earlier contain a remote code execution vulnerability. The trigger path is not complex—when generating a new repository from a template repository, Forgejo first clones the template, deletes the .git directory, performs variable expansion on files listed in .forgejo/template, and then re-runs git init. The problem lies in that middle step: variable expansion can be abused to recreate a .git folder in the directory, which git then picks up during initialization. Thus, a malicious template repository can read arbitrary data on the Forgejo host and execute arbitrary processes on the host. The fix is straightforward: after variable expansion, clear any existing .git before initialization.

This version also patched three other vulnerabilities worth noting. First, the authorization reducer when editing repository content via API did not consider API-specific restrictions, allowing repo access tokens with restricted permissions to make unauthorized changes. Second, when an organization team is set to admin, it mistakenly gains owner permissions on associated repositories. Third, read-only users (including unauthenticated visitors to public repositories) could obtain metadata and full attachment content of draft releases through the GetReleaseAttachment interface and attachment download routes—both GetRelease and ListReleaseAttachments had checks, but these two entry points were missed. The official note indicates this is the same class of issue fixed upstream in Gitea, corresponding to CVE-2026-27660 and GHSA-q9pg-jj6x-j9p6. Additionally, google.golang.org/grpc was updated to v1.83.1 and golang.org/x/crypto to v0.56.0, both marked with [SECURITY].

Those who self-host Git services should be familiar with such incidents: the code hosting platform itself is often the most valuable machine, holding your code, CI credentials, and deployment keys. The template repository feature is used infrequently, making it easy to overlook—whoever can push a template repository to an organization might exploit this path to access the host. So don't just focus on the version number; also check who has permissions to create repositories. Upgrading to 16.0.4 is the simplest solution; if you can't upgrade immediately, at least restrict the sources of template repositories. As for the statement "self-hosting is safer", this vulnerability reminds us of its prerequisite: patches must be kept up-to-date, otherwise self-hosting merely moves the risk from others to yourself.

Sources:

• Forgejo 16.0.4 release notes

JEP 544: stores native code from training runs in AOT cache

JEP 544 aims to address a long-standing issue with Java applications: slow startup and warmup. HotSpot runs an application through three phases—startup, warmup, and peak performance. Initially, it relies on the bytecode interpreter, profiling as it goes, first having C1 compile "moderately optimized" native code, and once enough profile data is accumulated, handing it over to C2 for a highly optimized version. The CPU and memory spent in this process could have been saved for the application itself. JEP 544's approach is to move this work to a training run: compile application code into native code during the training run, store it in the AOT cache, and make it directly available when starting production runs.

Key constraints must be clarified. This is not an AOT-only mode; in the same run, AOT code and JIT code coexist, switching automatically as needed, and this switching is invisible to the application. Cross-compilation is not supported—the code compiled during the training run must run on the same CPU architecture and feature set. Currently, AArch64 and x64 are supported, with other architectures to follow via future ports. It does not modify application, library, or framework code, nor does it change HotSpot configuration; it only requests the use of the AOT cache. The Serial, Parallel, G1, and ZGC collectors continue to be supported. The workflow is not new but extends the existing AOT cache creation process.

The official comparison is: static compilation provides peak performance at startup without warmup, but it can only optimize for a set of hotspots; changing the architecture, operating system, or JDK version requires recompilation, and it struggles with dynamic class loading, dynamic linking, dynamic dispatch, and reflection—core Java features. Thus, static compiler implementers often adopt incompatible constraints like the closed-world assumption and require developers to pre-mark classes for reflection. JEP 544 takes a different path: AOT handles startup and warmup, while JIT maintains sustained peak performance after workload changes. If you're maintaining startup-time-sensitive services, this JEP is worth tracking; but first confirm that your target architecture is on the support list, and don't expect it to eliminate profiling—it just moves profiling to the training run. The original text does not provide specific startup speedup numbers or indicate which stage this JEP is currently in.

Sources:

• JEP 544: Ahead-of-Time Code Compilation

RTK claims to save tokens, but cost benchmarks don't add up

RTK publicly claims to save tokens, but when someone ran cost benchmarks, the conclusion was that savings don't materialize. The original text only has a title and a brief summary, without detailing which models were tested, how much was saved, or where the discrepancy lies, so don't rush to treat it as a conclusion. What's useful for you is the action itself: saving tokens is not the same as saving money; cache hits, retries, and context bloat can all eat into the numbers. When you see "saves tokens" promoted, first ask which part of the tokens it saves.

Sources:

• Does RTK make AI coding cheaper?

Cognition launches SWE-2: 92.8 on Terminal-Bench 2.1, but don't rush to believe it

Cognition released a new model, SWE-2, promoting it as competitive with Fable 5.1 and GPT-Astra, achieving 92.8 on Terminal-Bench 2.1. The number looks good, but my first reaction is: what task set was this 92.8 tested on, and how far is the evaluation environment from real repositories? Benchmarks like Terminal-Bench test continuous operations in the terminal, which differs significantly from making a breaking change in a large, legacy codebase. Model capability is determined by data, not promotion—first see how it runs on your own set of tasks before considering a switch.

Sources:

• Cognition launches new SWE-2 model
• Cognition's SWE-2 achieves 92.8 on Terminal-Bench 2.1

Microsoft lists Rust as a tier-1 language, original text only has the title

Microsoft has listed Rust as a tier-1 language, a post from the Rust Foundation's website with only a title and no elaboration on specific actions. For coders, it's worth noting the term "tier-1" itself—it typically means toolchains, internal support, and hiring practices will follow, but how exactly it's implemented isn't detailed. To judge whether it's worth following, first see if it's providing resources or just slogans.

Sources:

• Rust is tier-1 language at Microsoft

A single webpage can freeze a Mac: Deathray attack

Someone has made "freezing a Mac" a very simple task: just open an untrusted webpage. This article, titled The Deathray, explains this. The original text only has a title, without reproduction steps or which macOS versions are affected, so don't rush to try it. But the direction is worth noting—things running in the browser ultimately cost you on your machine. Frontend developers should especially remember: the more a page can do, the more it can be used for.

Sources:

• The Deathray: A simple way for an untrusted site to freeze a Mac

OpenAI math proof controversy escalates: accusations shift from plagiarism to training data sources

A few days ago, we discussed OpenAI's math proof being accused of plagiarism and the inability to replicate it internally. Today's item isn't a new event but a layer up in the same controversy: accusations have shifted from "the results plagiarized others" to "the training data sources are illegitimate"—some researchers claim OpenAI used their unpublished conversations to train models, then publicly announced it as a breakthrough. The math community's demand is straightforward: provide proof of where these math contents actually came from.

Why is this layer heavier than plagiarism? Plagiarism disputes authorship, while data source disputes question the legality of the acquisition method itself. The former is an issue of academic etiquette, while the latter is "what right do you have to obtain these things". The former can be resolved with an apology and retraction, but if the latter is confirmed, it affects the legality of the entire data supply chain. The original text only has a title and several social media links, without detailing who is involved or which conversations are in question—wait for solid evidence. But the direction is clear: model capability is determined by data, not by the wording of press releases.

Sources:

• hackernews · pred_
• hackernews · ColinWright
• hackernews · ibobev
• hackernews · kevcampb

---

Is the app you're working on continuing with React Native or migrating back to native? See you at 8 AM tomorrow.

This issue selects 8 items from 70 pieces of information collected over the past 24 hours from X / Hacker News / GitHub Trending (written hourly throughout the day, fact-checked and selected in the morning). Content is generated with LLM assistance, each item includes original source links, and important decisions should be cross-verified.