Build stuck? Start here.

Open the relevant instance in the control panel and check its machine ID, service status, and expiry date. Use the connection address and login details shown on that instance's details page. Don't reuse details from an earlier order or another customer's machine.

Once you've confirmed the address, check the Remote Desktop client's connection method and account. If the client times out, try again on a different local network. If authentication fails, check the username, password, and keyboard layout. Don't keep changing passwords without distinguishing between these two errors.

If it still fails, note the client name, full error message, time, and time zone. Redact passwords from screenshots. Connection credentials are available only in the signed-in instance details; never post them publicly.

Find the SSH address, port, and username in the instance details in the control panel. For a connection timeout, first check the address, port, your local outbound network, and the machine status. If authentication is denied, check the account and the authentication method you're using.

For more detail, add -v to your existing connection command and see whether it gets stuck while establishing the connection or during authentication. Include the relevant error lines in your ticket. Never send a private key, password, or a complete log containing sensitive paths.

SSH works well for command-line builds. For initial checks of the graphical setup, Keychain permissions, or Xcode configuration, Remote Desktop is often easier to work with.

First, confirm which Xcode version the project requires. Check the active toolchain with xcodebuild -version and xcode-select -p. After installing or switching versions, complete any first-launch setup in the graphical interface before running your build script.

Signing assets must be provided with the customer's authorisation. Import the signing certificate into the Keychain used by the project, then check that it includes the matching private key, is still valid, and matches the team, Bundle Identifier, and export method in the provisioning profile.

If compilation succeeds but export fails, keep the Archive and export errors separate. Try validating the process in Xcode before adding automation. Re-running the whole pipeline won't help if the signing assets haven't been verified.

Sync your code and dependency lockfiles to the cloud Mac. Start by checking the iOS toolchain with flutter doctor -v, then run flutter pub get. The team should use the Flutter version specified by the project; avoid upgrading dependencies just before delivery.

After configuring the Xcode project and signing, run flutter build ipa. If the error occurs while installing dependencies, resolve that first. If it points to signing or a provisioning profile, review the signing configuration instead; fetching dependencies again usually won't fix it.

When the build succeeds, export the IPA and any required symbol files, and confirm which commit was used. You can continue day-to-day development on Windows; the final iOS build and signing must be completed on a Mac.

Pin the Node.js, package manager, and project dependency versions, then install the iOS dependencies as described in the repository. If the project uses CocoaPods, open the corresponding workspace rather than the standalone project file.

In Xcode, select the correct Scheme and Release configuration, then run Archive. Check whether the failure is in JavaScript bundling, native dependency compilation, or signing and export. A local debug server used in development does not mean the release bundle already contains all required assets.

In your ticket, include the failing stage, the first relevant error, and the tool versions. Errors in application code or third-party dependencies need to be fixed by the project team using the source code. Our support team can help investigate machine connectivity and environment issues.

For parallel client work where clear separation matters, rent a separate dedicated physical machine for each client. Match each machine ID to its repository, Keychain, and delivery date, and avoid build queues on a shared machine.

For a small project that needs an occasional build, you can rent one machine by the day and rotate it between projects. At a minimum, keep local user accounts, code directories, and signing assets separate. This can make work easier to manage, but it is not the same as using separate physical machines.

A dedicated machine is assigned to one rental customer; it does not automatically isolate every project within that customer's studio. If client contracts specify data boundaries, confirm those requirements before deciding whether to share a machine or use separate ones.

In the control panel, open the relevant instance's order or subscription management page to check its expiry date and renewal options. Confirm the machine and rental period before paying. Don't rely on a machine note alone, or you may renew the wrong customer's project.

Your service stops at expiry if you don't renew, with no cancellation fee. Submitting a payment doesn't mean the rental has been extended; check the payment result and updated expiry date in the control panel. If you need to keep working, confirm the renewal before the current rental ends.

We accept USDT-TRC20 and Visa / Mastercard / Amex (via Stripe) only. All payments are settled in US dollars (USD). The payment options available for your transaction are determined by the response from the payment gateway.

If your payment status hasn't updated, find the relevant bill in the control panel and check the order number, amount, and gateway result. For USDT-TRC20 payments, verify the network and receiving details shown on the page. Don't make repeated payments to try to refresh the status.

Invoices and billing details are available in the control panel. If you need help, include the bill number in your ticket. For on-chain payments, you can include the transaction hash. Never send your full card number or security code.