Berry M4
- Chip
- M4
- Memory
- 16GB
- Storage
- 256GB
Choose a Cloud Mac
Put your development,
Put your development,
build, and experiment tasks on a dedicated physical Mac
BerryVM provides an entire dedicated Mac mini physical node, not a virtual machine. Install project dependencies, run Xcode and Swift toolchains, handle continuous builds, or evaluate MLX workloads on the high-memory configuration.
Confirm software compatibility, memory requirements, task duration, and target node before choosing Berry M4 or Berry M4 Pro. Manage access, project credentials, and signing materials according to your team’s security procedures.
- Service model
- Entire device dedicated
- Available configurations
- 2 options
- Available nodes
- 5
WORKLOAD ACCEPTANCE
Task batch intake
BATCH / DEV-05
Input
Code, dependencies, build parameters
Pending setup
Execution
Xcode / Swift / Runner / MLX
Dedicated node
Output
Build artifacts, logs, experiment results
Delivered by process
Berry M4 Pro
- Chip
- M4 Pro
- Memory
- 64GB
- Storage
- 2TB
Usually available to order
Live availability is shown in the console
iOS & macOS development
Turn a remote Mac into a reproducible development environment
Ideal for developers who need a complete macOS graphical and command-line environment, want to move local workloads to a remote node, or need a consistent toolchain across the team.
Development environment
Xcode & Swift projects
Install the Xcode version, command-line tools, and Swift dependencies required by the project, then run a clean build once. Keep derived data, package caches, and project artifacts in clearly defined directories to avoid untraceable temporary state shared across branches or toolchains.
- Project check:Confirm the project, workspace, Scheme, minimum OS version, and build target.
- Dependency check:Pin versions and lock files for Swift Package Manager, CocoaPods, or other dependency tools.
- Signing preparation:Transfer only the signing materials required for the task, restrict file permissions, and record who is responsible for updates.
- Collaboration:Hand off work through code repositories, artifact repositories, and redacted logs rather than using chat history as a substitute for change notes.
Check these 5 items first
- Device details
- Model, memory, and storage match the order
- System tools
- Terminal, Git, and basic networking work
- Development tools
- Xcode matches the project’s version requirements
- Disk planning
- Store source, caches, and artifacts in separate directories
- Remote session
- Display, keyboard, and reconnect behavior work as expected
CI/CD builds
Design build nodes around queues, caches, and logs
Continuous builds do not end with installing a Runner. Stable, reusable nodes depend on task isolation, cache invalidation, log retention, and concurrency scaling.
RUNNER CONTROL
Build batch / IOS-RELEASE
Node ready
QUEUE
Control the number of concurrent tasks
Start sequentially
Start with a single queue and track CPU, memory, disk, and build-time changes. Add separate devices when parallelism is needed instead of blindly stacking tasks on one node.
CACHE
Make caches identifiable and disposable
Clear by key
Include toolchain versions, dependency lock files, and target platforms in cache keys at minimum. When hit rates drop or dependencies behave unexpectedly, identify and clear the relevant batch instead of wiping the entire device.
LOGS
Keep enough logs to reproduce the issue
Redact first
Save the task ID, commit version, toolchain version, start time, final status, and failure stage. Remove tokens, secrets, and sensitive project fields before uploading.
SCALE
Scale concurrency with devices
Scale by node
When queue wait time becomes the bottleneck, assign new Runners to additional dedicated nodes. Maintain separate labels and working directories for each device so tasks are not scheduled on the wrong environment.
React Native builds
Check the JavaScript and native build chains separately
React Native builds depend on JavaScript packages, native modules, the Xcode project, and signing configuration. Troubleshooting layer by layer makes issues easier to locate than repeatedly reinstalling the environment.
Pin source and dependency inputs
Verify Node.js, the package manager, lock files, and access to private dependencies. Confirm that the working directory is clean before installation so leftover local modules are not mistaken for reproducible dependencies.
- Record Node.js and package manager versions
- Use the committed dependency lock file
- Limit access to private registry credentials
Check native modules
Confirm that Pods, Swift packages, and custom native modules are compatible with the target Xcode version. After upgrading dependencies, validate the JavaScript and native layers separately instead of mixing both error types in one build.
- Verify the iOS deployment target
- Check native module build settings
- Record dependency installation output
Run the Xcode build
Use explicit project, Scheme, Configuration, and export parameters. Associate build logs and artifact directories with the same task ID so failures can be traced to the exact stage.
- Separate debug and release configurations
- Keep redacted logs from the failed stage
- Run integrity checks on artifacts
Deliver artifacts and records
Upload build artifacts to a team-approved artifact location with the commit version, toolchain version, and build result. Never embed long-lived credentials in artifacts or ordinary logs.
- Generate traceable artifact names
- Link the commit version to the build batch
- Clean intermediate files according to internal rules
MLX & AI experiments
Calculate memory needs first, then choose the high-memory configuration
The high-memory option includes an M4 Pro, 64GB of memory, and 2TB of storage, making it better suited to local inference, model loading, and experiments with higher memory demands. Suitability still depends on the model, precision, context length, and concurrency.
High-memory workloads
Tasks to evaluate first on Berry M4 Pro
Model loading validation
Confirm the model format, quantization method, dependency versions, and actual memory usage.
Local inference experiments
Record prompts, context length, batch settings, and outputs to create reproducible experiments.
Data preprocessing
Separate raw data, intermediate files, and model caches so invisible temporary files do not consume all available disk space.
Multi-round parameter comparisons
Change one clearly defined variable per round and record peak memory, completion status, and anomalies.
Do not use the model name as a substitute for capacity planning
Validate the workflow on a small sample first, then choose the rental term based on actual peak memory and disk usage. Include model files, datasets, caches, and outputs in capacity planning.
- Model parameters
- Record the version, format, and quantization method
- Runtime context
- Confirm length, batch, and concurrency settings
- Peak memory
- Use measurements from the actual workload
- Disk capacity
- Calculate models, data, and caches together
- Result delivery
- Plan export and cleanup paths in advance
Remote debugging preparation
Keep the cloud Mac and external test devices in separate roles
A cloud Mac can run development tools, build projects, and collect host-side logs. Connecting external test devices, network reachability, and device-side actions remain the responsibility of your test environment.
Network path
Prove stable communication between both ends first
Record the cloud node, the networks containing external devices, required ports, and connection direction. Test basic connectivity and session stability before moving to application-layer debugging.
Credentials & signing
Grant only the permissions required for the task
Isolate keys, tokens, and signing materials by project, restrict read access, and define update responsibility. Never put credentials in code repositories, build-script output, or ordinary support requests.
Log security
Keep context, not secrets
Logs should include the task ID, timestamp, reproduction steps, and error stage. Before sending them to the support team, remove access credentials, private addresses, user data, and unrelated project content.
Workload-to-configuration mapping
Choose by memory, disk, and task duration
Both configurations are entire dedicated Mac mini physical nodes. Evaluate Berry M4 first for light builds and everyday development; evaluate Berry M4 Pro first for high-memory experiments, local inference, and larger working sets.
| Workload | Evaluate first | Listed specifications | Why choose it | Check before ordering |
|---|---|---|---|---|
| Everyday Swift development and project maintenance | Berry M4 | M4 / 16GB / 256GB | Suitable for toolchain setup, code editing, routine compilation, and single-task validation. | Project size, dependency caches, and derived data usage. |
| Light iOS and macOS builds | Berry M4 | M4 / 16GB / 256GB | Suitable for establishing a reproducible pipeline before adding dedicated nodes as queue pressure grows. | Peak memory, cache strategy, and build queue length. |
| React Native cloud builds | Berry M4 | M4 / 16GB / 256GB | Suitable for checking JavaScript dependencies, native modules, and the Xcode build chain. | Number of native modules, artifact size, and concurrent task count. |
| High-memory Xcode workspaces | Berry M4 Pro | M4 Pro / 64GB / 2TB | More memory and storage suit larger working sets, caches, and artifact directories. | Actual peak memory, disk growth, and rental period. |
| MLX local inference and experiments | Berry M4 Pro | M4 Pro / 64GB / 2TB | Best for model loading, higher memory requirements, and recording multi-round experiments. | Model format, quantization method, context length, and peak memory. |
Clear task boundaries and a lighter working set
Suitable for everyday development, light builds, dependency migration, and a single-queue Runner. Move to a higher configuration if memory or disk consistently becomes a bottleneck.
Higher memory needs and a larger working set
Suitable for larger Xcode workspaces, MLX experiments, local inference, and larger cache directories. Validate capacity against the actual model and task parameters.
Final checks before starting
Have you confirmed the configuration, term, node, and data paths?
Choose the rental term you actually need—daily, weekly, monthly, or quarterly. Before ordering, confirm Berry M4 or Berry M4 Pro, candidate nodes, additional storage, peak task memory, and how build artifacts and experiment data will be delivered.