Summary: In September 2026, Apple’s machine-learning research team published SimpleDesign, a protein sequence-and-structure co-design model trained directly in data space with one end-to-end objective. The approach removes the separate autoencoder and latent stage that conventional generative pipelines use, leaving one model, loss curve, and checkpoint to debug. The supplied paper page reports competitive benchmark results but omits per-benchmark numbers, training compute, and inference cost, and does not establish how the design scales.
Generative protein models usually inherit their recipe from image and video research: an autoencoder compresses the data into latents, and a generative model is then trained inside that compressed space. The recipe does work, but it costs two separate training runs, two sets of hyperparameters, and a latent representation that may silently throw away the detail you care about.
In September 2026, Apple’s ML research team published a paper arguing that protein co-design may not need that two-stage arrangement at all. Their model, SimpleDesign, is trained directly in data space with a single end-to-end objective.
What the single-stage objective actually consists of
According to the supplied paper page, a single loss brings two parts together: discrete cross-entropy for amino acid sequences, and a regression objective for 3D structures. There is no separate tokenizer stage, and no frozen latent space sitting in the middle.
Because sequence and structure are different kinds of data, the authors handle them with Transformer-based multimodal backbones: modality-specific processing is allowed while global self-attention is kept across both modalities. The training set spanned over 2M sequence-structure pairs, and the paper reports competitive performance on co-design and unconditional sequence/structure generation benchmarks.
What deserves attention here is not a speed argument for one stage. It is that nobody had validated the multi-stage assumption for this problem in the first place. The authors state their hypothesis directly: multi-stage training is not necessary to get a performant co-design model.
Why this matters if you build on protein models
Anyone who has wired a protein design pipeline together knows where the friction lives. The autoencoder exists as a separate artifact, carrying its own version, its own evaluation, and its own failure modes. When generated structures come out wrong, you must work out whether the fault lies with the generative model or with the compression step underneath it. A single-stage objective removes that ambiguity — there is one model to debug, one loss curve to read, one checkpoint to ship.
That is a real reduction in operational surface area, and it is the kind of change that matters more to a small team than a benchmark point or two. The same instinct appears elsewhere in the stack: a single persistent kernel reshapes how code models get served, because collapsing stages stops you paying coordination overhead you never noticed.
What the paper does not settle
Competitive benchmark results are reported on the supplied page, but per-benchmark numbers, training compute, and inference cost are absent. Nor does it say how the single-stage approach behaves if you push dataset size or model size further — whether it scales the way latent-space training does. Answers to those questions decide if this becomes a default or stays one lab’s result.
One related thread is worth reading alongside it. Apple’s earlier SimpleFold work, published September 24, 2025, asked whether folding models require heavy domain-specific architectural design at all. Both papers carry the same skepticism toward inherited pipeline complexity.
A practical way to read this
When you evaluate protein design models for a product, treat “single-stage” as something to ask vendors and open-source projects about, not a settled advantage. Three things are worth asking: what the loss combines, what data the model saw, and whether the reported benchmarks include the tasks you actually need. SimpleDesign is interesting because of the hypothesis it tests — that a simpler training recipe can hold up — and you can test that against your own evaluation set instead of taking it on faith.