Apple cluster control means one computer as the master, turning work that used to be tapped by hand, one phone at a time, into one dispatch and a batch run. The iPhone itself does not need a jailbreak.
Why batch operations is tiring, and what the offline activator covers
Hosting providers and Apple cluster control operations teams spend the most time preparing the environment for a hundred iPhones: pairing certificates, developer disk images, WiFi debugging, and self-activation. Each stage means switching among several screens. A few minutes per phone by hand is several hours for a hundred, and it is easy to skip a step, miss a trust prompt, or mismatch an image version, then go back and check phone by phone.
From a new iPhone to one that can run automation is a fixed chain:
Device connection → trust pairing → flash the developer disk image → write the device ID (initialize)
→ install the main program → push the pairing file → turn on WiFi debugging → confirm the self-activation environment is ready
If any stage fails, every stage after it is unusable. By hand you also switch among the central control, i4Tools, and system settings. The steps depend on each other and cannot run in parallel. Once the count is high, time stacks by the number of phones. The offline activator pulls environment preparation into one screen: select devices, run in a batch, read the result column, with no code. The word offline in the name means that after a script is sent to the device, the device can run on its own without the computer. What the activator has to do is prepare that standalone environment in one pass. The activator itself is always a desktop client running while connected to the computer.
When you install the main program, iOS 15 and above can use offline main program v7.2.0 and above as the USB automation program. The official download page has a pre-signed IPA you can use for testing. Below iOS 15 it does not apply. The offline edition supports iOS 15 and above only. From 7.0.0, a single app installs only the main program. A dual app also installs an agent IPA.
What it can do:
| Capability | Note |
|---|---|
| Batch initialize | Write the device ID into the phone and bind the device to the main program |
| Batch generate pairing files | Generate trust pairing certificates between devices and the computer in a batch |
| Batch push pairing files | Push the pairing certificates to the phones |
| Batch push image files | Push the developer disk image to the phones |
| Scan device IPs | Scan the LAN for the WiFi IP of devices that are already initialized |
| One-click self-activation environment | WiFi on + pairing generated + image and pairing pushed in one pass |
| Self-activation test | Confirm the environment is ready. Internal or external VPN |
| Single-device actions | Initialize, flash the image, restart, view the pairing certificate, copy the device ID or ECID |
Batch initialize writes the device ID into the phone. Later binding depends on it. Without initialization, the main program cannot tell which machine it is, and licenses and tasks will not line up. Batch generate and push of pairing files turns a trust credential that takes tens of seconds per phone into tens of seconds for a batch. Batch push of the image keeps the image version the same across a batch of devices. Without the image the connection is unstable and commands do not go out. Scan device IPs finds devices on the LAN that are already initialized, so you do not copy IPs by hand. One-click self-activation combines the earlier steps into one and skips fewer steps. The self-activation test runs once after the environment is ready and confirms it really is ready.
Five steps to get started
Get the materials together before a batch action, so you do not get stuck in the middle:
| Material | Check |
|---|---|
| Main-program IPA | Installed on the phone, signature valid, in the foreground |
| BundleId | Copied from the central control and saved. Separate several bundle names with English commas |
| Developer disk image | The file is in bridgebin\config\DeveloperDiskImage, and the version matches the device iOS |
| Computer environment | The central control is running, the USB driver is fine, and the powered hub is plugged in |
| Network | Before WiFi debugging, confirm the device and the computer are on the same LAN |
Step 1, connect the device. Start the EasyClick central control (ioscenter.exe), click the offline activator on the top toolbar, and choose the new interface. Connect the iPhone with a USB cable, confirm i4Tools can recognize it, click refresh devices, and the device appears in the list with the connection type showing USB. If the list is empty, check the cable, the USB port, and whether i4Tools recognizes it. For a batch connection, connect a few first, and fill the rest after it is stable.
Step 2, configure the BundleId. On the BundleId configuration card, enter the main-program BundleId. It is required. Separate several with English commas. If you will use start automation service, also enter the agent BundleId, then save. In the dual-app setup, the agent IPA is the program this field points at. From 7.0.0, a single app installs only the main program and you leave the agent bundle name empty. If you do not know the bundle name, in i4Tools under Apps and Games, right-click the app and choose copy identifier. Initialization writes the device ID into a specific app’s storage. Leave it empty and there is no way to know which app to write, and later licenses and starting the service will not line up.
Step 3, flash the developer disk image. Select the devices (multi-select is fine), choose Environment on the toolbar, then flash image. The image column turning green means success. On failure, check whether the image file is in the bridgebin\config\DeveloperDiskImage directory and whether the phone is unlocked and trusts the computer. When device iOS versions are not the same, check the image against the version first. A version mismatch often still flashes, and afterward the connection is unstable and commands fail now and then, which looks like a network problem. Group devices by iOS version.
Step 4, batch initialize. The main program is already on the phone and in the foreground. Select the devices, go through self-activation, batch actions, batch initialize, and wait for the message column to show success.
Step 5, turn on WiFi debugging. This step is optional. For a wireless connection, select the devices, go through WiFi debugging, turn on WiFi debugging. After success, the debug address column shows the device IP. When the device and the computer are on the same LAN, connect directly by IP. WiFi debugging depends on network quality. With many devices, plan the channel and the bandwidth first.
How to run a batch, how to troubleshoot, and the mistakes
The recommended batch flow:
Select devices (select all is fine)
→ batch generate pairing files
→ batch push pairing files
→ batch push image files
→ one-click complete the self-activation environment (or run the steps separately)
→ self-activation test to verify
→ bind the license in the license center
→ return to the activator, refresh, and confirm the status
Selecting dozens or a hundred at once buries a failed step in the result column. Batches of 10 to 20 are clearer. After a batch run, filter the devices whose message column is abnormal and handle them one by one. Do not let one device stall the whole batch. The first time you prepare a new environment, walk the full flow by hand on one phone, then use the batch button. The left side of the activator shows the license validity of each device. An expired row shows ×. Bind the license in the license center of the central control. Rebinding and transfer are supported. After binding, refresh the activator and you can see the latest status.
After the environment is ready, accept against this list before you put it into use: the initialize column is success on every device, and the device ID matches the ledger; the image column is green, and the version has been checked; the pairing file has been pushed, and the trust state on the phone is normal; devices that need wireless management have WiFi debugging on and have an IP; the self-activation test passed on all of them; the license is bound, and the validity covers the period of use; pick 2 or 3 phones at random and run a real script once to confirm the path works end to end. After a license expires, the device cannot start the automation service. Keep a license ledger, write down the expiry date of each phone, and renew ahead of time, so a whole batch of tasks does not stop halfway through.
When something goes wrong, troubleshoot from near to far
Common problems:
| Symptom | What to do |
|---|---|
| Initialize says fill in and save the main-program BundleId first | Set the BundleId and save it, or the device ID cannot be written |
| Start automation service says the agent BundleId is missing | Fill in the agent bundle name |
| Pairing file generation failed | The phone needs a lock-screen passcode. Generating again overwrites the old certificate. Tap trust on the prompt on the phone |
| Disk-image flash failed | Check the image directory and version. Live Screen in i4Tools can trigger one image push |
| Self-activation test failed | WiFi debugging has to be on. The pairing certificate has been pushed. The phone is on WiFi (mobile data will not do). External VPN mode needs LocalDevVpn installed |
| The device list is empty | Check the cable, i4Tools recognition, refresh devices, and try another USB port |
| The debug address column has no IP | Confirm WiFi debugging is on, the device and the computer are on the same LAN, and the router is not isolating clients |
Troubleshoot from near to far: read the error in the result column first, then the preconditions of that stage, and last the directory, the version, and the network. When the self-activation test fails, check four preconditions first: WiFi debugging, the pairing certificate, the WiFi connection, and the VPN component. Most problems are in those four.
The batch button saves repeated clicks. The result column still has to be read. Skipping the single-phone check and going straight to the full set doubles the rework when the setup has a problem. The order is one phone, ten phones, then the full set. When the image and the iOS version do not match, it often looks like an unstable network. Handling a license after it expires is more work than keeping the ledger. After WiFi debugging is on, network quality directly decides whether control stays stable.
About EasyClick: A mobile automation script development platform covering three phone ecosystems: Android without root, iOS without jailbreak, and HarmonyOS. It also offers Apple script writing, Apple cluster control, Android cluster control, remote cloud control, and AI phone cluster control. → Explore all products
Ready to build it for real?
Every approach in this article can be built on the EasyClick phone automation platform — full documentation, developer tools and cluster/cloud-control products, free to try.