Choose iOS slim categories per lease, and re-sync slim-labels.ts with simslim's new mdm category

Abierto
  • ¿Algo no está bien?
#1,244 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
ios, typescript
Área
devtools, mobile-dev

Línea de trabajo

Start by reviewing slim-labels.ts and the label changes in MobAI-App/simslim#66, once that PR is merged. Then trace how lease requests apply ios.slim.categories and determine how per-lease category choices should combine with the operator setting. Done means the labels are re-synced and a lease can select slim categories without making ordinary slim leases fail the readback rule or preventing simulator boot.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

The problem

A lease can only choose slim or full, and the slim categories are fixed per host in ios.slim.categories. So a test that needs one slimmed capability has to take a full simulator, and on our farm that costs a great deal. Our PassKit tests are the example. On an iPhone 17 Pro / iOS 26.2, a full lease taken only for Wallet costs 5.7 GB, which is 4.5× one of our slim leases. That one dependency decides how many simulators fit on the host.

Separately, MobAI-App/simslim#66 adds a mdm category, and moves com.apple.accessibility.axassetsd and com.apple.ClipServices.clipserviced into other. On a fresh iOS 26.5 simulator that takes a fully slim one from 904 to 847 MiB under simslim measure, with 6 fewer processes. On our iOS 26.2 farm sims, which had been running tests, the same daemons were heavier: the device-management ones alone came to about 149 MB.

Who runs into this

We run a shared Mac Studio farm. The CI e2e and store-screenshot jobs of several React Native/Expo apps lease simulators from it through simlock. Most jobs are happy with slim. A few need one capability, such as Wallet/PassKit, so they lease full, and those leases crowd out the slim ones.

What you would like to happen
  1. Re-sync slim-labels.ts from simslim once MobAI-App/simslim#66 is merged.
  2. Choose slim categories per lease. For example, a lease request could carry except: ["store", "other"], or a lighter full that keeps only the named categories, on top of the operator's ios.slim.categories. For the PassKit case, keeping just store/other (passd, financed) would, we estimate, put that lease at about 1.6 GB instead of 5.7 GB.
Anything else

While preparing the simslim PR, I found two traps worth knowing before anyone extends the label list by hand:

  • The iPhone-side Watch companion labels drift. These are the 17 that CoreSimulator writes as explicit false into disabled.plist: NPKCompanionAgent, appconduitd, pairedsyncd, bulletindistributord, eventkitsyncd and others. On iOS 26.5, CoreSimulator rewrites them to false at every boot, even after they were written true while the device was shut down. Under simlock's readback rule ("a label not as written → full"), adding them would turn every slim lease into full.
  • simslim's forbiddenLabels still wedge iOS 26.5. I persisted the disable for sleepd, dmd, ManagedSettingsAgent, routined, biomesyncd, mobiletimerd and the nano* registry daemons on a throwaway simulator, and it never finished booting. SpringBoard looped on com.apple.sleepd.sleepserver, and appprotectiond looped on com.apple.dmd. The farm memory we saw from stopping them only applies to a live bootout after boot, never to a pre-boot override.
Lenguaje dominante
TypeScript
Estrellas
535
Forks
21
Merge medio
9 h 26 min
PR fusionados (30 d)
437

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de callstackincubator/simlock

Todos los issues de callstackincubator/simlock

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.